サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ノーベル賞
qiita.com/f96q
はじめに AWS Fargateの場合、トラブルがあった時に動かしてるコンテナの中に入ってなくて調査できないのが不便なのでコンテナに入る方法を調査した。 現時点(2020年9月)でAWS Fargateの独自機能でコンテナの中に入る方法はない コンテナにsshdをインストールする方法とssm-agentをインストールする方法がある ssm-agentを使うとSSHのポートの開放やSSHする公開鍵の管理などをしなくて済むためssm-agentを使う方法で行った。 コンテナにsshdをインストールする方法 SSHのポートを空けておく コンテナの中の~/.ssh/authorzied_keysにsshするユーザーの公開鍵を追加しておく コンテナの中にsshdをインストールしておいて、コンテナ起動時にsshdを立ち上げておく メリット セッションマネージャーを使わないため、セッションマネージャーを
はじめに 普段EC2でサーバーを運用していて、スポットインスタンスを使うことで約1/4の料金で利用できてる。 スポットインスタンスについて 基本的にオンデマンドインスタンスに比べてかなり安いがオンデマンドインスタンスより値段が高くなる場合もある 設定した最高価格の値段より高くなった時にデフォルトの動作だとインスタンスが削除される 停止にする設定もある。 容量が指定料金内で利用不可能になりイベントが中断された場合に、Amazon EC2 スポットで Amazon EBS-backed インスタンスを終了する代わりに、それを停止することが可能になりました。 同じインスタンスタイプでもavailability zoneで値段が違う 上位のインスタンスタイプのほうが安くなる場合もある 最高価格 スポットインスタンスをリクエストするときは、デフォルトの上限料金 (オンデマンド料金) を使用することを
qiita.com/f96q@github
Terraform AWSのインフラ構成はTerraform管理してる. tfstateを分割する tfstateが1つのままだと、Terraformのresourceを増やしていったときに 頻繁に更新するresourceとそうでもないものがある 適応するのに時間が掛かる エラーの切り分けしずらくなる ということからtfstateを分割してる。 ただ分割しすぎると、適応漏れや適応順番が複雑になるので2つに分割してる。 . ├── environments │ ├── immutable │ │ ├── backend.tf │ │ ├── main.tf │ │ ├── provider.tf │ │ └── variable.tf │ └── mutable │ ├── backend.tf │ ├── main.tf │ ├── ou
.bundle log tmp node_modules yarn-error.log .byebug_history app/assets/javascripts/bundle.js config/database.yml .env .env.app .env.db .git FROM alpine:3.7 ENV RAILS_ENV="production" \ NODE_ENV="production" \ NPM_CONFIG_PRODUCTION="false" \ RUNTIME_PACKAGES="bash ruby ruby-irb ruby-json ruby-rake ruby-bigdecimal ruby-io-console ruby-dev nodejs yarn libxml2-dev libxslt-dev mariadb-client-libs tzdat
方針 playbook.ymlを一つ実行すれば環境構築が済むようにする 以前はChef Solo + Berkshelfで開発環境構築を行っていたが、以下のようなことが手間になりAnsibleに移行した。 レシピを実行できる環境を作るまでが手間 レシピのソースを読まないとカスタマイズがしずらいのと、どう動いてるかが分かりづらい Vagrant + VirtualBoxで動かす 最近は開発環境にDockerを使うという選択肢もあるが、init.dやsystemdで起動するものがapt-get installしただけだと動かなくて別途設定が必要なこともありVirtualBoxを使っている。 Vagrantの場合に以下のように設定を追加しておくと、初回にvagrant upした時にansibleが実行されるので便利。 Vagrant.configure(2) do |config| config
バックエンド 設定関係 settingslogic使うのやめて、最近のRailsだと標準で使えるconfig.xを使う。 S3に画像アップロード carrierwave + fogの構成だとawsのAPI叩くのをfog-awsで独自実装していて、carrierwave-awsだとaws本家が作ってるaws-sdkを使っているので、fog使うよりcarrierwave-awsを使うのがお薦め。 テスト rspec-rails factory_girl_rails capybara poltergeist database_rewinder よく使うのはこの構成。 DBの不整合を防ぐのにやること 外部キー制約 not null制約 unique制約 アプリケーションレイヤーのバリデーションだけだと、正しくバリデーションされないケースがあってdbの機能も使ったほうがいい。 中間テーブルの命名規則
自分が趣味で開発しているKPTBoardをRailsの4系からRailsの5.0.0.beta1にアップデートした時に引っかかった点で他のアプリでもアップデートする時にありそうなことを書きます。 deviseとcapybaraはgithubのmasterブランチから取得しないと動かなかった gem 'devise', github: 'plataformatec/devise' gem 'capybara', github: 'jnicklas/capybara'
このページを最初にブックマークしてみませんか?
『qiita.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く