翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# OpsWorks スタックインスタンスの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックを使用してインスタンスを作成し、スタックに追加できます。
**Topics**
+ [OpsWorks スタックオペレーティングシステム](workinginstances-os.md)
+ [レイヤーへのインスタンスの追加](workinginstances-add.md)
+ [カスタム AMI の使用](workinginstances-custom-ami.md)
+ [24/7 インスタンスの手動による起動、停止、再起動](workinginstances-starting.md)
+ [時間ベースおよび負荷ベースのインスタンスによる負荷の管理](workinginstances-autoscaling.md)
# OpsWorks スタックオペレーティングシステム
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは、Amazon および Ubuntu Linux ディストリビューション、Microsoft Windows Server など、いくつかの組み込みオペレーティングシステムの 64 ビットバージョンをサポートしています。一般的な注意事項をいくつか示します。
+ スタックのインスタンスは、Linux または Windows を実行できます。
スタックは、インスタンスごとに異なる Linux バージョンまたはディストリビューションを実行できますが、Linux インスタンスと Windows インスタンスを混在させることはできません。
+ [カスタム AMIs](workinginstances-custom-ami.md) (Amazon マシンイメージ) を使用できますが、このセクションのトピックで説明されている OpsWorks スタックがサポートする AMIs のいずれかに基づいている必要があります。カスタム AMI またはコミュニティで作成された AMI から作成された他のオペレーティングシステム (CentOS 6.*x* など) を使用してインスタンスを作成または登録できる場合もありますが、そのような方法は公式にはサポートされていません。
+ [Linux オペレーティングシステム:](workinginstances-os-linux.md)
+ [Microsoft Windows Server](workinginstances-os-windows.md)
+ [インスタンスを手動で開始および停止する](workinginstances-starting.md)ことも、 OpsWorks スタックでインスタンス数を[自動的にスケールする](workinginstances-autoscaling.md)こともできます。
どのスタックでも、時間ベースの自動スケーリングを使用できます。Linux スタックでは、負荷ベースのスケーリングも使用できます。
+ OpsWorks スタックを使用して Amazon EC2 インスタンスを作成するだけでなく、スタックの外部[で作成された Linux スタックにインスタンスを登録](workinginstances-autoscaling.md)することもできます。 OpsWorks
これには、Amazon EC2 インスタンスと、独自のハードウェアを実行するインスタンスが含まれます。ただし、そのインスタンスがサポートされている Linux ディストリビューションの 1 つを実行している必要があります。Amazon EC2 インスタンスまたはオンプレミスの Windows インスタンスを登録することはできません。
OpsWorks Stacks [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html) API を実行して、サポートされているオペレーティングシステムとそのサポートされているバージョンの Chef のリストを返すことができます。以下は AWS CLIを使用したコマンドの例です。
```
aws opsworks describe-operating-systems
```
以下に、応答の例を示します。
```
{
"OperatingSystems": [
{
"Name": "Amazon Linux",
"Id": "Amazon Linux",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2014.03",
"Supported": false
},
{
"Name": "Amazon Linux 2",
"Id": "Amazon Linux 2",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2"
},
{
"Name": "Amazon Linux 2014.09",
"Id": "Amazon Linux 2014.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2014.09",
"Supported": false
},
{
"Name": "Amazon Linux 2015.03",
"Id": "Amazon Linux 2015.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2015.03",
"Supported": false
},
{
"Name": "Amazon Linux 2015.09",
"Id": "Amazon Linux 2015.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2015.09",
"Supported": false
},
{
"Name": "Amazon Linux 2016.03",
"Id": "Amazon Linux 2016.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2016.03"
},
{
"Name": "Amazon Linux 2016.09",
"Id": "Amazon Linux 2016.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2016.09"
},
{
"Name": "Amazon Linux 2017.03",
"Id": "Amazon Linux 2017.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2017.03"
},
{
"Name": "Amazon Linux 2017.09",
"Id": "Amazon Linux 2017.09",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2017.09"
},
{
"Name": "Amazon Linux 2018.03",
"Id": "Amazon Linux 2018.03",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "amazon",
"ReportedVersion": "2018.03"
},
{
"Name": "CentOS Linux 7",
"Id": "CentOS Linux 7",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "CentOS Linux",
"ReportedVersion": "7"
},
{
"Name": "Microsoft Windows Server 2012 R2 Base",
"Id": "Microsoft Windows Server 2012 R2 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Express",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Standard",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2012 R2 with SQL Server Web",
"Id": "Microsoft Windows Server 2012 R2 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2012 r2 standard",
"Supported": false
},
{
"Name": "Microsoft Windows Server 2019 Base",
"Id": "Microsoft Windows Server 2019 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Express",
"Id": "Microsoft Windows Server 2019 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Standard",
"Id": "Microsoft Windows Server 2019 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2019 with SQL Server Web",
"Id": "Microsoft Windows Server 2019 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2019 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 Base",
"Id": "Microsoft Windows Server 2022 Base",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Express",
"Id": "Microsoft Windows Server 2022 with SQL Server Express",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Standard",
"Id": "Microsoft Windows Server 2022 with SQL Server Standard",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Microsoft Windows Server 2022 with SQL Server Web",
"Id": "Microsoft Windows Server 2022 with SQL Server Web",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
],
"ReportedName": "microsoft windows server",
"ReportedVersion": "2022 datacenter"
},
{
"Name": "Red Hat Enterprise Linux 7",
"Id": "Red Hat Enterprise Linux 7",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "Red Hat Enterprise Linux",
"ReportedVersion": "7"
},
{
"Name": "Ubuntu 12.04 LTS",
"Id": "Ubuntu 12.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "12.04",
"Supported": false
},
{
"Name": "Ubuntu 14.04 LTS",
"Id": "Ubuntu 14.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "14.04"
},
{
"Name": "Ubuntu 16.04 LTS",
"Id": "Ubuntu 16.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "16.04"
},
{
"Name": "Ubuntu 18.04 LTS",
"Id": "Ubuntu 18.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "18.04"
},
{
"Name": "Ubuntu 20.04 LTS",
"Id": "Ubuntu 20.04 LTS",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
}
],
"ReportedName": "ubuntu",
"ReportedVersion": "20.04"
},
{
"Name": "Custom",
"Id": "Custom",
"Type": "Linux",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12"
},
{
"Name": "Chef",
"Version": "11.10"
},
{
"Name": "Chef",
"Version": "11.4"
},
{
"Name": "Chef",
"Version": "0.9"
}
]
},
{
"Name": "CustomWindows",
"Id": "CustomWindows",
"Type": "Windows",
"ConfigurationManagers": [
{
"Name": "Chef",
"Version": "12.2"
}
]
}
]
}
```
**Topics**
+ [Linux オペレーティングシステム:](workinginstances-os-linux.md)
+ [Microsoft Windows Server](workinginstances-os-windows.md)
# Linux オペレーティングシステム:
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタックは、次の Linux オペレーティングシステムの 64 ビットバージョンをサポートしています。
+ [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/faqs/) と [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) (現在サポートされているバージョンについては、「[OpsWorks スタックコンソール](https://console.aws.amazon.com/opsworks/)」を参照)
+ [Ubuntu 20.04 LTS](https://wiki.ubuntu.com/FocalFossa/ReleaseNotes)
+ [CentOS 7](https://docs.centos.org/en-US/centos/install-guide/Revision_History/)
+ [Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/)
これらのオペレーティングシステムに基づく[カスタム AMI](workinginstances-custom-ami.md) を使用することもできます。
Linux インスタンスの一般的な注意事項をいくつか示します。
**サポートされているパッケージのバージョン**
Ruby などのパッケージでサポートされているバージョンとパッチレベルは、以下のセクションで説明するようにオペレーティングシステムとバージョンによって異なります。
**更新**
デフォルトでは、 OpsWorks スタックは、インスタンスの起動`apt-get update`後に `yum update` または を自動的に呼び出すことで、Linux インスタンスに最新のセキュリティパッチがあることを保証します。自動更新を無効にするには、[CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html)、[UpdateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html)、[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)、または [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html) のいずれかのアクションを使用するか、同等の [AWS SDK](https://aws.amazon.com/tools/) メソッドまたは [AWS CLI](https://aws.amazon.com/documentation/cli/) コマンドを使用して、`InstallUpdatesOnBoot` パラメータを `false` に設定します。
サービスの中断を避けるため、インスタンスがオンラインになった後、 OpsWorks スタックは自動的に更新をインストールしません。オンラインインスタンスのオペレーティングシステムは、[Upgrade Operating System スタックコマンド](workingstacks-commands.md)を実行することでいつでも手動で更新できます。セキュリティの更新を管理する方法の詳細については、「[セキュリティ更新の管理](workingsecurity-updates.md)」を参照してください。
OpsWorks スタックがインスタンスを更新する方法をより詳細に制御するには、サポートされているオペレーティングシステムのいずれかに基づいてカスタム AMI を作成します。たとえば、カスタム AMI を使用して、インスタンスにインストールするパッケージのバージョンを指定できます。Linux ディストリビューションによってサポートタイムラインとパッケージマージポリシーが異なるため、要件に最適な方法を検討する必要があります。詳細については、「[カスタム AMI の使用](workinginstances-custom-ami.md)」を参照してください。
**ホストファイル**
各オンラインインスタンスには、IP アドレスをホスト名にマッピングする`/etc/hosts`ファイルがあります。 OpsWorks スタックには、各インスタンスの `hosts` ファイル内のすべてのスタックのオンラインインスタンスのパブリックアドレスとプライベートアドレスが含まれます。例えば、2 つの Node.js アプリケーションサーバーインスタンス (nodejs-app1 と nodejs-app2) と、1 つの MySQL インスタンス (db-master1) があるとします。nodejs-app1 インスタンスの `hosts` ファイルは以下の例のようなものであり、他のインスタンスにも同様の `hosts` ファイルがあります。
```
...
# OpsWorks Layer State
192.0.2.0 nodejs-app1.localdomain nodejs-app1
10.145.160.232 db-master1
198.51.100.0 db-master1-ext
10.243.77.78 nodejs-app2
203.0.113.0 nodejs-app2-ext
10.84.66.6 nodejs-app1
192.0.2.0 nodejs-app1-ext
```
**OpsWorks スタックエージェントプロキシのサポート**
Chef 11.10 以降のスタック用の OpsWorks スタックエージェントには、プロキシサーバーの基本サポートが含まれています。プロキシサーバーは通常、分離された VPCsで使用されます。プロキシサーバーのサポートを有効にするには、HTTP と HTTPS のトラフィックに適した設定を定義した `/etc/environment` ファイルがインスタンスに必要です。このファイルは以下のようになります (強調表示されたテキストはプロキシサーバーの URL とポートに置き換えます)。
```
http_proxy="http://myproxy.example.com:8080/"
https_proxy="http://myproxy.example.com:8080/"
no_proxy="169.254.169.254"
```
プロキシのサポートを有効にするには、該当する [ ファイルを含む](workinginstances-custom-ami.md)カスタム AMI を作成`/etc/environment`し、その AMI を使用してインスタンスを作成することをお勧めします。
カスタムレシピを使用してインスタンスに `/etc/environment` ファイルを作成することはお勧めしません。 OpsWorks スタックでは、カスタムレシピが実行される前に、セットアッププロセスの早い段階でプロキシサーバーデータが必要です。
**Topics**
+ [Amazon Linux](#workinginstances-os-amazon)
+ [Ubuntu LTS](#workinginstances-os-linux-ubuntu)
+ [CentOS](#workinginstances-os-linux-centos)
+ [Red Hat Enterprise Linux](#workinginstances-os-linux-rhel)
## Amazon Linux
OpsWorks スタックは、Amazon Linux および Amazon Linux 2 の 64 ビットバージョンをサポートしています。Amazon Linux では定期的な更新やパッチに加えて、新しいバージョンを約 6 か月ごとにリリースしており、大きな変更が実施される場合もあります。スタックまたは新しいインスタンスを作成する際に、使用する Amazon Linux のバージョンを指定する必要があります。AWS から新しいバージョンがリリースされたとき、ユーザーが明示的にバージョンを変更するまで、インスタンスでは指定されたバージョンが引き続き実行されます。新しい Amazon Linux バージョンのリリース後 4 週間は移行期間となっており、その間は古いバージョン向けの定期的な更新が引き続き AWS で提供されます。移行期間の終了後も、インスタンスで古いバージョンを引き続き実行できますが、AWS では更新が提供されなくなります。詳細については、「[Amazon Linux AMI に関するよくある質問](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)」を参照してください。
Amazon Linux の新しいバージョンがリリースされたら、インスタンスがセキュリティの更新を引き続き受け取ることができるように、移行期間の間に新しいバージョンに更新することをお勧めします。本稼働用スタックのインスタンスを更新する前に、新しいインスタンスを起動し、新しいバージョンでアプリケーションが正常に実行されるかどうかを確認することをお勧めします。その後で、本稼働用スタックインスタンスを更新できます。
**注記**
デフォルトで、Amazon Linux に基づくカスタム AMI は、新しいバージョンがリリースされると自動的に更新されます。カスタム AMI は特定の Amazon Linux バージョンにロックしておき、新しいバージョンをテストするまで更新を延期できるようにすることをお勧めします。詳細については、「[AMI を特定のバージョンに固定するにはどうすればよいですか?](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)」を参照してください。
CloudFormation テンプレートを使用して Amazon Linux を実行しているインスタンスでスタックを作成する場合、テンプレートは Amazon Linux バージョンを明示的に指定する必要があります。特に、テンプレートで `Amazon Linux` を指定している場合、インスタンスでは引き続きバージョン 2016.09 が実行されます。詳細については、「[AWS::OpsWorks::Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-stack.html)」および「[AWS::OpsWorks::Instance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-instance.html)」を参照してください。
インスタンスの Amazon Linux のバージョンを更新するには、次のいずれかを実行します。
+ オンラインインスタンスの場合、[**Upgrade Operating System** スタックコマンド](workingstacks-commands.md)を実行します。
新しいバージョンの Amazon Linux が利用可能になると、[**Instances**] ページと [**Stack**] ページに通知が表示されます。この通知内のリンクをクリックすると、[**Run Command**] ページが表示されます。ここで [**Upgrade Operating System**] を実行して、インスタンスをアップグレードできます。
+ オフラインの Amazon Elastic Block Store-backed (EBS-backed) インスタンスの場合、インスタンスを起動して、前の項目で説明した方法で**オペレーティングシステムのアップグレード**を実行します。
+ 時間ベースのインスタンスと負荷ベースのインスタンスを含め、オフラインの Instance Store-Backed インスタンスの場合は、[インスタンスの [**Operating system**] 設定を編集して](workinginstances-properties.md)新しいバージョンを指定してください。
OpsWorks スタックは、インスタンスを再起動すると、インスタンスを新しいバージョンに自動的に更新します。
**Amazon Linux: サポートされている Node.js バージョン**
| Amazon Linux バージョン | Node.js バージョン |
| --- | --- |
| 2
| (Not applicable to operating systems that are available for Chef 12 and higher stacks only)
|
| 2018.03
| 0.12.18
|
| 2017.09
| 0.12.18
|
| 2017.03
| 0.12.18
|
| 2016.09
| 0.12.18
0.12.17
0.12.16
0.12.15
|
| 2016.03
| 0.12.18
0.12.17
0.12.16
0.12.15
0.12.14
0.12.13
0.12.12
0.12.10
|
**Amazon Linux: サポートされている Chef のバージョン**
| Chef のバージョン | サポートされている Amazon Linux のバージョン |
| --- | --- |
| 12
| Amazon Linux 2
Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
|
| 11.10
| Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03
|
| 11.4 (deprecated)
| Amazon Linux 2016.09
Amazon Linux 2016.03
|
**重要**
t1.micro インスタンスを更新する前に、各インスタンスに一時スワップファイル `/var/swapfile` があることを確認してください。Chef 0.9 スタックの t1.micro インスタンスにはスワップファイルがありません。Chef 11.4 および Chef 11.10 スタックでは、最近のバージョンのインスタンスエージェントによって、t1.micro インスタンスのスワップファイルが自動的に作成されます。ただし、この変更が導入されたのは数週間の期間であったため、2014 年 3 月 24 日頃より前に作成されたインスタンスに `/var/swapfile` が存在するかどうかを確認する必要があります。
スワップファイルがない t1.micro インスタンスでは、次の方法でスワップファイルを作成できます。
Chef 11.10 以降のスタックの場合、新しい t1.micro インスタンスを作成すると、スワップファイルが自動的に作成されます。
Chef 0.9 スタックの場合、各インスタンスで root ユーザーとして次のコマンドを実行します。
```
dd if=/dev/zero of=/var/swapfile bs=1M count=256
mkswap /var/swapfile
chown root:root /var/swapfile
chmod 0600 /var/swapfile
swapon /var/swapfile
```
新しいインスタンスを作成しない場合、これらのコマンドは Chef 11.10 以降のスタックでも使用できます。
## Ubuntu LTS
Ubuntu では、約 2 年ごとに新しい Ubuntu LTS バージョンがリリースされ、各リリースは約 5 年間サポートされます。オペレーティングシステムのサポート期間中は、セキュリティパッチと更新が提供されます。詳細については、[Ubuntu Wiki の LTS に関するページ](https://wiki.ubuntu.com/LTS)を参照してください。
+ 既存の Ubuntu インスタンスを以降の Ubuntu に更新することはできません。
[新しい Ubuntu インスタンスを作成](workinginstances-add.md)し、[古いインスタンスを削除](workinginstances-delete.md)する必要があります。
+ Ubuntu 20.04 LTS は、Chef 12 以降のスタックでのみサポートされます。
## CentOS
OpsWorks スタックは [CentOS 7 ](https://docs.centos.org/en-US/docs/)の 64 ビットバージョンをサポートしています。最初にサポートされているバージョンは CentOS 7 で、CentOS は約 2 年ごとに新しいバージョンをリリースします。
CentOS スタックで新しいインスタンスを起動すると、 OpsWorks スタックは最新の CentOS バージョンを自動的にインストールします。新しい OpsWorks CentOS マイナーバージョンがリリースされたとき、 スタックは既存のインスタンスのオペレーティングシステムを自動的に更新しないため、新しく作成されたインスタンスは、スタックの既存のインスタンスよりも新しいバージョンを受け取る可能性があります。以下の方法で既存のインスタンスを現在の CentOS バージョンに更新することで、スタック間のバージョンの整合性を維持することができます。
+ オンラインインスタンスの場合は、[[**Upgrade Operating System**] スタックコマンド](workingstacks-commands.md)を`yum update`指定したインスタンスで実行して、オペレーティングシステムを現在のバージョンに更新します。
新しい CentOS 7 のマイナーバージョンが利用可能になると、[**Instances**] ページと [**Stack**] ページに通知が表示されます。この通知内のリンクをクリックすると、[**Run Command**] ページが表示されます。ここで [**Upgrade Operating System**] を実行して、インスタンスをアップグレードできます。
+ オフラインの更新された Amazon EBS インスタンスの場合は、インスタンスを起動し、前のリスト項目で説明したように**オペレーティングシステムのアップグレード**を実行します。
+ オフラインの instance store-backed インスタンスの場合、インスタンスの再起動時に OpsWorks スタックは自動的に新しいバージョンをインストールします。
**CentOS: サポートされている Chef のバージョン**
| Chef のバージョン | サポートされている CentOS のバージョン |
| --- | --- |
| 12
| CentOS 7
|
| 11.10
| (None supported)
|
| 11.4 (deprecated)
| (None supported)
|
**注記**
OpsWorks スタックは CentOS インスタンスの Apache 2.4 をサポートしています。
## Red Hat Enterprise Linux
OpsWorks スタックは、[Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/) (RHEL 7) の 64 ビットバージョンをサポートしています。最初にサポートされているバージョンは RHEL 7.1 で、Red Hat は約 9 か月ごとにマイナーバージョンをリリースします。マイナーバージョンは RHEL 7.0 と互換性があります。詳細については、「[ライフサイクルと更新ポリシー](https://access.redhat.com/support/policy/update_policies)」を参照してください。
新しいインスタンスを起動すると、 OpsWorks Stacks は現在の RHEL 7 バージョンを自動的にインストールします。新しい RHEL 7 マイナーバージョンがリリースされたとき、 OpsWorks スタックは既存のインスタンスのオペレーティングシステムを自動的に更新しないため、新しく作成されたインスタンスは、スタックの既存のインスタンスよりも新しいバージョンを受け取る可能性があります。以下の方法で既存のインスタンスを現在の RHEL 7 バージョンに更新することで、スタック間のバージョンの整合性を維持することができます。
+ オンラインインスタンスの場合は、[[**Upgrade Operating System**] スタックコマンド](workingstacks-commands.md)を`yum update`指定したインスタンスで実行して、オペレーティングシステムを現在のバージョンに更新します。
新しいバージョンの RHEL 7 が利用可能になると、[**Instances**] ページと [**Stack**] ページに通知が表示されます。この通知内のリンクをクリックすると、[**Run Command**] ページが表示されます。ここで [**Upgrade Operating System**] を実行して、インスタンスをアップグレードできます。
+ オフラインの更新された Amazon EBS インスタンスの場合は、インスタンスを起動し、前のリスト項目で説明したように**オペレーティングシステムのアップグレード**を実行します。
+ オフラインの instance store-backed インスタンスの場合、インスタンスの再起動時に OpsWorks スタックは自動的に新しいバージョンをインストールします。
**Red Hat Enterprise Linux: サポートされている Node.js のバージョン**
| RHEL バージョン | Node.js バージョン |
| --- | --- |
| 7
| (Node.js versions only apply to Chef 11.10 stacks)
0.8.19
0.8.26
0.10.11
0.10.21
0.10.24
0.10.25
0.10.27
0.10.29
0.10.40
0.12.10
0.12.12
0.12.13
0.12.15
|
**Red Hat Enterprise Linux: サポートされている Chef のバージョン**
| Chef のバージョン | サポートされている RHEL バージョン |
| --- | --- |
| 12
| Red Hat Enterprise Linux 7
|
| 11.10
| Red Hat Enterprise Linux 7
|
| 11.4 (deprecated)
| (None supported)
|
0.10.40 よりも古いバージョンの Node.js はすべて非推奨です。また、0.12.7 と 0.12.9 も非推奨となっています。
**注記**
OpsWorks スタックは、RHEL 7 インスタンスの Apache 2.4 をサポートしています。
# Microsoft Windows Server
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
以下の注意事項では、Windows インスタンスの OpsWorks スタックサポートについて説明します。Windows インスタンスは、Chef 12.2 スタックでのみ使用できます。Windows スタックの正確な Chef バージョン番号は 12.22 です。
現在、 OpsWorks スタックエージェントは、**英語 - 米国** (en-US) 以外のシステム UI 言語を使用する Windows ベースのインスタンスにインストールすることはできません。 OpsWorks また、 スタックは管理できません。
**バージョン**
OpsWorks スタックは、次の Windows 64 ビットバージョンをサポートしています。
+ Microsoft Windows Server 2022 Base
+ Microsoft Windows Server 2022 および SQL Server Express
+ Microsoft Windows Server 2022 および SQL Server Standard
+ Microsoft Windows Server 2022 および SQL Server Web
+ Microsoft Windows Server 2019 Base
+ Microsoft Windows Server 2019 および SQL Server Express
+ Microsoft Windows Server 2019 および SQL Server Standard
+ Microsoft Windows Server 2019 および SQL Server Web
**インスタンスの作成**
スタックコンソール、API、または CLI OpsWorks を使用して Windows インスタンスを作成します。Windows インスタンスは Amazon EBS でバックアップされていますが、余分な Amazon EBS ボリュームをマウントすることはできません。
Windows スタックでは、手動での起動と停止が可能な [24/7](workinginstances-starting.md) インスタンスを使用できます。また、[時間ベースの自動スケーリング](workinginstances-autoscaling-timebased.md)を使用することもできます。これは、ユーザーが指定したスケジュールでインスタンスを自動的に起動および停止する機能です。Windows ベースのスタックでは、[負荷ベースの自動スケーリング](workinginstances-autoscaling-loadbased.md)を使用することはできません。
スタックの外部で作成された [Windows インスタンスをスタックに登録](registered-instances.md)することはできません。 OpsWorks
**更新**
AWS は、パッチセットごとに Windows AMI を更新するため、インスタンスを作成すると最新の更新が適用されます。ただし、 OpsWorks スタックはオンライン Windows インスタンスに更新を適用する方法を提供しません。Windows を最新の状態に保つには、最新の AMI が常に実行されるようにインスタンスを定期的に置き換えるのが最も簡単です。
**レイヤー**
ソフトウェアのインストールと設定やアプリケーションのデプロイなどのタスクを処理するには、カスタムレシピを使用して 1 つ以上の[カスタムレイヤー](workinglayers-custom.md) を実装する必要があります。
**Chef**
Windows インスタンスは Chef 12.22 を使用して [chef-client をローカルモード](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)で実行します。これにより、[chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero) と呼ばれるローカルインメモリの Chef サーバーが起動されます。このサーバーが存在する場合、カスタムレシピで Chef 検索およびデータバッグを使用できます。
**リモートログイン**
OpsWorks スタックは、承認された IAM ユーザーに Windows インスタンスへのログインに使用できるパスワードを提供します。このパスワードは、指定した時間が経過すると期限切れになります。管理者は、SSH キーペアを使用してインスタンスの管理者パスワードを取得し、[RDP に無制限にアクセス](workinginstances-rdp.md)することができます。詳細については、「[RDP でのログイン](workinginstances-rdp.md)」を参照してください。
**AWS SDK**
OpsWorks スタックは、各インスタンス[AWS SDK for .NET](https://aws.amazon.com/sdk-for-net/)に を自動的にインストールします。このパッケージには、AWS .NET ライブラリと Windows 用 AWS ツール ([AWS Tools for PowerShell](https://aws.amazon.com/powershell/)など) が含まれています。Ruby SDK を使用する場合、カスタムレシピによって適切な gem をインストールすることができます。
**モニタリングおよびメトリクス**
Windowsインスタンスは、標準的な [Amazon CloudWatch (CloudWatch)メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)をサポートしており、CloudWatch コンソールで表示することができます。
**Ruby**
スタックが Windows インスタンスにインストールする Chef OpsWorks 12.22 クライアントには、Ruby 2.3.6 が付属しています。ただし、 OpsWorks スタックは実行可能ファイルの ディレクトリを PATH 環境変数に追加しません。通常であれば `C:\opscode\chef\embedded\bin\` で検索し、アプリケーションがこの Ruby バージョンを使用できるようにします。
**OpsWorks スタックエージェント CLI**
Windows インスタンスの OpsWorks スタックエージェントは、[コマンドラインインターフェイス](agent.md)を公開しません。
**プロキシのサポート**
Windows インスタンス用のプロキシサポートをセットアップするには、次の作業を行います。
1. を変更`machine.config`して以下を追加します。これにより、Windows PowerShell (初期ブートストラップ) および .NET (OpsWorks スタックエージェント) アプリケーションにプロキシサポートが追加されます。
```
```
1. Chef と Git で後で使用するために、次のコマンドを実行して環境変数を設定します。
```
setx /m no_proxy "localhost,169.254.169.254"
setx /m http_proxy "http://10.100.1.91:3128"
setx /m https_proxy "http://10.100.1.91:3128"
```
**注記**
OpsWorks スタックがインスタンスを更新する方法をより詳細に制御するには、Microsoft Windows Server 2022 Base に基づいてカスタム AMI を作成します。たとえば、カスタム AMI を使用してインスタンスにインストールするソフトウェア (Web Server (IIS) など) を指定できます。詳細については、「[カスタム AMI の使用](workinginstances-custom-ami.md)」を参照してください。
# レイヤーへのインスタンスの追加
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
レイヤーを作成した後、通常は最低 1 個のインスタンスを追加します。現在の設定が負荷を処理できない場合、より多くのインスタンスを後で追加できます。自動的にインスタンス数を拡張するために、[ロードベースまたは時間ベースのインスタンス](workinginstances-autoscaling.md)を使用することもできます。
レイヤーに新規または既存のインスタンスを追加できます。
+ **新規** - OpsWorks は新しいインスタンスを作成し、仕様に合わせて設定して、レイヤーのメンバーにします。
+ **既存** - 互換性のある任意のレイヤーの既存のインスタンスを追加できます。ただし、オフライン (停止)状態である必要があります。
インスタンスが複数のレイヤーに属している場合、ライフサイクルイベントが発生したときや、[スタック](workingstacks-commands.md)や[デプロイメント](workingapps-deploying.md)コマンドを実行したときに、 OpsWorks Stacks はインスタンスの各レイヤーのレシピを実行します。
また、インスタンスの設定を編集することによって、インスタンスを複数のレイヤーのメンバーにすることができます。詳細については、「[インスタンス設定の編集](workinginstances-properties.md)」を参照してください。
**レイヤーに新しいインスタンスを追加するには**
1. [**Instances**] ページで適切なレイヤーの [**\$1Instance**] を選択し、必要であれば [**New**] タブを選択します。**[ホスト名]**、**[サイズ]**、**[サブネット]**、**[アベイラビリティアベイラビリティゾーン]** 以外の設定も行う場合は、**[Advanced >>]** を選択してさらにオプションを表示します。以下にすべてのオプションを示します。
![\[[Instances] ページの新しいインスタンスの [+Instance]\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/add_instance.png)
1. 必要に応じて、多くはスタックの作成時に指定したデフォルト設定をオーバーライドできます。詳細については、「[新しいスタックを作成する](workingstacks-creating.md)」を参照してください。
**Hostname**
ネットワークのインスタンスを識別します。デフォルトでは、 OpsWorks スタックは、スタックの作成時に指定した**ホスト名テーマ**を使用して各インスタンスのホスト名を生成します。この値をオーバーライドして、任意のホスト名を指定できます。
**サイズ**
メモリの量や仮想コアの数など、インスタンスのリソースを指定する Amazon EC2 インスタンスタイプ。 OpsWorks スタックは各インスタンスのデフォルトサイズを指定し、任意のインスタンスタイプで上書きできます。
OpsWorks スタックでサポートされているインスタンスタイプは、スタックが VPC にあるかどうかによって異なります。また、AWS 無料利用枠を使用しているアカウントでは、インスタンスタイプは制限されています。[**Size (サイズ)**] ドロップダウンリストには、使用しているスタックでサポートされている Chef バージョンに対してサポートされているインスタンスタイプが表示されます。t1.micro などのマイクロインスタンスには、いくつかのレイヤーをサポートするだけの十分なリソースがない場合があることに注意してください。詳細については、「[ のインスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
[負荷分散されたインスタンス](workinginstances-autoscaling-loadbased.md)を使用している場合、[Configure ライフサイクルイベント](workingcookbook-events.md)によって、1 分以上続くことがある大きな CPU 負荷のスパイクが発生する可能性があることに注意してください。より小規模のインスタンスでは、この負荷のスパイクにより上限がトリガーされる可能性があります (特に、頻繁な Configure イベントがある大規模な負荷分散スタックの場合)。以下に、Configure イベントが不要な上限を発生させる可能性を減らすことができるいくつかの方法を示します。
+ より大きなインスタンスを使用し、Configure イベントからの追加の負荷が上限をトリガーしないようにします。
+ CPU リソースを共有する T2 などのインスタンスタイプを使用しないでください。
これにより、Configure イベントが発生した場合は、すべてのインスタンスの CPU リソースすべてが直ちに使用できるようになります。
+ `exceeded threshold` 時間を、Configure イベントの処理に必要な時間よりもかなり長くします (5 分など)。
詳細については、「[自動負荷ベースのスケーリングの使用](workinginstances-autoscaling-loadbased.md)」を参照してください。
**アベイラビリティーゾーン/サブネット**
スタックが VPC 内にない場合、この設定は [**Availability Zone**] と表示され、リージョンのゾーンがリストされます。スタックを作成したときに指定したデフォルトのアベイラビリティーゾーンを上書きするには、この設定を使用できます。
スタックが VPC で実行されている場合、この設定は、[**Subnet**] と表示され、VPC のサブネットがリストされます。スタックを作成したときに指定したデフォルトのサブネットを上書きするには、この設定を使用できます。
デフォルトでは、 OpsWorks スタックはサブネットの CIDR 範囲を一覧表示します。リストをより読みやすくするには、VPC コンソールまたは API を使用して、**キー**を に設定**Name**し、**値を**サブネットの名前に設定します。 OpsWorks スタックはその名前を CIDR 範囲に追加します。前の例では、サブネットの Name タグは **Private** に設定されています。
**スケーリングタイプ**
インスタンスの起動方法と停止方法を決定します。
+ デフォルト値は **24/7** インスタンスで、手動で開始および停止します。
+ OpsWorks スタックは、指定されたスケジュールに基づいて**時間ベースの**インスタンスを起動および停止します。
+ (Linux のみ) OpsWorks スタックは、指定された**ロードメトリクスに基づいてロードベースの**インスタンスを起動および停止します。
負荷ベースまたは時間ベースのインスタンスを手動で開始または停止することはできません。代わりに、インスタンスを設定すると、 OpsWorks スタックは設定に基づいてインスタンスを起動および停止します。詳細については、「[時間ベースおよび負荷ベースのインスタンスによる負荷の管理](workinginstances-autoscaling.md)」を参照してください。
**SSH キー**
Amazon EC2 キーペア。 OpsWorks スタックはインスタンスにパブリックキーをインストールします。
+ Linux インスタンスの場合、SSH クライアントで対応するプライベートキーを使用して[インスタンスにログイン](workinginstances-ssh.md)できます。
+ Windows インスタンスの場合、対応するプライベートキーを使用して[インスタンスの管理者パスワードを取得](workinginstances-rdp.md#workinginstances-rdp-admin)できます。その後、RDP でそのパスワードを使用してインスタンスに管理者としてログインできます。
この設定は、スタックの作成時に指定した [**Default SSH key**] 値に初期設定されます。
+ デフォルト値が **[デフォルトのSSHキーを使用しない]** に設定されている場合は、自分のアカウントの Amazon EC2 キーのいずれかを指定できます。
+ デフォルト値が Amazon EC2 キー に設定されている場合は、別のキーを指定することも、キーを指定しないこともできます。
**オペレーティングシステム**
**オペレーティングシステム**は、インスタンスが実行されているオペレーティングシステムを指定します。 OpsWorks スタックは 64 ビットオペレーティングシステムのみをサポートします。
この設定は、スタックの作成時に指定した [**デフォルトのオペレーティングシステム**] 値に初期設定されます。デフォルト値を上書きして、別の Linux オペレーティングシステムまたはカスタム Amazon マシンイメージ (AMI) を指定できます。ただし、Linux から Windows にまたは Windows から Linux に切り替えることはできません。
[**Use custom AMI**] を選択すると、ページには [**Architecture**] および [**Root device type**] ではなくカスタム AMI のリストが表示されます。
![\[[Instances] ページの新しいインスタンスの [+Instance]\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/add_instance_ami.png)
詳細については、「[カスタム AMI の使用](workinginstances-custom-ami.md)」を参照してください。
**OpsWorks Agent version**
**OpsWorks エージェントバージョン**は、インスタンスで実行する OpsWorks Stacks エージェントのバージョンを指定します。 OpsWorks スタックがエージェントを自動的に更新するようにするには、[**Inherit from stack (スタックから継承する)**] をオンにします。エージェントの特定のバージョンをインストールし、インスタンスでエージェントを手動更新するには、ドロップダウンリストからバージョンを選択します。
エージェントのバージョンとオペレーティング システムのリリースの組み合わせによってはうまく機能しない場合があります。インスタンスがエージェントを実行している場合、またはインスタンスオペレーティングシステムで完全にサポートされていないエージェントをインスタンスにインストールしている場合、 OpsWorks スタックコンソールには、互換性のあるエージェントをインストールするように指示するエラーメッセージが表示されます。
**テナンシー**
インスタンスのテナンシーオプションを選択します。お客様専用の物理サーバー上でインスタンスを実行することも可能です。
+ **Default - Rely on VPC settings**: テナンシーなし、または VPC からテナンシー設定を継承します。
+ **Dedicated - Run a dedicated instance**: シングルテナントハードウェアで実行されるインスタンスに対して、時間単位でお支払いいただきます。詳細については、Amazon VPC ユーザーガイドの「[ハードウェア専有インスタンス](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedicated-instance.html)」、および「[Amazon EC2 ハードウェア専有インスタンス](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/)」を参照してください。
+ **Dedicated host - Run this instance on a dedicated host**: 完全にインスタンスの実行専用の物理ホストに対してお支払いいただき、既存のソケット単位、コア単位、または VM 単位のソフトウェアライセンスを持ち込んでコストを削減できます。詳細については、Amazon EC2 ドキュメントの[専有ホストの概要](https://aws.amazon.com/ec2/dedicated-hosts/)および[Amazon EC2 専有ホスト](https://aws.amazon.com/ec2/dedicated-hosts/)を参照してください。
**ルートデバイスタイプ**
インスタンスのルートデバイスストレージを指定します。
+ Linux インスタンスは、Amazon EBS-backed または Instance store-backed のどちらかです。
+ Windows インスタンスは、Amazon EBS-Backed である必要があります。
詳細については、[「ストレージ」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)を参照してください。
スタックはインスタンスのソフトウェアを最初から再インストールする必要 OpsWorks がないため、最初の起動後、Amazon EBS-backed インスタンスは instance store-backed インスタンスよりも速く起動します。詳細については、「[ルートデバイスストレージ](best-practices-storage.md)」を参照してください。
**ボリュームタイプ**
ルートデバイスボリュームタイプ ([**Magnetic**]、[**Provisioned IOPS (SSD)**] または [**General Purpose (SSD)**]) を指定します。詳細については、「[Amazon EBS ボリュームのタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)」を参照してください。
**ボリュームサイズ**
指定したボリュームタイプのルートデバイスボリュームのサイズを指定します。詳細については、「[Amazon EBS ボリュームのタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)」を参照してください。
+ **汎用 (SSD)**。許容される最小サイズは 8 GiB で、最大サイズは 16384 GiB です。
+ **プロビジョンド IOPS (SSD)**。許容される最小サイズは 8 GiB で、最大サイズは 16384 GiB です。設定できる 1 秒あたりの入力/出力操作数は、最小 100 IOPS、最大240 IOPS です。
+ **マグネティック**。許容される最小サイズは 8 GiB で、最大サイズは 1024 GiB です。
1. [**Add Instance**] を選択して、新しいインスタンスを作成します。
**注記**
インスタンスを作成するとき、[スタックのデフォルトエージェントバージョン](workingstacks-creating.md#workingstacks-creating-advanced-agent)の設定を上書きすることはできません。カスタムエージェントバージョンの設定を指定するには、インスタンスを作成し、[その設定を編集](workinginstances-properties.md)する必要があります。
**既存のインスタンスをレイヤーに追加するには**
1. [**Instances**] ページで適切なレイヤーの [**\$1Instance**] を選択し、[**Existing**] タブを開きます。
**注記**
既存のインスタンスを使用しないことにした場合は、前述の手順に従って、[**New**] を選択して、新しいインスタンスを作成します。
1. [**Existing**] タブで、リストからインスタンスを選択します。
1. [**Add Instance**] を選択して、新しいインスタンスを作成します。
インスタンスは Amazon EC2 OpsWorks インスタンスを表しますが、基本的には スタックのデータ構造にすぎません。次のセクションで説明するように、実行中の Amazon EC2 インスタンスを作成するには、インスタンスが開始されている必要があります。
**重要**
デフォルト VPC 内でインスタンスを起動する場合は、VPC 設定の変更について注意する必要があります。インスタンスは、 OpsWorks スタックサービス、Amazon S3、およびパッケージリポジトリと常に通信できる必要があります。たとえば、デフォルトゲートウェイを削除すると、インスタンスは OpsWorks スタックサービスへの接続を失い、インスタンスは失敗として扱われ、[自動的に修復](workinginstances-autohealing.md)されます。ただし、 OpsWorks スタックは修復されたインスタンスにインスタンスエージェントをインストールできません。エージェントがない場合、インスタンスはサービスと通信できず、起動プロセスは `booting` ステータスの先に進みません。デフォルト VPC の詳細については、「[サポートされているプラットフォーム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html)」を参照してください。
スタックの外部で作成されたスタックに Linux OpsWorks コンピューティングリソースを組み込むこともできます。
+ コンソール、CLI、または API を使用して直接作成した Amazon EC2 インスタンス。
+ 仮想マシンで実行しているインスタンスを含め、独自のハードウェアで実行している *On-premises* (オンプレミス) インスタンス。
詳細については、「[OpsWorks Stacks の外部で作成されたコンピューティングリソースの使用](registered-instances.md)」を参照してください。
# カスタム 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**] を選択します。
これで、インスタンスを起動して実行できるようになりました。
# 24/7 インスタンスの手動による起動、停止、再起動
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
**注記**
Linux スタックと Windows スタックの両方で 24/7 インスタンスを使用できます。
24/7 インスタンスをレイヤーに追加したら、インスタンスを手動で起動して対応する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動し、手動で停止して Amazon EC2 インスタンスを終了する必要があります。正常に機能していないインスタンスを手動で再起動することもできます。 OpsWorks スタックは、時間ベースおよび負荷ベースのインスタンスを自動的に開始および停止します。詳細については、「[時間ベースおよび負荷ベースのインスタンスによる負荷の管理](workinginstances-autoscaling.md)」を参照してください。
**重要**
OpsWorks スタックインスタンスは、 OpsWorks コンソールでのみ起動、停止、再起動する必要があります。Amazon EC2 OpsWorks コンソールで実行された起動、停止、再起動オペレーションは認識されません。
**Topics**
+ [インスタンスの起動または再起動](#workinginstances-starting-start)
+ [インスタンスの停止](#workinginstances-starting-stop)
+ [インスタンスの再起動](#workinginstances-starting-reboot)
## インスタンスの起動または再起動
新しいインスタンスを起動するには、**[Instances]** (インスタンス) ページでインスタンスの **[Actions]** (アクション) 列の **[start]** (開始) をクリックします。
![\[[Instances] ページでの [start] アクション\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/start_instance.png)
複数のインスタンスを作成し、[**Start all Instances**] をクリックしてこれらのすべてを同時に起動することもできます。
インスタンスを起動すると、 OpsWorks スタックは Amazon EC2 インスタンスを起動し、オペレーティングシステムを起動します。起動プロセスには通常数分かかり、Windows インスタンスの方が Linux インスタンスより少し時間がかまります。起動処理が進行するに従って、インスタンスの [**Status**] フィールドに次のような一連の値が表示されます。
1. **リクエスト** - OpsWorks スタックが Amazon EC2 サービスを呼び出して Amazon EC2 インスタンスを作成しました。
1. **保留中** - OpsWorks スタックは Amazon EC2 インスタンスの起動を待っています。
1. **[booting]** (起動中) - Amazon EC2 インスタンスの起動中です。
1. **running\$1setup** - OpsWorks スタックが Setup イベントをトリガーし、レイヤーのSetupレシピとそれに続くDeployレシピを実行しています。詳細については、「[レシピの実行](workingcookbook-executing.md)」を参照してください。スタックに[カスタムクックブックを追加](workingcookbook-installingcustom-enable.md)した場合、 および SetupDeployレシピを実行する前に、 OpsWorks スタックはリポジトリから現在のバージョンをインストールします。
1. **online** - インスタンスは利用可能です。
[**Status**] が [**online**] に変わると、インスタンスは完全に操作可能になります。
+ レイヤーにロードバランサーがアタッチされている場合、 OpsWorks スタックはインスタンスを追加します。
+ OpsWorks スタックはConfigureイベントをトリガーし、各インスタンスのConfigureレシピを実行します。
必要に応じて、新しいインスタンスに対応するためにこれらのレシピによりインスタンスが更新されます。
+ OpsWorks スタックは、インスタンス**の開始**アクションを停止に置き換え****ます。これを使用してインスタンスを停止できます。
インスタンスが正常に起動しなかった場合、または Setup レシピが失敗した場合、ステータスはそれぞれ **start\$1failed** または **setup\$1failed** に設定されます。ログを確認して原因を特定できます。詳細については、「[デバッグとトラブルシューティングのガイド](troubleshoot.md)」を参照してください。
停止されたインスタンスはスタックの一部として残り、すべてのリソースを保持します。例えば、Amazon EBS ボリュームや Elastic IP アドレスは、停止したインスタンスに関連付けられたままです。停止したインスタンスを再開するには、インスタンスの **[Actions]** (アクション) 列で **[start]** (開始) を選択します。停止したインスタンスを再開すると、次の処理が実行されます。
+ Instance store-backed インスタンス – OpsWorks スタックは、同じ設定で新しい Amazon EC2 インスタンスを起動します。
+ Amazon EBS-backed インスタンス – OpsWorks スタックは Amazon EC2 インスタンスを再起動し、ルートボリュームを再アタッチします。
インスタンスの起動が完了すると、 OpsWorks スタックはオペレーティングシステムの更新をインストールし、最初の起動と同様に Setupおよび Deployレシピを実行します。 OpsWorks スタックは、再起動されたインスタンスに対して必要に応じて以下も実行します。
+ Elastic IP アドレスを再度関連付けます。
+ Amazon Elastic Block Store (Amazon EBS) ボリュームを再接続します。
+ Instance store-backed インスタンスの場合、最新のクックブックバージョンをインストールします。
Amazon EBS-backed インスタンスは、ルートボリュームに保存されたカスタムクックブックを使用し続けます。インスタンスを停止してからカスタムクックブックが変化した場合、インスタンスがオンラインになったら手動で更新する必要があります。詳細については、「[カスタムクックブックの更新](workingcookbook-installingcustom-enable-update.md)」を参照してください。
**注記**
Elastic IP アドレスが再開されたインスタンスに再度関連付けられるには数分かかる場合があります。インスタンスの **Elastic IP** 設定はメタデータを表しており、アドレスがインスタンスと関連付けられる必要があることを示しているにすぎない点に注意してください。[**Public IP**] 設定はインスタンスの状態を反映しており、最初は空の可能性があります。Elastic IP アドレスがインスタンスに関連付けられると、そのアドレスは [**Public IP**] 設定に割り当てられ、その後に「(EIP)」が付きます。
## インスタンスの停止
**インスタンス**ページで、インスタンスの**アクション**列の**停止**をクリックします。これにより、シャットダウンレシピを実行して EC2 インスタンスを終了するように OpsWorks スタックに通知されます。
![\[[Instances] ページの [stop] アクション\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/stop_instance.png)
また、[**Stop All Instances**] をクリックして、すべてのインスタンスをシャットダウンすることもできます。
インスタンスを停止すると、 OpsWorks Stacks はいくつかのタスクを実行します。
1. インスタンスのレイヤーに Elastic Load Balancing ロードバランサーがアタッチされている場合、 OpsWorks Stacks はインスタンスの登録を解除します。
レイヤーでロードバランサーの Connection Draining 機能がサポートされている場合、 OpsWorks スタックは Connection Draining が完了するまで Shutdown イベントのトリガーを遅らせます。詳細については、「[Elastic ロードバランシングレイヤー](layers-elb.md)」を参照してください。
1. OpsWorks スタックは、インスタンスのShutdownレシピを実行するShutdownイベントをトリガーします。
1. Shutdown イベントをトリガーした後、 OpsWorks スタックは指定された時間待機してShutdownレシピが終了するのを許可し、以下を実行します。
+ Instance store-Backed インスタンスを終了し、これによりすべてのデータが削除されます。
+ Amazon EBS-Backed インスタンスを停止します。これによりルートボリュームのデータが保持されます。
インスタンスストレージについては、「[ストレージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)」を参照してください。
**注記**
デフォルトのシャットダウンタイムアウト設定は 120 秒です。Shutdown レシピでさらに時間が必要な場合は、[レイヤー設定を編集](workinglayers-basics-edit.md)して設定を変更できます。
シャットダウンプロセスは、インスタンスの **Status** 列を見ることでモニタリングできます。シャットダウン処理が進行するに従って、次のような一連の値が表示されます。
1. **終了** - OpsWorks スタックは Amazon EC2 インスタンスを終了しています。
1. **shutting\$1down** - OpsWorks スタックはレイヤーのShutdownレシピを実行しています。
1. **[terminated終了]** (終了) - Amazon EC2 インスタンスを終了しました。
1. **stopped** - インスタンスは停止しました。
## インスタンスの再起動
[**Instances**] ページで、機能していないインスタンスの名前をクリックし、詳細ページを開いた後、[**Reboot**] をクリックします。
![\[[Instances] ページの [Reboot] ボタン\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/reboot_instance.png)
このコマンドは、関連付けられた Amazon EC2 インスタンスのソフト再起動を実行します。Instance store-backed インスタンスの場合でもインスタンスのデータを削除せず、[ライフサイクルイベント](workingcookbook-events.md)をトリガーしません。
**注記**
OpsWorks スタックで障害が発生したインスタンスを自動的に置き換えるには、自動ヒーリングを有効にします。詳細については、「[自動ヒーリングの使用](workinginstances-autohealing.md)」を参照してください。
# 時間ベースおよび負荷ベースのインスタンスによる負荷の管理
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
着信トラフィックが一定でない場合、負荷を処理するにはスタックのインスタンスが少なすぎたり、必要以上に多すぎたりします。時間ベースまたは負荷ベースのインスタンスを使用することで、レイヤーのインスタンス数が自動的に調整され、不必要な容量に余分な支払いをすることなく着信トラフィックを処理するのに十分なインスタンスを常に確保できるので、時間と費用の両方で節約できます。サーバーの負荷を監視したり、手動でインスタンスを起動または停止したりする必要はありません。また、時間ベースおよび負荷ベースのインスタンスは自動的に、リージョン内の複数のアベイラビリティゾーンでアプリケーションを分散、スケーリング、および均等にし、地理的冗長性と拡張性を提供します。
自動スケーリングは、2 つのインスタンスタイプに基づいており、異なる条件でレイヤーのオンラインインスタンスを調整します。
+ **時間ベース**のインスタンス
これらのインスタンスは、特定の時間または特定の日にのみ実行するインスタンスを含めることで、スタックが予測パターンに従って負荷を処理できるようにします。たとえば、午後 6 時からに一部のインスタンスを起動して夜間のバックアップタスクを実行したり、トラフィックが少ない週末に一部のインスタンスを停止したりできます。
+ **負荷ベース**のインスタンス
これらのインスタンスにより、任意の負荷メトリクスに基づいて、トラフィックが多い時には追加のインスタンスを起動し、トラフィックが少ない時にはトラフィック停止することで、スタックが変化する負荷を処理できるようにします。たとえば、平均 CPU 使用率が 80% を超えると OpsWorks スタックでインスタンスを起動し、平均 CPU 負荷が 60% を下回るとインスタンスを停止できます。
Linux スタックでは時間ベースと負荷ベース両方のインスタンスがサポートされますが、Windows スタックでは時間ベースのインスタンスのみがサポートされています。
手動で起動および停止する必要がある 24/7 インスタンスとは異なり、時間ベースまたは負荷ベースのインスタンスは手動で起動または停止する必要がありません。代わりに、インスタンスを設定すると OpsWorks 、 スタックはその設定に基づいてインスタンスを開始または停止します。たとえば、指定したスケジュールで開始および停止するように時間ベースのインスタンスを設定します。 OpsWorks スタックはその設定に従ってインスタンスを開始および停止します。
一般的な方法は、次のように 3 つのインスタンスタイプを共に使用することです。
+ 基本負荷を処理する一連の 24/7 インスタンス。通常、これらのインスタンスを起動し、常に実行するようにします。
+ 予測可能なトラフィックのバリエーションを処理するために OpsWorks スタックが開始および停止する、時間ベースのインスタンスのセット。たとえば、就業時間にトラフィックが最も多い場合、朝に起動して夜にシャットダウンするように時間ベースのインスタンスを設定できます。
+ 予期しないトラフィックの変動を処理するために OpsWorks スタックが開始および停止する負荷ベースのインスタンスのセット。 OpsWorks スタックは、負荷がスタックの 24/7 および時間ベースのインスタンスの容量に近づいたときに起動し、トラフィックが通常に戻ったときに停止します。
これらのスケーリング時間を処理する方法の詳細については、「[サーバー数の最適化 ](best-practices-autoscale.md)」を参照してください。
**注記**
インスタンスのレイヤー用のアプリケーションを作成した場合、またはカスタムクックブックを作成した場合、 OpsWorks スタックは、最初に起動されたときに最新バージョンを時間ベースおよびロードベースのインスタンスに自動的にデプロイします。ただし、 OpsWorks スタックは、再起動されたオフラインインスタンスに最新のクックブックをデプロイするとは限りません。詳細については、「[アプリケーションの編集](workingapps-editing.md)」および「[カスタムクックブックの更新](workingcookbook-installingcustom-enable-update.md)」を参照してください。
**Topics**
+ [自動時間ベースのスケーリングの使用](workinginstances-autoscaling-timebased.md)
+ [自動負荷ベースのスケーリングの使用](workinginstances-autoscaling-loadbased.md)
+ [負荷ベースのスケーリングと自動修復の違い](#workinginstances-autoscaling-differs)
# 自動時間ベースのスケーリングの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
時間ベースのスケーリングでは、指定したスケジュールでインスタンスを開始または停止することで、レイヤーが特定の時間帯または曜日にオンラインにするインスタンスの数を制御できます。 OpsWorks スタックは数分ごとにチェックし、必要に応じてインスタンスを開始または停止します。次のように、インスタンスごとに個別の予定を指定します。
+ 時刻。たとえば、夜間よりも日中により多くのインスタンスを実行することができます。
+ 曜日。たとえば、週末より平日により多くのインスタンスを実行することができます。
**注記**
特定の日付を指定することはできません。
**Topics**
+ [レイヤーへの時間ベースのインスタンスを追加する](#workinginstances-autoscaling-timebased-add)
+ [時間ベースのインスタンスの構成](#workinginstances-autoscaling-timebased-configure)
## レイヤーへの時間ベースのインスタンスを追加する
レイヤーに新しい時間ベースのインスタンスを追加するか、既存のインスタンスを使用します。
**新しい時間ベースのインスタンスを追加するには**
1. **[インスタンス]** ページで **[\$1 インスタンス]** を選択して、インスタンスを追加します。**[新規]** タブで、**[アドバンスト]** を選択してから、**[時間ベース]** を選択します。
![\[[Add instance] ページの時間ベースのスケーリングオプション\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/time_based_instances.png)
1. インスタンスを設定します。次に、**[インスタンスの追加]** を選択して、インスタンスをレイヤーに追加します。
**既存の時間ベースのインスタンスをレイヤーに追加するには**
1. **[時間ベースのインスタンス]** ページで、すでに時間ベースのインスタンスがある場合、**[\$1 インスタンス]** を選択します。それ以外の場合は、**[時間ベースのインスタンスを追加]** をクリックします。次に、**[既存]** タブを選択します。
![\[既存の時間ベースのインスタンスをレイヤーに追加する\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/time_based_instances_existing.png)
1. **[既存]** タブで、リストからインスタンスを選択します。リストには時間ベースのインスタンスのみが表示されます。
**注記**
既存のインスタンスを使用しなくなった場合は、前述の手順に従って、**[新規]** タブで新しいインスタンスを作成します。
1. **[インスタンスの追加]** を選択して、インスタンスをレイヤーに追加します。
## 時間ベースのインスタンスの構成
レイヤーに時間ベースのインスタンスを追加したら、次のようにスケジュールを設定します。
**時間ベースのインスタンスを設定するには**
1. ナビゲーションペインの **[インスタンス]** で、**[時間ベース]** を選択します。
1. 希望する時間の下にある適切なボックスを入力して、各時間ベースのインスタンスにオンライン期間を指定します。
+ 毎日同じスケジュールを使用するには、**[毎日]** タブを選択し、次にオンライン期間を指定します。
+ 異なる日に異なるスケジュールを使用するには、毎日を選択し、次に適切な期間を選択します。
![\[時間ベーススケーリングのスケジュール\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/time_based.png)
**注記**
インスタンスを起動するのにかかる時間を確保し、 OpsWorks スタックがインスタンスを起動または停止するかどうかを数分ごとにチェックするようにしてください。たとえば、インスタンスを 1 時 (UTC) までに実行する必要がある場合、0 時 (UTC) にそのインスタンスを起動します。そうしないと、 OpsWorks スタックは 1:00 UTC から数分経過するまでインスタンスを起動せず、インスタンスがオンラインになるまでにさらに数分かかることがあります。
上記の手順を実行することで、インスタンスのオンライン期間をいつでも変更できます。次回 OpsWorks スタックがチェックするとき、新しいスケジュールを使用してインスタンスを起動または停止するかどうかを決定します。
**注記**
レイヤーに新しい時間ベースのインスタンスを 追加するには、**[時間ベース]** ページを開き、**[時間ベースのインスタンスを追加]** (レイヤーに時間ベースのインスタンスをまだ追加していない場合) を選択、または **[\$1インスタンス]** (レイヤーにすでに1つ以上の時間ベースのインスタンスがある場合) を選択します。次に、前述の手順で説明したようにインスタンスを構成します。
# 自動負荷ベースのスケーリングの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ロードベースのインスタンスを使用すると、受信トラフィックの変化に応じてインスタンスをすばやく開始または停止できます。 OpsWorks スタックは [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) データを使用して、レイヤーごとに次のメトリクスを計算します。これは、レイヤーのすべてのインスタンスの平均値を表します。
+ CPU: CPU の平均使用率 (例、80%)
+ メモリ: メモリの平均使用率 (例、60%)
+ 負荷: システムが 1 分で実行する平均計算作業。
これらのメトリックスのいずれか、またはすべてに、*上限*しきい値と*下限*しきい値を定義します。カスタム CloudWatch アラームをしきい値として使用することもできます。
しきい値を超えると、*スケーリングイベント*がトリガーされます。以下の内容を指定することで、 OpsWorks スタックがスケーリングイベントに対応する方法を決定します。
+ 起動または停止するインスタンス数。
+ インスタンスを起動または削除する前に OpsWorks 、スタックがしきい値を超えた後に待機する時間。たとえば、CPU 使用率は少なくとも 15 分間はしきい値を超過する必要があります。この値により、トラフィックの短い変動を無視することができます。
+ メトリクスを再度モニタリングする前に OpsWorks 、インスタンスの起動または停止後に スタックが待機する時間。レイヤーが引き続きしきい値を超えているかどうかを評価する前に、起動されたインスタンスがオンラインになる、または停止されたインスタンスがシャットダウンされるまで十分な時間が経過する必要があります。
スケーリングイベントが発生すると、 OpsWorks スタックは負荷ベースのインスタンスのみを開始または停止します。24/7 インスタンスまたは時間ベースのインスタンスは起動または停止されません。
**注記**
負荷ベースの自動スケーリングでは、新しいインスタンスは作成されません。ユーザーが作成したインスタンスのみが起動および停止されます。したがって、予測される最大負荷を処理するのに十分な負荷ベースのインスタンスを事前に備える必要があります。
**負荷ベースのインスタンスを作成するには**
1. **[インスタンス]** ページの **[\$1 インスタンス]** を選択して、インスタンスを追加します。**[アドバンスト]** を選択してから、**[負荷ベース]** を選択します。
![\[[Add instance] ページの負荷ベースのスケーリングオプション\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/load_based_instances.png)
1. インスタンスを設定し、**[\$1 インスタンスを追加]** を選択して、インスタンスをレイヤーに追加します。
必要な数のインスタンスが作成されるまで、この手順を繰り返します。必要に応じて、後からインスタンスを追加または削除することができます。
負荷ベースのインスタンスをレイヤーに追加したら、負荷ベースのスケーリングを可能にし、設定を指定する必要があります。負荷ベースのスケーリング設定はインスタンスのプロパティではなく、レイヤーのプロパティであるため、レイヤーが負荷ベースのインスタンスを起動または停止する時を指定します。負荷ベースのインスタンスを使用するレイヤーごとに個別に指定する必要があります。
**負荷ベースの自動スケーリングを可能にし設定するには**
1. ナビゲーションペインの **[インスタンス]** で **[負荷ベース]** を選択し、続いて適切なレイヤーの **[編集]** を選択します。
![\[レイヤーのインスタンスの編集操作\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/load_based.png)
1. **[Load-based auto scaling enabled]** (負荷ベースの自動スケーリングの有効化) を **[On]** に設定します。次に、しきい値とスケーリングパラメータを設定し、インスタンスを追加する方法とタイミングを定義します。
![\[負荷ベースのスケーリングのしきい値\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/load_based_config.png)
**レイヤー平均しきい値**
スケーリングしきい値は、レイヤーのすべてのインスタンス間で平均された以下の値に基づいて設定できます。
+ **[Average CPU]** (平均CPU) – レイヤーの平均 CPU 使用率 (合計に対する割合)。
+ **[Average memory]** (平均メモリ) – レイヤーの平均メモリ使用率 (合計に対する割合)。
+ **[Average load]** (平均負荷) – レイヤーの平均負荷。
負荷を計算する方法の詳細については、ウィキペディアで [[Load (computing)]](http://en.wikipedia.org/wiki/Load_(computing)) (負荷(コンピューティング)) を参照してください。
しきい値を超えると、スケーリングイベントが発生し、より多くのインスタンスが必要な場合はスケールアップされ、より少ないインスタンスが必要な場合はスケールダウンされます。 OpsWorks その後、 スタックはスケーリングパラメータに基づいてインスタンスを追加または削除します。
** カスタム CloudWatch アラーム**
最大 5 つのカスタム CloudWatch アラームを、アップスケーリングまたはダウンスケーリングのしきい値として使用することができます。これらは、スタックと同じリージョンにある必要があります。カスタムアラームの方法の詳細については、「[Creating Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/AlarmThatSendsEmail.html)」(Amazon CloudWatch アラームの作成) を参照してください。
カスタムアラームを使用するには、サービスロールを更新して `cloudwatch:DescribeAlarms` を許可する必要があります。この機能を初めて使用するときに OpsWorks スタックでロールを更新するか、ロールを手動で編集できます。詳細については、「[OpsWorks スタックがユーザーに代わって動作することを許可する](opsworks-security-servicerole.md)」を参照してください。
負荷ベース設定に複数のアラームが設定されている場合、あるアラームが `INSUFFICIENT_DATA` メトリックアラーム状態になっていると、他のアラームが `ALARM` 状態になっていてもロードベースのインスタンススケーリングができません。オートスケーリングは、すべてのアラームが `OK` or `ALARM` の状態の場合にのみ実行できます。CloudWatch アラームの使用の詳細については、*「Amazon CloudWatch User Guide」*(Amazon CloudWatch ユーザーガイド) の[「Using Amazon CloudWatch alarms」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)(Amazon CloudWatch アラームの使用) を参照してください。
**スケーリングパラメータ**
次のパラメータは OpsWorks 、 スタックがスケーリングイベントを管理する方法を制御します。
+ **[Start servers in batches of]** (サーバをバッチで起動) - スケーリングイベントが発生したときに追加または削除するインスタンスの数。
+ **しきい値を超えた場合** – OpsWorks スタックがスケーリングイベントをトリガーする前に、負荷がアップスケーリングしきい値またはダウンスケーリングしきい値を下回る必要がある時間 (分単位）。
+ **スケーリング後、メトリクスを無視**する – スケーリングイベントの発生後 OpsWorks 、スタックがメトリクスを無視し、追加のスケーリングイベントを抑制する時間 (分単位）。
たとえば、 OpsWorks スタックはアップスケーリングイベント後に新しいインスタンスを追加しますが、インスタンスは起動して設定されるまで負荷の軽減を開始しません。新しいインスタンスがオンラインになってリクエストを処理するまで (通常、これには数分かかります)、追加のスケーリングイベントが発生するポイントはありません。この設定を使用すると、新しいインスタンスがオンラインになるまでの間 OpsWorks スタックにスケーリングイベントを抑制させることができます。
この設定を増やすことで、**[Average CPU]** (平均CPU)、**[Average memory]** (平均メモリ)、**[Average load]** (平均負荷) などのレイヤーの平均値が一時的に不一致になった場合に、スケーリングの急激な変動を防ぐことができます。
例えば、CPU 使用率が制限を超え、メモリ使用量がダウンスケールに近い場合、インスタンスのアップスケールイベントの直後に、メモリのダウンスケールイベントが続く可能性があります。これを回避するには、**[After scaling, ignore metrics]** (スケーリング後、メトリックスを無視する) 設定で分単位で時間を増やすことができます。この例では、CPU のスケーリングが発生しますが、メモリのダウンスケールイベントは発生しません。
1. 負荷ベースのインスタンスを追加するには、**[\$1 Instance]** (\$1 インスタンス) を選択し、設定を行い、**[Add Instance]** (インスタンスを追加) を選択します。予測される最大負荷を処理するのに十分な負荷ベースのインスタンス数になるまで繰り返します。次に、**[Save (保存)]** を選択します。
**注記**
レイヤーに新しい負荷ベースのインスタンスを 追加するには、**[Load-based]** (負荷ベース) ページを開き、**[Add a load-based instance]** (ロードベースインスタンスを追加) (負荷ベースのインスタンスをレイヤーにまだ追加していない場合) を選択するか、**[\$1 Instance]** (\$1 インスタンス) (1 つ以上の負荷ベースのインスタンスがすでにレイヤーにある場合) を選択します。次に、このセクションで前述したように、インスタンスを設定します。
**既存の負荷ベースのインスタンスをレイヤーに追加するには**
1. ナビゲーションペインの **[Instances]** (インスタンス) で、**[Load-based]** (負荷ベース) を選択します。
1. レイヤーの負荷ベースの自動スケーリングをすでに有効にしている場合は、**[\$1 Instance]** (\$1 インスタンス) を選択します。それ以外の場合は、**[Add a load-based instance]** (負荷ベースのインスタンスを追加) を選択します。**[EXisting]** (既存) タブ。
![\[既存の負荷ベースのインスタンスをレイヤーに追加する\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/load_based_instances_existing.png)
1. **[EXisting] **(既存) タブで、インスタンスを選択します。リストには、負荷ベースのインスタンスのみが表示されます。
**注記**
既存のインスタンスを使用しなくなった場合は、**[New]** (新規) タブで、前述の手順に従って新しいインスタンスを作成します。
1. **[Add Instance]** (インスタンスを追加) を選択して、インスタンスをレイヤーに追加します。
いつでも、負荷ベースの自動スケーリングの設定を変更したり、負荷ベースの自動スケーリングを無効にしたりすることができます。
**負荷ベースのスケーリングを無効にするには**
1. ナビゲーションペインの **[Instances]** (インスタンス) で、**[負荷ベース]** (Load-based) を選択してから、適切なレイヤーの **[edit]** (編集) を選択します。
1. **[Load-based auto scaling enabled]** (負荷ベースの自動スケーリングの有効化) を **[No]** (いいえ) に切り替えます。
## 負荷ベースのスケーリングと自動修復の違い
負荷ベースの自動スケーリングは、実行中のすべてのインスタンスで平均される負荷メトリクスを使用します。メトリクスが指定されたしきい値の間にとどまる場合、 OpsWorks スタックはインスタンスを開始または停止しません。一方、自動ヒーリングでは、インスタンスの応答が停止すると、 OpsWorks スタックは同じ設定で新しいインスタンスを自動的に開始します。ネットワークの問題やインスタンスに障害が発生した場合に、インスタンスが応答できない場合があります。
例えば、CPU のアップスケーリングのしきい値が 80% で、1 つのインスタンスが応答を停止するとします。
+ 自動ヒーリングが無効になっており、残りの実行中のインスタンスが平均 CPU 使用率を 80% 未満に維持できる場合、 OpsWorks スタックは新しいインスタンスを起動しません。残りのインスタンス全体で CPU の平均使用率が 80% を超えた場合、代替インスタンスを起動します。
+ 自動ヒーリングが有効になっている場合、 OpsWorks スタックは負荷しきい値に関係なく代替インスタンスを開始します。