PackerでAWS AMIを自動で作成する - ぺい
AWS AMIの管理は面倒 AWSでEC2（IaaS）使ったアプリケーションを構築する時に、AMIの管理が地味に面倒です。例えば、AWS側から提供されているAMIをそのまま使うと、OSがデフォルトに近い状態なので、アプリケーションの実行に必要なものを準備する必要があります。 そこで、実行するために必要な準備を完了させているAMIを作成して、それを使ってインスタンスを作成して、アプリケーションコードを反映するだけで、すぐに使える状態にするということをします。 ただ、これをするのが地味に面倒です。やり方とかは以下の記事に詳しくあります。 tikasan.hatenablog.com ざっくりいうと、出来上がってるインスタンスからスナップショットを作成して、スナップショットからAMIを作成して、AMIを使ってインスタンスを作成するという手順を踏む必要があります。 これらを自動でやってくれるのが、
AWS CodeBuild と HashiCorp Packer を用いた AMI ビルダーの構築方法 | Amazon Web Services
Amazon Web Services ブログ AWS CodeBuild と HashiCorp Packer を用いた AMI ビルダーの構築方法 独自の アマゾン マシン イメージ を作成し維持することは、運用とセキュリティにおけるベストプラクティスです。インフラストラクチャをコードとして維持することもまたベストプラクティスの1つです。そのため、Amazon EC2 インスタンスを素早く起動するために AMI を作成し設定する、といったことをスクリプト化するための自動化ツールを利用することには価値があります。 公開する2つの記事の最初にあたるこの記事では、AWS においてプログラマブルに AMI を作成するために AWS CodeBuild を使用します。AMI 生成の一部として、OS のパッチを適用し、バナーステートメントを設定し、よく使うソフトのいくつかをインストールし、将来的な
Applibotでのサーバイメージ作成 – Packer+Ansible -（AWS AMI編）
HOME ブログ インフラ , サーバー Applibotでのサーバイメージ作成 – Packer+Ansible -（AWS AMI編） こんにちは。 インフラチームです。 弊社ではAWS/GCPを使用しており、それぞれのサーバ構築/環境設定はAnsibleで行なっています。 環境の設定の更新を行う場合、AWSであればAMI、GCPであればマシンイメージを更新しておく必要があります。 ゴールデンイメージ（起動してからの設定更新を行わない、最新設定のイメージ）で管理しているのですが、 そのイメージを更新しようとする場合、手動対応では下記手順が必要になります。 一つ一つは大したことない作業ですが、毎回この手順では手間も待ち時間も多く、ミスが発生しやすかったです。 起動対象のイメージを間違えたり、 他の作業している間に起動したことすら忘れてたり、 イメージ取得後のインスタンス消し忘れなんかもよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fixing Ansible error: "SSH Error: data could not be sent to remote host "127.0.0.1". Make sure this host can be reached over ssh"
