翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# でのシステムメンテナンス AWS OpsWorks for Chef Automate
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
必須のシステムメンテナンスにより、セキュリティ更新プログラムを含む最新のマイナーバージョンの Chef Server と Chef Automate Server が常に AWS OpsWorks for Chef Automate サーバーで実行されます。システムメンテナンスは週に 1 回以上実行する必要があります。を使用すると AWS CLI、必要に応じて毎日の自動メンテナンスを設定できます。を使用して AWS CLI 、スケジュールされたシステムメンテナンスに加えて、オンデマンドでシステムメンテナンスを実行することもできます。
Chef ソフトウェアの新しいマイナーバージョンが使用可能になった場合、システムメンテナンスでは、それらが AWS のテストをパスし次第、サーバー上の Chef Automate および Chef Server のマイナーバージョンを自動的に更新するように設計されています。AWS では、Chef のアップグレードが本稼働で問題なく使用でき、お客様の既存の環境を害さないかどうかを検証するために、広範なテストを実行します。そのため、Chef ソフトウェアがリリースされてから、Chef Automate サーバーの既存の OpsWorks に適用できるようになるまで、時間差が生じる場合があります。Chef ソフトウェアの使用可能なマイナーバージョンをオンデマンドで更新するには、このトピックの「[オンデマンドでのシステムメンテナンスの開始](#opscm-maintenance-startdemand)」を参照してください。
システムメンテナンスでは、メンテナンスプロセスの一環として実行されるバックアップから新しいインスタンスを起動します。これにより、定期的なメンテナンスを受ける Amazon EC2 インスタンスの低下や障害によるリスクを軽減することができます。
**重要**
システムメンテナンスでは、 AWS OpsWorks for Chef Automate サーバーに追加したすべてのファイルやカスタム設定が削除されます。失われた設定やファイルを回復する詳しい方法については、このトピックの「[メンテナンス後のカスタム設定およびカスタムファイルの復旧](#opscm-maintenance-restore)」を参照してください。
**Topics**
+ [ノードが OpsWorks 認証機関を信頼していることを確認する](#w2ab1b9c40c15)
+ [システムメンテナンスの設定](#w2ab1b9c40c17)
+ [オンデマンドでのシステムメンテナンスの開始](#opscm-maintenance-startdemand)
+ [メンテナンス後のカスタム設定およびカスタムファイルの復旧](#opscm-maintenance-restore)
## ノードが OpsWorks 認証機関を信頼していることを確認する
**注記**
AWS OpsWorks for Chef Automate サーバーでカスタムドメインと証明書を使用している場合、このセクションのステップは必要ありません。
AWS OpsWorks for Chef Automate サーバーで管理しているノードは、証明書を使用してサーバーで認証する必要があります。システムメンテナンス中、 はサーバーインスタンスを OpsWorks 置き換え、認証局 (CA) を通じて新しい OpsWorks 証明書を再生成します。メンテナンスの完了後にマネージドノードとの通信を自動的に復元するには、ノードはスターターキットに付属し、 でサポートされているリージョンでホストされている OpsWorks CA を信頼する必要があります AWS OpsWorks for Chef Automate。 OpsWorks CA を使用してノードとサーバー間の信頼を確立すると、ノードはメンテナンス後に新しいサーバーインスタンスに再接続されます。で説明されている EC2 `userdata`スクリプトを使用して EC2 ノードを追加する場合[でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md)、ノードはすでに OpsWorks CA を信頼するように設定されています。
+ Linux ベースのノードの場合、CA の S3 バケットの場所は `https://opsworks-cm-${REGION}-prod-default-assets.s3.amazonaws.com/misc/opsworks-cm-ca-2020-root.pem` です。 OpsWorks 信頼された CA はパス に保存する必要があります`/etc/chef/opsworks-cm-ca-2020-root.pem`。
+ Windows ベースのノードの場合、CA の S3 バケットの場所は `https://opsworks-cm-$env:AWS_REGION-prod-default-assets.s3.amazonaws.com/misc/opsworks-cm-ca-2020-root.pem` です。 OpsWorks CA はルート Chef フォルダに保存する必要があります。例: `C:\chef\opsworks-cm-ca-2020-root.pem`
この 2 つのパスで region 変数は次のいずれかに解決されます。
+ `us-east-2`
+ `us-east-1`
+ `us-west-1`
+ `us-west-2`
+ `ap-northeast-1`
+ `ap-southeast-1`
+ `ap-southeast-2`
+ `eu-central-1`
+ `eu-west-1`
## システムメンテナンスの設定
新しい AWS OpsWorks for Chef Automate サーバーを作成するときは、システムメンテナンスを開始するために、[協定世界時](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) (UTC) で曜日と時刻を設定できます。メンテナンスは、指定した時間中に開始します。システムメンテナンス中はサーバーがオフラインになることを想定する必要があるため、通常の営業時間内でサーバー需要が低い時刻を選択します。メンテナンスの進行中は、サーバーのステータスが `UNDER_MAINTENANCE` になります。
次のスクリーンショットに示すように、 AWS OpsWorks for Chef Automate サーバーの設定ページのシステムメンテナンスエリアで設定を変更することで、既存のサーバーの**システムメンテナンス****設定を変更**することもできます。
![\[Chef Automate サーバー設定で [System maintenance] (システムメンテナンス) セクションが表示されています。\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_exist_update_maintenance.png)
**[System maintenance]** セクションで、システムメンテナンスを開始する日付と時刻を設定します。
### を使用したシステムメンテナンスの設定 AWS CLI
システムメンテナンスの自動開始時刻を AWS CLIで設定することもできます。 AWS CLI では、3 文字の平日プレフィックスを省略して、必要に応じて毎日の自動メンテナンスを設定できます。
`create-server` コマンドで、サーバーインスタンスを作成する要件 (インスタンスタイプ、インスタンスプロファイル ARN、サービスロール ARN など) を指定した後で、`--preferred-maintenance-window` パラメータをコマンドに追加します。次の `create-server` の例では、`--preferred-maintenance-window` を `Mon:08:00` に設定しています。これで、毎月曜の午前 8 時 0 分 (UTC) にメンテナンスが開始されます 。
```
aws opsworks-cm create-server --engine "Chef" --engine-model "Single" --engine-version "12" --server-name "automate-06" --instance-profile-arn "arn:aws:iam::1019881987024:instance-profile/aws-opsworks-cm-ec2-role" --instance-type "t2.medium" --key-pair "amazon-test" --service-role-arn "arn:aws:iam::044726508045:role/aws-opsworks-cm-service-role" --preferred-maintenance-window "Mon:08:00"
```
`update-server` コマンドでは、必要に応じて、`--preferred-maintenance-window` の値のみを更新できます。次の例では、メンテナンス時刻を金曜の午後 6 時 15 分 (UTC) に設定しています 。
```
aws opsworks-cm update-server --server-name "shiny-kitchen" --preferred-maintenance-window "Fri:18:15"
```
メンテナンス時間の開始時刻を毎日午後 6 時 15 分 (UTC) に変更するには、次の例に示すように、曜日を表す 3 文字のプレフィックスを省略します。
```
aws opsworks-cm update-server --server-name "shiny-kitchen" --preferred-maintenance-window "18:15"
```
を使用して優先システムメンテナンスウィンドウを設定する方法の詳細については AWS CLI、[「create-server](https://docs.aws.amazon.com/cli/latest/reference/opsworkscm/update-server.html)」と[「update-server](https://docs.aws.amazon.com/cli/latest/reference/opsworkscm/update-server.html)」を参照してください。
## オンデマンドでのシステムメンテナンスの開始
システムメンテナンスをオンデマンドで開始するには、設定した週次または日次自動メンテナンスの外部で、次の AWS CLI コマンドを実行します。 AWS マネジメントコンソールでオンデマンドメンテナンスを開始することはできません。
```
aws opsworks-cm start-maintenance --server-name server_name
```
このコマンドの詳細については、[「start-maintenance」](https://docs.aws.amazon.com/cli/latest/reference/opsworkscm/start-maintenance.html)を参照してください。
## メンテナンス後のカスタム設定およびカスタムファイルの復旧
システムメンテナンスでは、 AWS OpsWorks for Chef Automate サーバーに追加したカスタムファイルまたは設定を削除または変更できます。
`RunCommand` または SSH を使用して追加したファイルや設定がメンテナンスの実行後に Chef サーバーに見つからない場合は、Amazon マシンイメージ (AMI) を使用して、新しい Amazon EC2 インスタンスを起動できます。サーバーのメンテナンス前の設定に基づいて構築された AMI を利用できます。
新しいインスタンスは、メンテナンス前の Chef サーバーと同じ状態であり、見つからないファイルや設定が含まれています。
**重要**
新しいインスタンスを使用してサーバーを復元することはできません。インスタンスを Chef サーバーとして実行することはできません。インスタンスは、ファイルや設定の復旧にのみ使用できます。
AMI から EC2 インスタンスを起動するには、Amazon EC2 コンソールで [**Launch**] (起動) ウィザードを開き、**[My AMIs]** (マイAMI) を選択して、サーバー名と同じ名前の AMI を選択します。他の任意のインスタンスを起動する手順と同様に、Amazon EC2 ウィザードの手順に従います。