この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。 SRE風のインフラエンジニア SREとDevOps そもそもDevOpsとは SRE本でも取り上げられている、DevとOpsの目的の差異 ミクロなDevの目的 ミクロなOpsの目的 Ops側の視点での安定性の考え方を改める システムを高速に更新可能にしておくことで安定性を担保する インフラエンジニアではなくSREとしてどう高速リリースを実現するか プロダクトの高速リリースに効くところを見極める リリースするにあたっての心配事を潰す 開発チームが自律して動ける仕組みやツールを提供する 今の組織でやれていること 開発チーム出身の人がSREチームにジョインしてくれている SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている SREチームのケツを叩い

ECSのTaskの実行について APIアクセスによるTaskの実行 困ること API経由でのTaskの実行は非同期で行われる で、何が困るか？ 同期的に実行できるようなコマンドを作った 今後 ECSのTaskの実行について ECSにはServiceとTaskという二つのコンテナの実行方法がある。 Serviceは主にwebサーバーなどに代表されるような常に一定数のコンテナを保つように管理されるもので、Taskの方は一回実行したらそれっきりで終了するバッチ的な利用を想定されている。 APIアクセスによるTaskの実行 awscliやecs-cliによりこのTaskはAPI経由で実行することができる。 awscliであればこんな感じ。 aws ecs run-task --cluster default --task-definition sleep360:1 困ること API経由でのTask

Dockerfileをどこに置いて誰が管理するのが良いのか？という話 Dockerを導入する前の構成 Docker導入初期 中央管理により発生する問題 Dockerfileの多様化 インフラ作業が律速になる可能性 アプリエンジニアのDocker知識がつかない アプリケーションのレポジトリに置くことにする デメリット 各自が自由にできるので、、、 重複部分が生まれる 一斉に編集できない 今後 まとめ Dockerfileをどこに置いて誰が管理するのが良いのか？という話 結論から言うと、各アプリケーションのレポジトリ直下に置いて置けばいいのではないか、と言うのが現状。 そんなん当たり前だろと思った方はそのまま読み飛ばしていただいて、自分の思考の備忘もかねて。 チーム構成とか、開発やデプロイで使っているツールとか、アプリケーションの数でこの辺りの判断は変化しそうだけど、自分がインフラエンジニアの

Docker imageを小さくする RailsのDockerイメージ 現状のDockerイメージ rbenvのinstallとrubyのinstallが無駄ではないか？ ruby-alpineに変えてみる 結局何がサイズを大きくしてんの？？ Multi-Stage Buildsを使おう OSを変える いらなそうなファイルがないか探す とても大事なことに最後に気づく、、、 まとめ ちなみに Docker imageを小さくする Dockerイメージは小さいほど良いです。これは自明です。 プログラムを動かすための必要最低限の実行ファイルがあれば良いのです。 RailsのDockerイメージ そもそもバイナリだけで動くgoみたいな言語と違って、イメージが大きくなりがちなんですが それでも多少は頑張りたいと思い試行錯誤してみる。 現状のDockerイメージ Railsに関係する部分だけが削減対象