翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 サポート チームにお問い合わせください。
AWS OpsWorks for Chef Automate では、AWS で [Chef Automate](https://www.chef.io/automate/) サーバーを実行できます。Chef サーバーを数分でプロビジョニングし、 がそのオペレーション、バックアップ、復元、ソフトウェアアップグレード AWS OpsWorks for Chef Automate を処理できます。 を使用すると、Chef サーバーを管理する代わりに、コア設定管理タスクに集中 AWS OpsWorks for Chef Automate できます。
Chef Automate サーバーは、ノードに対して実行する Chef レシピを [https://docs.chef.io/chef_client.html](https://docs.chef.io/chef_client.html) に指示します。また、ノードに関する情報を保存し、Chef クックブックの中央リポジトリとして機能します。 AWS OpsWorks for Chef Automate は、Chef Automate の優れた機能 (Chef Infra と Chef InSpec) を含む Chef サーバーを提供します。
AWS OpsWorks for Chef Automate サーバーは Amazon Elastic Compute Cloud インスタンスで実行されます。 AWS OpsWorks for Chef Automate サーバーは、最新バージョンの Amazon Linux (Amazon Linux 2) を実行するように設定されています。Chef Automate のこのバージョンの変更については、「[Chef Automate リリースノート](https://automate.chef.io/release-notes/?v=20190415203801)」を参照してください。次の表は、 AWS OpsWorks for Chef Automate サーバーにインストールされている Chef コンポーネントを示しています。
| コンポーネント名 | 説明 | AWS OpsWorks for Chef Automate サーバーにインストールされているバージョン |
| --- | --- | --- |
| Chef Automate | Chef Automate は、継続的デプロイのための自動化されたワークフローを提供し、管理対象ノードに関する洞察をウェブベースのマネジメントコンソールに表示する、エンタープライズサーバーソフトウェアパッケージです。Chef Automate は、Chef Infra を含むことによりインフラストラクチャを自動化します。また、Chef InSpec を含むことによりセキュリティおよびコンプライアンスに関する情報を提供します。さらに、Chef Habitat を含むことによりデプロイを自動化します。 Chef Automate の詳細については、Chef のウェブサイトの「[Chef Automate](https://www.chef.io/products/automate/)」を参照してください。 | 2.0 |
| Chef Infra | Chef Infra Server (旧称 Chef Server) は、Chef Infra クライアント (`chef-client`) エージェントを使用して、管理対象ノードに設定を継続的に適用することで、目的の状態を維持します。 Infra の詳細については、Chef のウェブサイトの「[Chef Infra](https://www.chef.io/products/chef-infra/)」を参照してください。 | 12.x |
| Chef InSpec | Chef InSpec は、ソフトウェアエンジニア、運用部門、セキュリティエンジニアの間で共有できるセキュリティとコンプライアンスのルールを定義します。コンプライアンス、セキュリティ、その他のポリシー要件により、`chef-client` エージェントが管理対象ノードに対して実行できる自動テストのフレームワークが形成され、標準の一貫した実施が確実になります。 InSpec の詳細については、Chef のウェブサイトの「[Chef InSpec](https://www.chef.io/products/chef-inspec/)」を参照してください。 | 3.9.0 |
AWS OpsWorks for Chef Automate サーバーに関連付けられているノードでサポートされている `chef-client` の最小バージョンは 13.*x* です。少なくとも 14.10.9、または最新の安定`chef-client`バージョンを実行することをお勧めします。
Chef ソフトウェアの新しいマイナーバージョンが使用可能になった場合、システムメンテナンスでは、それらが AWS のテストをパスし次第、サーバー上の Chef Automate および Chef Server のマイナーバージョンを自動的に更新するように設計されています。AWS では、Chef のアップグレードが本稼働で問題なく使用でき、お客様の既存の環境を害さないかどうかを検証するために、広範なテストを実行します。そのため、Chef ソフトウェアがリリースされてから、Chef Automate サーバーの既存の OpsWorks に適用できるようになるまで、時間差が生じる場合があります。また、システムメンテナンスでは、ご使用のサーバーを Amazon Linux の最新バージョンにアップグレードします。
サポートされているオペレーティングシステムを実行し、 AWS OpsWorks for Chef Automate サーバーへのネットワークアクセスを持つオンプレミスのコンピュータまたは EC2 インスタンスに接続できます。お客様が管理するノードに対応するオペレーティングシステムの一覧は、[Chef のウェブサイト](https://docs.chef.io/platforms.html)を参照してください。[https://docs.chef.io/chef_client.html](https://docs.chef.io/chef_client.html) エージェントソフトウェアは Chef サーバーで管理したいノードにインストールされます。
**Topics**
+ [のリージョンサポート AWS OpsWorks for Chef Automate](#opscm-region)
+ [AWS OpsWorks Chef Automate のサポート終了に関するFAQs](opscm-eol-faqs.md)
+ [AWS OpsWorks for Chef Automate サーバーを Chef Automate 2 にアップグレードする](opscm-a2upgrade.md)
+ [の開始方法 AWS OpsWorks for Chef Automate](gettingstarted-opscm.md)
+ [を使用して AWS OpsWorks for Chef Automate サーバーを作成する CloudFormation](opscm-create-server-cfn.md)
+ [カスタムドメインを使用するように AWS OpsWorks for Chef Automate サーバーを更新する](opscm-update-server-custom-domain.md)
+ [AWS OpsWorks for Chef Automate サーバーのスターターキットを再生成する](opscm-regenerate-starterkit.md)
+ [AWS OpsWorks for Chef Automate リソースでのタグの使用](opscm-tags.md)
+ [AWS OpsWorks for Chef Automate サーバーのバックアップと復元](opscm-backup-restore.md)
+ [でのシステムメンテナンス AWS OpsWorks for Chef Automate](opscm-maintenance.md)
+ [でのコンプライアンススキャン AWS OpsWorks for Chef Automate](opscm-chefcompliance.md)
+ [AWS OpsWorks for Chef Automate サーバーからノードの関連付けを解除する](opscm-disassociate-node.md)
+ [AWS OpsWorks for Chef Automate サーバーを削除する](opscm-delete-server.md)
+ [Chef Automate ダッシュボードの認証情報のリセット](opscm-resetchefcreds.md)
+ [を使用した AWS OpsWorks for Chef Automate API コールのログ記録 AWS CloudTrail](logging-opsca-using-cloudtrail.md)
+ [トラブルシューティング AWS OpsWorks for Chef Automate](troubleshoot-opscm.md)
## のリージョンサポート AWS OpsWorks for Chef Automate
次のリージョンエンドポイントは AWS OpsWorks for Chef Automate servers をサポートしています。 は、インスタンスプロファイル、ユーザー、サービスロールなど、Chef サーバーに関連付けられているリソースを、Chef サーバーと同じリージョンエンドポイントに AWS OpsWorks for Chef Automate 作成します。Chef サーバーは VPC 内にある必要があります。作成するかすでに作成してある VPC を使用することも、デフォルトの VPC を使用することもできます。
+ 米国東部 (オハイオ) リージョン
+ 米国東部(バージニア州北部) リージョン
+ US West (N. California) Region
+ 米国西部 (オレゴン) リージョン
+ Asia Pacific (Tokyo) Region
+ アジアパシフィック (シンガポール) リージョン
+ アジアパシフィック (シドニー) リージョン
+ 欧州 (フランクフルト) リージョン
+ 欧州 (アイルランド) リージョン
# AWS OpsWorks Chef Automate のサポート終了に関するFAQs
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。
**Topics**
+ [このサポート終了により、既存のユーザーはどのような影響を受けますか?](#w2ab1b9c23b7)
+ [何もアクションを実行しない場合サーバーはどうなりますか?](#w2ab1b9c23b9)
+ [どのような代替案に移行できますか?](#w2ab1b9c23c11)
+ [このサービスはまだ新規顧客を受け入れていますか？](#w2ab1b9c23c13)
+ [End of Life はすべての AWS リージョン に同時に影響しますか?](#w2ab1b9c23c15)
+ [どのレベルのテクニカルサポートが受けられますか?](#w2ab1b9c23c17)
+ [私は現在 OpsWorks for Chef Automate の顧客で、以前はサービスを使用していなかったアカウントでサーバーを起動する必要があります。これはできますか?](#w2ab1b9c23c19)
+ [来年に主要な特徴量のリリースは行われますか？](#w2ab1b9c23c21)
## このサポート終了により、既存のユーザーはどのような影響を受けますか?
既存のお客様は、 OpsWorks for Chef Automate のサポート終了日である 2024 年 5 月 5 日まで影響を受けません。サポート終了日を過ぎると、お客様は OpsWorks コンソールまたは API を使用してサーバーを管理できなくなります。
## 何もアクションを実行しない場合サーバーはどうなりますか?
2024 年 5 月 5 日以降、 OpsWorks コンソールまたは API を使用しているサーバーを管理できなくなります。その時点で、バックアップやメンテナンスなど、サーバーの継続的な管理機能の実行は停止されます。お客様への影響を抑えるため、 Chef Automate サーバーをバックアップしている EC2 インスタンスを実行したままにします。しかし、その使用は Chef との間の OpsWorks for Chef Automate サービス契約の対象 (または請求) ではなくなったため、そのライセンスは無効になります。[Chef](https://www.chef.io/products/chef-saas/aws-opsworks-support) に連絡して新しいライセンスを取得する必要があります。シェフに連絡するときは、必ず OpsWorks for Chef Automate の既存顧客であり、 OpsWorks から移行する予定であることを伝えてください。
## どのような代替案に移行できますか?
AWS と Progress Chef では、フルマネージド型の Chef Automate サービスのメリットを引き続き享受できるように、新しい Chef SaaS サービスに移行することをお勧めします。Chef SaaS を使い始めるには、[Chef](https://www.chef.io/products/chef-saas/aws-opsworks-support) に連絡して Chef SaaS アカウントの設定方法やデータとノードの移行方法に関するドキュメントを入手してください。
管理する AWS アカウントの EC2 インスタンスで Chef Automate を実行するために Chef SaaS がニーズを満たさない場合、Chef には、[AWS Marketplace Bring Your Own License (BYOL) モデル](https://aws.amazon.com/marketplace/pp/prodview-r26bs6uknftps)や EC2 でのセルフホスティングなど、複数のオプションが用意されています。このような移行を実行する方法の詳細については、[Progress Chef](https://www.chef.io/products/chef-saas/aws-opsworks-support) にお問い合わせください。
## このサービスはまだ新規顧客を受け入れていますか？
いいえ。 AWS OpsWorks for Chef Automate は新規顧客を受け入れなくなりました。
## End of Life はすべての AWS リージョン に同時に影響しますか?
はい。API とコンソールは 2024 年 5 月 5 日をもってサポート終了となり、すべての AWS リージョンを使用できなくなります。for Chef Automate が利用可能な の詳細については、[AWS 「リージョンサービスリスト](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) AWS リージョン AWS OpsWorks 」を参照してください。
## どのレベルのテクニカルサポートが受けられますか?
AWS は、お客様がサポート終了日まで現在持っているのと同じレベルのサポートを OpsWorks for Chef Automate に引き続き提供します。ご質問やご不明点がございましたら、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。移行サポートについては、お客様が [Progress Chef](https://www.chef.io/products/chef-saas/aws-opsworks-support) に連絡することをお勧めします。
## 私は現在 OpsWorks for Chef Automate の顧客で、以前はサービスを使用していなかったアカウントでサーバーを起動する必要があります。これはできますか?
例外的な事情がない限り、一般的にはできません。特別な状況が発生した場合は、[AWS re:Post](https://repost.aws/) または [AWS Premium Support](https://aws.amazon.com/support) を通じて AWS サポート チームに連絡し、その詳細と根拠を説明して、リクエストを確認します。
## 来年に主要な特徴量のリリースは行われますか？
いいえ。サービスのサポート終了が近づいているため、新特徴量のリリースは行いません。しかし、サポート終了日までは、引き続きセキュリティの改善とサーバーの管理を予定どおりに行います。
# AWS OpsWorks for Chef Automate サーバーを Chef Automate 2 にアップグレードする
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
## Chef Automate 2 にアップグレードするための前提条件
開始する前に、Chef Automate 2 で新しく追加される機能と、Chef Automate 2 でサポートされない機能を確認してください。Chef Automate 2 の新しい機能およびサポートされない機能については、Chef ウェブサイトにある [Chef Automate 2 のドキュメント](https://automate.chef.io/docs/upgrade/#considerations)を参照してください。
Chef Automate 1 を実行しているサーバーがアップグレード対象となるには、2019 年 11 月 1 日以降に少なくとも 1 つのメンテナンスが正常に実行されている必要があります。
AWS OpsWorks for Chef Automate サーバーのメンテナンスオペレーションと同様に、サーバーはアップグレード中にオフラインになります。アップグレードプロセス中に最大 3 時間のダウンタイムを予定する必要があります。
Chef Automate ダッシュボードウェブサイト用として、このサーバーのサインイン認証情報が必要です。アップグレードが完了したら、Chef Automate ダッシュボードにサインインし、ノードおよび設定情報が変更されていないことを確認します。
**重要**
AWS OpsWorks for Chef Automate サーバーを Chef Automate 2 にアップグレードする準備ができたら、ここでの手順のみを使用してアップグレードします。はバックアップの作成など、多くのアップグレードプロセス AWS OpsWorks for Chef Automate を自動化するため、Chef ウェブサイトのアップグレード指示に従わないでください。
## アップグレードプロセスについて
アップグレードプロセスでは、アップグレードの開始前と終了後にサーバーがバックアップされます。次のバックアップが作成されます。
+ Chef Automate 1 (バージョン 12.17.33) を実行しているサーバーのバックアップ。
+ アップグレードの終了後に Chef Automate 2 (バージョン 2019-08) を実行しているサーバーのバックアップ。
アップグレードプロセスでは、サーバーで Chef Automate 1 を実行したときに使用していた Amazon EC2 インスタンスが終了します。Chef Automate 2 サーバーを実行するための新しいインスタンスが作成されます。
## Chef Automate 2 にアップグレードする (コンソール)
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) で OpsWorks コンソールを開きます。
1. 左側のナビゲーションペインで、[**AWS OpsWorks for Chef Automate**] を選択します。
1. サーバーを選択して、そのプロパティページを表示します。ページの上部にある青いバナーは、サーバーが Chef Automate 2 へのアップグレード対象であるかどうかを示します。
**注記**
Chef Automate 1 を実行しているサーバーがアップグレード対象となるには、2019 年 11 月 1 日以降に少なくとも 1 つのメンテナンスが正常に実行されている必要があります。
1. サーバーがアップグレード対象である場合は、[**Start upgrade**] を選択します。
1. アップグレードには最大 3 時間かかります。アップグレードプロセス中は、プロパティページにサーバーのステータスとして [**Under maintenance**] と表示されます。
1. アップグレードが完了すると、プロパティページにメッセージとして、[**Successfully upgraded to Automate 2**] と [**Maintenance completed successfully**] の 2 つが表示されます。サーバーのステータスは [**HEALTHY**] となります。
1. 既存の認証情報を使用して Chef Automate ダッシュボードにサインインし、ノードが正しくレポートすることを確認します。
## Chef Automate 2 にアップグレードする (CLI)
1. (オプション) アップグレードの対象となる AWS OpsWorks for Chef Automate サーバーがわからない場合は、次のコマンドを実行します。デフォルトの AWS リージョンとは異なる AWS リージョンの AWS OpsWorks for Chef Automate サーバーを一覧表示する場合は、必ず `--region`パラメータを追加してください。
```
aws opsworks-cm describe-servers
```
表示された結果で、`true` 属性の値が `CHEF_MAJOR_UPGRADE_AVAILABLE` であるものを探します。これは、サーバーが Chef Automate 2 へのアップグレード対象であることを示します。アップグレードの対象となる AWS OpsWorks for Chef Automate サーバーの名前を書き留めます。
1. server*\$1name* を AWS OpsWorks for Chef Automate サーバーの名前に置き換えて、次のコマンドを実行します。定期的なシステムメンテナンスを実行せずに Chef Automate 2 にアップグレードする場合は、コマンドに示すように `CHEF_MAJOR_UPGRADE` エンジン属性を追加します。ターゲットサーバーがデフォルトの AWS リージョンにない場合は、`--region` パラメータを追加します。1 つのコマンドでアップグレードできるサーバーは 1 つだけです。
```
aws opsworks-cm start-maintenance --server-name server_name --engine-attributes Name=CHEF_MAJOR_UPGRADE,Value=true --region region
```
が何らかの理由でサーバーをアップグレード AWS OpsWorks for Chef Automate できない場合、このコマンドは検証例外になります。
1. アップグレードには最大 3 時間かかります。次のコマンドを実行すると、定期的にアップグレードのステータスを確認できます。
```
aws opsworks-cm describe-servers --server-name server_name
```
表示された結果で、`Status` 値を探します。`Status` が `UNDER_MAINTENANCE` である場合は、アップグレードがまだ進行中であることを示します。アップグレードに成功すると、次のようなメッセージが返されます。
```
2019/10/24 00:27:56 UTC Successfully upgraded to Automate 2.
2019/10/23 23:50:38 UTC Upgrading Chef server from Automate 1 to Automate 2
```
アップグレードが失敗した場合、 は自動的にサーバーを Chef Automate 1 に AWS OpsWorks for Chef Automate ロールバックします。
アップグレードには成功したが、サーバーがアップグレード前と同じように動作しない場合 (たとえば、マネージドノードがレポートしない場合) は、サーバーを手動でロールバックできます。手動のロールバックについては、「[AWS OpsWorks for Chef Automate サーバーを Chef Automate 1 にロールバックする (CLI)](#opscm-a2upgrade-rollback-cli)」を参照してください。
## AWS OpsWorks for Chef Automate サーバーを Chef Automate 1 にロールバックする (CLI)
アップグレードプロセスが失敗した場合、 は自動的にサーバーを Chef Automate 1 に AWS OpsWorks for Chef Automate ロールバックします。アップグレードは成功したが、サーバーがアップグレード前と同じように機能していない場合は、 を使用して AWS OpsWorks for Chef Automate 手動で Chef Automate 1 にサーバーをロールバックできます AWS CLI。
1. 次のコマンドを実行して、アップグレードの試行前にサーバーで実行された最後のバックアップの `BackupId` を表示します。サーバーがデフォルトの AWS リージョンとは異なる AWS リージョンにある場合は、`--region` パラメータを追加します。
```
aws opsworks-cm describe-backups server_name
```
バックアップ ID は、*ServerName-yyyyMMddHHmmssSSS* という形式になっています。表示された結果で、次の Chef Automate 1 のプロパティを探します。
```
"Engine": "Chef"
"EngineVersion": "12.17.33"
```
1. ステップ 1 で返されたバックアップ ID を `--backup-id` の値として使用し、次のコマンドを実行します。
```
aws opsworks-cm restore-server --server-name server_name --backup-id ServerName-yyyyMMddHHmmssSSS
```
サーバーに保存したデータの量に応じて、サーバーの復元には 20 分～3 時間ほどかかります。復元中のサーバーのステータスは `RESTORING` になります。このステータスは、 のサーバーのプロパティページに表示され AWS マネジメントコンソール、 **describe-servers** コマンドの結果に返されます。
1. 復元が完了すると、コンソールに [**Restore completed successfully**] というメッセージが表示されます。 AWS OpsWorks for Chef Automate サーバーはオンラインであり、アップグレードプロセスを開始する前と同じです。
## 以下の資料も参照してください。
+ [でのシステムメンテナンス AWS OpsWorks for Chef Automate](opscm-maintenance.md)
+ [バックアップから AWS OpsWorks for Chef Automate サーバーを復元する](opscm-chef-restore.md)
+ 「*[https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DescribeServers.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DescribeServers.html) API リファレンス*」の「OpsWorks 」
+ 「*[https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_StartMaintenance.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_StartMaintenance.html) API リファレンス*」の「OpsWorks 」
# の開始方法 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 サポート チームにお問い合わせください。
AWS OpsWorks for Chef Automate では、[Chef Automate](https://www.chef.io/automate/) サーバーを で実行できます AWS。約 15 分で Chef サーバーをプロビジョニングできます。
2021 年 5 月 3 日以降、 は一部の Chef Automate サーバー属性を に AWS OpsWorks for Chef Automate 保存します AWS Secrets Manager。詳細については、「[との統合 AWS Secrets Manager](data-protection.md#data-protection-secrets-manager)」を参照してください。
次のチュートリアルは、 で最初の Chef サーバーを作成するのに役立ちます AWS OpsWorks for Chef Automate。
## 前提条件
開始する前に、以下の前提条件を満たしている必要があります
**Topics**
+ [VPC のセットアップ](#set-up-vpc)
+ [カスタムドメインを使用するための前提条件 (オプション)](#gettingstarted-opscm-prereq-customdomain)
+ [EC2 のキーペアをセットアップする (オプション)](#gettingstarted-opscm-prereq-keypair)
### VPC のセットアップ
AWS OpsWorks for Chef Automate サーバーは Amazon Virtual Private Cloud で動作する必要があります。既存の VPC にそのサーバーを追加するか、デフォルトの VPC を使用するか、またはそのサーバーを含めて新しい VPC を作成します。Amazon VPC の情報および新しい VPC の作成方法については、[「Amazon VPC 入門ガイド」](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/)を参照してください。
独自の VPC を作成するか、既存の VPC を使用する場合、VPC には次の設定またはプロパティが必要です。
+ VPC には少なくとも 1 つのサブネットが必要です。
AWS OpsWorks for Chef Automate サーバーがパブリックにアクセスできる場合は、サブネットをパブリックにし、**パブリック IP の自動割り当て**を有効にします。
+ [**DNS resolution**] は有効である必要があります。
+ サブネットで、[**Auto-assign public IP**] を有効にします。
### カスタムドメインを使用するための前提条件 (オプション)
独自のドメインで Chef Automate サーバーをセットアップし、サーバーのエンドポイントとして使用するカスタムドメインのパブリックエンドポイントを指定できます。カスタムドメインを使用する場合は、このセクションで詳しく説明するように、次のすべてが必要です。
**Topics**
+ [カスタムドメインをセットアップする](#gettingstarted-opscm-prereq-domain)
+ [証明書を取得する](#gettingstarted-opscm-prereq-cert)
+ [プライベートキーを取得する](#gettingstarted-opscm-prereq-privatekey)
#### カスタムドメインをセットアップする
独自のカスタムドメインで Chef Automate サーバーを実行するには、`https://aws.my-company.com` などサーバーのパブリックエンドポイントが必要です。カスタムドメインを指定する場合は、前のセクションで説明したように、証明書とプライベートキーも指定する必要があります。
作成後にサーバーにアクセスするには、優先 DNS サービスに CNAME DNS レコードを追加します。このレコードは、Chef Automate サーバーの作成プロセスで生成されるエンドポイント (サーバーの `Endpoint` 属性の値) にカスタムドメインをポイントしている必要があります。サーバーがカスタムドメインを使用している場合は、生成された `Endpoint` 値を使用してサーバーにアクセスできません。
#### 証明書を取得する
独自のカスタムドメインで Chef Automate サーバーをセットアップするには、PEM 形式の HTTPS 証明書が必要です。これは、単一の自己署名証明書、または証明書チェーンです。[**Create Chef Automate server (Chef Automate サーバーの作成)**] ワークフローを完了するときに、この証明書を指定する場合は、カスタムドメインとプライベートキーも指定する必要があります。
証明書の値の要件は次のとおりです。
+ 自己署名証明書、カスタム証明書、または完全な証明書チェーンを指定できます。
+ 証明書は、有効な X509 証明書、または PEM 形式の証明書チェーンである必要があります。
+ 証明書はアップロード時に有効である必要があります。有効期間の開始 (証明書の `NotBefore` 日付) 前、または有効期間の終了 (証明書の `NotAfter` 日) 後に証明書を使用することはできません。
+ 証明書の共通名またはサブジェクトの代替名 (SAN) が存在する場合は、カスタムドメインの値と一致する必要があります。
+ 証明書は、[**Custom private key (カスタムプライベートキー)**] フィールドの値と一致する必要があります。
#### プライベートキーを取得する
独自のカスタムドメインで Chef Automate サーバーをセットアップするには、HTTPS を使用してサーバーに接続するための PEM 形式のプライベートキーが必要です。プライベートキーは暗号化しないでください。パスワードやパスフレーズで保護することはできません。カスタムプライベートキーを指定する場合は、カスタムドメインと証明書も指定する必要があります。
### EC2 のキーペアをセットアップする (オプション)
Chef サーバーの通常の管理では、SSH 接続は不要であり、推奨されていません。[https://docs.chef.io/knife.html](https://docs.chef.io/knife.html) コマンドを使用して、Chef サーバーに対するほとんどの管理タスクを実行できます。
Chef Automate ダッシュボードのサインインパスワードがわからなくなった場合や変更する場合には、SSH を使用してサーバーに接続する際に EC2 のキーペアが必要です。その場合は、既存のキーペアを使用するか、または新しいキーペアを作成できます。EC2 の新しい EC2 のキーペアの作成方法の詳細については、[「Amazon EC2 Key Pairs」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)(Amazon EC2 のキーペア) を参照してください。
EC2 のキーペアが必要なければ、Chef サーバーを作成する準備ができています。
# 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 サーバーは、 AWS OpsWorks for Chef Automate コンソールまたは を使用して作成できます AWS CLI。
**Topics**
+ [で Chef Automate サーバーを作成する AWS マネジメントコンソール](#gettingstarted-opscm-create-console)
+ [を使用して Chef Automate サーバーを作成する AWS CLI](#gettingstarted-opscm-create-cli)
## で Chef Automate サーバーを作成する AWS マネジメントコンソール
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) で OpsWorks コンソールを開きます。
1. OpsWorks ホームページで、**OpsWorks for Chef Automate に移動します**。
![\[OpsWorks サービスホーム\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opspup_day0.png)
1. AWS OpsWorks for Chef Automate ホームページで、**Chef Automate サーバーの作成**を選択します。
![\[Chef Automate サーバーのホーム\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_dashboardhome.png)
1. [**Set name, region, and type**] ページで、サーバーの名前を指定します。Chef サーバー名は 40 文字以内で、英数字とハイフンのみを使用できます。サポートされているリージョンを選択し、管理するノード数をサポートしているインスタンスタイプを選択します。サーバーを作成した後でも、必要に応じてインスタンスタイプを変更できます。このウォークスルーでは、米国西部 (オレゴン) で **[m5.large]** インスタンスタイプを作成します。[**次へ**] を選択します。
![\[[Set name, region, and type] ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_setname.png)
1. [**Configure server (サーバーの構成)**] ページで、キーペア名を指定しない場合は、[**SSH key (SSH キー)**] ドロップダウンリストでデフォルトの選択のままにします。
![\[[Select an SSH key] ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_keypair.png)
1. サーバーを独自のカスタムドメインで使用しない場合は、[**Specify server endpoint (サーバーエンドポイントを指定)**] をデフォルトの [**Use an automatically-generated endpoint (自動的に生成されたエンドポイントを指定する)**] のままにして、[**Next (次へ)**] を選択します。カスタムドメインを設定するには、次のステップに進みます。
![\[サーバーエンドポイントの指定セクション\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_use_auto_endpoint.png)
1. カスタムドメインを使用するには、[**Specify server endpoint (サーバーエンドポイントを指定)**] で、ドロップダウンリストから [**Use a custom domain (カスタムドメインを使用)**] を選択します。
![\[カスタムドメイン名を使用する\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_use_custom_domain.png)
1. [**Fully qualified domain name (FQDN) (完全修飾ドメイン名 (FQDN))**] で、FQDN を指定します。使用するドメイン名を所有している必要があります。
1. [**SSL certificate**] (SSL 証明書) に、PEM 形式の証明書全体を貼り付けます。この証明書は `–––--BEGIN CERTIFICATE-----` で始まり、`–––--END CERTIFICATE-----` で終わります。SSL 証明書のサブジェクトは、前のステップで入力した FQDN と一致する必要があります。
1. [**SSL private key**] (SSL プライベートキー) には、RSA プライベートキー全体を貼り付けます。このプライベートキーは `–––--BEGIN RSA PRIVATE KEY-----` で始まり、`–––--END RSA PRIVATE KEY-----` で終わります。SSL プライベートキーは、前のステップで入力した SSL 証明書のパブリックキーと一致する必要があります。[**次へ**] を選択します。
1. [**Configure Advanced Settings**] (詳細設定の設定) ページの [**Network and Security**] (ネットワークとセキュリティ) 領域で、VPC、サブネット、および 1 つ以上のセキュリティグループを選択します。VPC の要件を以下に示します。
+ VPC には、少なくとも 1 つのパブリックサブネットが必要です。
+ DNS 解決を有効にする必要があります。
+ [**Auto-assign public IP (パブリック IP の自動割り当て)**] を、パブリックサブネット上で有効にする必要があります。
OpsWorks は、使用するセキュリティグループ、サービスロール、インスタンスプロファイルがまだない場合は、生成できます。サーバーは複数のセキュリティグループのメンバーにできます。このページから次に進んだ後に、Chef サーバーのネットワーク設定およびセキュリティ設定を変更することはできません。
![\[[Network and Security]\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_networksec.png)
1. **[System maintenance]** セクションで、システムメンテナンスを開始する日付と時刻を設定します。システムメンテナンス中はサーバーがオフラインになることを想定する必要があるため、通常の営業時間内でサーバー需要が低い時刻を選択します。接続されたノードは、メンテナンスが完了するまで `pending-server` 状態になっています。
メンテナンス時間は必須です。または APIs を使用して AWS マネジメントコンソール AWS CLI、開始日時を後で変更できます。
![\[[System maintenance]\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_sysmaint.png)
1. バックアップを設定します。デフォルトでは、自動バックアップが有効になっています。自動バックアップを開始する頻度と時刻を設定し、Amazon Simple Storage Service に保存するバックアップの世代数を設定します。最大 30 個のバックアップが保持されます。最大値に達すると、 は最も古いバックアップ AWS OpsWorks for Chef Automate を削除して、新しいバックアップ用のスペースを確保します。
![\[[Automatic backups(自動バックアップ)]\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_backupconfig.png)
1. (オプション) [**Tags**] (タグ) で、サーバーおよび関連リソース (EC2 インスタンス、Elastic IP アドレス、セキュリティグループ、S3 バケット、バックアップなど) にタグを追加します。 AWS OpsWorks for Chef Automate サーバーのタグ付けの詳細については、「」を参照してください[AWS OpsWorks for Chef Automate リソースでのタグの使用](opscm-tags.md)。
1. 詳細設定が完了したら、[**Next**] を選択します。
1. **[確認]** ページで選択内容を確認します。サーバーを作成する準備ができたら、[**Launch**] を選択します。
Chef サーバーの作成 OpsWorks を待っている間に、 に移動[スターターキットを使用して Chef サーバーを設定する](opscm-starterkit.md)し、スターターキットと Chef Automate ダッシュボード認証情報をダウンロードします。これらをダウンロードするために、サーバーがオンラインになるまで待つ必要はありません。
サーバーの作成が完了すると、 AWS OpsWorks for Chef Automate のホームページで、Chef サーバーが [**online**] のステータスになり、利用可能になります。サーバーがオンラインになると、Chef Automate ダッシュボードがサーバーのドメインで `https://your_server_name-random.region.opsworks-cm.io` の形式の URL で利用できます。
## を使用して Chef Automate サーバーを作成する AWS CLI
AWS CLI コマンドを実行して AWS OpsWorks for Chef Automate サーバーを作成することは、 コンソールでのサーバーの作成とは異なります。コンソールで、使用する既存のロールを指定しない場合、 はサービスロールとセキュリティグループ OpsWorks を作成します。では AWS CLI、セキュリティグループを指定しない場合は作成 OpsWorks できますが、サービスロールは自動的に作成されません。`create-server`コマンドの一部としてサービスロール ARN を指定する必要があります。コンソールで、 OpsWorks が Chef Automate サーバーを作成している間、Chef Automate スターターキットと Chef Automate ダッシュボードのサインイン認証情報をダウンロードします。を使用してサーバー AWS OpsWorks for Chef Automate を作成するときにこれを行うことはできないため AWS CLI、JSON 処理ユーティリティを使用して、新しい AWS OpsWorks for Chef Automate サーバーがオンラインになった後の`create-server`コマンドの結果からサインイン認証情報とスターターキットを取得します。または、新しい AWS OpsWorks for Chef Automate サーバーがオンラインになった後、コンソールでサインイン認証情報の新しいセットと新しいスターターキットを生成できます。
ローカルコンピュータで がまだ実行されていない場合は AWS CLI、*AWS コマンドラインインターフェイスユーザーガイド* AWS CLI [のインストール手順に従って](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)、 をダウンロードしてインストールします。このセクションでは、`create-server` コマンドで使用できるパラメータのすべては説明しません。`create-server` パラメータの詳細については、「[`create-server` リファレンス](https://docs.aws.amazon.com/cli/latest/reference/opsworks-cm/create-server.html)」の「*AWS CLI *」を参照してください。
1. 必ず前提条件、特に「[VPC のセットアップ](gettingstarted-opscm.md#set-up-vpc)」を満たしてください。または、使用する既存の VPC があることを確認してください。Chef Automate サーバーを作成するには、サブネット ID が必要です。
1. 必要に応じて、Chef の中枢キーを [OpenSSL](https://www.openssl.org/) を使用して作成し、そのキーをローカルコンピュータ上の安全で便利なファイルに保存してください。中枢キーは、`create-server` コマンドで指定しない場合は、サーバー作成プロセスの一部として自動的に生成されます。このステップをスキップする場合は、代わりに、`create-server` コマンドにより生成される Chef Automate 主要キーを取得できます。Chef Automate 主要キーの値は、RSA キーペアの公開鍵に相当するため、下記のコマンドを使用して主要キーを生成する場合は、必ず `-pubout` パラメータを含めてください。詳細については、ステップ 6 を参照してください。
```
umask 077
openssl genrsa -out "pivotal" 2048
openssl rsa -in "pivotal" -pubout
```
1. サービスロールとインスタンスプロファイルを作成します。
1. アカウント内のサービスロールARNs を検索してコピーします。
```
aws iam list-roles --path-prefix "/service-role/" --no-paginate
```
`list-roles` コマンドの結果内で、次のようなサービスロール ARN のエントリを探します。サービスロール ARN を書き留めます。Chef Automate サーバーを作成するにはこれらの値が必要です。
1. アカウントでインスタンスプロファイルの ARN を検索してコピーします。
```
aws iam list-instance-profiles --no-paginate
```
`list-instance-profiles` コマンドの結果内で、次のようなインスタンスプロファイル ARN のエントリを探します。インスタンスプロファイルの ARN を書き留めます。Chef Automate サーバーを作成するにはこれらの値が必要です。
1. `create-server` コマンドを実行して AWS OpsWorks for Chef Automate サーバーを作成します。
+ `--engine` の値は、`ChefAutomate`、`--engine-model` は、`Single`、`--engine-version` は `12` です。
+ サーバー名は、 AWS アカウント内で各リージョン内で一意である必要があります。サーバー名は文字で始める必要があります。その後は文字、数字、またはハイフン (-) を最大 40 文字まで使用できます。
+ ステップ 4 と 5 でコピーしたインスタンスプロファイル ARN とサービスロール ARN を使用します。
+ 有効なインスタンスタイプは `m5.large`、`r5.xlarge`、または `r5.2xlarge` です。これらのインスタンスタイプの仕様の詳細については、*「Amazon EC2 ユーザーガイド」*の[「インスタンスタイプ」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)を参照してください。
+ `--engine-attributes` パラメータはオプションです。いずれかまたは両方の値を指定しない場合、サーバー作成プロセスで値が生成されます。`--engine-attributes` を追加する場合は、ステップ 2 で生成した `CHEF_AUTOMATE_PIVOTAL_KEY` 値、`CHEF_AUTOMATE_ADMIN_PASSWORD`、またはその両方を指定します。
`CHEF_AUTOMATE_ADMIN_PASSWORD` の値を設定しない場合、`create-server` レスポンスの一部としてパスワードが生成され返されます。コンソールでスターターキットをもう一度ダウンロードして、このパスワードを再生成することもできます。パスワードの最小の長さは 8 文字、最大は 32 文字です。パスワードには、文字、数字、および特殊文字 (`!/@#$%^+=_`) を使用できます。パスワードは、少なくとも 1 つの小文字、1 つの大文字、1 つの数字、および 1 つの特殊文字を含む必要があります。
+ SSH キーペアはオプションですが、Chef Automate ダッシュボードの管理者パスワードをリセットする必要がある場合に Chef Automate サーバーに接続することができます。SSH キーペアの作成の詳細については、*「Amazon EC2 User Guide」*(Amazon EC2 ユーザーガイド) の[「Amazon EC2 Key Pairs」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)(Amazon EC2のキーペア) を参照してください。
+ カスタムドメインを使用するには、コマンドに以下のパラメータを追加します。それ以外の場合は、Chef Automate サーバー作成プロセスによって自動的にエンドポイントが生成されます。カスタムドメインを構成するには、3 つのパラメータすべてが必要です。これらのパラメータを使用するための追加の要件については、CM API リファレンスの[CreateServer](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html) OpsWorks 」を参照してください。
+ `--custom-domain` - サーバーのオプションのパブリックエンドポイント (`https://aws.my-company.com` など)。
+ `--custom-certificate` - PEM 形式の HTTPS 証明書。値には、単一の自己署名証明書、または証明書チェーンを指定できます。
+ `--custom-private-key` - HTTPS を使用してサーバーに接続するための PEM 形式のプライベートキー。プライベートキーは暗号化しないでください。パスワードやパスフレーズで保護することはできません。
+ 週 1 回のシステムメンテナンスが必要です。次の形式で有効な値を指定する必要があります: `DDD:HH:MM`。指定時刻は協定世界時 (UTC) です。`--preferred-maintenance-window` の値を指定しない場合、火曜日、水曜日、または金曜日の 1 時間がランダムでデフォルト値になります。
+ `--preferred-backup-window` の有効な値は次の形式のいずれかで指定する必要があります: 日次バックアップの場合は `HH:MM`、週次バックアップの場合は `DDD:HH:MM`。指定時刻は UTC です。デフォルト値は日次で開始時間はランダムです。自動バックアップを無効にするには、代わりにパラメータ `--disable-automated-backup` を追加します。
+ `--security-group-ids` に、1 つ以上のセキュリティグループ ID をスペースで区切って入力します。
+ `--subnet-ids` には、サブネット ID を入力します。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" --server-name "server_name" --instance-profile-arn "instance_profile_ARN" --instance-type "instance_type" --engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"pivotal_key","CHEF_AUTOMATE_ADMIN_PASSWORD":"password"}' --key-pair "key_pair_name" --preferred-maintenance-window "ddd:hh:mm" --preferred-backup-window "ddd:hh:mm" --security-group-ids security_group_id1 security_group_id2 --service-role-arn "service_role_ARN" --subnet-ids subnet_ID
```
以下に例を示します。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" --server-name "automate-06" --instance-profile-arn "arn:aws:iam::12345678912:instance-profile/aws-opsworks-cm-ec2-role" --instance-type "m5.large" --engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"MZZE...Wobg","CHEF_AUTOMATE_ADMIN_PASSWORD":"zZZzDj2DLYXSZFRv1d"}' --key-pair "amazon-test" --preferred-maintenance-window "Mon:08:00" --preferred-backup-window "Sun:02:00" --security-group-ids sg-b00000001 sg-b0000008 --service-role-arn "arn:aws:iam::12345678912:role/service-role/aws-opsworks-cm-service-role" --subnet-ids subnet-300aaa00
```
次の例では、カスタムドメインを使用する Chef Automate サーバーを作成します。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" \
--server-name "my-custom-domain-server" \
--instance-profile-arn "arn:aws:iam::12345678912:instance-profile/aws-opsworks-cm-ec2-role" \
--instance-type "m5.large" \
--engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"MZZE...Wobg","CHEF_AUTOMATE_ADMIN_PASSWORD":"zZZzDj2DLYXSZFRv1d"}' \
--custom-domain "my-chef-automate-server.my-corp.com" \
--custom-certificate "-----BEGIN CERTIFICATE----- EXAMPLEqEXAMPLE== -----END CERTIFICATE-----" \
--custom-private-key "-----BEGIN RSA PRIVATE KEY----- EXAMPLEqEXAMPLE= -----END RSA PRIVATE KEY-----" \
--key-pair "amazon-test" \
--preferred-maintenance-window "Mon:08:00" \
--preferred-backup-window "Sun:02:00" \
--security-group-ids sg-b00000001 sg-b0000008 \
--service-role-arn "arn:aws:iam::12345678912:role/service-role/aws-opsworks-cm-service-role" \
--subnet-ids subnet-300aaa00
```
以下の例では、2 つのタグ `Stage: Production` および `Department: Marketing` を追加する Chef Automate サーバーを作成します。 AWS OpsWorks for Chef Automate サーバーでのタグの追加と管理の詳細については、このガイド[AWS OpsWorks for Chef Automate リソースでのタグの使用](opscm-tags.md)の「」を参照してください。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" \
--server-name "my-test-chef-server" \
--instance-profile-arn "arn:aws:iam::12345678912:instance-profile/aws-opsworks-cm-ec2-role" \
--instance-type "m5.large" \
--engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"MZZE...Wobg","CHEF_AUTOMATE_ADMIN_PASSWORD":"zZZzDj2DLYXSZFRv1d"}' \
--key-pair "amazon-test" \
--preferred-maintenance-window "Mon:08:00" \
--preferred-backup-window "Sun:02:00" \
--security-group-ids sg-b00000001 sg-b0000008 \
--service-role-arn "arn:aws:iam::12345678912:role/service-role/aws-opsworks-cm-service-role" \
--subnet-ids subnet-300aaa00 \
--tags [{\"Key\":\"Stage\",\"Value\":\"Production\"},{\"Key\":\"Department\",\"Value\":\"Marketing\"}]
```
1. AWS OpsWorks for Chef Automate 新しいサーバーの作成には約 15 分かかります。`create-server` コマンドの出力を閉じたり、シェルセッションを閉じたりしないでください。今後表示されない重要な情報が出力に含まれている場合があります。`create-server` の結果からパスワードとスターターキットを取得するには、次のステップに進みます。
サーバーでカスタムドメインを使用している場合は、`create-server` コマンドの出力で `Endpoint` 属性の値をコピーします。以下に例を示します。
```
"Endpoint": "automate-07-exampleexample.opsworks-cm.us-east-1.amazonaws.com"
```
1. がキーとパスワード AWS OpsWorks for Chef Automate を生成することを選択した場合は、[jq](https://stedolan.github.io/jq/) などの JSON プロセッサを使用して`create-server`、結果から使用可能な形式で抽出できます。[jq](https://stedolan.github.io/jq/) をインストールした後、以下のコマンドを実行して中枢キー、Chef Automate ダッシュボード管理者パスワード、およびスターターキットを抽出できます。ステップ 4 で独自の中枢キーとパスワードを指定しなかった場合は、抽出した中枢キーと管理者パスワードを使いやすく安全な場所に保存してください。
```
#Get the Chef password:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_AUTOMATE_ADMIN_PASSWORD") | .Value'
#Get the Chef Pivotal Key:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_AUTOMATE_PIVOTAL_KEY") | .Value'
#Get the Chef Starter Kit:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_STARTER_KIT") | .Value' | base64 -D > starterkit.zip
```
1. オプションで、`create-server`コマンド結果からスターターキットを抽出しなかった場合は、 AWS OpsWorks for Chef Automate コンソールのサーバーのプロパティページから新しいスターターキットをダウンロードできます。新しいスターターキットをダウンロードすると、Chef Automate ダッシュボードの管理者パスワードがリセットされます。
1. カスタムドメインを使用していない場合は、次のステップに進みます。サーバーでカスタムドメインを使用している場合は、エンタープライズの DNS 管理ツールで CNAME エントリを作成して、ステップ 7 でコピーした AWS OpsWorks for Chef Automate エンドポイントにカスタムドメインをポイントします。このステップを完了するまで、カスタムドメインを使用するサーバーにアクセスしたりサインインしたりすることはできません。
1. サーバーの作成プロセスが完了したら、「[スターターキットを使用して Chef サーバーを設定する](opscm-starterkit.md)」に進みます。
# スターターキットを使用して Chef サーバーを設定する
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Chef サーバー作成の進行中に、 AWS OpsWorks for Chef Automate コンソールでプロパティページを開きます。新しい Chef サーバーの初回操作時に、[Properties] ページで 2 つの必須項目をダウンロードするように求められます。Chef サーバーがオンラインになる前に、これらの項目をダウンロードします。新しいサーバーがオンラインになった後は、ダウンロードボタンは使用できません。
![\[AWS OpsWorks for Chef Automate 新しいサーバープロパティページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_serverpropsdownload.png)
+ [**Sign-in credentials for the Chef server (Chef サーバー用のサインイン認証情報)**]。これらの認証情報を使用して Chef Automate ダッシュボードにサインインします。ここでは、ワークフローやコンプライアンススキャンなどの Chef Automate のプレミアム機能を使用します。 OpsWorks は、これらの認証情報を保存しません。これは、表示およびダウンロードできる最後の時間です。必要であれば、これらの認証情報で提供されたパスワードをサインイン後に変更できます。
+ **Starter Kit** (スターターキット)。スターターキットには、サンプル付きの README ファイル、`knife.rb` の設定ファイル、およびプライマリユーザーまたは主要ユーザー用のプライベートキーが含まれています。スターターキットをダウンロードするごとに、新しいキーペアが生成され、以前のキーはリセットされます。
Starter Kit .zip ファイルには、新しいサーバーでのみ機能する認証情報に加えて、任意の AWS OpsWorks for Chef Automate サーバーで動作する Chef リポジトリの簡単な例が含まれています。Chef リポジトリには、Chef で管理するノード用のクックブック、ロール、設定ファイル、および他のアーティファクトが保存されます。このリポジトリは、バージョン管理システム (Git など) に保存し、ソースコードとして扱うことをお勧めします。Git で追跡されるように Chef リポジトリをセットアップする方法に関する情報およびサンプルについては、Chef ドキュメントの「[About the chef-repo](https://docs.chef.io/chef_repo.html)」(chef-repo について) を参照してください。
## 前提条件
1. サーバー作成の進行中に、Chef サーバーのサインイン認証情報をダウンロードし、セキュアだが便利な場所に保存します。
1. スターターキットをダウンロードし、スターターキットの .zip ファイルをワークスペースディレクトリに解凍します。スターターキットのプライベートキーは共有しないでください。他のユーザーが Chef サーバーを管理する場合は、後で Chef Automate ダッシュボードでそのユーザーを管理者として追加します。
1. [[Chef Workstation]](https://downloads.chef.io/products/workstation) (以前はChef Development Kit または Chef DK として知られていた)をダウンロードして、Chef サーバおよびノードの管理に使用するコンピュータにインストールします。[https://docs.chef.io/knife.html](https://docs.chef.io/knife.html) ユーティリティは Chef Workstation の一部です。その手順については、Chef のウェブサイトにある[「Install Chef Workstation」](https://docs.chef.io/workstation/install_workstation/)(Chef Workstationのインストール) を参照してください。
## スターターキットの内容を見る
スターターキットの内容は以下のとおりです。
+ `cookbooks/` - 作成するクックブックのディレクトリ。`cookbooks/` フォルダには、[Chef スーパーマーケット](https://supermarket.chef.io/cookbooks/nginx)ウェブサイトの `nginx` クックブックに依存する `opsworks-webserver` クックブック、ラッパークックブックが含まれています。クックブックの依存関係が `cookbooks/` のディレクトリ内で利用できない場合、`Policyfile.rb` のデフォルトでは Chef supermarket を二次ソースとして使用します。
+ `Policyfile.rb` - ノードのポリシーになるクックブック、依存関係、属性を定義する Ruby ベースのポ リシーファイル。
+ `userdata.sh` および `userdata.ps1` - Chef Automate サーバーの起動後に、ユーザーデータファイルを使用してノードを自動的に関連付けることができます。`userdata.sh` は Linux ベースのノードのブートストラップ用、`userdata.ps1` は Windows ベースのノード用です。
+ `Berksfile` - Berkshelf と `berks` のコマンドを使用してクックブックとその依存関係をアップロードする場合は、このファイルを使用できます。このチュートリアルでは、`Policyfile.rb` と Chef コマンドを使用して、クックブック、依存関係、属性をアップロードします。
+ `README.md` - スターターキットを使用して Chef Automate サーバーを初めて設定する方法について説明する Markdown ベースのファイル。
+ `.chef` - knife 設定ファイル (`knife.rb`) とシークレット認証キーファイル (.pem) を含む隠しディレクトリ。
+ `.chef/knife.rb` - knife 設定ファイル (`knife.rb`)。この[https://docs.chef.io/config_rb_knife.html](https://docs.chef.io/config_rb_knife.html)ファイルは、Chef の[https://docs.chef.io/knife.html](https://docs.chef.io/knife.html)ツールオペレーションが AWS OpsWorks for Chef Automate サーバーに対して実行されるように設定されています。
+ `.chef/ca_certs/opsworks-cm-ca-2020-root.pem` - OpsWorksに付属している、認証機関 (CA) による署名付きの SSL プライベートキー。このキーによって、サーバーで管理されるノード上の Chef Infra クライアントエージェントに対して、サーバーが自身を識別できるようになります。
## Chef リポジトリを設定する
Chef リポジトリには複数のディレクトリが置かれています。スターターキットの各ディレクトリには、そのディレクトリの目的、および Chef でシステムを管理するための使用方法が記述されている README ファイルがあります。Chef サーバーにクックブックをインストールするには、2 つの方法があります。`knife` コマンドを実行する方法と、Chef コマンドを実行する方法です。後者のコマンドは、ポリシーファイル (`Policyfile.rb`) をサーバーにアップロードし、指定されたクックブックをダウンロードしてインストールします。このチュートリアルでは、Chef コマンドと `Policyfile.rb` を使用してクックブックをサーバーにインストールします。
1. クックブックを保存するためのディレクトリ (`chef-repo` など) をローカルコンピュータ上に作成します。このリポジトリにクックブック、ロール、および他のファイルを追加した後に、バージョニングされているセキュアなシステム (CodeCommit、Git、Amazon S3 など) にリポジトリをアップロードまたは保存することをお勧めします。
1. `chef-repo` ディレクトリに、以下のディレクトリを作成します。
+ `cookbooks/` - クックブックを保存する。
+ `roles/` - ロールを `.rb` 形式または `.json` 形式で保存します。
+ `environments/` - 環境を `.rb` 形式または `.json` 形式で保存します。
## Policyfile.rb を使用してリモートソースからクックブックを取得する
このセクションでは、クックブックを指定するように `Policyfile.rb` を編集してから、そのファイルをサーバーにアップロードしてクックブックをインストールする Chef コマンドを実行します。
1. スターターキットの `Policyfile.rb` を表示します。デフォルトでは `Policyfile.rb` には、`opsworks-webserver` ラッパークックブックが含まれています。これは、Chef Supermarket のウェブサイトで入手可能な [https://supermarket.chef.io/cookbooks/nginx](https://supermarket.chef.io/cookbooks/nginx) クックブックの依存関係となります。`nginx` は、管理対象ノードにウェブサーバーをインストールして設定するクックブックです。また、管理対象ノードに Chef Infra クライアントエージェントをインストールする、必須の `chef-client` クックブックも指定されています。
`Policyfile.rb` は、ノードのコンプライアンススキャンの設定に使用できるオプションの Chef Audit クックブックも参照しています。コンプライアンススキャンの設定と管理対象ノードのコンプライアンス結果の取得の詳細については、「[でのコンプライアンススキャン AWS OpsWorks for Chef Automate](opscm-chefcompliance.md)」を参照してください 今すぐコンプライアンススキャンと監査を設定しない場合は、`'audit'` セクションから `run_list` を削除します。ファイルの末尾に `audit` クックブックの属性を指定しないでください。
```
# Policyfile.rb - Describe how you want Chef to build your system.
#
# For more information about the Policyfile feature, visit
# https://docs.chef.io/policyfile.html
# A name that describes what the system you're building with Chef does.
name 'opsworks-demo-webserver'
# The cookbooks directory is the preferred source for external cookbooks
default_source :chef_repo, "cookbooks/" do |s|
s.preferred_for "nginx", "windows", "chef-client", "yum-epel", "seven_zip",
"build-essential", "mingw", "ohai", "audit", "logrotate", "cron"
end
# Alternative source
default_source :supermarket
# run_list: chef-client runs these recipes in the order specified.
run_list 'chef-client',
'opsworks-webserver',
'audit'
# add 'ssh-hardening' to your runlist to fix compliance issues detected by the ssh-baseline profile
# Specify a custom source for a single cookbook:
cookbook 'opsworks-webserver', path: 'cookbooks/opsworks-webserver'
# Policyfile defined attributes
# Define audit cookbook attributes
default["opsworks-demo"]["audit"]["reporter"] = "chef-server-automate"
default["opsworks-demo"]["audit"]["profiles"] = [
{
"name": "DevSec SSH Baseline",
"compliance": "admin/ssh-baseline"
}
]
```
以下に示しているのは、現時点で `Policyfile.rb` ウェブサーバーのみを設定する場合に、`audit` クックブックとその属性を削除した `nginx` の例です。
```
# Policyfile.rb - Describe how you want Chef to build your system.
#
# For more information on the Policyfile feature, visit
# https://docs.chef.io/policyfile.html
# A name that describes what the system you're building with Chef does.
name 'opsworks-demo-webserver'
# Where to find external cookbooks:
default_source :supermarket
# run_list: chef-client will run these recipes in the order specified.
run_list 'chef-client',
'opsworks-webserver'
# Specify a custom source for a single cookbook:
cookbook 'opsworks-webserver', path: 'cookbooks/opsworks-webserver'
```
`Policyfile.rb` に変更を加えた場合は、必ずこのファイルを保存してください。
1. `Policyfile.rb` に定義されているクックブックをダウンロードしてインストールします。
```
chef install
```
すべてのクックブックはクックブックの `metadata.rb` ファイルでバージョニングされています。クックブックを変更するたびに `metadata.rb` にあるクックブックのバージョンを上げる必要があります。
1. コンプライアンススキャンを設定し、`audit` クックブックの情報をポリシーファイルに保存した場合は、ポリシー `opsworks-demo` をサーバーにプッシュします。
```
chef push opsworks-demo
```
1. ステップ 3 が完了したら、ポリシーのインストールを確認します。以下のコマンドを実行してください。
```
chef show-policy
```
結果は以下のようになります。
```
opsworks-demo-webserver
=======================
* opsworks-demo: ec0fe46314
```
1. これで、Chef Automate サーバーにノードを追加 (ブートストラップ) する準備ができました。ノードの関連付けを自動化するには、[でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md) のステップに従うか、または [ノードを個別に追加します](opscm-addnodes-individually.md) のステップに従ってノードを 1 つずつ追加します。
## (代替) Berkshelf を使用してリモートソースからクックブックを取得する
Berkshelf は、クックブックとその依存関係を管理するためのツールです。ローカルストレージにクックブックをインストールするために `Policyfile.rb` の代わりに Berkshelf を使用する場合は、前のセクションの代わりにこのセクションの手順を使用します。Chef サーバーで使用するクックブックとそのバージョンを指定し、クックブックをアップロードできます。スターターキットには、クックブックの一覧表示に使用できる `Berksfile` というファイルが含まれています。
1. 使用を開始するには、含まれている Berksfile に `chef-client` クックブックを追加します。`chef-client` クックブックは、Chef Automate サーバーに接続する各ノードで Chef Infra クライアントエージェントソフトウェアを設定します。このクックブックの詳細については、Chef Supermarket にある「[Chef Client Cookbook](https://supermarket.chef.io/cookbooks/chef-client)」(Chef クライアントクックブック) を参照してください。
1. テキストエディタを使用して、ウェブサーバーアプリケーションをインストールする Berksfile に別のクックブックを追加します。たとえば、Apache ウェブサーバーをインストールする `apache2` クックブックです。Berksfile は以下のようになります。
```
source 'https://supermarket.chef.io'
cookbook 'chef-client'
cookbook 'apache2'
```
1. そのクックブックをローカルコンピュータにダウンロードしてインストールします。
```
berks install
```
1. そのクックブックを Chef サーバーにアップロードします。
Linux では、次のコマンドを実行します。
```
SSL_CERT_FILE='.chef/ca_certs/opsworks-cm-ca-2020-root.pem' berks upload
```
Windows では、PowerShell セッションで次の Chef Workstation コマンドを実行します。コマンドを実行する前に、PowerShell の実行ポリシーを `RemoteSigned` に設定しておきます。PowerShell で Chef Workstation のユーティリティコマンドを利用できるように、`chef shell-init` を追加します。
```
$env:SSL_CERT_FILE="ca_certs\opsworks-cm-ca-2020-root.pem"
chef shell-init berks upload
Remove-Item Env:\SSL_CERT_FILE
```
1. Chef Automate サーバーで現在使用可能なクックブックのリストを表示して、クックブックがインストールされていることを確認します。そのためには、以下の `knife` コマンドを実行します。
AWS OpsWorks for Chef Automate サーバーで管理するノードを追加する準備ができました。
```
knife cookbook list
```
## (オプション) カスタムドメインを使用するように `knife` を設定します。
Chef Automate サーバーがカスタムドメインを使用している場合は、サーバーの証明書チェーンに署名したルート CA の PEM 証明書を追加するか、証明書が自己署名の場合はサーバー PEM 証明書を追加する必要があります。`ca_certs` は、Chef `knife` ユーティリティによって信頼される認証機関 (CA) を含む `chef/` のサブディレクトリです。
カスタムドメインを使用していない場合、またはカスタム証明書がオペレーティングシステムで信頼されているルート CA によって署名されている場合は、このセクションを省略できます。それ以外の場合は、次のステップで説明するように、Chef Automate サーバーの SSL 証明書を信頼するように `knife` を設定します。
1. 以下のコマンドを実行してください。
```
knife ssl check
```
結果が次のような場合は、この手順の残りの部分をスキップして、「[Chef サーバーで管理するノードを追加する](opscm-addnodes.md)」に進みます。
```
Connecting to host my-chef-automate-server.my-corp.com:443
Successfully verified certificates from 'my-chef-automate-server.my-corp.com'
```
次のようなエラーメッセージが表示された場合は、次のステップに進みます。
```
Connecting to host my-chef-automate-server.my-corp.com:443
ERROR: The SSL certificate of my-chef-automate-server.my-corp.com could not be verified.
...
```
1. `knife ssl fetch` を実行して、 AWS OpsWorks for Chef Automate サーバーの証明書を信頼します。または、サーバーのルート CA 証明書 (PEM 形式) を、`trusted_certs_dir` の出力の `knife ssl check` の値であるディレクトリに手動でコピーすることもできます。デフォルトでは、このディレクトリはスターターキットの `.chef/ca_certs/` にあります。出力は次のようになります。
```
WARNING: Certificates from my-chef-automate-server.my-corp.com will be fetched and placed in your trusted_cert
directory (/Users/username/starterkit/.chef/../.chef/ca_certs).
Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.
Adding certificate for my-chef-automate-server in /Users/users/starterkit/.chef/../.chef/ca_certs/servv-aqtswxu20swzkjgz.crt
Adding certificate for MyCorp_Root_CA in /Users/users/starterkit/.chef/../.chef/ca_certs/MyCorp_Root_CA.crt
```
1. `knife ssl check` をもう一度実行します。出力は次のようになります。
```
Connecting to host my-chef-automate-server.my-corp.com:443
Successfully verified certificates from 'my-chef-automate-server.my-corp.com'
```
これで、Chef Automate サーバーで `knife` を使用する準備ができました。
# Chef サーバーで管理するノードを追加する
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
[https://docs.chef.io/chef_client.html](https://docs.chef.io/chef_client.html) エージェントは、サーバーに関連付けられている物理コンピュータまたは仮想コンピュータ ([*nodes*] (ノード) と呼ばれる) で Chef レシピを実行します。オンプレミスのコンピュータまたはインスタンスを Chef サーバーに接続して管理できます (サポートされているオペレーティングシステムがそのノードで実行されている場合)。Chef サーバーにノードを登録すると、そのノードに `chef-client` エージェントソフトウェアがインストールされます。
次の方法を使用してノードを追加できます。
+ このチュートリアルでは、Chef サーバが管理できるように、EC2 インスタンスを追加または*ブートストラップする* `knife` コマンドを個別に実行する方法を説明します。詳細については、「[ノードを個別に追加します](opscm-addnodes-individually.md)」を参照してください。
+ スクリプトを使って自動的にノードを追加し、Chefサーバとノードの自動関連付けを行います。[スターターキット](opscm-starterkit.md)のコードでは、ユーザーの介入なしに複数のノードを自動的に追加する方法を示しています。詳細については、「[でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md)」を参照してください。
**Topics**
+ [ノードを個別に追加します](opscm-addnodes-individually.md)
+ [でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md)
# ノードを個別に追加します
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
この節では、ChefサーバがEC2インスタンスを管理できるようにEC2インスタンスを追加、または*ブートストラップする*`knife` コマンドの実行方法を説明します。
AWS OpsWorks for Chef Automate サーバーに関連付けられているノードでサポートされている `chef-client` の最小バージョンは 13.*x* です。最新の安定した`chef-client`バージョンを実行することをお勧めします。
**Topics**
+ [(オプション) Chef Automate サーバールート CA の URL を指定します。](#opscm-addnodes-customdomain)
+ [サポートされるオペレーティングシステム](#w2ab1b9c28c17c13c13)
+ [knife を使用してノードを追加する](#w2ab1b9c28c17c13c15)
## (オプション) Chef Automate サーバールート CA の URL を指定します。
サーバーがカスタムドメインと証明書を使用している場合は、ユーザーデータスクリプトの `ROOT_CA_URL` 変数を編集して、サーバーのルート CA 証明書 (PEM 形式) を取得するために使用できるパブリック URL にする必要があります。次の AWS CLI コマンドは、ルート CA を Amazon S3 バケットにアップロードし、1 時間使用できる署名付き URL を生成します。
1. ルート CA 証明書 (PEM 形式) を S3 にアップロードします。
```
aws s3 cp ROOT_CA_PEM_FILE_PATH s3://bucket_name/
```
1. ルート CA をダウンロードするために 1 時間 (この例では 3600 秒) 使用できる署名付き URL を生成します。
```
aws s3 presign s3://bucket_name/ROOT_CA_PEM_FILE_NAME --expires-in 3600
```
1. 署名付き URL の値を使用してユーザーデータスクリプトの `ROOT_CA_URL` 変数を編集します。
## サポートされるオペレーティングシステム
ノードでサポートされているオペレーティングシステムの最新の一覧については、[[Chef website](https://docs.chef.io/platforms.html)] (Chef のウェブサイト) を参照してください。
## knife を使用してノードを追加する
[https://github.com/chef/knife-ec2](https://github.com/chef/knife-ec2) プラグインは Chef Workstation に含まれています。`knife-ec2` に慣れている場合は、`knife bootstrap` ではなくそれを使用して、新しい EC2 インスタンスをプロビジョニングおよびブートストラップできます。慣れていない場合は、新しい EC2 インスタンスを起動した後に、このセクションの手順に従います。
**管理するノードを追加するには**
1. 次の `knife bootstrap` コマンドを実行します。このコマンドは、Chef サーバーで管理されるノードに EC2 インスタンスをブートストラップします。「[Policyfile.rb を使用してリモートソースからクックブックを取得する](opscm-starterkit.md#install-cookbooks-policyfile)」でインストールした `nginx` クックブックからレシピを実行するように、Chef サーバーに指示していることに注意してください。`knife bootstrap` コマンドを使用したノードの追加に関する詳細については、Chef ドキュメントの「[Bootstrap a Node](https://docs.chef.io/install_bootstrap.html)」(ノードのブートストラップ) を参照してください。
このステップの `knife` コマンドでノードのオペレーティングシステムに対して有効なユーザー名を次の表に示します。`root` と `ec2-user` のどちらでも動作しない場合は、AMI プロバイダーに確認してください。Linux ベースのインスタンスへの接続の詳細については、AWS ドキュメントの「[Connecting to Your Linux Instance Using SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)」(SSH を使用した Linux インスタンスへの接続) を参照してください。
**ノードのオペレーティングシステムで有効なユーザー名の値**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/opscm-addnodes-individually.html)
```
knife bootstrap INSTANCE_IP_ADDRESS -N INSTANCE_NAME -x USER_NAME --sudo --run-list "recipe[nginx]"
```
1. 次のコマンド ([*INSTANCE\$1NAME*] (インスタンス名) は追加したインスタンスの名前に置き換えます) を実行して、新しいノードが追加されていることを確認します。
```
knife client show INSTANCE_NAME
knife node show INSTANCE_NAME
```
# でノードを自動的に追加する 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 サポート チームにお問い合わせください。
このトピックでは、Amazon Elastic Compute Cloud (Amazon EC2) ノードを Chef サーバーに自動的に追加する方法を説明します。[スターターキット](opscm-starterkit.md)のコードでは、ユーザーの介入なしに複数のノードを自動的に追加する方法を示しています。ユーザーの介入なしに (自動で) で新しいノードを関連付ける方法としては、[Chef クライアントクックブック](https://supermarket.chef.io/cookbooks/chef-client)を設定することをお勧めします。スターターキットの `userdata` スクリプトを使用し、`run_list` スクリプトの `userdata` セクションを変更することも、または、ノードに適用するクックブックの `Policyfile.rb` を変更することもできます。`chef-client` エージェントを実行する前に、Chef Client クックブックを Chef サーバーにアップロードし、以下のサンプルコマンドで示しているように (例えば HTTPD ロールを使用して)、`chef-client` エージェントをサービスモードでインストールします。
```
chef-client -r "chef-client,role[httpd]"
```
Chef サーバーと通信するには、`chef-client` エージェントソフトウェアは、クライアントノードのパブリックキーへのアクセスを許可されている必要があります。Amazon EC2 でパブリックキーとプライベートキーのペアを生成し、そのパブリックキーを OpsWorks `associate-node`ノード名で API コールに渡すことができます。スターターキットに含まれているスクリプトは、お客様の組織名、サーバー名、サーバーエンドポイントを収集します。これにより、そのノードが Chef サーバーに関連付けられ、プライベートキーを照合した後に、そのノードで実行される `chef-client` エージェントソフトウェアがサーバーと通信できるようになります。
AWS OpsWorks for Chef Automate サーバーに関連付けられているノードでサポートされている `chef-client` の最小バージョンは 13.*x* です。最新の安定した`chef-client`バージョンを実行することをお勧めします。
ノードの関連付けを解除する方法については、このガイド[AWS OpsWorks for Chef Automate サーバーからノードの関連付けを解除する](opscm-disassociate-node.md)の「」と AWS OpsWorks for Chef Automate API ドキュメントの[https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html)「」を参照してください。
**Topics**
+ [サポートされるオペレーティングシステム](#w2ab1b9c28c17c15c17)
+ [ステップ 1: インスタンスプロファイルとして使用する IAM ロールを作成します](#opscm-create-instance-profile)
+ [ステップ 2: Chef クライアントクックブックをインストールする](#w2ab1b9c28c17c15c21)
+ [ステップ 3: 自動関連付けスクリプトを使用してインスタンスを作成する](#opscm-unattend-script)
+ [`chef-client` の繰り返し実行を自動化する他の方法](#w2ab1b9c28c17c15c25)
+ [関連トピック](#opscm-unattend-assoc-related)
## サポートされるオペレーティングシステム
ノードでサポートされているオペレーティングシステムの最新の一覧については、[[Chef website](https://docs.chef.io/platforms.html)] (Chef のウェブサイト) を参照してください。
## ステップ 1: インスタンスプロファイルとして使用する IAM ロールを作成します
EC2 インスタンスプロファイルとして使用する AWS Identity and Access Management (IAM) ロールを作成し、次のポリシーを IAM ロールにアタッチします。このポリシーでは、ノード登録時に AWS OpsWorks for Chef Automate (`opsworks-cm`) API が EC2 インスタンスと通信することが許可されています。インスタンスプロファイルの詳細については、Amazon EC2 のドキュメントの[「Using Instance Profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) (インスタンスプロファイルの使用)」を参照してください。IAM ロールを作成する方法については、Amazon EC2 のドキュメントの[「Creating an IAM Role in the Console」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role-console)(コンソールでの IAM ロールの作成) を参照してください。。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"opsworks-cm:AssociateNode",
"opsworks-cm:DescribeNodeAssociationStatus"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## ステップ 2: Chef クライアントクックブックをインストールする
まだ実行していない場合は、「[(代替) Berkshelf を使用してリモートソースからクックブックを取得する](opscm-starterkit.md#opscm-berkshelf)」の手順に従って、Berksfile または `Policyfile.rb` ファイルレファレンス によって Chef クライアントクックブックが参照され、クックブックがインストールされることを確認します。
## ステップ 3: 自動関連付けスクリプトを使用してインスタンスを作成する
1. EC2 インスタンスを作成するには、[スターターキット](opscm-starterkit.md)から EC2 インスタンス手順の `userdata`セクション、Amazon EC2 Auto Scaling グループの起動設定、または CloudFormation テンプレートに`userdata`スクリプトをコピーします。ユーザーデータへのスクリプトの追加の詳細については、Amazon EC2 ドキュメントの[「Running Commands on Your Linux Instance at Launch」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)(Linux インスタンスでの起動時のコマンドの実行) を参照してください。
このスクリプトは、`opsworks-cm` API の [https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_AssociateNode.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_AssociateNode.html) コマンドを実行して、新しいノードを Chef サーバーに関連付けます。
デフォルトでは、登録された新しいノードの名前はインスタンス ID ですが、`NODE_NAME` スクリプトの `userdata` 変数の値を変更することで、その名前を変更できます。現在、Chef コンソール UI の組織名を変更することはできないため、`CHEF_AUTOMATE_ORGANIZATION`の設定は `default` のままにします。
1. EC2 ドキュメントの[インスタンスの作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html)の手順に従い、ここで説明する変更を加えます。EC2 インスタンス起動ウィザードで、Amazon Linux AMI を選択します。
1. [**Configure Instance Details**] ページで IAM ロールとして作成した「[ステップ 1: インスタンスプロファイルとして使用する IAM ロールを作成します](#opscm-create-instance-profile)」を選択します。
1. [**Advanced Details**] で、先の手順で作成した `userdata.sh` スクリプトをアップロードします。
1. [**Add Storage**] ページで必要な変更はありません。[**Add Tags**] に進みます。
1. [**セキュリティグループの設定**] ページで、[**ルールの追加**] を選択し、タイプに [**HTTP**] を選択してこの例の Apache ウェブサーバーでポート番号 443 と 80 を開きます。
1. **Review and Launch** (確認と作成) を選択してから、**Launch** (起動) を選択します。新しいノードを開始すると、そのノードは `RUN_LIST` パラメータで渡されたレシピによって指定された設定を適用します。
1. オプション: 実行リストに `nginx` クックブックを追加した場合、新しいノードのパブリック DNS にリンクしたウェブページを開くと、nginx ウェブサーバーがホストするウェブサイトが表示されます。
## `chef-client` の繰り返し実行を自動化する他の方法
達成はより難しく、推奨されませんが、このトピックのスクリプトはスタンドアロンインスタンスのユーザーデータの一部としてのみ実行できます。 CloudFormation テンプレートを使用して新しいインスタンスのユーザーデータに追加したり、スクリプトを定期的に実行するように`cron`ジョブを設定したり、サービス`chef-client`内で実行したりできます。ただし、他の自動化の方法にはいくつかの欠点があるため、Chef クライアントクックブックの方法をお勧めします。
`chef-client` に指定できるパラメータの詳細なリストについては、[Chef のドキュメント](https://docs.chef.io/ctl_chef_client.html)を参照してください。
## 関連トピック
次の AWS ブログ記事では、Auto Scaling グループを使用するか、複数のアカウント内で、Chef Automate サーバーにノードを自動的に関連付ける方法について詳しく説明します。
+ [Using AWS OpsWorks for Chef Automate to Manage EC2 Instances with Auto Scaling](https://aws.amazon.com/blogs/mt/using-aws-opsworks-for-chef-automate-to-manage-ec2-instances-with-auto-scaling/)
+ [OpsWorks for Chef Automate – Automatically Bootstrapping Nodes in Different Accounts](https://aws.amazon.com/blogs/mt/opsworks-for-chef-automate-automatically-bootstrapping-nodes-in-different-accounts/)
# 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 サーバーの [Properties] ページでサインイン認証情報をダウンロードし、サーバーがオンラインになったら、Chef Automate ダッシュボードにサインインします。このウォークスルーでは、最初にクックブックをアップロードし、管理するノードを 1 つ以上追加します。そうすることによって、クックブックおよびノードに関する情報をダッシュボードで表示できるようになります。
ダッシュボードウェブページに接続しようとすると、Chef サーバーの管理に使用しているクライアントコンピュータに OpsWorks特定の CA 署名付き SSL 証明書をインストールするまで、証明書の警告がブラウザに表示されます。ダッシュボードのウェブページに進む前に警告が表示されないようにするには、サインインする前に SSL 証明書をインストールします。
クライアント側 SSL 証明書をインストールした後は、Chef Automate ダッシュボードへのサインイン時に警告メッセージが表示されなくなります。
**注記**
Ubuntu および Linux オペレーティングシステムで Google Chrome を使用しているユーザーは、サインインで問題が発生する場合があります。Mozilla Firefox または他のブラウザを使用してサインインし、これらのオペレーティングシステムで Chef Automate ダッシュボードを使用することをお勧めします。Windows または MacOS では Google Chrome の使用で問題は出ていません。
**Chef Automate ダッシュボードにサインインするには**
1. 「[前提条件](opscm-starterkit.md#finish-server-prereqs)」でダウンロードした Chef Automate 認証情報を解凍して開きます。サインインするには、これらの認証情報が必要です。
1. Chef サーバーの [**Properties**] (プロパティ) ページを開きます。
1. [**Properties**] (プロパティ) ページの右上にある [**Open Chef Automate dashboard**] を選択します。
1. ステップ 1 で認証情報を使用してサインインします。
![\[Chef Automate ダッシュボードのサインインページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_chefsignin.png)
1. Chef Automate ダッシュボードでは、ブートストラップしたノード、クックブックの実行の進行状況とイベント、ノードのコンプライアンスレベル、などに関する詳細情報を表示できます。Chef Automate ダッシュボードの機能およびその使用方法の詳細については、[[Chef Automate Documentation](https://docs.chef.io/chef_automate.html)] (Chef Automate ドキュメント) を参照してください。
![\[Chef Automate ダッシュボード\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_chefdashhome.png)
**注記**
Chef Automate ダッシュボードへのサインインに使用するパスワードを変更する方法については、「[Chef Automate ダッシュボードの認証情報のリセット](opscm-resetchefcreds.md)」を参照してください。
# を使用して AWS OpsWorks for Chef Automate サーバーを作成する CloudFormation
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
AWS OpsWorks for Chef Automate では、[Chef Automate](https://www.chef.io/automate/) サーバーを で実行できます AWS。約 15 分で Chef Automate サーバーをプロビジョニングできます。
2021 年 5 月 3 日以降、 は一部の Chef Automate サーバー属性を に AWS OpsWorks for Chef Automate 保存します AWS Secrets Manager。詳細については、「[との統合 AWS Secrets Manager](data-protection.md#data-protection-secrets-manager)」を参照してください。
次のチュートリアルは、 でスタックを作成 AWS OpsWorks for Chef Automate することで、 でサーバーを作成するのに役立ちます CloudFormation。
**Topics**
+ [前提条件](#opscm-create-server-cfn-prereqs)
+ [CloudFormationで Chef Automate サーバーを作成する](#opscm-create-server-cfn-main)
## 前提条件
新しい Chef Automate サーバーを作成する前に、Chef サーバーにアクセスして管理するために必要なリソースを AWS OpsWorks for Chef Automate の外部で作成してください。詳細については、このガイドの「はじめる」セクションにある「[前提条件](gettingstarted-opscm.md#gettingstarted-opscm-prereq)」を参照してください。
*CloudFormation ユーザーガイド*テンプレートリファレンスの [OpsWorks-CM セクション](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworkscm-server.html)で、サーバーの作成に使用する CloudFormation テンプレートでサポートされている値と必要な値を確認してください。
カスタムドメインを使用するサーバーを作成する場合は、カスタムドメイン、証明書、およびプライベートキーが必要です。 CloudFormation テンプレートで、これら 3 つのパラメータすべてに値を指定する必要があります。`CustomDomain`、`CustomCertificate`、および `CustomPrivateKey` パラメータの要件の詳細については、OpsWorks CM API リファレンス の[サーバーの作成](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html) を参照してください
`CHEF_AUTOMATE_ADMIN_PASSWORD` エンジン属性のパスワード値を作成します。パスワードの最小の長さは 8 文字、最大は 32 文字です。パスワードには、文字、数字、および特殊文字 (`(!/@#$%^+=_)`) を使用できます。パスワードは、少なくとも 1 つの小文字、1 つの大文字、1 つの数字、および 1 つの特殊文字を含む必要があります。テンプレートでこのパスワードを指定するか CloudFormation 、スタックの作成時に `CHEF_AUTOMATE_ADMIN_PASSWORD`パラメータの値として指定します。
Chef Automate サーバーの作成を開始する前に、base64 でエンコードされた RSA キーペアを生成します CloudFormation。ペアの公開キーは `CHEF_AUTOMATE_PIVOTAL_KEY` の値で、[[CreateServer]](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html) (サーバーの作成) API からのシェフ固有の [[EngineAttributes]](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworkscm-server.html#cfn-opsworkscm-server-engineattributes) (エンジンの属性) です。このキーは、 CloudFormation コンソールの **Parameters** の値、または の **create-stack** コマンドの値として提供されます AWS CLI。このキーを生成するには、次の方法をお勧めします。
+ Linux ベースのコンピュータで、次の [OpenSSL](https://www.openssl.org/) コマンドを実行してこのキーを生成できます。
```
openssl genrsa -out pivotal_key_file_name.pem 2048
```
生成したら、鍵ペアの RSA 公開鍵部分をファイルにエクスポートします。公開鍵は、`CHEF_AUTOMATE_PIVOTAL_KEY` の値となります。
```
openssl rsa -in pivotal_key_file_name.pem -pubout -out public.pem -outform PEM
```
+ Windows ベースのコンピュータでは、PuTTYgen ユーティリティを使用して base64 でエンコードされた RSA キーペアを生成できます。詳細については、SSH.com で「[PuTTYgen - Key Generator for PuTTY on Windows](https://www.ssh.com/ssh/putty/windows/puttygen)」を参照してください。
## CloudFormationで Chef Automate サーバーを作成する
このセクションでは、 CloudFormation テンプレートを使用して AWS OpsWorks for Chef Automate サーバーを作成するスタックを構築する方法について説明します。これを行うには、 CloudFormation コンソールまたは を使用します AWS CLI。[サンプル CloudFormation テンプレート](samples/opsworkscm-server.zip)を使用して、 AWS OpsWorks for Chef Automate サーバースタックを構築できます。サンプルテンプレートを更新するには、必ず、独自のサーバー名、IAM ロール、インスタンスプロファイル、サーバーの説明、バックアップ保持数、メンテナンスオプション、およびオプションのタグを使用してください。サーバーがカスタムドメインを使用する場合は、 CloudFormation テンプレートで `CustomDomain`、`CustomCertificate`、および `CustomPrivateKey`パラメータの値を指定する必要があります。 CloudFormation テンプレートで `CHEF_AUTOMATE_ADMIN_PASSWORD`および `CHEF_AUTOMATE_PIVOTAL_KEY` エンジン属性とその値を指定するか、属性のみを指定し、 CloudFormation **スタックの作成**ウィザードまたは**create-stack**コマンドで属性の値を指定できます。これらの属性の詳細については、このガイドの「はじめに」セクションの「[で Chef Automate サーバーを作成する AWS マネジメントコンソール](gettingstarted-opscm-create.md#gettingstarted-opscm-create-console)」を参照してください。
**Topics**
+ [CloudFormation (コンソール) を使用して Chef Automate サーバーを作成する](#opscm-create-server-cfn-console)
+ [CloudFormation (CLI) を使用して Chef Automate サーバーを作成する](#opscm-create-server-cfn-cli)
### CloudFormation (コンソール) を使用して Chef Automate サーバーを作成する
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. CloudFormation ホームページで、**スタックの作成**を選択します。
1. **前提条件 - テンプレートを準備する**で、[サンプル CloudFormation テンプレート](samples/opsworkscm-server.zip)を使用している場合は、**テンプレートの準備ができました**を選択します。
1. **[Specify template]** 内で、テンプレートのソースを選択します。このチュートリアルでは、**テンプレートファイルをアップロード**を選択し、Chef Automate サーバーを作成する CloudFormation テンプレートをアップロードします。テンプレートファイルを参照し、[**Next**] を選択します。
CloudFormation テンプレートは YAML 形式または JSON 形式のいずれかです。[サンプル CloudFormation テンプレート](samples/opsworkscm-server.zip)を使用できます。サンプル値は必ず独自の値に置き換えてください。 CloudFormation テンプレートデザイナーを使用して、新しいテンプレートを構築したり、既存のテンプレートを検証したりできます。これを行う方法については、CloudFormation ユーザーガイド の[CloudFormation 「Designer Interface Overview](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-overview.html) (Designer インターフェイスの概要) を参照してください。
![\[CloudFormation の [Create stack] (スタックの作成) ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/cfn_select_template.png)
1. [**Specify stack details**] ページでスタックの名前を入力します。これは、サーバーの名前と同じ名前にしないでください。スタック名にすぎません。[**Parameters (パラメータ)**] 領域に、「[前提条件](#opscm-create-server-cfn-prereqs)」で作成した値を貼り付けます。[**Password**] にパスワードを入力します。
RSA キーファイルのコンテンツを [**PivotalKey**] 内に貼り付けます。 CloudFormation コンソールでは、次のスクリーンショットに示すように、ピボットキー値の各行の末尾に改行 (**\$1n**) 文字を追加する必要があります。[**次へ**] を選択します。
![\[CloudFormation の [Specify stack details] (スタックの詳細を指定) ページ\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/cfn_template_params_opscm.png)
1. **[Configure stack options]** (スタックオプションの設定) ページでは、スタックを使用して作成するサーバーにタグを追加することができ、テンプレートで使用する IAM ロールをまだ指定していない場合には、リソースを作成するための IAM ロールを選択できます。オプションの指定を終了したら、[**Next (次へ)**] を選択します。ロールバックトリガーなどの高度なオプションの詳細については、*CloudFormation 「 ユーザーガイド*」の[CloudFormation 「スタックオプションの設定](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html)」を参照してください。
1. **[確認]** ページで選択内容を確認します。サーバースタックを作成する準備ができたら、[**Create stack**] を選択します。
がスタックを作成する CloudFormation のを待っている間に、スタックの作成ステータスを表示します。スタックの作成に失敗した場合、コンソールに表示されるエラーメッセージを確認し、問題を解決します。 CloudFormation スタックのエラーのトラブルシューティングについての詳細は、CloudFormation ユーザーガイドの[「Troubleshooting Errors」](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors) (エラーのトラブルシューティング) を参照してください。
サーバーの作成が完了すると、 AWS OpsWorks for Chef Automate のホームページで、Chef Automate サーバーが [**online**] のステータスになり、利用可能になります。サーバーの [Properties (プロパティ)] ページで、新しいスターターキットと Chef Automate ダッシュボードの認証情報を生成します。サーバーがオンラインになると、Chef Automate ダッシュボードがサーバーのドメインで `https://your_server_name-randomID.region.opsworks-cm.io` の形式の URL で利用できます。
**注記**
サーバーのカスタムドメイン、証明書、プライベートキーを指定した場合は、エンタープライズの DNS 管理ツールで CNAME エントリを作成し、カスタムドメインをサーバー用に AWS OpsWorks for Chef Automate 自動生成されたエンドポイントにマッピングします。生成されたエンドポイントをカスタムドメイン値にマッピングするまで、サーバーを管理したり、サーバーの Chef Automate ダッシュボードに接続したりできません。
生成されたエンドポイント値を取得するには、サーバーがオンラインになった後に次の AWS CLI コマンドを実行します。
```
aws opsworks describe-servers --server-name server_name
```
### CloudFormation (CLI) を使用して Chef Automate サーバーを作成する
ローカルコンピュータで がまだ実行されていない場合は AWS CLI、*AWS コマンドラインインターフェイスユーザーガイド* AWS CLI [のインストール手順に従って](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)、 をダウンロードしてインストールします。このセクションでは、**create-stack** コマンドで使用できるパラメータのすべては説明しません。**create-stack** パラメータの詳細については、「[**create-stack**リファレンス](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html)」の「*AWS CLI *」を参照してください。
1. 必ず [[前提条件](gettingstarted-opscm.md#gettingstarted-opscm-prereq)] を実行して AWS OpsWorks for Chef Automate サーバーを作成してください。
1. サービスロールとインスタンスプロファイルを作成します。
アカウントでサービスロールの ARNs を検索してコピーします。
```
aws iam list-roles --path-prefix "/service-role/" --no-paginate
```
`list-roles` コマンドの結果内で、次のようなサービスロールとインスタンスプロファイルのエントリを探します。サービスロールとインスタンスプロファイルの ARNs を書き留め、サーバースタックの作成に使用する CloudFormation テンプレートに追加します。
1. **create-stack** コマンドを再度実行して AWS OpsWorks for Chef Automate サーバーを作成します。
+ *stack\$1name* をスタックの名前に置き換えます。これは、Chef Automate サーバーではなく、 CloudFormation スタックの名前です。Chef Automate サーバー名は、 CloudFormation テンプレート`ServerName`内の の値です。
+ *template* をテンプレートファイルへのパスに置き換え、*yaml または json* を必要に応じて `.yaml` または `.json` に置き換えます。
+ `--parameters` の値は [[CreateServer](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html)] (サーバーの作成) API からの [[EngineAttributes]](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworkscm-server.html#cfn-opsworkscm-server-engineattributes) (エンジンの属性) に対応しています。Chef の場合、サーバーを作成するためにユーザーが指定するエンジン属性は、`CHEF_AUTOMATE_PIVOTAL_KEY` (「[前提条件](#opscm-create-server-cfn-prereqs)」で説明されているユーティリティを使用して生成する base64 でエンコードされた RSA パブリックキー) と `CHEF_AUTOMATE_ADMIN_PASSWORD` (ユーザーが作成する 8～32 文字のパスワード) です。`CHEF_AUTOMATE_ADMIN_PASSWORD` の詳細については、「[を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)」を参照してください。例に示すように、`PivotalKey` パラメータの値として重要なキーが含まれている PEM ファイルへのポインターを指定できます。`CHEF_AUTOMATE_ADMIN_PASSWORD` と の値がテンプレートで指定されていない場合`CHEF_AUTOMATE_PIVOTAL_KEY`は、 AWS CLI コマンドで値を指定する必要があります。
```
aws cloudformation create-stack --stack-name stack_name --template-body file://template.yaml or json --parameters ParameterKey=PivotalKey,ParameterValue="base64_encoded_RSA_public_key_value"
```
`CHEF_AUTOMATE_ADMIN_PASSWORD` 属性と `CHEF_AUTOMATE_PIVOTAL_KEY` 属性のサンプル値が含まれている例を以下に示します。 CloudFormation テンプレートでこれらの属性の値を指定しなかった場合は、同様のコマンドを実行します。
```
aws cloudformation create-stack --stack-name "OpsWorksCMChefServerStack" --template-body file://opsworkscm-server.yaml --parameters ParameterKey=PivotalKey,ParameterValue="$(openssl rsa -in "pivotalKey.pem" -pubout)" ParameterKey=Password,ParameterValue="SuPer\$ecret890"
```
1. スタックの作成が完了したら、 AWS OpsWorks for Chef Automate コンソールで新しいサーバーのプロパティページを開き、スターターキットをダウンロードします。新しいスターターキットをダウンロードすると、Chef Automate ダッシュボードの管理者パスワードがリセットされます。
1. サーバーでカスタムドメイン、証明書、およびプライベートキーを使用する場合は、[(オプション) カスタムドメインを使用するように `knife` を設定します。](opscm-starterkit.md#opscm-starterkit-customdomain) に `knife.rb` を設定のステップに従い、ステップ 7 に進みます。
1. 新しいサーバーで `knife` コマンドを使用するには、Chef `knife.rb` 設定ファイルの設定を更新します。サンプル `knife.rb` ファイルは、スターターキットに含まれています。次の例は、カスタムドメインを使用しないサーバーで `knife.rb` を設定する方法を示しています。カスタムドメインを使用している場合は、`knife` 設定手順の [(オプション) カスタムドメインを使用するように `knife` を設定します。](opscm-starterkit.md#opscm-starterkit-customdomain) を参照してください。
+ *ENDPOINT* をサーバーのエンドポイント値で置き換えます。これは、スタック作成オペレーションの出力の一部です。エンドポイントを取得するには、次のコマンドを実行します。
```
aws cloudformation describe-stacks --stack-name stack_name
```
+ `client_key` の設定の *key\$1pair\$1file.pem* を、サーバーの作成に使用した `CHEF_AUTOMATE_PIVOTAL_KEY` を含む PEM ファイルの名前に置き換えます。
```
base_dir = File.join(File.dirname(File.expand_path(__FILE__)), '..')
log_level :info
log_location STDOUT
node_name 'pivotal'
client_key File.join(base_dir, '.chef', 'key_pair_file.pem')
syntax_check_cache_path File.join(base_dir, '.chef', 'syntax_check_cache')
cookbook_path [File.join(base_dir, 'cookbooks')]
chef_server_url 'ENDPOINT/organizations/default'
ssl_ca_file File.join(base_dir, '.chef', 'ca_certs', 'opsworks-cm-ca-2020-root.pem')
trusted_certs_dir File.join(base_dir, '.chef', 'ca_certs')
```
1. サーバーの作成プロセスが完了したら、「[スターターキットを使用して Chef サーバーを設定する](opscm-starterkit.md)」に進みます。スタックの作成に失敗した場合、コンソールに表示されるエラーメッセージを確認し、問題を解決します。 CloudFormation スタックのエラーのトラブルシューティングの詳細については、*CloudFormation 「 ユーザーガイド*」の[「エラーのトラブルシューティング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors)」を参照してください。
# カスタムドメインを使用するように 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 サポート チームにお問い合わせください。
このセクションでは、サーバーのバックアップを使用して新しい AWS OpsWorks for Chef Automate サーバーを作成することで、カスタムドメインと証明書を使用するように既存のサーバーを更新する方法について説明します。基本的に、バックアップから新しいサーバーを作成し、カスタムドメイン、証明書、プライベートキーを使用するように新しいサーバーを設定することで、既存の AWS OpsWorks for Chef Automate 2.0 サーバーをコピーします。
**Topics**
+ [前提条件](#opscm-update-server-custom-domain-reqs)
+ [制限事項](#opscm-update-server-custom-domain-limits)
+ [カスタムドメインを使用するようにサーバーを更新する](#opscm-update-server-custom-domain-howto)
+ [以下の資料も参照してください。](#opscm-update-server-custom-domain-seealso)
## 前提条件
以下は、カスタムドメインと証明書を使用するように既存の AWS OpsWorks for Chef Automate サーバーを更新するための要件です。
+ 更新 (またはコピー) するサーバーは、Chef Automate 2.0 を実行している必要があります。
+ 新しいサーバーの作成に使用するバックアップを決定します。更新するサーバーのバックアップが少なくとも 1 つ必要です。でのバックアップの詳細については AWS OpsWorks for Chef Automate、「」を参照してください[AWS OpsWorks for Chef Automate サーバーのバックアップ](opscm-chef-backup.md)。
+ バックアップのソースである既存のサーバーを作成するために使用したサービスロールとインスタンスプロファイルの ARN を準備します。
+ 最新リリースの AWS CLIを実行していることを確認してください。 AWS CLI ツールの更新の詳細については、*AWS コマンドラインインターフェイスユーザーガイド*[の「 のインストール AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
## 制限事項
バックアップから新しいサーバーを作成して既存のサーバーを更新する場合、新しいサーバーを既存の AWS OpsWorks for Chef Automate サーバーとまったく同じにすることはできません。
+ この手順は、 AWS CLI またはいずれかの [AWS SDKs](https://docs.aws.amazon.com/#sdks)。 AWS マネジメントコンソールを使用してバックアップから新しいサーバーを作成することはできません。
+ 新しいサーバーに、アカウント内および AWS リージョン内の既存のサーバーと同じ名前は使用できません。名前は、バックアップのソースとして使用した既存のサーバーとは異なる必要があります。
+ 既存のサーバーに接続されたノードは、新しいサーバーによって管理されません。次のいずれかを行う必要があります。
+ 複数の Chef Automate サーバーでノードを管理することはできないため、異なるノードをアタッチします。
+ 既存のサーバー (バックアップのソース) から新しいサーバーと新しいカスタムドメインエンドポイントにノードを移行します。ノードの移行方法の詳細については、Chef のドキュメントの「」を参照してください。
## カスタムドメインを使用するようにサーバーを更新する
既存の Chef Automate 2.0 サーバーを更新するには、バックアップ、カスタムドメイン、カスタム証明書、カスタムプライベートキーを指定するパラメータを追加して `create-server` コマンドを実行し、コピーを作成します。
1. `create-server` コマンドで指定できるサービスロールまたはインスタンスプロファイルの ARN がない場合は、「[を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)」のステップ 1～5 に従って、使用できるサービスロールとインスタンスプロファイルを作成します。
1. まだ作成していない場合は、カスタムドメインで新しいサーバーのベースにする既存の Chef Automate 2.0 サーバーのバックアップを探します。次のコマンドを実行して、アカウントとリージョン内のすべての AWS OpsWorks for Chef Automate バックアップに関する情報を表示します。使用するバックアップの ID を書き留めておきます。
```
aws opsworks-cm --region region name describe-backups
```
1. `create-server` コマンドを実行して AWS OpsWorks for Chef Automate サーバーを作成します。
+ `--engine` の値は、`ChefAutomate`、`--engine-model` は、`Single`、`--engine-version` は `12` です。
+ サーバー名は、 AWS アカウント内で各リージョン内で一意である必要があります。サーバー名は文字で始める必要があります。その後は文字、数字、またはハイフン (-) を最大 40 文字まで使用できます。
+ ステップ 1 のインスタンスプロファイル ARN とサービスロール ARN を使用します。
+ 有効なインスタンスタイプは `m5.large`、`r5.xlarge`、または `r5.2xlarge` です。これらのインスタンスタイプの仕様の詳細については、*「Amazon EC2 ユーザーガイド」*の[「インスタンスタイプ」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)を参照してください。
+ `--engine-attributes` パラメータはオプションです。いずれかまたは両方の値を指定しない場合、サーバー作成プロセスで値が生成されます。`--engine-attributes` を追加する場合は、ステップ 2 で生成した `CHEF_AUTOMATE_PIVOTAL_KEY` 値、`CHEF_AUTOMATE_ADMIN_PASSWORD`、またはその両方を指定します。
`CHEF_AUTOMATE_ADMIN_PASSWORD` の値を設定しない場合、`create-server` レスポンスの一部としてパスワードが生成され返されます。コンソールでスターターキットをもう一度ダウンロードして、このパスワードを再生成することもできます。パスワードの最小の長さは 8 文字、最大は 32 文字です。パスワードには、文字、数字、および特殊文字 (`!/@#$%^+=_`) を使用できます。パスワードは、少なくとも 1 つの小文字、1 つの大文字、1 つの数字、および 1 つの特殊文字を含む必要があります。
+ SSH キーペアはオプションですが、Chef Automate ダッシュボードの管理者パスワードをリセットする必要がある場合に Chef Automate サーバーに接続することができます。SSH キーペアの作成の詳細については、*「Amazon EC2 User Guide」*(Amazon EC2 ユーザーガイド) の[「Amazon EC2 Key Pairs」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)(Amazon EC2のキーペア) を参照してください。
+ カスタムドメインを使用するには、コマンドに以下のパラメータを追加します。それ以外の場合は、Chef Automate サーバー作成プロセスによって自動的にエンドポイントが生成されます。カスタムドメインを構成するには、3 つのパラメータすべてが必要です。これらのパラメータを使用するための追加の要件については、CM API リファレンスの[CreateServer](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html) OpsWorks 」を参照してください。
+ `--custom-domain` - サーバーのオプションのパブリックエンドポイント (`https://aws.my-company.com` など)。
+ `--custom-certificate` - PEM 形式の HTTPS 証明書。値には、単一の自己署名証明書、または証明書チェーンを指定できます。
+ `--custom-private-key` - HTTPS を使用してサーバーに接続するための PEM 形式のプライベートキー。プライベートキーは暗号化しないでください。パスワードやパスフレーズで保護することはできません。
+ 週 1 回のシステムメンテナンスが必要です。次の形式で有効な値を指定する必要があります: `DDD:HH:MM`。指定時刻は協定世界時 (UTC) です。`--preferred-maintenance-window` の値を指定しない場合、火曜日、水曜日、または金曜日の 1 時間がランダムでデフォルト値になります。
+ `--preferred-backup-window` の有効な値は次の形式のいずれかで指定する必要があります: 日次バックアップの場合は `HH:MM`、週次バックアップの場合は `DDD:HH:MM`。指定時刻は UTC です。デフォルト値は日次で開始時間はランダムです。自動バックアップを無効にするには、代わりにパラメータ `--disable-automated-backup` を追加します。
+ `--security-group-ids` に、1 つ以上のセキュリティグループ ID をスペースで区切って入力します。
+ `--subnet-ids` には、サブネット ID を入力します。
+ `--backup-id` には、ステップ 2 でコピーしたバックアップの ID を入力します。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" --server-name "server_name" --instance-profile-arn "instance_profile_ARN" --instance-type "instance_type" --engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"pivotal_key","CHEF_AUTOMATE_ADMIN_PASSWORD":"password"}' --key-pair "key_pair_name" --preferred-maintenance-window "ddd:hh:mm" --preferred-backup-window "ddd:hh:mm" --security-group-ids security_group_id1 security_group_id2 --service-role-arn "service_role_ARN" --subnet-ids subnet_ID --backup-id backup_ID
```
次の例では、カスタムドメインを使用する Chef Automate サーバーを作成します。
```
aws opsworks-cm create-server --engine "ChefAutomate" --engine-model "Single" --engine-version "12" \
--server-name "my-custom-domain-server" \
--instance-profile-arn "arn:aws:iam::12345678912:instance-profile/aws-opsworks-cm-ec2-role" \
--instance-type "m5.large" \
--engine-attributes '{"CHEF_AUTOMATE_PIVOTAL_KEY":"MZZE...Wobg","CHEF_AUTOMATE_ADMIN_PASSWORD":"zZZzDj2DLYXSZFRv1d"}' \
--custom-domain "my-chef-automate-server.my-corp.com" \
--custom-certificate "-----BEGIN CERTIFICATE----- EXAMPLEqEXAMPLE== -----END CERTIFICATE-----" \
--custom-private-key "-----BEGIN RSA PRIVATE KEY----- EXAMPLEqEXAMPLE= -----END RSA PRIVATE KEY-----" \
--key-pair "amazon-test" \
--preferred-maintenance-window "Mon:08:00" \
--preferred-backup-window "Sun:02:00" \
--security-group-ids sg-b00000001 sg-b0000008 \
--service-role-arn "arn:aws:iam::12345678912:role/service-role/aws-opsworks-cm-service-role" \
--subnet-ids subnet-300aaa00 \
--backup-id MyChefServer-20191004122143125
```
1. AWS OpsWorks for Chef Automate 新しいサーバーの作成には約 15 分かかります。`create-server` コマンドの出力で、`Endpoint` 属性の値をコピーします。以下に例を示します。
```
"Endpoint": "automate-07-exampleexample.opsworks-cm.us-east-1.amazonaws.com"
```
`create-server` コマンドの出力を閉じたり、シェルセッションを閉じたりしないでください。今後表示されない重要な情報が出力に含まれている場合があります。`create-server` の結果からパスワードとスターターキットを取得するには、次のステップに進みます。
1. でキーとパスワード AWS OpsWorks for Chef Automate を生成することを選択した場合は、[jq](https://stedolan.github.io/jq/) などの JSON プロセッサを使用して`create-server`、結果から使用可能な形式で抽出できます。[jq](https://stedolan.github.io/jq/) をインストールした後、以下のコマンドを実行して中枢キー、Chef Automate ダッシュボード管理者パスワード、およびスターターキットを抽出できます。ステップ 3 で独自の中枢キーとパスワードを指定しなかった場合は、抽出した中枢キーと管理者パスワードを使いやすく安全な場所に保存してください。
```
#Get the Chef password:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_AUTOMATE_ADMIN_PASSWORD") | .Value'
#Get the Chef Pivotal Key:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_AUTOMATE_PIVOTAL_KEY") | .Value'
#Get the Chef Starter Kit:
cat resp.json | jq -r '.Server.EngineAttributes[] | select(.Name == "CHEF_STARTER_KIT") | .Value' | base64 -D > starterkit.zip
```
1. オプションで、`create-server`コマンド結果からスターターキットを抽出しなかった場合は、 AWS OpsWorks for Chef Automate コンソールのサーバーのプロパティページから新しいスターターキットをダウンロードできます。新しいスターターキットをダウンロードすると、Chef Automate ダッシュボードの管理者パスワードがリセットされます。
1. エンタープライズの DNS 管理ツールで CNAME エントリを作成して、ステップ 4 でコピーした AWS OpsWorks for Chef Automate エンドポイントにカスタムドメインをポイントします。このステップを完了するまで、サーバーにアクセスしたりサインインしたりすることはできません。
1. サーバーの作成プロセスが完了したら、「[スターターキットを使用して Chef サーバーを設定する](opscm-starterkit.md)」に進みます。
## 以下の資料も参照してください。
+ [を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)
+ [バックアップから AWS OpsWorks for Chef Automate サーバーを復元する](opscm-chef-restore.md)
+ CM API リファレンス OpsWorks の [CreateServer](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html)
+ [**create-server**「 コマンドリファレンス」](https://docs.aws.amazon.com/cli/latest/reference/opsworks-cm/create-server.html)の*「AWS CLI 」*を参照してください。
# 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 サポート チームにお問い合わせください。
のスターターキット AWS OpsWorks for Chef Automate には、例を含む README ファイル、`knife.rb`設定ファイル、プライマリまたはピボットユーザーのプライベートキーが含まれています。スターターキットをダウンロードするごとに、新しいキーペアが生成され、古いキーはリセットされます。 AWS OpsWorks for Chef Automate サーバーのスターターキットは、次の 2 つの方法のいずれかで再生成できます。
+ OpsWorks コンソールで、 AWS OpsWorks for Chef Automate サーバーの詳細ページの**アクション**メニュー。古いピボットキーを再生成してリセットするかどうかを確認するよう求められます。
+ でコマンドを実行する。 AWS CLI
スターターキットの使用方法の詳細については、「[スターターキットを使用して Chef サーバーを設定する](opscm-starterkit.md)」を参照してください。
## を使用して AWS OpsWorks for Chef Automate スターターキットを再生成する AWS CLI
**注記**
スターターキットを再生成するときに、Chef Automate サーバーの認証キーペアも再生成してリセットし、現在のキーペアを削除します。
[https://docs.aws.amazon.com/cli/latest/reference/opsworks-cm/update-server-engine-attributes.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks-cm/update-server-engine-attributes.html) コマンドを実行して、スターターキットを再生成します。 AWS CLI セッションで、次のコマンドを実行します。サーバ名を `--server-name` の値として指定します。`CHEF_AUTOMATE_PIVOTAL_KEY` の値として自分の公開鍵を設定するにはで、`--attribute-value` でパブリックキーの値を指定します。それ以外の場合は、null に `--attribute-value` が設定されます。
```
aws opsworks-cm update-server-engine-attributes \
--server-name server_name \
--attribute-name "CHEF_AUTOMATE_PIVOTAL_KEY" \
--attribute-value your_public_key
```
次のコマンドは、サーバーの管理者が使用する公開キーの値を指定する例です。
```
aws opsworks-cm update-server-engine-attributes \
--server-name your-test-server \
--attribute-name "CHEF_AUTOMATE_PIVOTAL_KEY" \
--attribute-value "-----BEGIN PUBLIC KEY-----ExamplePublicKey-----END PUBLIC KEY-----"
```
次のコマンドは、 がパブリックキー AWS OpsWorks for Chef Automate を再生成できるようにする例です。
```
aws opsworks-cm update-server-engine-attributes \
--server-name your-test-server \
--attribute-name "CHEF_AUTOMATE_PIVOTAL_KEY" \
--attribute-value null
```
このコマンドの出力は、サーバに関する情報と base64 でエンコードされた ZIP ファイルです。ZIP ファイルには、README、設定ファイル、および必要な RSA プライベートキーを含む Chef スターターキットが含まれています。このファイルを保存して解凍し、ファイルの内容を解凍したディレクトリに移動します。このディレクトリから、`knife` コマンドを実行することができます。
# 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 サポート チームにお問い合わせください。
タグとは、AWS リソースを識別および整理するためのメタデータとして使用される単語やフレーズのことです。では AWS OpsWorks for Chef Automate、リソースに最大 50 個のユーザー適用タグを含めることができます。各タグはキーと 1 つのオプションの値で構成されます。 AWS OpsWorks for Chef Automateで以下のリソースにタグを適用できます。
+ AWS OpsWorks for Chef Automate サーバー
+ AWS OpsWorks for Chef Automate サーバーのバックアップ
AWS リソースのタグは、コストの追跡、リソースへのアクセスの制御、タスクを自動化するためのリソースのグループ化、目的またはライフサイクルステージ別のリソースの整理に役立ちます。タグのメリットの詳細については、AWS Billing and Cost Management ユーザーガイドの[AWS タグ付け戦略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) AWS Answers と[コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what) を参照してください。
タグを使用して AWS OpsWorks for Chef Automate サーバーまたはバックアップへのアクセスを制御するには、 AWS Identity and Access Management (IAM) でポリシーステートメントを作成または編集します。詳細については、*AWS Identity and Access Management ユーザーガイド* の[「Controlling Access to AWS Resources Using Resource Tags」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)(リソースタグを使用した リソースへのアクセスの制御) を参照してください。
AWS OpsWorks for Chef Automate サーバーにタグを適用すると、タグはサーバーのバックアップ、バックアップを保存する Amazon S3 バケット、サーバーの Amazon EC2 インスタンス、保存先のサーバーのシークレット AWS Secrets Manager、サーバーで使用される Elastic IP アドレスにも適用されます。タグは、 がサーバーの作成 OpsWorks に使用する CloudFormation スタックには伝達されません。
**Topics**
+ [でのタグの仕組み AWS OpsWorks for Chef Automate](#opscm-tags-concepts)
+ [でのタグの追加と管理 AWS OpsWorks for Chef Automate (コンソール)](#opscm-tags-howto-console)
+ [( AWS OpsWorks for Chef Automate CLI) でのタグの追加と管理](#opscm-tags-howto)
+ [以下の資料も参照してください。](#opscm-tags-seealso)
## でのタグの仕組み AWS OpsWorks for Chef Automate
このリリースでは、[OpsWorks CM API](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/Welcome.html) または AWS マネジメントコンソールを使用してタグを追加および管理できます。 OpsWorks CM は、EC2 インスタンス、Secrets Manager のシークレット、Elastic IP アドレス、セキュリティグループ、S3 バケット、バックアップなど、サーバーに関連付けられた AWS リソースにサーバーに追加するタグも追加しようとします。以下の表では、 AWS OpsWorks for Chef Automateでタグを追加および管理する方法の概要を示しています。
| Action | 使用するもの |
| --- | --- |
| 手動で作成する新しい AWS OpsWorks for Chef Automate サーバーまたはバックアップにタグを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/opscm-tags.html) |
| リソースのタグを表示します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/opscm-tags.html) |
| バックアップが手動で作成されたか自動的に作成されたかにかかわらず、既存の AWS OpsWorks for Chef Automate サーバーまたはバックアップにタグを追加します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/opscm-tags.html) |
| リソースからタグを削除する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/opscm-tags.html) |
`DescribeServers` および `DescribeBackups` のレスポンスにタグ情報は含まれません。タグを表示するには、`ListTagsForResource` API を使用します。
## でのタグの追加と管理 AWS OpsWorks for Chef Automate (コンソール)
このセクションの手順は AWS マネジメントコンソールで実行されます。
タグを追加する場合、タグのキーを空にすることはできません。キーは最大 127 文字で、Unicode 文字、数字、区切り文字、または特殊文字 (`+ - = . _ : / @`) のみを含めることができます。タグの値はオプションです。キーはあるが値はないタグであれば、追加できます。値は最大 255 文字とし、Unicode 文字、数字、区切り文字、または特殊文字 (`+ - = . _ : / @`) のみを含めることができます。
**Topics**
+ [新しい AWS OpsWorks for Chef Automate サーバーにタグを追加する (コンソール)](#opscm-tags-howto-createserver-console)
+ [新しいバックアップにタグを追加する (コンソール)](#opscm-tags-howto-createbackup-console)
+ [既存のサーバーにタグを追加または表示する (コンソール)](#opscm-tags-howto-server-tag-console)
+ [既存のバックアップにタグを追加または表示する (コンソール)](#opscm-tags-existing-backup-console)
+ [サーバからタグを削除する (コンソール)](#opscm-tags-delete-server-console)
+ [バックアップからタグを削除する (コンソール)](#opscm-tags-delete-backup-console)
### 新しい AWS OpsWorks for Chef Automate サーバーにタグを追加する (コンソール)
1. AWS OpsWorks for Chef Automate サーバーを作成するための[前提条件](gettingstarted-opscm.md#gettingstarted-opscm-prereq-customdomain)を必ず満たしてください。
1. [Chef Automate サーバーの作成](gettingstarted-opscm-create.md) の手順 1～10 に従います。
1. 自動バックアップ設定を指定した後、**[Configure advanced settings]** (詳細設定の設定) ページの **[Tags]** (タグ) の領域でタグを追加します。最大 50 個のタグを追加できます。タグを追加したら、[**次へ**] を選択します。
1. [Chef Automate サーバーの作成](gettingstarted-opscm-create.md) のステップ 13 に進み、新しいサーバーに対して選択した設定を確認します。
### 新しいバックアップにタグを追加する (コンソール)
1. AWS OpsWorks for Chef Automate ホームページで、既存の Chef Automate サーバーを選択します。
1. サーバーの詳細ページで、ナビゲーションペインで [**Backups (バックアップ)**] を選択します。
1. [**Backups (バックアップ)**] ページで、[**Create backup (バックアップの作成)**] を選択します。
1. タグを追加。タグの追加が完了したら、[**Create (作成)**] を選択します。
### 既存のサーバーにタグを追加または表示する (コンソール)
1. AWS OpsWorks for Chef Automate ホームページで、既存の Chef Automate サーバーを選択して詳細ページを開きます。
1. ナビゲーションペインで [**Tags (タグ)**] を選択するか、詳細ページの下部にある [**View all tags (すべてのタグを表示)**] を選択します。
1. [**Tags (タグ)**] ページで、[**Edit (編集)**] を選択します。
1. サーバー上のタグを追加または編集します。完了したら、[**保存**] を選択します。
**注記**
Chef Automate サーバーでタグを変更すると、EC2 インスタンス、Elastic IP アドレス、セキュリティグループ、S3 バケット、バックアップなど、サーバーに関連付けられているリソースのタグも変更されることに注意してください。
### 既存のバックアップにタグを追加または表示する (コンソール)
1. AWS OpsWorks for Chef Automate ホームページで、既存の Chef Automate サーバーを選択して詳細ページを開きます。
1. ナビゲーションペインで [**Backups (バックアップ)**] を選択するか、詳細ページの [**Recent backups (最近のバックアップ)**] 領域で [**View all backups (すべてのバックアップを表示)**] を選択します。
1. [**Backups (バックアップ)**] ページで、管理するバックアップを選択し、[**Edit backup (バックアップの編集)**] を選択します。
1. バックアップにタグを追加または編集します。完了したら、[**Update (更新)**] を選択します。
### サーバからタグを削除する (コンソール)
1. AWS OpsWorks for Chef Automate ホームページで、既存の Chef Automate サーバーを選択して詳細ページを開きます。
1. ナビゲーションペインで [**Tags (タグ)**] を選択するか、詳細ページの下部にある [**View all tags (すべてのタグを表示)**] を選択します。
1. [**Tags (タグ)**] ページで、[**Edit (編集)**] を選択します。
1. タグを削除するには、タグの横にある [**X**] を選択します。完了したら、[**保存**] を選択します。
**注記**
Chef Automate サーバーでタグを変更すると、EC2 インスタンス、Elastic IP アドレス、セキュリティグループ、S3 バケット、バックアップなど、サーバーに関連付けられているリソースのタグも変更されることに注意してください。
### バックアップからタグを削除する (コンソール)
1. AWS OpsWorks for Chef Automate ホームページで、既存の Chef Automate サーバーを選択して詳細ページを開きます。
1. ナビゲーションペインで [**Backups (バックアップ)**] を選択するか、詳細ページの [**Recent backups (最近のバックアップ)**] 領域で [**View all backups (すべてのバックアップを表示)**] を選択します。
1. [**Backups (バックアップ)**] ページで、管理するバックアップを選択し、[**Edit backup (バックアップの編集)**] を選択します。
1. タグを削除するには、タグの横にある [**X**] を選択します。完了したら、[**Update (更新)**] を選択します。
## ( AWS OpsWorks for Chef Automate CLI) でのタグの追加と管理
このセクションの手順は AWS CLIで実行されます。タグの使用 AWS CLI を開始する前に、 の最新リリースを実行していることを確認してください。のインストールまたは更新の詳細については AWS CLI、 *AWS Command Line Interface ユーザーガイド*[の「 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)のインストール」を参照してください。
タグを追加する場合、タグのキーを空にすることはできません。キーは最大 127 文字で、Unicode 文字、数字、区切り文字、または特殊文字 (`+ - = . _ : / @`) のみを含めることができます。タグの値はオプションです。キーはあるが値はないタグであれば、追加できます。値は最大 255 文字とし、Unicode 文字、数字、区切り文字、または特殊文字 (`+ - = . _ : / @`) のみを含めることができます。
**Topics**
+ [新しい AWS OpsWorks for Chef Automate サーバーにタグを追加する (CLI)](#opscm-tags-howto-createserver)
+ [新しいバックアップにタグを追加する (CLI)](#opscm-tags-howto-createbackup)
+ [既存のサーバーまたはバックアップにタグを追加する (CLI)](#opscm-tags-howto-addtags)
+ [リソースタグのリストを取得する](#opscm-tags-howto-listtags)
+ [リソースからタグを削除する](#opscm-tags-howto-untag)
### 新しい AWS OpsWorks for Chef Automate サーバーにタグを追加する (CLI)
AWS OpsWorks for Chef Automate サーバーを作成するときに AWS CLI 、 を使用してタグを追加できます。この手順では、サーバーの作成方法について詳しく説明していません。このガイドの を使用して AWS OpsWorks for Chef Automate サーバーを作成する方法の詳細については、[を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli) AWS CLI 「」を参照してください。サーバーには最大 50 個のタグを追加できます。
1. AWS OpsWorks for Chef Automate サーバーを作成するための[前提条件](gettingstarted-opscm.md#gettingstarted-opscm-prereq-customdomain)を必ず満たしてください。
1. 「[を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)」のステップ 1 〜 5 を完了します。
1. ステップ 6 では、`create-server` コマンドを実行するときに、以下の例に示すように、コマンドに `--tags` パラメータを追加します。
```
aws opsworks-cm create-server ... --tags Key=Key1,Value=Value1 Key=Key2,Value=Value2
```
以下の例では、`create-server` コマンドのタグ部分のみを示しています。
```
aws opsworks-cm create-server ... --tags Key=Stage,Value=Production Key=Department,Value=Marketing
```
1. 「[を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)」の残りのステップを行います。タグが新しいサーバーに追加されたことを確認するには、このトピックの「[リソースタグのリストを取得する](#opscm-tags-howto-listtags) 」の手順に従います。
### 新しいバックアップにタグを追加する (CLI)
を使用して、 サーバーの新しい手動バックアップ AWS OpsWorks for Chef Automate を作成するときにタグ AWS CLI を追加できます。この手順では、手動バックアップの作成方法について詳しく説明していません。手動バックアップの作成方法の詳細については、の「 で手動バックアップを実行するには AWS CLI」を参照してください[AWS OpsWorks for Chef Automate サーバーのバックアップ](opscm-chef-backup.md)。バックアップには最大 50 個のタグを追加できます。サーバにタグがある場合、新しいバックアップにはサーバのタグが自動的にタグ付けされます。
デフォルトでは、新しい AWS OpsWorks for Chef Automate サーバーを作成すると、自動バックアップが有効になります。このトピックの「[既存のサーバーまたはバックアップにタグを追加する (CLI)](#opscm-tags-howto-addtags) 」で説明されている `tag-resource` コマンドを実行して、自動バックアップにタグを追加できます。
+ 手動バックアップの作成中にタグをバックアップに追加するには、以下のコマンドを実行します。コマンドのタグ部分のみを示しています。フル `create-backup` コマンドの例に関しては、[AWS OpsWorks for Chef Automate サーバーのバックアップ](opscm-chef-backup.md) の「 AWS CLIで手動バックアップを実行するには」を参照してください。
```
aws opsworks-cm create-backup ... --tags Key=Key1,Value=Value1 Key=Key2,Value=Value2
```
以下の例では、`create-backup` コマンドのタグ部分のみを示しています。
```
aws opsworks-cm create-backup ... --tags Key=Stage,Value=Production Key=Department,Value=Marketing
```
### 既存のサーバーまたはバックアップにタグを追加する (CLI)
`tag-resource` コマンドを実行して、タグを既存の AWS OpsWorks for Chef Automate サーバーまたはバックアップに追加できます (バックアップが手動で作成されたか自動的に作成されたかに関係なく)。ターゲットリソースの Amazon リソースナンバー (ARN) を指定して、タグを追加します。
1. タグを適用するリソースの ARN を取得するには:
+ サーバーの場合は、`describe-servers --server-name server_name` を実行します。コマンドの結果には、サーバーの ARN が表示されます。
+ バックアップの場合は、`describe-backups --backup-id backup_ID` を実行します。コマンドの結果には、バックアップの ARN が表示されます。を実行して`describe-backups --server-name server_name`、特定の AWS OpsWorks for Chef Automate サーバーのすべてのバックアップに関する情報を表示することもできます。
以下の例では、`ServerArn` コマンドの結果の `describe-servers --server-name opsworks-cm-test` のみを示しています。`tag-resource` コマンドに `ServerArn` 値を指定して、サーバーにタグを追加します。
```
{
"Servers": [
{
...
"ServerArn": "arn:aws:opsworks-cm:us-west-2:123456789012:server/opsworks-cm-test/EXAMPLEd-66b0-4196-8274-d1a2bEXAMPLE"
}
]
}
```
1. ステップ 1 で返された ARN を使用して、`tag-resource`コマンドを実行します。
```
aws opsworks-cm tag-resource --resource-arn "server_or_backup_ARN" --tags Key=Key1,Value=Value1 Key=Key2,Value=Value2
```
以下に例を示します。
```
aws opsworks-cm tag-resource --resource-arn "arn:aws:opsworks-cm:us-west-2:123456789012:server/opsworks-cm-test/EXAMPLEd-66b0-4196-8274-d1a2bEXAMPLE" --tags Key=Stage,Value=Production Key=Department,Value=Marketing
```
1. タグが正常に追加されたことを確認するには、次の手順「[リソースタグのリストを取得する](#opscm-tags-howto-listtags) 」に進みます。
### リソースタグのリストを取得する
`list-tags-for-resource` コマンドを実行して、 AWS OpsWorks for Chef Automate サーバーまたはバックアップにアタッチされているタグを表示できます。ターゲットリソースの ARN を指定して、そのタグを表示します。
1. タグを一覧表示するリソースの ARN を取得するには:
+ サーバーの場合は、`describe-servers --server-name server_name` を実行します。コマンドの結果には、サーバーの ARN が表示されます。
+ バックアップの場合は、`describe-backups --backup-id backup_ID` を実行します。コマンドの結果には、バックアップの ARN が表示されます。を実行して`describe-backups --server-name server_name`、特定の AWS OpsWorks for Chef Automate サーバーのすべてのバックアップに関する情報を表示することもできます。
1. ステップ 1 で返された ARN を使用して、`list-tags-for-resource`コマンドを実行します。
```
aws opsworks-cm list-tags-for-resource --resource-arn "server_or_backup_ARN"
```
以下に例を示します。
```
aws opsworks-cm tag-resource --resource-arn "arn:aws:opsworks-cm:us-west-2:123456789012:server/opsworks-cm-test/EXAMPLEd-66b0-4196-8274-d1a2bEXAMPLE"
```
リソースにタグがある場合、コマンドは以下のような結果を返します。
```
{
"Tags": [
{
"Key": "Stage",
"Value": "Production"
},
{
"Key": "Department",
"Value": "Marketing"
}
]
}
```
### リソースからタグを削除する
`untag-resource` コマンドを実行して、 AWS OpsWorks for Chef Automate サーバーまたはバックアップからタグを削除できます。リソースが削除されると、リソースのタグも削除されます。ターゲットリソースの Amazon リソースナンバー (ARN) を指定して、タグを削除します。
1. タグを削除するリソースの ARN を取得するには:
+ サーバーの場合は、`describe-servers --server-name server_name` を実行します。コマンドの結果には、サーバーの ARN が表示されます。
+ バックアップの場合は、`describe-backups --backup-id backup_ID` を実行します。コマンドの結果には、バックアップの ARN が表示されます。を実行して`describe-backups --server-name server_name`、特定の AWS OpsWorks for Chef Automate サーバーのすべてのバックアップに関する情報を表示することもできます。
1. ステップ 1 で返された ARN を使用して、`untag-resource` コマンドを実行します。削除するタグのみを指定します。
```
aws opsworks-cm untag-resource --resource-arn "server_or_backup_ARN" --tags Key=Key1,Value=Value1 Key=Key2,Value=Value2
```
この例では、`untag-resource` コマンドは、キーが `Stage` で値が `Production` のタグのみを削除します。
```
aws opsworks-cm untag-resource --resource-arn "arn:aws:opsworks-cm:us-west-2:123456789012:server/opsworks-cm-test/EXAMPLEd-66b0-4196-8274-d1a2bEXAMPLE" --tags Key=Stage,Value=Production
```
1. タグが正常に削除されたことを確認するには、このトピックの「[リソースタグのリストを取得する](#opscm-tags-howto-listtags) 」の手順に従います。
## 以下の資料も参照してください。
+ [を使用して Chef Automate サーバーを作成する AWS CLI](gettingstarted-opscm-create.md#gettingstarted-opscm-create-cli)
+ [AWS OpsWorks for Chef Automate サーバーのバックアップ](opscm-chef-backup.md)
+ [AWS タグ付け戦略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ *AWS Identity and Access Management ユーザーガイド*[の AWS リソースタグを使用したリソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)
+ 「*AWS Billing and Cost Management ユーザーガイド*」の「[コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what)」
+ OpsWorks CM API リファレンス の [CreateBackup](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateBackup.html)
+ OpsWorks CM API リファレンス の [CreateServer](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html)
+ OpsWorks CM API リファレンス の [TagResource](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_TagResource.html)
+ OpsWorks CM API リファレンス の [ListTagsForResource](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_ListTagsForResource.html)
+ [OpsWorks 「CM API Reference」](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_UntagResource.html) (CM API リファレンス) の *UntagResource* (リソースのタグを外す)
# 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 サポート チームにお問い合わせください。
このセクションでは、 AWS OpsWorks for Chef Automate サーバーをバックアップおよび復元する方法と、バックアップを削除する方法について説明します。
**Topics**
+ [AWS OpsWorks for Chef Automate サーバーのバックアップ](opscm-chef-backup.md)
+ [バックアップから AWS OpsWorks for Chef Automate サーバーを復元する](opscm-chef-restore.md)
# 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 サポート チームにお問い合わせください。
毎日または毎週の定期的な AWS OpsWorks for Chef Automate サーバーバックアップを定義し、ユーザーに代わって Amazon Simple Storage Service (Amazon S3) にバックアップを保存させることができます。または、必要に応じて手動でバックアップを実行することもできます。
バックアップが Amazon S3 に保存されるため、追加料金を負担します。30 世代を上限としてバックアップ保持期間を定義できます。 AWS サポートチャネルを使用して、サービスリクエストを送信して、その制限を変更することができます。Amazon S3 バケットに配信されるコンテンツには、カスタマーコンテンツが含まれている場合があります。機密データの削除の詳細については、[「S3 バケットを空にする方法」](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)または[「S3 バケットを削除する方法」](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)を参照してください。
AWS OpsWorks for Chef Automate サーバーのバックアップにタグを追加できます。 AWS OpsWorks for Chef Automate サーバーにタグを追加した場合、サーバーの自動バックアップはこれらのタグを継承します。バックアップでタグを追加および管理する方法についての詳細は、このガイドの「[AWS OpsWorks for Chef Automate リソースでのタグの使用](opscm-tags.md)」を参照してください。
**Topics**
+ [自動バックアップ](#opscm-chef-backup-auto)
+ [手動バックアップ](#opscm-chef-backup-manual)
+ [バックアップの削除](#opscm-chef-backup-delete)
## 自動バックアップ
AWS OpsWorks for Chef Automate サーバーを設定するときは、自動バックアップまたは手動バックアップのいずれかを選択します。 は、Setup の**「高度な設定を構成する**」ページの「自動バックアップ」セクションで選択した時間と日に**自動バックアップ** AWS OpsWorks for Chef Automate を開始します。サーバーがオンライン状態になった後で、バックアップ設定を変更することもできます。そのためには、Chef Automate サーバーのホームページのサーバータイルまたはサーバーの [Properties] ページで、以下のステップを実行します。
**自動バックアップ設定を変更するには**
1. **[Chef servers]** (Chef サーバー) ホームページのサーバのタイルの **[Actions]** (アクション) メニューで、**[Change settings]** (設定を変更する) を選択します。
1. 自動バックアップを無効にするには、**[Enable automated backups]** (自動バックアップの有効化) オプションの **[No]** (いいえ) を選択します。変更を保存します。次のステップに進む必要はありません。
1. [**Automated Backup**] セクションで、頻度、開始時刻、または保持する世代数を変更します。変更内容を保存します。
## 手動バックアップ
手動バックアップは、 でいつでも開始することも AWS マネジメントコンソール、[create-backup](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateBackup.html) コマンドを実行して AWS CLI 開始することもできます。手動バックアップは、保存される最大 30 世代の自動バックアップには含まれず、最大 10 個の手動バックアップが保存され、Amazon S3 から手動で削除する必要があります。
AWS OpsWorks for Chef Automate サーバーの新しい手動バックアップを作成するときにタグを追加できます。手動バックアップを作成するときにタグを追加する方法の詳細については、「[新しいバックアップにタグを追加する (CLI)](opscm-tags.md#opscm-tags-howto-createbackup)」を参照してください
**で手動バックアップを実行するには AWS マネジメントコンソール**
1. [**Chef Automate servers**] ページで、バックアップするサーバーを選択します。
1. サーバーのプロパティページの左のナビゲーションペインで、[**Backups**] を選択します。
1. **[Create backup]** (バックアップの作成) を選択します。
1. ページでバックアップの [**Status**] 欄に緑色のチェックマークが表示されると、手動バックアップは完了です。
**で手動バックアップを実行するには AWS CLI**
+ 手動バックアップを開始するには、次の AWS CLI コマンドを実行します。
```
aws opsworks-cm --region region name create-backup --server-name "Chef server name" --description "optional descriptive string"
```
## バックアップの削除
バックアップを削除すると、バックアップが保存されている S3 バケットから完全に削除されます。
**でバックアップを削除するには AWS マネジメントコンソール**
1. [**Chef Automate servers**] ページで、バックアップするサーバーを選択します。
1. サーバーのプロパティページの左のナビゲーションペインで、[**Backups**] を選択します。
1. 削除するバックアップを選択してから、[**Delete backup**] を選択します。一度に 1 つのバックアップのみを選択できます。
1. 削除の確認を指示されたら、[**Delete the backup, which is stored in an S3 bucket**] チェックボックスにチェックを入れ、[**Yes, Delete**] を選択します。
**でバックアップを削除するには AWS CLI**
+ バックアップを削除するには、次の AWS CLI コマンドを実行し、 を削除したいバックアップの ID `--backup-id`に置き換えます。バックアップ ID は、*ServerName-yyyyMMddHHmmssSSS* という形式になっています。例えば、**test-chef-server-20171218132604388**。
```
aws opsworks-cm --region region name delete-backup --backup-id ServerName-yyyyMMddHHmmssSSS
```
# バックアップから 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 サポート チームにお問い合わせください。
使用可能なバックアップを参照した後、 AWS OpsWorks for Chef Automate サーバーを復元する時点を選択できます。サーバーのバックアップには、設定管理ソフトウェアの永続データ (クックブック、登録されたノードなど) のみが含まれています。サーバーのインプレース復元を実行する (つまり、既存の AWS OpsWorks for Chef Automate サーバーを新しい EC2 インスタンスに復元する) と、サーバーの復元に使用するバックアップ時に登録されたノードが再登録されます。復元が成功し、復元された AWS OpsWorks for Chef Automate サーバーの状態が の場合、トラフィックは新しいインスタンスに切り替わります`Healthy`。新しく作成された AWS OpsWorks for Chef Automate サーバーに復元すると、ノード接続は維持されません。サーバーを復元すると、Chef ソフトウェアのマイナーバージョンが更新されません。選択したバックアップにあるものと同じ Chef バージョンと設定管理データが適用されます。
通常、サーバの復元には新しいサーバを作成するよりも時間がかかります。時間は選択するバックアップのサイズによります。復元が完了すると、古い EC2 インスタンスは `Running` または `Stopped` 状態のままになりますが、一時的にのみです。最終的には終了します。
このリリースでは、 を使用して Chef サーバーを AWS CLI 復元できます AWS OpsWorks for Chef Automate。
**注記**
[restore-server](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_RestoreServer.html) コマンドは、現在のインスタンスタイプを変更する場合や、紛失または漏洩が発生した SSH キーの復元または設定を行う場合にも実行できます。
**サーバーをバックアップから復元するには**
1. で AWS CLI、次のコマンドを実行して、使用可能なバックアップとその IDs のリストを返します。使用するバックアップの ID を書き留めておきます。バックアップ ID は、*myServerName-yyyyMMddHHmmssSSS* という形式になっています。
```
aws opsworks-cm --region region name describe-backups
```
1. 以下のコマンドを実行してください。
```
aws opsworks-cm --region region name restore-server --backup-id "myServerName-yyyyMMddHHmmssSSS" --instance-type "Type of instance" --key-pair "name of your EC2 key pair" --server-name "name of Chef server"
```
以下に例を示します。
```
aws opsworks-cm --region us-west-2 restore-server --backup-id "MyChefServer-20161120122143125" --server-name "MyChefServer"
```
1. 復元が完了するまで待ちます。
# でのシステムメンテナンス 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 ウィザードの手順に従います。
# でのコンプライアンススキャン 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 サポート チームにお問い合わせください。
コンプライアンススキャンを使用すると、事前定義されたポリシー (*ルール*とも呼ばれる) に基づいてインフラストラクチャ内の管理対象ノードのコンプライアンスを追跡できます。Compliance のビューを使用すると、アプリケーションの脆弱性と非準拠設定を定期的に監査できます。Chef には、コンプライアンススキャンに使用できる事前定義された 100 個を超える Compliance *プロファイル* (特定のノード設定に適用するルールの集合) が用意されています。また、[Chef InSpec の言語](https://www.inspec.io/docs/)を使用して独自のカスタムプロファイルを作成することもできます。
サーバーでまだ Chef Automate 2.0 が実行されていない場合は、Audit クックブックをインストールすることで手動で [Chef Compliance](https://www.chef.io/solutions/compliance/) を設定できます。
**注記**
AWS OpsWorks for Chef Automate サーバーに関連付けられたノードでサポートされている Chef Infra クライアントエージェントソフトウェア (`chef-client`) の最小バージョンは 13.*x* です。最新の安定`chef-client`バージョン、または少なくとも 14.10.9 を実行することをお勧めします。
**Topics**
+ [Chef Automate 2.0 の Compliance](#opscm-compliance-ca20)
+ [Chef Automate 1.*x* の Compliance](#opscm-compliance-ca1x)
+ [Compliance の更新](#opscm-chefcompliance-updates)
+ [コミュニティとカスタム Compliance プロファイル](#opscm-compliance-custom)
+ [以下の資料も参照してください。](#opscm-compliance-seealso)
## Chef Automate 2.0 の Compliance
AWS OpsWorks for Chef Automate サーバーが Chef Automate 2.0 を実行している場合は、このセクションの手順を使用して Chef Compliance を設定します。
### Chef Automate 2.0 を使用したコンプライアンススキャンジョブの実行
Chef Automate 2.0 には、以前は手動の設定とクックブックの設定が必要だった Chef InSpec コンプライアンススキャン機能が含まれています。Chef Automate 2.0 を実行している AWS OpsWorks for Chef Automate サーバーで*スキャンジョブ*を実行できます。ジョブは、すぐに (1 回) 実行するか、後で実行するようにスケジュールするか、指定した間隔 (毎日または 2 時間ごとなど) で実行するようにスケジュールすることができます。スキャンジョブの結果はコンプライアンスレポートに送信されます。Chef Automate ダッシュボードで、コンプライアンススキャンの結果を表示して対処できます。[**Compliance**] タブを開いてレポートを表示するには、Chef Automate ダッシュボードの [**Scan Jobs**] タブで、管理対象ノード行の右側にある [**Report**] を選択します。
管理対象ノードでスキャンジョブを実行するには、以下のものが必要です。
+ 名前空間にインストールされた 1 つ以上の Compliance プロファイル。
+ 手動で追加された 1 つの以上のターゲットノード、または[自動的に追加された](opscm-unattend-assoc.md) EC2 インスタンス。
では AWS OpsWorks for Chef Automate、スキャンジョブは次のターゲットでサポートされています。
+ 手動で追加されたノード
+ `aws-ec2` インスタンス
+ AWS リージョン
スキャンジョブの実行方法の詳細については、Chef のドキュメントの「[Chef Automate Scan Jobs](https://automate.chef.io/docs/scan-jobs/)」を参照してください。
### (オプション、Chef Automate 2.0) Audit クックブックによるコンプライアンスの設定
どの AWS OpsWorks for Chef Automate サーバーでもコンプライアンスを設定できます。 AWS OpsWorks for Chef Automate サーバーを起動した後、Chef Automate ダッシュボードからプロファイルをインストールしたり、`Policyfile.rb` ポリシーファイルで Audit クックブックの属性に目的のプロファイルを追加したりできます。スターターキットには、事前入力済みの `Policyfile.rb` ファイルが含まれています。
監査クックブックの属性として `Policyfile.rb` プロファイルを編集した後、`chef push` コマンドを実行して [[Audit cookbook]](https://supermarket.chef.io/cookbooks/audit) (監査クックブック) と `Policyfile.rb` で指定された他のクックブックを Chef Automate サーバーにアップロードします。Audit クックブックをインストールすると、Chef によって作成されたオープンソースのテストおよび監査フレームワークである [Chef InSpec](https://www.inspec.io/) の gem もインストールされます。Chef Automate [2.0](https://discourse.chef.io/t/automate-2-version-20190410001346-released/14930) の場合は、Audit クックブックのバージョン 7.1.0 以降を選択します。InSpec gem はバージョン 2.2.102 以降であることが必要です。
このセクションの手順は `opsworks-audit` クックブックを実装する方法を示しています。Audit クックブックは指定されたプロファイルを Chef Automate サーバーからダウンロードし、**DevSec SSH Baseline** プロファイルに対してノードを評価して、`chef-client` の実行ごとにコンプライアンススキャンの結果をレポートします。
**Compliance プロファイルをインストールするには**
1. まだ行っていない場合は [Chef Automate ウェブベースダッシュボードにサインインします](opscm-chef-dashboard.md)。 AWS OpsWorks for Chef Automate サーバーの作成時にスターターキットをダウンロードした際に受信した認証情報を使用します。
1. Chef Automate ダッシュボードで、[**Asset Store**] タブを選択します。
![\[Compliance プロファイル\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_profiles.png)
1. 定義済みのプロファイルを表示するには、[**Available**] タブを選択します。
1. プロファイルのリストを参照します。オペレーティングシステムおよび少なくとも 1 つの管理対象ノードの設定に一致するプロファイルを選択します。プロファイルの対象となる違反の説明および基盤となるルールコードを含むプロファイルの詳細を表示するには、プロファイル項目の右にある [**>**] を選択します。複数のプロファイルを選択できます。スターターキットのサンプルを設定する場合は、[**DevSec SSH Baseline**] を選択します。
![\[Chef Compliance プロファイルの詳細ビュー\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_rule.png)
1. 選択されたプロファイルを Chef Automate サーバーにインストールするには、[**Get**] を選択します。
1. プロファイルをインストールすると、それらは Chef Automate ダッシュボードの [**Profiles**] タブに表示されます。
**`Policyfile.rb` を使用してクックブックをインストールするには**
1. スターターキットの `Policyfile.rb` を表示して、Audit クックブックの属性で `['profiles']` の `ssh-baseline` プロファイルが指定されていることを確認します。
```
# Define audit cookbook attributes
default["opsworks-demo"]["audit"]["reporter"] = "chef-server-automate"
default["opsworks-demo"]["audit"]["profiles"] = [
{
"name": "DevSec SSH Baseline",
"compliance": "admin/ssh-baseline"
}
]
```
1. `Policyfile.rb` に定義されているクックブックをダウンロードしてインストールします。
```
chef install
```
すべてのクックブックはクックブックの `metadata.rb` ファイルでバージョニングされています。クックブックを変更するたびに `metadata.rb` にあるクックブックのバージョンを上げる必要があります。
1. `Policyfile.rb` に定義されているポリシー `opsworks-demo` をサーバーにプッシュします。
```
chef push opsworks-demo
```
1. ポリシーのインストールを確認します。以下のコマンドを実行してください。
```
chef show-policy
```
結果は以下のようになります。
```
opsworks-demo-webserver
=======================
* opsworks-demo: ec0fe46314
```
1. まだ行っていない場合は、サーバーにノードを追加して管理できるようにします。最初のノードを AWS OpsWorks for Chef Automate サーバーに接続するには、このスターターキットに含まれている`userdata.sh`スクリプトを使用します。`AssociateNode` API を使用して、ノードを OpsWorks サーバーに接続します。
「[でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md)」のステップに従ってノードの関連付けを自動化できます。または「[ノードを個別に追加します](opscm-addnodes-individually.md)」のステップに従ってノードを １ 度に 1 つずつ追加できます。
1. ノードの実行リストを更新すると、`chef-client` エージェントが次回の実行時に、指定したレシピを実行します。この処理はデフォルトで 1,800 秒 (30 分) ごとに行われます。その実行後、Chef Automate ダッシュボードの [**Compliance**] タブからコンプライアンス結果を表示し、アクションを実行できます。
![\[Chef Compliance のスキャン結果\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_scan.png)
### コンプライアンススキャンの実行
ノードの実行リストを設定した後、エージェントが初めて実行されるとすぐに、Chef Automate ダッシュボードにコンプライアンススキャンの結果が表示されます。
![\[Chef Compliance レポートページビュー\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_reporting.png)
Chef Automate ダッシュボードで、[**Compliance**] タブを選択します。左のナビゲーションペインの [**Reporting**] を選択します。[**Profiles**] タブを選択して [**Scan Results**] を選択した後、スキャンによって非準拠と見なされたノードを選択して、そのノードがどのルールに対して非準拠になったかを調べます。
![\[非準拠結果のリスト\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_results.png)
新しいノードは **DevSec SSH Baseline** プロファイルのルールすべてを満たさないため、通常はスキャンの非準拠結果が表示されます。[DevSec Hardening Framework](https://github.com/dev-sec) はコミュニティベースのプロジェクトで、**DevSec SSH Baseline** プロファイルのルールに違反する問題を修正するクックブックを提供します。
### (オプション) 非準拠結果の解決
スターターキットにはオープンソースのクックブック `ssh-hardening` が含まれています。このクックブックは、**DevSec SSH Baseline** プロファイルに対して実行したスキャンの非準拠結果を修正するために実行できます。
**注記**
`ssh-hardening` クックブックは **DevSec SSH Baseline** ルールに準拠するようにノードを変更します。本稼働ノードでこのクックブックを実行する前にクックブックがターゲットにするルール違反を理解するため、Chef Automate の **DevSec SSH Baseline** プロファイルの詳細を確認してください。本稼働ノードでこれを実行する前に、オープンソースの [https://github.com/dev-sec/chef-ssh-hardening](https://github.com/dev-sec/chef-ssh-hardening) クックブックに関する情報を確認します。
**`ssh-hardening` クックブックを実行するには**
1. テキストエディタで、`ssh-hardening` の実行リストに `Policyfile.rb` クックブックを追加します。実行リスト `Policyfile.rb` は以下のようになります。
```
run_list 'chef-client', 'opsworks-webserver', 'audit', 'ssh-hardening'
```
1. `Policyfile.rb` を更新し、 AWS OpsWorks for Chef Automate サーバーにプッシュします。
```
chef update Policyfile.rb
chef push opsworks-demo
```
1. `opsworks-demo` ポリシーに関連付けられているノードは実行リストを自動的に更新し、次の `chef-client` の実行時に `ssh-hardening` クックブックを適用します。
`chef-client` クックブックを使用しているため、ノードが定期的にチェックインします (デフォルトでは 30 分ごと)。次のチェックインで `ssh-hardening` クックブックが実行され、**DevSec SSH Baseline** プロファイルのルールを満たすようにノードセキュリティの改善をサポートします。
1. `ssh-hardening` クックブックの初回実行が完了したら 30 分待機し再びコンプライアンススキャンを実行します。Chef Automate ダッシュボードで結果を表示します。**DevSec SSH Baseline** スキャンの初回実行時に発生した非準拠の結果が解決されます。
## Chef Automate 1.*x* の Compliance
AWS OpsWorks for Chef Automate サーバーが Chef Automate 1.*x* を実行している場合は、このセクションの手順を使用して Chef Compliance を設定します。
### (オプション、Chef Automate 1.*x*) Chef Compliance の設定
Chef Compliance は任意の AWS OpsWorks for Chef Automate サーバーで設定できます。 AWS OpsWorks for Chef Automate サーバーを起動した後、Chef Automate ダッシュボードのプロファイルから実行するプロファイルを選択します。プロファイルをインストールした後、`berks` コマンドを実行して [Audit クックブック](https://supermarket.chef.io/cookbooks/audit)を Chef Automate サーバーにアップロードします。Audit クックブックをインストールすると、[InSpec](https://www.inspec.io/) のジェムもインストールされます。これは、Chef によって実行されるオープンソースのテストフレームワークであり、デプロイメントパイプラインの任意のステージに自動化されたテストを統合できます。Chef Automate 1.*x* の場合は、監査クックブックのバージョン 5.0.1 以降を選択します。InSpec gem はバージョン 1.24.0 以降であることが必要です。
AWS OpsWorks for Chef Automate スターターキットには、Chef の Audit クックブックの適切なバージョンをダウンロードしてインストール`opsworks-audit`するラッパークックブック が含まれています。`opsworks-audit` クックブックは `chef-client` エージェントが、この後のトピックで行う Chef Compliance コンソールからインストールする **DevSec SSH Baseline** プロファイルに対しノード評価を行うように指示します。独自の設定に適したように、いずれかのクックブックを使用してコンプライアンスをセットアップできます。このセクションの手順は `opsworks-audit` クックブックを実装する方法を示しています。
**Compliance プロファイルをインストールするには**
1. まだ行っていない場合は [Chef Automate ウェブベースダッシュボードにサインインします](opscm-chef-dashboard.md)。 AWS OpsWorks for Chef Automate サーバーの作成時に Starter Kit をダウンロードしたときに受け取った認証情報を使用します。
1. Chef Automate ダッシュボードで、[**Compliance**] タブを選択します。
![\[Chef Compliance プロファイル\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_profiles_ca1.png)
1. 左ナビゲーションバーで、[**Profile Store**] を選択してから [**Available**] タブを選択して、事前定義されたプロファイルを表示します。
1. プロファイルのリストを参照します。オペレーティングシステムおよび少なくとも 1 つの管理対象ノードの設定に一致するプロファイルを選択します。プロファイルの対象となる違反の説明および基盤となるルールコードを含むプロファイルの詳細を表示するには、プロファイル項目の右にある [**>**] を選択します。複数のプロファイルを選択できます。
![\[Chef Compliance プロファイルの詳細ビュー\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_rule_ca1.png)
1. 選択されたプロファイルを Chef Automate サーバーにインストールするには、[**Get**] を選択します。
1. ダウンロードが完了したら、次の手順に進んでください。
**`opsworks-audit` クックブックをインストールしてセットアップする**
1. このステップはオプションですが、ノードの実行リストにレシピを追加する場合のステップ 6 で時間の節約になります。 AWS OpsWorks for Chef Automate サーバーの作成時にダウンロードしたスターターキットに含まれている `roles/opsworks-example-role.rb` ファイルを編集します。次の行を追加します。コンプライアンススキャンを実行してから非準拠ノードを解決するために `ssh-hardening` クックブックとレシピを追加することはオプションなので、最後の行はコメントアウトされています。
```
run_list(
"recipe[chef-client]",
"recipe[apache2]",
"recipe[opsworks-audit]"
# "recipe[ssh-hardening]"
)
```
1. テキストエディタを使用して Berksfile で希望のクックブックを指定します。サンプル Berksfile はスターターキットに含まれています。この例では、Chef Infra クライアント ([`chef-client`) クックブック、`apache2`クックブック、`opsworks-audit` クックブックをインストールします。Berksfile は以下のようになります。
```
source 'https://supermarket.chef.io
cookbook 'chef-client'
cookbook 'apache2', '~> 5.0.1'
cookbook 'opsworks-audit', path: 'cookbooks/opsworks-audit', '~> 1.0.0'
```
すべてのクックブックはクックブックの `metadata.rb` ファイルでバージョニングされています。クックブックを変更するたびに `metadata.rb` にあるクックブックのバージョンを上げる必要があります。
1. 次のコマンドを実行してローカルまたは使用中のコンピュータにある `cookbooks` フォルダにクックブックをダウンロードしインストールします。
```
berks vendor cookbooks
```
1. 次のコマンドを実行して、 AWS OpsWorks for Chef Automate サーバーにベンダーのクックブックをアップロードします。
```
knife upload .
```
1. `opsworks-audit` クックブックがインストールされていることを確認するには、次のコマンドを実行してサーバーで現在使用可能なクックブックのリストを表示します。
```
knife cookbook list
```
1. まだ行っていない場合は、サーバーにノードを追加して管理できるようにします。「[でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md)」のステップに従ってノードの関連付けを自動化できます。または「[ノードを個別に追加します](opscm-addnodes-individually.md)」のステップに従ってノードを １ 度に 1 つずつ追加できます。ノードの実行リストを編集して、ステップ 1 の `opsworks-example-role` で指定したロールを追加します。この例では `RUN_LIST` の属性を `userdata` スクリプトで編集します。これはノードの関連性を自動化するために使用します。
```
RUN_LIST="role[opsworks-example-role]"
```
ステップ 1 をスキップしロールを設定しなかった場合は、実行リストに各レシピの名前を追加します。変更を保存して [ステップ 3: 自動関連付けスクリプトを使用してインスタンスを作成する](opscm-unattend-assoc.md#opscm-unattend-script) のステップに従がって、ユーザーデータスクリプトをAmazon EC2 インスタンスに適用します。
```
RUN_LIST="recipe[chef-client],recipe[apache2],recipe[opworks-audit]"
```
1. ノードの実行リストを更新すると、`chef-client` エージェントが次回の実行時に、指定したレシピを実行します。この処理はデフォルトで 1,800 秒 (30 分) ごとに行われます。実行後、Chef Automate ダッシュボードでコンプライアンス結果を見ることができます。
### コンプライアンススキャンの実行
ノードの実行リストを設定した後初めてエージェントデーモンが実行された後短時間で、Chef Automate ダッシュボードにコンプライアンススキャンの結果が表示されます。
![\[Chef Compliance レポートページビュー\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_reporting_ca1.png)
Chef Automate ダッシュボードで、[**Compliance**] タブを選択します。左のナビゲーションペインの [**Reporting**] を選択します。[**Profiles**] タブを選択して [**Scan Results**] を選択した後、スキャンによって非準拠と見なされたノードを選択して、そのノードがどのルールに対して非準拠になったかを調べます。
![\[Chef Compliance 失敗結果リスト\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/opscm_compliance_results_ca1.png)
新しいノードは **DevSec SSH Baseline** プロファイルのルールすべてを満たさないため、通常はスキャンの非準拠結果が表示されます。[DevSec Hardening Framework](https://github.com/dev-sec) はコミュニティベースのプロジェクトで、**DevSec SSH Baseline** プロファイルのルールに違反する問題を修正するクックブックを提供します。
### (オプション) 非準拠結果の解決
スターターキットにはオープンソースのクックブック `ssh-hardening` が含まれています。このクックブックは、**DevSec SSH Baseline** プロファイルに対して実行したスキャンの非準拠結果を修正するために実行できます。
**注記**
`ssh-hardening` クックブックは **DevSec SSH Baseline** ルールに準拠するようにノードを変更します。本稼働ノードでこのクックブックを実行する前にクックブックがターゲットにするルール違反を理解するため、Chef Automate の **DevSec SSH Baseline** プロファイルの詳細を確認してください。本稼働ノードでこれを実行する前に、オープンソースの [https://github.com/dev-sec/chef-ssh-hardening](https://github.com/dev-sec/chef-ssh-hardening) クックブックに関する情報を確認します。
**`ssh-hardening` クックブックを実行するには**
1. テキストエディタで、`ssh-hardening` クックブックを Berksfile に追加します。Berksfile は以下のようになります。
```
source 'https://supermarket.chef.io'
cookbook 'chef-client'
cookbook 'apache2', '~> 5.0.1'
cookbook 'opsworks-audit', path: 'cookbooks/opsworks-audit', '~> 1.0.0' # optional
cookbook 'ssh-hardening'
```
1. 次のコマンドを実行して `ssh-hardening` クックブックをローカルのクックブックフォルダにダウンロードし、 AWS OpsWorks for Chef Automate サーバーにアップロードします。
```
berks vendor cookbooks
knife upload .
```
1. ノードの実行リストに `ssh-hardening` レシピを追加します。この操作はステップ 1 とステップ 6 ([`opsworks-audit` クックブックをインストールしてセットアップする](#opscm-compliance-setup-cookbook)) で説明されています。
`opsworks-example-role.rb` ファイルを更新するには、次のコマンドを実行してサーバーに変更をアップロードします。
```
knife upload .
```
実行リストを直接更新するには、次のコマンドを実行して変更をアップロードします。通常、ノード名はインスタンス ID になります。
```
knife node run_list add 'recipe[ssh-hardening]'
```
1. `chef-client` クックブックを使用しているため、ノードが定期的にチェックインします (デフォルトでは 30 分ごと)。次のチェックインで `ssh-hardening` クックブックが実行され、**DevSec SSH Baseline** プロファイルのルールを満たすようにノードセキュリティの改善をサポートします。
1. `ssh-hardening` クックブックの初回実行が完了したら 30 分待機し再びコンプライアンススキャンを実行します。Chef Automate ダッシュボードで結果を表示します。**DevSec SSH Baseline** スキャンの初回実行時に発生した非準拠の結果が解決されます。
## Compliance の更新
AWS OpsWorks for Chef Automate サーバーでは、スケジュールされた[システムメンテナンス](opscm-maintenance.md)によってコンプライアンス機能が自動的に更新されます。Chef Automate、Chef Infra Server、Chef InSpec の最新リリースが AWS OpsWorks for Chef Automate サーバーで使用可能になると、サーバーで実行されている Audit クックブックおよび Chef InSpec gem のサポートされているバージョンを確認および更新する必要があります。 AWS OpsWorks for Chef Automate サーバーにインストール済みのプロファイルは、メンテナンスの一環として更新されません。
## コミュニティとカスタム Compliance プロファイル
Chef には現在 100 種類を超えるコンプライアンススキャンプロファイルが含まれています。コミュニティとカスタムプロファイルをリストに追加して、含まれているプロファイルと同様にそれらのプロファイルに基づいてコンプライアンススキャンをダウンロードして実行できます。コミュニティベースの Compliance プロファイルは [Chef Supermarket](https://supermarket.chef.io/tools?q=&type=compliance_profile) から入手できます。カスタムプロファイルは Ruby ベースのプログラムであり、スキャンルールを指定するコントロールのフォルダが含まれています。
## 以下の資料も参照してください。
+ [Chef Compliance 発表ブログ投稿](https://blog.chef.io/2017/07/05/chef-automate-release-july-2017/)
+ [Chef Automate Compliance オンライントレーニング](https://training.chef.io/instructor-led-training/chef-automate-compliance)
+ [Chef InSpec](https://www.inspec.io/) のウェブサイト
+ [Chef InSpec チュートリアル](https://www.inspec.io/tutorials/)
# 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 サポート チームにお問い合わせください。
このセクションでは、 AWS OpsWorks for Chef Automate サーバーによる管理からマネージドノードの関連付けを解除または削除する方法について説明します。このオペレーションはコマンドラインで実行されます。 AWS OpsWorks for Chef Automate マネジメントコンソールでノードの関連付けを解除することはできません。現在、 AWS OpsWorks for Chef Automate API では複数のノードをバッチ削除することはできません。このセクションのコマンドでは、一度に 1 つのノードの関連付けを切り離します。
Chef サーバーを削除する場合は、ノードがサーバーへの再接続を試行することなく動作を続行できるように、サーバーとノードとの関連付けを解除することをお勧めします。これを行うには、 [https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html) AWS CLI コマンドを実行します。
**ノードの関連付けを解除するには**
1. で AWS CLI、次のコマンドを実行してノードの関連付けを解除します。*[Node\$1name]* (ノードネーム) は関連付けを解除するノードの名前です。Amazon EC2インスタンスの場合、これはインスタンス ID になります。*Server\$1name* は、ノードとの関連付けを解除する Chef サーバーの名前です。`--engine-attributes` にはデフォルトの `CHEF_AUTOMATE_ORGANIZATION` 名を指定します。これら 3 つのパラメータはすべて必須です。
デフォルトのリージョンにない Chef サーバーからノードの関連付けを解除しない限り、`--region` パラメータは必須ではありません。
```
aws opsworks-cm --region Region_name disassociate-node --node-name Node_name --server-name Server_name --engine-attributes "Name=CHEF_AUTOMATE_ORGANIZATION,Value='default'"
```
コマンドの例を次に示します。
```
aws opsworks-cm --region us-west-2 disassociate-node --node-name i-0010zzz00d66zzz90 --server-name opsworkstest --engine-attributes "Name=CHEF_AUTOMATE_ORGANIZATION,Value='default'"
```
1. 関連付けの解除が完了したことを示す応答メッセージが表示されるまで待ちます。
AWS OpsWorks for Chef Automate サーバーからノードの関連付けを正常に解除しても、Chef Automate ダッシュボードに表示されることがあります。Chef はデフォルトでノード状態情報の保持期間を適用し、数日後にはノードを自動消去します。
AWS OpsWorks for Chef Automate サーバーを削除する方法の詳細については、「」を参照してください[AWS OpsWorks for Chef Automate サーバーを削除する](opscm-delete-server.md)。
## 関連トピック
次の AWS ブログ記事では、Auto Scaling グループを使用するか、複数のアカウント内で、Chef Automate サーバーにノードを自動的に関連付ける方法について詳しく説明します。
+ [Using AWS OpsWorks for Chef Automate to Manage EC2 Instances with Auto Scaling](https://aws.amazon.com/blogs/mt/using-aws-opsworks-for-chef-automate-to-manage-ec2-instances-with-auto-scaling/)
+ [OpsWorks for Chef Automate – Automatically Bootstrapping Nodes in Different Accounts](https://aws.amazon.com/blogs/mt/opsworks-for-chef-automate-automatically-bootstrapping-nodes-in-different-accounts/)
# 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 サポート チームにお問い合わせください。
このセクションでは、 AWS OpsWorks for Chef Automate サーバーを削除する方法について説明します。サーバーを削除すると、サーバーに保存されていたイベント、ログ、およびクックブックも削除されます。サポートするリソース (Amazon Elastic Compute Cloud インスタンス、Amazon Elastic Block Store ボリュームなど) やすべての自動バックアップも削除されます。
サーバーを削除してもノードは削除されませんが、これらは削除されたサーバーによって管理されなくなり、継続的に再接続が試行されます。このため、Chef サーバーを削除する場合は、管理されているノードの関連付けを事前に解除することをお勧めします。このリリースでは、 AWS CLI コマンドを実行してノードの関連付けを解除できます。
## ステップ 1: 管理されているノードの関連付けを解除する
Chef サーバーを削除する場合は、ノードがサーバーへの再接続を試行することなく動作を続行できるように、サーバーとノードとの関連付けを解除します。これを行うには、 [https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DisassociateNode.html) AWS CLI コマンドを実行します。
**ノードの関連付けを解除するには**
1. で AWS CLI、次のコマンドを実行してノードの関連付けを解除します。*Server\$1name* は、ノードが関連付けられている Chef サーバーの名前です。
```
aws opsworks-cm --region Region_name disassociate-node --node-name Node_name --server-name Server_name
```
1. 関連付けの解除が完了したことを示す応答メッセージが表示されるまで待ちます。
## ステップ 2: サーバーを削除する
1. ダッシュボードのサーバータイルで、**[Actions]** メニューを展開します。
1. [**Delete server**] を選択します。
1. 削除の確認を求められたら、**[Yes]** を選択します。
# 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 Automate ダッシュボードへのサインインに使用するパスワードを定期的に変更したい場合があります。このセクションに示す Amazon EC2 Systems Manager AWS CLI コマンドを使用して、Chef Automate ダッシュボードのパスワードを紛失した場合に変更することもできます。使用するコマンドは、Chef Automate サーバーが Chef Automate のバージョン 1 とバージョン 2 のどちらを実行しているかによって異なります。
1. Chef サーバーのインスタンス ID を返すには、 を開いて次のページ AWS マネジメントコンソール に移動します。
https://console.aws.amazon.com/ec2/v2/home?region=*サーバーのリージョン*\$1Instances:search=aws-opsworks-cm-*サーバー名*
例えば、米国西部 (オレゴン) リージョン にある **[MyChefServer]** (マイ Chef サーバー) という名前の Chef サーバーの場合、コンソール URL は次のようになります。
https://console.aws.amazon.com/ec2/v2/home?region=us-west-2\$1Instances:search=aws-opsworks-cm-MyChefServer
コンソールに表示されるインスタンス ID を書き留めておきます。パスワードを変更する際にこの値が必要になります。
1. Chef Automate ダッシュボードのサインインパスワードをリセットするには、サーバーが Chef Automate 1 を実行しているか、Chef Automate 2 を実行しているかに応じて、次の AWS CLI コマンドのいずれかを実行します。*[enterprise\$1name]* を自分のエンタープライズ名または組織名に、*[user\$1name]* をサーバーの管理者の IAM ユーザー名に、*[new\$1password]* を使用するパスワードに、*[region\$1name]* をサーバーが配置されているリージョンに、それぞれ置き換えます。エンタープライズの名前を指定していない場合、エンタープライズ名は `default` になります。デフォルトでは、*enterprise\$1name* は、`default` (常にプロビジョニングされる組織の名前) です。*user\$1name* の場合、 は という名前のユーザー AWS OpsWorks for Chef Automate のみを作成します`admin`。新しいパスワードを書き留めて、安全かつ便利な場所に保存します。
Chef Automate 1 の場合:
```
aws ssm send-command --document-name "AWS-RunShellScript" --comment "reset admin password" --instance-ids "instance_id"
--parameters commands="sudo delivery-ctl reset-password enterprise_name user_name new_password" --region region_name --output text
```
Chef Automate 2 の場合:
```
aws ssm send-command --document-name "AWS-RunShellScript" --comment "reset admin password" --instance-ids "instance_id"
--parameters commands="sudo chef-automate iam admin-access restore new_password" --region region_name --output text
```
1. パスワード変更が完了したことを示す出力テキスト (この場合はコマンド ID) が表示されるのを待ちます。
# を使用した AWS OpsWorks for Chef Automate API コールのログ記録 AWS CloudTrail
**重要**
AWS OpsWorks for Chef Automate は 2024 年 5 月 5 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。既存のお客様は、 Chef SaaS または代替ソリューションに移行することをお勧めします。ご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
AWS OpsWorks for Chef Automate は AWS CloudTrail、IAM ID または のサービスによって実行されたアクションを記録する AWS サービスである と統合されています AWS OpsWorks for Chef Automate。CloudTrail は、 AWS OpsWorks for Chef Automate コンソールからの呼び出しや API へのコード呼び出しを含む、 のすべての API コールをイベント AWS OpsWorks for Chef Automate としてキャプチャします。 AWS OpsWorks for Chef Automate APIs 証跡を作成する場合は、イベントを含む Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます AWS OpsWorks for Chef Automate。証跡を設定しない場合でも、CloudTrail コンソールの **[イベント履歴]** で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、リクエストの実行元の IP アドレス AWS OpsWorks for Chef Automate、リクエストの実行者、リクエストの実行日時などの詳細を確認できます。
CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。
## AWS OpsWorks for Chef Automate CloudTrail の情報
CloudTrail は、 AWS アカウントの作成時にアカウントで有効になります。でアクティビティが発生すると AWS OpsWorks for Chef Automate、そのアクティビティはイベント**履歴**の他の AWS サービスイベントとともに CloudTrail イベントに記録されます。 AWS アカウントで最近のイベントを表示、検索、ダウンロードできます。詳細については、[CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)を参照してください。
のイベントなど、 AWS アカウントのイベントの継続的な記録については AWS OpsWorks for Chef Automate、証跡を作成します。証跡により、ログファイルを CloudTrail で Amazon S3 バケットに配信できます。デフォルトでは、コンソールで追跡を作成するときに、追跡がすべてのリージョンに適用されます。証跡は、 AWS パーティション内のすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集されたイベントデータをさらに分析して処理するように他の AWS サービスを設定できます。詳細については、以下を参照してください。
+ [証跡を作成するための概要](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートするサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [CloudTrail 用 Amazon SNS 通知の構成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [複数のリージョンから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)および[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
すべての AWS OpsWorks for Chef Automate アクションは CloudTrail によってログに記録され、 [AWS OpsWorks for Chef Automate API リファレンス](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/Welcome.html)に記載されています。例えば、[https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateServer.html) (サーバーの作成)]、[https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateBackup.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_CreateBackup.html) (バックアップの作成)、および [https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DescribeServers.html](https://docs.aws.amazon.com/opsworks-cm/latest/APIReference/API_DescribeServers.html) (サーバーの説明) アクションの呼び出しにより、CloudTrail ログファイルにエントリが生成されます。
各イベントまたはログエントリには、誰がリクエストを生成したかという情報が含まれます。同一性情報は次の判断に役立ちます。
+ リクエストが、ルートと IAM ユーザー認証情報のどちらを使用して送信されたか。
+ リクエストがロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが別の AWS サービスによって行われたかどうか。
詳細については、「[CloudTrail userIdentity 要素](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## AWS OpsWorks for Chef Automate ログファイルエントリについて
「トレイル」は、指定した Amazon S3 バケットにイベントをログファイルとして配信するように設定できます。CloudTrail のログファイルは、単一か複数のログエントリを含みます。イベントはあらゆるソースからの単一のリクエストを表し、リクエストされたアクション、アクションの日時、リクエストのパラメータなどの情報が含まれます。CloudTrail ログファイルは、公開 API コールの順序付けられたスタックトレースではないため、特定の順序では表示されません。
次の例は、 AWS OpsWorks for Chef Automate `CreateServer` アクションの CloudTrail ログエントリを示しています。
```
{"eventVersion":"1.05",
"userIdentity":{
"type":"AssumedRole",
"principalId":"ID number:OpsWorksCMUser",
"arn":"arn:aws:sts::831000000000:assumed-role/Admin/OpsWorksCMUser",
"accountId":"831000000000","accessKeyId":"ID number",
"sessionContext":{
"attributes":{
"mfaAuthenticated":"false",
"creationDate":"2017-01-05T22:03:47Z"
},
"sessionIssuer":{
"type":"Role",
"principalId":"ID number",
"arn":"arn:aws:iam::831000000000:role/Admin",
"accountId":"831000000000",
"userName":"Admin"
}
}
},
"eventTime":"2017-01-05T22:18:23Z",
"eventSource":"opsworks-cm.amazonaws.com",
"eventName":"CreateServer",
"awsRegion":"us-west-2",
"sourceIPAddress":"101.25.190.51",
"userAgent":"console.amazonaws.com",
"requestParameters":{
"serverName":"OpsChef-test-server",
"engineModel":"Single",
"engine":"Chef",
"instanceProfileArn":"arn:aws:iam::831000000000:instance-profile/aws-opsworks-cm-ec2-role",
"backupRetentionCount":3,"serviceRoleArn":"arn:aws:iam::831000000000:role/service-role/aws-opsworks-cm-service-role",
"engineVersion":"12",
"preferredMaintenanceWindow":"Fri:21:00",
"instanceType":"t2.medium",
"subnetIds":["subnet-1e111f11"],
"preferredBackupWindow":"Wed:08:00"
},
"responseElements":{
"server":{
"endpoint":"OpsChef-test-server-thohsgreckcnwgz3.us-west-2.opsworks-cm.io",
"createdAt":"Jan 5, 2017 10:18:22 PM",
"serviceRoleArn":"arn:aws:iam::831000000000:role/service-role/aws-opsworks-cm-service-role",
"preferredBackupWindow":"Wed:08:00",
"status":"CREATING",
"subnetIds":["subnet-1e111f11"],
"engine":"Chef",
"instanceType":"t2.medium",
"serverName":"OpsChef-test-server",
"serverArn":"arn:aws:opsworks-cm:us-west-2:831000000000:server/OpsChef-test-server/8epp7f6z-e91f-4z10-89z5-8c6219cdb09f",
"engineModel":"Single",
"backupRetentionCount":3,
"engineAttributes":[
{"name":"CHEF_STARTER_KIT","value":"*** Redacted ***"},
{"name":"CHEF_PIVOTAL_KEY","value":"*** Redacted ***"},
{"name":"CHEF_DELIVERY_ADMIN_PASSWORD","value":"*** Redacted ***"}],
"engineVersion":"12.11.1",
"instanceProfileArn":"arn:aws:iam::831000000000:instance-profile/aws-opsworks-cm-ec2-role",
"preferredMaintenanceWindow":"Fri:21:00"
}
},
"requestID":"de7f64f9-d394-12ug-8081-7bb0386fbcb6",
"eventID":"8r7b18df-6c90-47be-87cf-e8346428cfc3",
"eventType":"AwsApiCall",
"recipientAccountId":"831000000000"
}
```
# トラブルシューティング 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 サポート チームにお問い合わせください。
このトピックには、いくつかの一般的な AWS OpsWorks for Chef Automate 問題と、それらの問題に対する推奨される解決策が含まれています。
**Topics**
+ [一般的なトラブルシューティングのヒント](#w2ab1b9c52b9)
+ [特定のエラーのトラブルシューティング](#tshooterrors-chef)
+ [その他のヘルプとサポート](#tshooterrors-chef-support)
## 一般的なトラブルシューティングのヒント
Chef サーバーを作成または操作できない場合は、エラーメッセージやログを表示すると、問題のトラブルシューティングに役立ちます。以下のタスクでは、Chef サーバーに関する問題のトラブルシューティングを行うときの一般的な開始点を示します。特定のエラーと解決方法については、このトピックの「[特定のエラーのトラブルシューティング](#tshooterrors-chef)」セクションを参照してください。
+ Chef サーバーの起動に失敗した場合のエラーメッセージを表示するには、 AWS OpsWorks for Chef Automate コンソールを使用します。Chef サーバーの詳細ページで、サーバーの起動と実行に関連するエラーメッセージが、ページの一番上に表示されます。エラーは AWS OpsWorks for Chef Automate、Chef サーバーの作成に使用されるサービス CloudFormation、または Amazon EC2 から発生する可能性があります。詳細ページでは、実行中のサーバーで発生するイベントを表示することもできます。これには、障害イベントメッセージが含まれる場合があります。
+ EC2 に関する問題を解決するため、SSH を使用してサーバーのインスタンスに接続してログを表示します。EC2 インスタンスのログは `/var/log/aws/opsworks-cm` ディレクトリに保存されています。これらのログは、 が Chef サーバー AWS OpsWorks for Chef Automate を起動している間のコマンド出力をキャプチャします。
## 特定のエラーのトラブルシューティング
**Topics**
+ [サーバーの状態は **[接続が失われました]**](#tshooterrors-chef-connection-lost)
+ [フルマネージドログ管理ノードが、欠落している列の Chef Automate ダッシュボードに表示される](#w2ab1b9c52c11b6)
+ [Chef ボールトを作成できず、`knife vault` コマンドがエラーで失敗する](#w2ab1b9c52c11b8)
+ [サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する](#w2ab1b9c52c11c10)
+ [Chef サーバーが、Chef Automate ダッシュボードで追加された組織名を認識できない](#w2ab1b9c52c11c12)
+ [サーバーの Amazon EC2 インスタンスを作成できない](#w2ab1b9c52c11c14)
+ [サービスロールのエラーによりサーバーを作成できない](#w2ab1b9c52c11c16)
+ [Elastic IP アドレスの制限を超えた](#w2ab1b9c52c11c18)
+ [Chef Automate ダッシュボードにサインインできない](#w2ab1b9c52c11c20)
+ [ノードの自動関連付けに失敗する](#w2ab1b9c52c11c22)
+ [システムメンテナンスの失敗](#tshooterrors-chef-maintenance-fails)
### サーバーの状態は **[接続が失われました]**
**問題:** サーバーのステータスに**[接続が失われました]**と表示される。
**原因:** これは、 の外部のエンティティが AWS OpsWorks for Chef Automate サーバーまたはそのサポートリソースに変更 OpsWorks を加えた場合に最もよく発生します。 OpsWorks は、バックアップの作成、オペレーティングシステムパッチの適用、Chef Automate の更新などのメンテナンスタスクを処理するために**、接続が失われた**状態で Chef Automate サーバーに接続できません。その結果、サーバーが重要なアップデートを見逃したり、セキュリティ上の問題の影響を受けやすくなったり、またはその他の理由で期待どおりに動作しない可能性があります。
**解決策:** 次の手順を試して、サーバーの接続を復元してください。
1. サービスロールに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。
1. 「**アクセス許可**」のタブで、`AWSOpsWorksCMServiceRole` が「**アクセス許可ポリシー**」リストに含まれていることを確認します。リストにない場合は、`AWSOpsWorksCMServiceRole` 管理ポリシーをロールに手動で追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `opsworks-cm.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. インスタンスプロファイルに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。
1. 「**権限**」のタブで、`AmazonEC2RoleforSSM` と `AWSOpsWorksCMInstanceProfileRole` が両方とも「**アクセス権限ポリシー**」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `ec2.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. Amazon EC2 コンソールで、 AWS OpsWorks for Chef Automate サーバーのリージョンと同じリージョンにいることを確認し、サーバーが使用している EC2 インスタンスを再起動します。
1. `aws-opsworks-cm-instance-`*server-name* という名前の EC2 インスタンスを選択します。
1. [**インスタンスの状態**]メニューで、[**インスタンスの再起動**] を選択します。
1. サーバーが再起動して完全にオンラインになるまで最大 15 分かかります。
1. AWS OpsWorks for Chef Automate コンソールのサーバーの詳細ページで、サーバーのステータスが**正常**であることを確認します。
上記の手順を実行してもサーバーステータスが **[接続が失われました]** のままの場合は、次のいずれかを試してください。
+ [新しいサーバーを作成し](gettingstarted-opscm-create.md)、[元のサーバーを削除して](opscm-delete-server.md)、サーバーを交換してください。現在のサーバー上のデータが重要な場合は、[最新のバックアップからサーバーを復元し](opscm-chef-restore.md)、[元の応答しないサーバーを削除する前に](opscm-delete-server.md) データが最新であることを確認してください。
+ [AWS Support](#tshooterrors-chef-support)にお問い合わせください。
### フルマネージドログ管理ノードが、欠落している列の Chef Automate ダッシュボードに表示される
**問題:** フルマネージドログ管理ノードが、Chef Automate ダッシュボードの**欠落している**列に表示される。
**原因:** ノードが、12 時間以上 Chef Automate サーバーに接続されず、`chef-client`かつノードで実行できない場合、ノードは、12 時間前の状態から変わり、Chef Automate ダッシュボードの**欠落している**列に移動します。
**解決策:** ノードがオンラインになっていることを確認してください。`knife node show node_name --run-list` を実行してノードで `chef-client` を実行できるか、または `knife node show -l node_name` がノードに関するすべての情報を表示するかを確認します。ノードがオフライン、あるいはネットワーク接続が切断している可能性があります。
### Chef ボールトを作成できず、`knife vault` コマンドがエラーで失敗する
**問題:** `knife vault` コマンドを実行して、Chef Automate サーバーでボールトを作成しようとしている (ドメイン結合 Windows ベースのノードの認証情報を保存するボールトなど)。このコマンドは、次のようなエラーメッセージを返す。
```
WARN: Auto inflation of JSON data is deprecated. Please pass in the class to inflate or use #edit_hash (CHEF-1)
at /opt/chefdk/embedded/lib/ruby/2.3.0/forwardable.rb:189:in `edit_data'.Please see https://docs.chef.io/deprecations_json_auto_inflate.html
for further details and information on how to correct this problem.
WARNING: pivotal not found in users, trying clients.
ERROR: ChefVault::Exceptions::AdminNotFound: FATAL: Could not find pivotal in users or clients!
```
`knife user list` をリモートに実行すると主要ユーザーは返されないが、Chef Automate サーバーで `chef-server-ctl user-show` コマンドをローカルに実行すると、結果で主要ユーザーが表示される。つまり、`knife vault` コマンドでは主要ユーザーを見つけることはできないが、ユーザーが存在していることは確認できる。
**原因:** 主要ユーザーは、Chef ではスーパーユーザーと見なされており、完全な権限を持っていますが、 AWS OpsWorks for Chef Automateで使用されている `default` 組織を含めて、いずれの組織のメンバーでもありません。コマンド `knife user list` は、Chef 設定の現在の組織に属するすべてのユーザーを返します。コマンド `chef-server-ctl user-show` は、主要ユーザーを含めて、組織にかかわらずすべてのユーザーを返します。
**解決策:** この問題を解決するには、`knife opc` を実行して、デフォルトの組織に主要ユーザーを追加します。
最初に、[knife-opc](https://github.com/chef/knife-opc) プラグインをインストールする必要があります。
```
chef gem install knife-opc
```
このプラグインをインストールしたら、次のコマンドを実行して主要ユーザーをデフォルトの組織に追加します。
```
knife opc org user add default pivotal
```
もう一度 `knife user list` を実行して、主要ユーザーがデフォルトの組織に属していることを確認できます。結果には `pivotal` が表示されている必要があります。次に、もう一度 `knife vault` を実行してみます。
### サーバーの作成が「リクエストされた設定は現在サポートされていません」というメッセージで失敗する
**問題:** Chef Automate サーバーの作成を試みているが、「リクエストされた設定は現在サポートされていません。サポートされている設定についてドキュメントをご確認ください」のようなエラーメッセージでサーバーの作成が失敗する。
**原因:** Chef Automate サーバーに対してサポートされていないインスタンスタイプが指定された可能性があります。[ハードウェア専有インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html)用など、デフォルトでないテナンシーを持つ VPC で Chef Automate サーバーの作成を選択した場合、指定された VPC 内のすべてのインスタンスも、専有テナンシーまたはホストテナンシーのインスタンスである必要があります。t2 など一部のインスタンスタイプはデフォルトテナンシーでしか使用できないため、Chef Automate サーバーインスタンスタイプは指定された VPC でサポート可能でない場合があり、そのためにサーバーの作成が失敗します。
**解決策:** デフォルト以外のテナンシーを持つ VPC を選択した場合は、専用テナンシーをサポートできる m4 インスタンスタイプを使用します。
### Chef サーバーが、Chef Automate ダッシュボードで追加された組織名を認識できない
**問題:** Chef Automate ダッシュボードで新しいワークフロー組織名を追加したり、[無人ノード関連付けスクリプト](opscm-unattend-assoc.md)で `"default"` 以外の `CHEF_AUTOMATE_ORGANIZATION` 値を指定したりしましたが、ノード関連付けに失敗します。 AWS OpsWorks for Chef Automate サーバーが新しい組織名を認識しない。
**原因:** Workflow 組織名および Chef サーバー組織名が同じではありません。ウェブベースの Chef Automate ダッシュボードで新しい Workflow 組織を作成できますが、Chef サーバー組織名は作成できません。Chef Automate ダッシュボードのみを使用して、既存の Chef サーバー組織を表示できます。Chef Automate ダッシュボードで作成する新しい組織は Workflow 組織であり、Chef サーバーによって認識されません。ノードの関連付けスクリプトでそれらを指定して、新しい組織名を作成することはできません。組織が最初に Chef サーバーに追加されていないときにノードの関連付けスクリプトで組織名を参照すると、ノードの関連付けに失敗します。
**解決策:** Chef Server で認識される新しい組織を作成するには、[https://docs.chef.io/plugin_knife_opc.html#opc-org-create](https://docs.chef.io/plugin_knife_opc.html#opc-org-create) コマンドを使用するか、[https://docs.chef.io/ctl_chef_server.html#organization-management](https://docs.chef.io/ctl_chef_server.html#organization-management) を実行します。
### サーバーの Amazon EC2 インスタンスを作成できない
**問題:** サーバーの作成が、次のようなエラーメッセージにより失敗する。「The following resource(s) failed to create: [EC2Instance]。Failed to receive 1 resource signal(s) within the specified duration」
**原因:** この問題のほとんどが、EC2 インスタンスでネットワークアクセスが可能でないことが原因です。
**解決策:** インスタンスにアウトバウンドインターネットアクセスがあり、 AWS サービスエージェントがコマンドを発行できることを確認します。VPC (単一のパブリックサブネットを持つ VPC) で **DNS 解決** が有効になっていて、サブネットで **[パブリック IP の自動割り当て] **設定が有効になっていることを確認します。
### サービスロールのエラーによりサーバーを作成できない
**問題:**「Not authorized to perform sts:AssumeRole.」という状態を示すエラーメッセージが表示され、サーバーを作成できない。
**原因:** お使いのサービスロールに新しいサーバーを作成するための適切なアクセス権限がない場合に、この問題が発生する可能性があります。
**解決策:** AWS OpsWorks for Chef Automate コンソールを開きます。コンソールを使用して、新しいサービスロールとインスタンスプロファイルロールを生成します。独自のサービスロールの使用を希望する場合は、**AWSOpsWorksCMServiceRole** ポリシーをロールにアタッチします。**opsworks-cm.amazonaws.com** がロールの **信頼関係** のサービス間でリストされていることを確認します。Chef サーバーに関連付けられているサービスロールに、**AWSOpsWorksCMServerRole** 管理ポリシーがアタッチされていることを確認します。
### Elastic IP アドレスの制限を超えた
**問題:**「The following resource(s) failed to create: [EIP, EC2Instance]。Resource creation cancelled, the maximum number of addresses has been reached.」という状態を示すエラーメッセージにより、サーバーを作成できない。
**原因:** アカウントで Elastic IP (EIP) アドレスの最大数を使用した場合に、この問題が発生します。EIP アドレスのデフォルトの制限は 5 です。
**解決策:** 既存の EIP アドレスを解放するか、アカウントがアクティブに使用していない EIP アドレスを削除するか、 AWS カスタマーサポートに連絡して、アカウントに関連付けられている EIP アドレスの制限を引き上げることができます。
### Chef Automate ダッシュボードにサインインできない
**問題:** Chef Automate ダッシュボードに、「Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://myserver-name.region.opsworks-cm.io/api/v0/e/default/verify-token。(Reason: CORS header 'Access-Control-Allow-Origin' missing)」のようなエラーが表示される。「The User Id / Password combination entered is incorrect.」のようなエラーの場合もある。
**原因:** Chef Automate ダッシュボードが明示的に FQDN を設定していて、相対 URL を受け付けていません。現時点では、Chef サーバーの IP アドレスを使用してサインインすることはできません。サーバーの DNS 名を使用してサインインできるのみです。
**解決策:** Chef サーバーの IP アドレスではなく、DNS 名エントリのみを使用して Chef Automate ダッシュボードにサインインします。また、[Chef Automate ダッシュボードの認証情報のリセット](opscm-resetchefcreds.md) で説明したように、 AWS CLI コマンドを実行して Chef Automate ダッシュボードの認証情報をリセットしてみることもできます。
### ノードの自動関連付けに失敗する
**問題:** 新しい Amazon EC2 ノードの自動 (無人) 関連付けに失敗する。Chef サーバーに追加されたはずのノードが Chef Automate ダッシュボードに表示されず、`knife client show` または `knife node show` コマンドの結果に含まれない。
**原因:** `opsworks-cm` API コールで新しい EC2 インスタンスとの通信を許可するインスタンスプロファイルとして IAM ロールをセットアップしていない場合に、この問題が発生する可能性があります。
**解決策:** [でノードを自動的に追加する AWS OpsWorks for Chef Automate](opscm-unattend-assoc.md) で説明したように、EC2 インスタンスのプロファイルにポリシーをアタッチして、`AssociateNode` と `DescribeNodeAssociationStatus` の API コールを EC2 と連携できるようにします。
### システムメンテナンスの失敗
AWS OpsWorks CM は毎週システムメンテナンスを実行し、セキュリティ更新プログラムを含む最新のマイナーバージョンの Chef Server と Chef Automate Server が常に AWS OpsWorks for Chef Automate サーバーで実行されていることを確認します。何らかの理由でシステムメンテナンスが失敗した場合、 は失敗 AWS OpsWorks CM を通知します。システムメンテナンスの詳細については、「[でのシステムメンテナンス AWS OpsWorks for Chef Automate](opscm-maintenance.md)」を参照してください。
このセクションでは、考えられる障害の原因を説明し、解決策を提案します。
**Topics**
+ [サービスロールまたはインスタンスプロファイルのエラーによって、システムのメンテナンスが妨げられる](#w2ab1b9c52c11c24b8)
#### サービスロールまたはインスタンスプロファイルのエラーによって、システムのメンテナンスが妨げられる
**問題:** システムメンテナンスが失敗し、「STS: AssumeRole を実行する権限がありません」というエラーメッセージ、または権限に関する同様のエラーメッセージが表示されます。
**原因:** これは、使用しているサービスロールまたはインスタンスプロファイルのいずれかに、サーバー上でシステムメンテナンスを実行するための適切な権限がない場合に発生する可能性があります。
**解決策:** サービスロールとインスタンスプロファイルに必要なすべての権限があることを確認してください。
1. サービスロールに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているサービスロールへのリンクを選択します。これにより、 IAM コンソールに表示されるサービスロールが開きます。
1. 「**アクセス許可**」のタブで、`AWSOpsWorksCMServiceRole` がサービスロールにアタッチされていることを確認します。`AWSOpsWorksCMServiceRole` がリストにない場合は、このポリシーをロールに追加します。
1. **opsworks-cm.amazonaws.com** がロールの **信頼関係** のサービス間でリストされていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
1. インスタンスプロファイルに必要な権限がすべてあることを確認してください。
1. サーバーの「**設定**」ページの「**ネットワークとセキュリティ**」で、サーバーが使用しているインスタンスプロファイルへのリンクを選択します。これにより、 IAM コンソールに表示されるインスタンスプロファイルが開きます。
1. 「**権限**」のタブで、`AmazonEC2RoleforSSM` と `AWSOpsWorksCMInstanceProfileRole` が両方とも「**アクセス権限ポリシー**」リストに含まれていることを確認します。一方または両方がリストにない場合は、これらの管理ポリシーを手動でロールに追加してください。
1. 「**信頼関係**」のタブで、ユーザーに代わって役割を引き受ける `ec2.amazonaws.com` サービスを信頼する信頼ポリシーがサービスロールに含まれていることを確認します。ロールで信頼ポリシーを使用する方法の詳細については、[「ロールの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html)」または AWS 「セキュリティブログ記事」の[「IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。
## その他のヘルプとサポート
発生している特定の問題がこのトピックで説明されていないか、このトピックの提案を試しても問題が解決しない場合は、[OpsWorks フォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=153&start=0)を参照してください。
また、[AWS Support Center](https://console.aws.amazon.com/support/home#/) を参照することもできます。 AWS サポートセンターは、サポートケースを作成および管理 AWS するためのハブです。 AWS サポートセンターには、フォーラム、技術的なFAQs、サービスのヘルスステータスなど、その他の役立つリソースへのリンクも含まれています AWS Trusted Advisor。