翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# カスタム AMI の使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは、カスタム [Amazon マシンイメージ (AMIs) ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)と Chef レシピの 2 つの方法でインスタンスをカスタマイズできます。どちらのアプローチでも、インストールするパッケージおよびパッケージバージョンの種類や設定方法などをコントロールできます。ただし、それぞれの利点は異なるため、どちらが最適であるかは要件によって変わります。
カスタム AMI の使用を検討する必要がある主な状況は、次のとおりです。
+ インスタンスの起動後に特定のパッケージをインストールするのではなく、特定のパッケージを事前にバンドルする場合。
+ レイヤーに一貫したベースイメージを提供するようにパッケージ更新のタイミングを管理する場合。
+ インスタンス (特に[負荷ベース](workinginstances-autoscaling.md)のインスタンス) を迅速に起動する場合。
Chef レシピの使用を検討すべき主な場合は、次のとおりです。
+ カスタム AMI より柔軟性が高い場合。
+ 更新が容易な場合。
+ 実行中のインスタンスで更新を実行できる場合。
現実的には、両方の手法を組み合わせることが最適なソリューションと考えることもできます。recipe の詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。
**Topics**
+ [カスタム AMIs と OpsWorks スタックの連携方法](#workinginstances-custom-ami-work)
+ [スタック用のカスタム AMI OpsWorks の作成](#workinginstances-custom-ami-create)
## カスタム AMIs と OpsWorks スタックの連携方法
インスタンスのカスタム AMI を指定するには、新しいインスタンスを作成するときにインスタンスのオペレーティングシステムとして**カスタム AMI を使用する**を選択します。 OpsWorks スタックは、スタックのリージョンにあるカスタム AMIs のリストを表示し、リストから適切なものを選択します。詳細については、「[レイヤーへのインスタンスの追加](workinginstances-add.md)」を参照してください。
**注記**
スタックのデフォルトオペレーティングシステムとして特定のカスタム AMI を指定することはできません。スタックのデフォルトオペレーティングシステムとして `Use custom AMI` を設定できますが、特定の AMI を指定できるのは、新しいインスタンスをレイヤーに追加するときのみです。詳細については、「[レイヤーへのインスタンスの追加](workinginstances-add.md)」および「[新しいスタックを作成する](workingstacks-creating.md)」を参照してください。カスタム AMI またはコミュニティで作成された AMI から作成された他のオペレーティングシステム (CentOS 6.*x* など) を使用してインスタンスを作成できる場合もありますが、そのような方法は公式にはサポートされていません。
このトピックでは、カスタム AMI を作成または使用する前に考慮する必要がある一般的な問題について説明します。
**Topics**
+ [開始時の動作](#workinginstances-custom-ami-work-startup)
+ [レイヤーの選択](#workinginstances-custom-ami-work-layer)
+ [アプリケーションの処理](#workinginstances-custom-ami-work-apps)
### 開始時の動作
インスタンスを起動すると、 OpsWorks Stacks は指定されたカスタム AMI を使用して新しい Amazon EC2 インスタンスを起動します。その後、 OpsWorks Stacks は [cloud-init](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonLinuxAMIBasics.html#included-aws-command-line-tools) を使用してインスタンスに OpsWorks Stacks エージェントをインストールし、エージェントはインスタンスの Setup レシピと Deploy レシピを実行します。インスタンスがオンラインになると、エージェントは新しく追加されたインスタンスを含め、スタックのすべてのインスタンスに対して Configure レシピを実行します。
### レイヤーの選択
OpsWorks スタックエージェントは通常、インストールされているパッケージと競合しません。ただし、インスタンスは少なくとも 1 つの Layer のメンバーである必要があります。 OpsWorks スタックは常にその Layer のレシピを実行するため、問題が発生する可能性があります。カスタム AMI を持つインスタンスをそのレイヤーに追加する前に、レイヤーのレシピによるインスタンスへの操作について正確に理解する必要があります。
インスタンスでレイヤータイプ別に実行されるレシピを確認するには、そのレイヤーを含むスタックを開きます。次に、ナビゲーションペインの [**Layers**] (レイヤー) をクリックし、目的のレイヤーの [**Recipes**] (レシピ) をクリックします。実際のコードを表示するには、レシピの名前をクリックします。
**注記**
Linux AMIs の場合、競合の可能性を減らす方法の 1 つは、 OpsWorks スタックを使用して、カスタム AMI の基礎となるインスタンスをプロビジョニングおよび設定することです。詳細については、「[スタックインスタンスからカスタム Linux AMI OpsWorks を作成する](#workinginstances-custom-ami-create-opsworks)」を参照してください。
### アプリケーションの処理
パッケージに加えて、AMI にアプリケーションを含めたい場合もあります。大規模で複雑なアプリケーションがある場合、AMI に含めると、インスタンスの起動時間を短縮できます。AMI に小さなアプリケーションを含めることはできますが、通常、 OpsWorks スタックによるアプリケーションのデプロイと比べて、時間上の利点はほとんどまたはまったくありません。
1 つのオプションは、アプリケーションを AMI に含めると共に、リポジトリからインスタンスにアプリケーションをデプロイする[アプリケーションを作成](workingapps-creating.md)することです。このアプローチでは、起動時間が短縮されるだけでなく、インスタンスの実行後にアプリケーションを更新する際に便利な方法を使用できます。Chef レシピはべき等であるため、リポジトリのバージョンがインスタンスのバージョンと同じである限り、デプロイレシピはアプリケーションを変更しません。
## スタック用のカスタム AMI OpsWorks の作成
スタックでカスタム AMI OpsWorks を使用するには、まずカスタマイズされたインスタンスから AMI を作成する必要があります。2 つのオプションから選択できます。
+ Amazon EC2 コンソールまたは API を使用して、[OpsWorks スタック対応 AMI](workinginstances-os.md) のいずれかの 64 ビット版に基づくインスタンスを作成およびカスタマイズします。
+ Linux AMI では、OpsWorks を使用して、関連するレイヤーの設定に基づく Amazon EC2 インスタンスを作成します。
カスタム Linux AMI を作成する前に、`/tmp`パーティション`noexec`で を無効にして、スタックがカスタム Linux OpsWorks インスタンスにエージェントをインストールできるようにします。
**注記**
AMI はすべてのインスタンスタイプに対応している訳ではないことにご注意ください。開始する AMI が、使用するインスタンスタイプと互換性があることを確認してください。特に、[R3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/r3-instances.html) インスタンスタイプには、ハードウェアアシストによる仮想化（HVM）AMI が必要です。
次に Amazon EC2 コンソールまたは API を使用して、カスタマイズしたインスタンスからカスタム AMI を作成します。インスタンスをレイヤーに追加し、カスタム AMI を指定することで、同じリージョンのすべてのスタックでカスタム AMI を使用できます。カスタム AMI を使用するインスタンスの作成方法の詳細については、「[レイヤーへのインスタンスの追加](workinginstances-add.md)」を参照してください。
**注記**
デフォルトでは、 OpsWorks スタックは起動時にすべての Amazon Linux 更新プログラムをインストールします。これにより、最新のリリースが提供されます。また Amazon Linux は新しいバージョンを約 6 か月ごとにリリースしており、大きな変更が実施される場合もあります。デフォルトで、Amazon Linux に基づくカスタム AMI は、新しいバージョンがリリースされると自動的に更新されます。カスタム AMI は特定の Amazon Linux バージョンにロックしておき、新しいバージョンをテストするまで更新を延期できるようにすることをお勧めします。詳細については、「[AMI を特定のバージョンに固定するにはどうすればよいですか?](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)」を参照してください。
**Topics**
+ [Amazon EC2 を使用したカスタム AMI の作成](#workinginstances-custom-ami-create-ec2)
+ [スタックインスタンスからカスタム Linux AMI OpsWorks を作成する](#workinginstances-custom-ami-create-opsworks)
+ [カスタム Windows AMI の作成](#w2ab1c14c55c15c13c21c20)
### Amazon EC2 を使用したカスタム AMI の作成
カスタム AMI を作成する最も簡単な方法 (Windows AMI の唯一のオプション) は、Amazon EC2 コンソールまたは API を使用してタスク全体を実行することです。次のステップの詳細については、[[独自の AMI の作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami.html)] を参照してください。
**Amazon EC2 コンソールまたは API を使用してカスタム AMI を作成するには**
1. [いずれかのOpsWorks スタック対応 AMI](workinginstances-os.md) の 64 ビット版を使用してインスタンスを作成します。
1. インスタンスを設定し、パッケージをインストールするなどして、ステップ 1 からインスタンスをカスタマイズします。インストールしたものすべてが、AMI に基づいてすべてのインスタンス上で再現されるため、特定のインスタンスに固有の項目は含めないでください。
1. インスタンスを停止し、カスタム AMI を作成します。
### スタックインスタンスからカスタム Linux AMI OpsWorks を作成する
カスタマイズされた Stacks Linux OpsWorks インスタンスを使用して AMI を作成するには、OpsWorks によって作成されたすべての Amazon EC2 インスタンスに一意の ID が含まれていることに注意してください。このようなインスタンスからカスタム AMI を作成した場合、その ID が含まれ、AMI に基づくすべてのインスタンスが同じ ID を持つことになります。カスタム AMI に基づくインスタンスが確実に固有の ID を得るには、AMI を作成する前に、カスタマイズしたインスタンスから ID を削除する必要があります。
**スタックインスタンスからカスタム AMI OpsWorks を作成するには**
1. [Linux スタックを作成](workingstacks-creating.md)し、[1 つ以上のレイヤーを追加](workinglayers-basics-create.md)して、カスタマイズしたインスタンスの設定を定義します。組み込みレイヤー、完全なカスタムレイヤーに加え、必要に応じてカスタマイズしたレイヤーを使用できます。詳細については、「[OpsWorks スタックのカスタマイズ](customizing.md)」を参照してください。
1. [レイヤーを編集](workinglayers-basics-edit.md)し、自動ヒーリングを無効にします。
1. [任意の Linux ディストリビューションを使用してインスタンスを](workinginstances-add.md)レイヤーに追加し、[起動します](workinginstances-starting.md)。Amazon EBS-backed インスタンスの使用をお勧めします。インスタンスの詳細ページを開き、後で使用できるよう Amazon EC2 ID を記録します。
1. インスタンスがオンラインである場合は、[SSH でログイン](workinginstances-ssh.md)し、インスタンスのオペレーティングシステムに応じて次の 4 つのステップのいずれかを実行します。
1. Chef 11 または Chef 12 スタックの Amazon Linux インスタンス、または Chef 11 スタックの Red Hat Enterprise Linux 7 インスタンスの場合、次を実行します。
1. `sudo /etc/init.d/monit stop`
1. `sudo /etc/init.d/opsworks-agent stop`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef`
**注記**
Chef 12 スタックのインスタンスについて、このコマンドに次の 2 つのフォルダを追加します。
`/var/chef`
`/opt/chef`
1. `sudo rpm -e opsworks-agent-ruby`
1. `sudo rpm -e chef`
1. Chef 12 スタックの Ubuntu 16.04 LTS または 18.04 LTS インスタンスでは、次を実行します。
1. `sudo systemctl stop opsworks-agent`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef`
1. `sudo apt-get -y remove chef`
1. `sudo dpkg -r opsworks-agent-ruby`
1. `systemctl stop apt-daily.timer`
1. `systemctl stop apt-daily-upgrade.timer`
1. `rm /var/lib/systemd/timers/stamp-apt-daily.timer`
1. `rm /var/lib/systemd/timers/stamp-apt-daily-upgrade.timer`
1. Chef 12 スタックの他のサポートされている Ubuntu バージョンでは、次を実行します。
1. `sudo /etc/init.d/monit stop`
1. `sudo /etc/init.d/opsworks-agent stop`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef`
1. `sudo apt-get -y remove chef`
1. `sudo dpkg -r opsworks-agent-ruby`
1. Chef 12 スタックの Red Hat Enterprise Linux 7 インスタンスの場合は、次を実行します。
1. `sudo systemctl stop opsworks-agent`
1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef /var/chef`
1. `sudo rpm -e opsworks-agent-ruby`
1. `sudo rpm -e chef`
1. このステップは、インスタンスタイプによって異なります。
+ Amazon EBS-backed インスタンスの場合は、「Amazon EBS-Backed Linux AMI の作成」の説明に従って OpsWorks 、 スタックコンソールを使用して[インスタンスを停止](workinginstances-starting.md)し、AMI を作成します。 [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)
+ instance store-backed インスタンスの場合は、[「Instance Store-Backed Linux AMI の作成」の説明に従って AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-instance-store.html) を作成し、 OpsWorks スタックコンソールを使用してインスタンスを停止します。
AMI を作成する際は、必ず証明書ファイルを含めます。例えば、`-i` 引数を `-i $(find /etc /usr /opt -name '*.pem' -o -name '*.crt' -o -name '*.gpg' | tr '\n' ',')` に設定して [https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html) コマンドを呼び出すことができます。バンドルするとき、apt パブリックキーを削除しないでください。デフォルトの `ec2-bundle-vol` コマンドがこのタスクを処理します。
1. スタックコンソールに戻り OpsWorks 、スタックから[インスタンスを削除](workinginstances-delete.md)して、スタックをクリーンアップします。
### カスタム Windows AMI の作成
次の手順では、Windows Server 2022 Base 用のカスタム AMI を作成します。Amazon EC2 管理コンソールで、他の Windows Server オペレーティングシステムを選択できます。
**重要**
現在、 OpsWorks スタックエージェントは、**英語 - 米国** (en-US) 以外のシステム UI 言語を使用する Windows ベースのインスタンスにインストールすることはできません。 OpsWorks また、 スタックは管理できません。
**Topics**
+ [`Sysprep` を使用したカスタム Windows AMI の作成](#w2ab1c14c55c15c13c21c20b9)
+ [`Sysprep` を使用しないカスタム Windows AMI の作成](#w2ab1c14c55c15c13c21c20c11)
+ [カスタム Windows AMI を使用した新しいインスタンスの追加](#w2ab1c14c55c15c13c21c20c13)
#### `Sysprep` を使用したカスタム Windows AMI の作成
通常、Sysprep を使用してカスタム Windows AMI を作成するとインスタンスの起動が遅くなりますが、よりクリーンなプロセスとなります。で作成されたイメージから作成されたインスタンスの初回起動`Sysprep`には、`Sysprep`アクティビティ、再起動、 OpsWorks スタックのプロビジョニング、およびセットアップや設定を含む最初の OpsWorks スタックの実行により、時間がかかります。Amazon EC2 コンソールで、カスタム Windows AMI を作成するためのステップを完了します。
**Sysprep でカスタム Windows AMI を作成するには**
1. Amazon EC2 コンソールで、**[Launch Instance** (インスタンスを起動する)] を選択します。
1. [**Microsoft Windows Server 2022 Base**] を見つけて、[**選択**] を選択します。
1. 目的のインスタンスタイプを選択し、[**Configure Instance Details**] を選択します。AMI で、マシン名、ストレージ、セキュリティグループ設定などの設定変更を行います。[**Launch**] (起動する) を選択します。
1. インスタンスのブートプロセスが終了したら、パスワードを使用して、Windows の [**リモートデスクトップ接続**] ウィンドウでインスタンスに接続します。
1. Windowsの **[Start]** (スタート) 画面で **[Start]** (スタート) を選択し、次に **ec2configservice** の入力を開始し、結果に **[EC2ConfigServiceSettings]** コンソールを表示されるまで続けます。 コンソール を開きます。
1. General ****タブで、**Enable UserData execution** チェックボックスがオンになっていることを確認します (このオプションは では必須ではありませんが`Sysprep`、 OpsWorks スタックがエージェントをインストールするために必要です）。[**Set the computer name of the instance...**] (インスタンスのコンピュータ名の設定...) オプションのチェックボックスをオフにします。このオプションをオンにすると、 OpsWorks スタックで再起動が繰り返されることがあるためです。
1. **[Image]** (イメージ) タブで、**[Administrator Password]** (管理者パスワード) を、Amazon EC2 が SSH キーで取得できるパスワードを自動的に生成することを許可する **[Random]** (ランダム)、または自分のパスワードを指定する **[Specify]** (指定) のいずれかに設定します。`Sysprep` はこの設定を保存します。独自のパスワードを指定した場合は、都合の良い場所にパスワードを保存します。[**Keep Existing**] は選択しないことをお勧めします。
1. [**Apply**] を選択し、[**Shutdown with Sysprep**] を選択します。確認を求められたら、[**Yes**] を選択します。
1. インスタンスが停止したら、Amazon EC2 コンソールで **[インスタンス]** リストのインスタンスを右クリックし、**[イメージ]** を選択して、**[イメージの作成]** を選択します。
1. [**Create Image**] ページで、イメージの名前と説明を指定し、ボリュームの設定を指定します。終了したら、[**Create Image**] を選択します。
1. [**Images**] ページを開き、イメージが [**pending**] 段階から [**available**] に変わるのを待ちます。新しい AMI を使用する準備ができました。
#### `Sysprep` を使用しないカスタム Windows AMI の作成
Amazon EC2 コンソールで、カスタム Windows AMI を作成するためのステップを完了します。
**Sysprep なしでカスタム Windows AMI を作成するには**
1. Amazon EC2 コンソールで、**[Launch Instance]** (インスタンスを起動する) を選択します。
1. [**Microsoft Windows Server 2022 Base**] を見つけて、[**選択**] を選択します。
1. 目的のインスタンスタイプを選択し、[**Configure Instance Details**] を選択します。AMI で、マシン名、ストレージ、セキュリティグループ設定などの設定変更を行います。[**Launch**] (起動する) を選択します。
1. インスタンスのブートプロセスが終了したら、パスワードを使用して、Windows の [**リモートデスクトップ接続**] ウィンドウでインスタンスに接続します。
1. インスタンスで、`C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml` を開き、次の 2 つの設定を変更してから、ファイルを保存して閉じます。
+ `Ec2SetPassword`～`Enabled`
+ `Ec2HandleUserData`～`Enabled`
1. **リモートデスクトップ**セッションからの接続を切り、Amazon EC2 コンソールに戻ります。
1. [**Instances**] リストで、インスタンスを停止します。
1. インスタンスが停止したら、コンソールで **[Instances]** (インスタンス) リストのインスタンスを右クリックし、**[Image]** (イメージ) を選択して、**[Create Image]** (イメージの作成) を選択します。
1. [**Create Image**] ページで、イメージの名前と説明を指定し、ボリュームの設定を指定します。終了したら、[**Create Image**] を選択します。
1. [**Images**] ページを開き、イメージが [**pending**] 段階から [**available**] に変わるのを待ちます。新しい AMI を使用する準備ができました。
#### カスタム Windows AMI を使用した新しいインスタンスの追加
イメージが [**available**] 状態に変わったら、カスタム Windows AMI に基づいて新しいインスタンスを作成できます。**[Operating system]** (オペレーティングシステム) のリストから **[Use custom Windows AMI]** (カスタム Window AMI を使用する) を選択すると、 OpsWorks Stacks はカスタム AMI のリストを表示します。
**カスタム Windows AMI に基づいて新しいインスタンスを追加するには**
1. 新しい AMI が利用可能になったら、 OpsWorks スタックコンソールに移動し、Windows **スタックのインスタンス**ページを開き、ページの下部にある **\$1 インスタンス**を選択して新しいインスタンスを追加します。
1. [**New**] タブの [**Advanced**] を選択します。
1. [**Operating system**] ドロップダウンリストで、[**Use custom Windows AMI**] を選択します。
1. [**Custom AMI**] ドロップダウンリストで、作成した AMI を選択し、[**Add Instance**] を選択します。
これで、インスタンスを起動して実行できるようになりました。