Packer令和あけましておめでとうございます。本記事は、「Ansibleによってサーバをデプロイした後、マシンイメージを作成するフローの自動化」の第二回です。導入に伴い、AnsibleとPackerを用いて、最新デプロイを反映したマシンイメージ(AMI)を作成するフローを自動化します。Ansibleを用いた構成管理についてまとめました。今回は、このAnsibleで管理される設定を反映したAMIを生成する処理についてまとめます。Ansibleを用いて、デプロイとAMI生成を連続して実行します。IaaSや仮想環境にマシンイメージを自動生成してくれるコマンドラインツールなのですが、構成管理ツールと連携したプロビジョニング機能を備えているのが特徴です。そのため、前記事で作成したAnsibleをそのまま利用して、マシンイメージを作成することができます。1.3.5サーバ構成4種類の異なるロールを持つサーバがあります。サーバ環境は2種類用意されています。バックグラウンド処理を非同期に担うサーバ。バックグラウンド処理を非同期に担うサーバ。動作イメージサーバへのデプロイでは、下記のansible-playbookコマンドを実行します。引数にてロールとステージを与えることで、対象のサーバを特定しています。"server_role=web"このコマンドによって、下記2つのAnsiblePlaybookが実行されます。達成するAnsiblePlaybookについて記述します。最終的には、8種類のサーバに準じた、8種類のAMIが作成されます。batch.yml設定について概念図ポイントSSH接続について(1)では、インベントリファイルが用いられます。Buildersの設定が用いられます。(1)で使用されたインベントリファイルは参照されません。動的な環境設定は、すべてグループで管理します。定義したグループを、Packerでも用います。group_varsを参照するため、インベントリディレクトリ(inventory_dir)にgroup_varsと同階層を指定するようにします。サーバごとに固定のAMI名を定義し、定義されたAMI名を持つAMIを、最新と定義しています。これにより、後続処理にて最新のAMIを検索する機会が削減されました。バックアップは別名称で保持します。AMI名は、グループ名から動的に生成されるようにしました。以上を踏まえ、各ファイルについて説明していきます。localhostで実行します。インベントリファイルへの設定は不要です。用いて、(1)で用いたインベントリファイルを指定しています。localhostで実行します。既存AMIをソースAMIとして用いるため、コピーしてリネームすることでバックアップとします。(1)と同一のパスが格納されています。そのため、このplaybookはgroup_varsを参照することができます。buildに与えるグループ名は、下記に定義したものを参照しています。production...ステージ名を持つstage変数を定義しています。}]}SSH接続設定が(1)とは異なることに注意します。Template内に、接続先のVPC、サブネット、セキュリティグループを定義します。ローカルから接続するため、接続先はパブリックサブネットである必要があります。ソースAMIと同一の名称でAMIを作成します。force_deregisterオプションは、AMI名が重複した場合、重複するAMIを削除します。このオプションによって、既存AMIを擬似的に上書きすることができます。AMI名は同一ですが、AMIIDが変わることに注意が必要です。ソースとする既存AMIが存在しない場合、Amazon公式イメージから新規作成することもできます。AmazonLinux2の場合、下記のように設定します。},PackerのプロビジョニングにてAnsibleを実行する際は、group_varsが参照されるようにします。プロビジョニングに使用される一時的なインベントリファイルは、デフォルトではシステム固有の一時ファイル置き場に置かれてしまうので、group_varsが参照できなくなってしまいます。inventory_directoryオプションにルートディレクトリを指定します。(1)で利用したinventory_dirを引数で与えることで、(1)と同一のAnsible構成を利用することができます。(1)で作成したインベントリファイルが参照されないため、グループは未定義の状態です。デプロイに必要なグループをgroupsオプションに与えます。packer_varsPackerで用いる動的な変数も、前記事で定義したAnsibleのグループで管理できるようにしました。(1)で参照したグループをそのまま(2)に与え、変数はグループ単位でファイルにまとめて読み込むことで、管理を容易にしています。}}/ansible_remote/update.template各変数ファイルを見ていきます。common.json共通設定ファイルです。AMI名のプリフィックスや、AWSクレデンシャル情報など、すべての環境において用いる変数を定義しています。"<aws_secret_key>"}[stage].jsonステージごとの設定ファイルです。VPCやサブネット、セキュリティグループなど、ステージ(環境)の設定を定義しています。"security_group_id":"sg-a1b2c3d4e5f6g7h8i9j0"}[server_role].json「ロール」ごとの設定ファイルです。インスタンスタイプやアタッチするボリュームのサイズなど、インスタンスの設定を定義しています。現状、後処理として下記を手動実行しており、このままではまだ完全なる自動化とは言い難いところです。ansible_remote/update.ymlに下記の処理を追加したいです。AutoScalingの起動テンプレートに、作成した最新のAMIを設定する処理どんどん溜まっていくAMIバックアップの過去分を削除する処理AMI削除と同時にスナップショットも削除する処理AWSのクレデンシャルをベタ書きで管理しているため、IAMロールを利用したいです。参考にしたサイト下記サイトを大変参考にさせていただきました。ありがとうございます!Packer+AnsibleによるAMIの作成PackerのAnsibleProvisionerでインベントリ毎のgroup_varsを使い分ける最後にこの記事の作成に多大にご協力いただいた足立さん、AnsibleやPackerについて随時情報を提供してくださった植垣さん、Ansibleのレビューをしてくださった奥村さん、本当にありがとうございました。playbookでのroleごとのユーザ切替を試すこんにちは、インフラ担当の天津です。ブログのタイトルで(Autoscal...2019-06-21AnsibleとShellでALBのTargetGroupのWebサーバのデーモンを再起動するこんにちは。本日は、AnsibleとShellでAL...2019-04-12公式ベストプラクティスを参考に、Ansibleを1から学んでつくってみました初めまして。社会人歴は長いのですがSE歴は短く、そ...2017-08-10ansibleでディスクを拡張してみるこんにちは。(1)ABOUT株式会社アドウェイズのエンジニアによるブログです!このブログでは、アドウェイズのエンジニアがざっくばらんに技術のことや日常生活について書いていきますので、みなさんよろしくお願いいたします。アドウェイズ中途採用情報スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。