Itamaeを採用するにあたって、mitamaeも候補にあったのですが今回は、移行スケジュール的にmitamaeを検証する余裕があまりなかったこと、また対応pluginがItamaeの方が豊富なことからmitamaeは使わずに、Itamaeを採用することにしました。Code化を進める中で迷ったのがItamaeの実行に関する以下のような問題です。どのサーバーからItamaeを実行するのかRailsのsecret_key_baseやDB接続のためのパスワードなどの秘匿情報をどうやって設置するかItamae初回実行前にレシピをどのように実行サーバーに設置するかそれぞれ解説していきます。sshの2つがあります。本番環境で利用するサーバーに対して実行することを想定すると、Itamae実行ユーザーに対してできるだけ大きな権限を渡したくないです。sshを利用する場合、Itamae実行対象であるリモートホストにssh可能なユーザーに対して任意のコマンドを実行可能なroot権限を渡すことになります。localコマンド実行を許可するだけで済みます。localの方が実行が高速。いった背景もあります。localの実行方式を採用しました。itamae-secretsを使って管理しています。itamae-secretsを使えば開発者が複数いる場合も、暗号化に使った秘密鍵を共有するだけで手元のマシンで秘匿情報を複合することができます。dotenvが比較されますが、公式で本番環境に利用するのを推奨していないため今回はitamae-secretsを採用するに至りました。localを実行するためにはレシピをサーバーに設置しておく必要があります。keyが存在しないため、秘密鍵を設置する必要があります。localで実行したい秘密鍵などの秘匿情報を設置したいという動機が生まれました。ユーザーデータとパラメータストアを利用する方法です。以下のような手順でインスタンス起動時に自動でItamaeレシピを適用しています。実際にユーザーデータで使用しているシェルスクリプトは以下のようなものです。localする権限を付与すればいいだけなので不用意に任意のコマンドを実行できる権限を与える心配が少なくなります。まとめイエウールではこうしてインフラ群の構成管理をしています。Route53などの設定はCloudFormation利用前から存在したリソースなため、まだコードで管理するに至っていません。現在、roadworkerなどのツールを使ってコードで管理できるよう計画中です。一度に全てを理想形にすることは難しいですが、ひとつずつ理想に近づけていければと思っています。2018に行ってきました!こんにちは。開発基盤ユニットの@selmertsxです。新卒エンジニアの中嶋です。エンジニアのDuenoです。今回はWebCo...2016-07-15Speeeの新卒エンジニア研修についてはじめまして。参加してきました月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。