翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# アプリケーション
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
OpsWorks スタック*アプリケーション*は、アプリケーションサーバーで実行するコードを表します。コード自体は Amazon S3 アーカイブなどのリポジトリにあります。アプリケーションには、適切なアプリケーションサーバーのインスタンスにコードをデプロイするために必要な情報が含まれます。
アプリケーションをデプロイすると、 OpsWorks スタックはデプロイイベントをトリガーし、各レイヤーのデプロイレシピを実行します。また、 OpsWorks スタックは、アプリケーションのリポジトリやデータベース接続データなど、アプリケーションのデプロイに必要なすべての情報を含む[スタック設定とデプロイ属性](workingcookbook-json.md)をインストールします。
スタック設定およびデプロイ属性からアプリケーションのデプロイデータを取得してデプロイタスクを処理するカスタムレシピを実装する必要があります。
**Topics**
+ [アプリケーションの追加](workingapps-creating.md)
+ [アプリケーションのデプロイ](workingapps-deploying.md)
+ [アプリケーションの編集](workingapps-editing.md)
+ [アプリケーションのデータベースサーバーへの接続](workingapps-connectdb.md)
+ [環境変数の使用](apps-environment-vars.md)
+ [アプリケーションへのデータの引き渡し](apps-data.md)
+ [Git リポジトリの SSH キーの使用](workingapps-deploykeys.md)
+ [カスタムドメインの使用](workingapps-domains.md)
+ [SSL の使用](workingsecurity-ssl.md)
# アプリケーションの追加
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
アプリケーションサーバーにアプリケーションをデプロイする際、最初に行うことは、そのアプリケーションをスタックに追加することです。app はアプリケーションを表し、さまざまなメタデータ (アプリケーションの名前や種類など) と、アプリケーションをサーバーインスタンスにデプロイするために必要な情報 (リポジトリ URL など) を保持します。アプリケーションをスタックに追加するには、Manage 権限が必要です。詳細については、「[ユーザー許可の管理](opsworks-security-users.md)」を参照してください。
**注記**
このセクションの手順は、Chef 12 以降のスタックに適用されます。Chef 11 スタックのレイヤーにアプリを追加する方法については、「[ステップ 2.4: アプリケーション - Chef 11 を作成してデプロイする](gettingstarted-simple-app.md)」を参照してください。
**スタックにアプリケーションを追加するには**
1. コードは、 Amazon S3 アーカイブ、 Gitリポジトリ、 Subversion リポジトリ、 HTTP アーカイブなど、望ましいリポジトリに加えてください。詳細については、「[Application Source](#workingapps-creating-source)」を参照してください。
1. ナビゲーションペインで [**Apps**] をクリックします。最初のアプリケーションの場合、[**Apps**] ページで [**Add an app**] をクリックします。それ以降のアプリケーションについては、[**\$1App**] をクリックします。
1. 次のセクションの説明に従い、[**App New**] ページを使用してアプリケーションを設定します。
## アプリケーションの設定
[**Add App**] ページは、[**Settings**]、[**Application source**]、[**Data Sources**]、[**Environment Variables**]、[**Add Domains**]、[**SSL Settings**] の各セクションで構成されています。
**Topics**
+ [設定](#workingapps-creating-settings)
+ [Application Source](#workingapps-creating-source)
+ [データソース](#workingapps-creating-data)
+ [環境可変](#workingapps-creating-environment)
+ [ドメインと SSL の設定](#workingapps-creating-domain-ssl)
### 設定
**名前**
UI でアプリを表すために使用されるアプリ名。 OpsWorks スタックは、この名前を使用して、内部で使用されるアプリの短縮名を生成し、[スタック設定およびデプロイ属性](workingcookbook-json.md)でアプリを識別します。アプリケーションをスタックに追加した後、ナビゲーションペインの [**Apps**] (アプリケーション) をクリックし、アプリケーションの名前をクリックして詳細ページを開くと短縮名を確認できます。
**[**Document root**]**
OpsWorks スタックは、アプリケーションの[`[:document_root]`](attributes-json-deploy.md#attributes-json-deploy-app-root)属性の `deploy` 属性に**ドキュメントルート**設定を割り当てます。デフォルト値は `null` です。デプロイレシピで標準の Chef ノード構文を使い、その値を `deploy` 属性から取得して、特定のコードをサーバー上の適切な場所にデプロイすることができます。アプリケーションのデプロイ方法の詳細については、「[Deploy レシピ](create-custom-deploy.md)」を参照してください。
### Application Source
以下の Git、 Amazon S3 bundle、 HTTP bundle などのリポジトリタイプからアプリケーションをデプロイできます。いずれのリポジトリタイプも、リポジトリのタイプとリポジトリの URL を指定する必要があります。リポジトリタイプにはそれぞれ固有の要件があります。以下、それらの要件について説明します。
**注記**
OpsWorks スタックは、標準リポジトリから組み込みサーバーレイヤーにアプリケーションを自動的にデプロイします。Windows スタックの唯一のオプションであるその他のリポジトリタイプを使用する場合、 OpsWorks スタックはアプリケーションの[`deploy`属性](workingcookbook-json.md#workingcookbook-json-deploy)にリポジトリ情報を配置しますが、デプロイタスクを処理するカスタムレシピを実装する必要があります。
**Topics**
+ [HTTP アーカイブ](#w2ab1c14c57c13c11b8b8)
+ [Amazon S3 アーカイブ](#w2ab1c14c57c13c11b8c10)
+ [Git リポジトリ](#w2ab1c14c57c13c11b8c12)
+ [その他のリポジトリ](#w2ab1c14c57c13c11b8c14)
#### HTTP アーカイブ
パブリックにアクセス可能な HTTP サーバーをリポジトリとして使用するには、次の手順を使用します。
1. アプリケーションのコードとあらゆる関連ファイルを含むフォルダの圧縮アーカイブ (zip、 gzip、 bzip2、 Java WAR、 tarball など) を作成します。
**注記**
OpsWorks スタックは非圧縮 tarball をサポートしていません。
1. アーカイブファイルをサーバーにアップロードします。
1. コンソールでリポジトリを指定するには、リポジトリタイプとして [HTTP Archive] を選択し、URL を入力します。
アーカイブがパスワードで保護されている場合、**アプリケーションソース** でサインイン認証を指定します。
#### Amazon S3 アーカイブ
Amazon シンプルストレージサービスバケットをリポジトリとして使用するには:
1. 公開またはプライベートの Amazon S3 バケットを作成します。詳細については、[「Amazon S3 Documentation」](https://aws.amazon.com/documentation/s3/)(Amazon S3のドキュメント) を参照してください。
1. OpsWorks スタックがプライベートバケットにアクセスするには、Amazon S3 バケットに対する少なくとも読み取り専用の権限を持つユーザーであり、アクセスキー ID とシークレットアクセスキーが必要です。詳細については、[AWS Identity and Access Management ドキュメント](https://docs.aws.amazon.com/iam/) を参照してください。
1. コードとすべての関連ファイルを単一フォルダに配置し、そのフォルダを圧縮アーカイブ (zip、gzip、bzip2、Java WAR、tarball のいずれか) に保存します。
**注記**
OpsWorks スタックは非圧縮 tarball をサポートしていません。
1. アーカイブファイルを Amazon S3 バケットにアップロードし、 URL を記録します。
1. OpsWorks スタックコンソールでリポジトリを指定するには、**リポジトリタイプ**を **S3 Archive** に設定し、アーカイブの URL を入力します。プライベートアーカイブの場合、ポリシーがバケットへのアクセス権限を付与する AWS アクセスキー ID とシークレットアクセスキーを提供する必要があります。パブリックアーカイブでは、これらの設定を空白のままにします。
#### Git リポジトリ
[Git](http://git-scm.com/) リポジトリは、ソース制御とバージョニングを提供します。 OpsWorks スタックは[GitHub](https://github.com/) や [Bitbucket](https://bitbucket.org) などのパブリックにホストされたリポジトリサイトと、プライベートにホストされた Git サーバーをサポートしています。アプリケーションも Git サブモジュールも、[**Application Source**] (アプリケーションソース) にリポジトリの URL を指定する際の形式は、リポジトリがパブリックであるかプライベートであるかによって異なります。
**[Public repository** (パブリックリポジトリ) ] - HTTPS または Git の読み取り専用プロトコルを使用します。例えば、[Chef 11 Linux スタックの使用開始](gettingstarted.md) では、以下のいずれかの URL 形式でアクセスできるパブリック GitHub リポジトリを使用します。
+ Git 読み取り専用: **git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git**
+ HTTPS: **https://github.com/amazonwebservices/opsworks-demo-php-simple-app.git**
**[Private repository** (プライベートリポジトリ) ] - 次の例に示す SSH の読み取り/書き込み形式を使用します。
+ Github リポジトリ: **git@github.com:*project*/*repository***。
+ Git サーバー上のリポジトリ: ***user*@*server*:*project*/*repository***
**[Source Control** (ソースコントロール) ] で **[Git** (Git) ] を選択すると、次の 2 つの追加オプション設定が表示されます。
**[Repository SSH key]**
プライベート Git リポジトリにアクセスするには、デプロイ SSH キーを指定する必要があります。このフィールドにはプライベートキーが必要となり、パブリックキーは Git リポジトリに割り当てられます。Git サブモジュールの場合、指定するキーには、それらのサブモジュールへのアクセス権が必要です。詳細については、「[Git リポジトリの SSH キーの使用](workingapps-deploykeys.md)」を参照してください。
デプロイ SSH キーはパスワードを要求できません。 OpsWorks スタックにはパスワードを渡す方法がありません。
**[Branch/Revision]**
リポジトリに複数のブランチがある場合、 OpsWorks スタックはデフォルトでマスターブランチをダウンロードします。特定のブランチを指定するには、ブランチ名、SHA1 ハッシュ、タグ名のいずれかを入力します。特定のコミットを指定するには、40 桁の 16 進数コミット ID を入力します。
#### その他のリポジトリ
標準のリポジトリでは要件を満たすことができない場合、他のリポジトリ ([Bazaar](http://bazaar.canonical.com/en/) など) を使用することができます。ただし、 OpsWorks スタックはそのようなリポジトリからアプリケーションを自動的にデプロイしません。デプロイプロセスを処理するカスタムレシピを独自に実装し、それらを適切なレイヤーの Deploy イベントに割り当てる必要があります。Deploy レシピの実装方法の例については、「[Deploy レシピ](create-custom-deploy.md)」を参照してください。
### データソース
このセクションはアプリケーションにデータベースをアタッチします。次のオプションがあります。
+ **RDS** - スタックの[ Amazon RDS サービスレイヤー](workinglayers-db-rds.md)の1つをアタッチします。
+ **[None** (なし) ] - データベースサーバーをアタッチしません。
**[RDS]** を選択する場合、以下の情報を指定する必要があります。
**Database instance**
このリストには、すべての Amazon RDS サービスレイヤーが含まれています。加えて、次のいずれかを選択することができます。
(必須) アプリケーションにアタッチするデータベースサーバーを指定します。リストの内容は、データソースによって異なります。
+ **[RDS** (RDS) ] - スタックの Amazon RDS サービスレイヤーのリスト。
**[Database name] (データベース名)**
(オプション) データベース名を指定します。
+ Amazon RDS レイヤー - Amazon RDS インスタンスに対して指定したデータベース名を入力します。
データベース名は、 [[Amazon RDS console](https://console.aws.amazon.com/rds/) (Amazon RDSコンソール) ] から取得できます。
データベースがアタッチされたアプリケーションをデプロイすると、 OpsWorks Stacks はデータベースインスタンスの接続をアプリケーションの[`deploy`属性](workingcookbook-json.md#workingcookbook-json-deploy)に追加します。
カスタムレシピを書き込んで `deploy` 属性から情報を取得し、アプリケーションからアクセスすることができるファイルに配置できます。これは、Other アプリケーションタイプにデータベース接続情報を提供する唯一のオプションです。
データベース接続を処理する方法の詳細については、「[データベースへの接続](workingapps-connectdb.md)」を参照してください。
データベースサーバーをアプリケーションからデタッチするには、[アプリケーションの設定を編集](workingapps-editing.md)して、異なるデータベースサーバーを指定するか、サーバーの指定を削除します。
### 環境可変
各アプリケーションに対し、アプリケーションに固有の一連の環境変数を指定できます。たとえば、2 つのアプリケーションがある場合、最初のアプリケーションに定義した環境変数を、もう 1 つのアプリケーションに定義することはできません。その逆も同様です。また、複数のアプリケーションに同じ環境変数を定義し、アプリケーションごとに異なる値を割り当てることもできます。
**注記**
環境変数の数に、特定の制限はありません。ただし、変数の名前、値、および保護されたフラグ値を含む、関連するデータ構造のサイズは、 20 KB を超えることはできません。この制限は、すべてではないものの、ほとんどのユースケースに適合します。これを超えると、サービスエラー (コンソール) または例外 (API) が発生し、"Environment: is too large (maximum is 20KB)" というメッセージが表示されます。
OpsWorks スタックは、変数を属性としてアプリケーションの[`deploy`属性](workingcookbook-json.md#workingcookbook-json-deploy)に保存します。標準の Chef ノード構文を使用して、カスタムレシピにこれらの値を取得することができます。アプリケーションの環境変数にアクセスする方法の例については [環境変数の使用](apps-environment-vars.md) を参照してください。
**Key**
変数名。最大 64 個の大文字および小文字の文字、数字、下線 (\$1) を含めることができますが、冒頭には文字または下線を使用する必要があります。
**値**
変数値。最大 256 文字を含めることができますが、すべて表示可能な文字である必要があります。
**Protected value**
値を保護するかどうかを指定します。この設定では、パスワードなどの機密情報を非表示にすることができます。変数に [**Protected value**] を設定した場合、アプリケーションの作成後は次のようになります。
+ アプリケーションの詳細ページには値が表示されず、変数名だけが表示されます。
+ アプリケーションを編集するアクセス許可がある場合、[**Update value** ] をクリックして新しい値を指定することはできますが、古い値を確認したり、編集したりすることはできません。
**注記**
Chef のデプロイログ には、環境変数が含まれることがあります。これは、保護された変数がコンソールに表示される場合があることを意味します。保護された変数がコンソールに表示されないようにするには、コンソールに表示したくない保護された変数のストレージとして Amazon S3 バケットを使用すること推奨します。この目的で S3 バケットを使用する例は、このガイドの「[Amazon S3 バケットの使用する](gettingstarted.walkthrough.photoapp.md)」を参照してください。
### ドメインと SSL の設定
その他のアプリタイプの場合、 OpsWorks スタックはアプリの`deploy`属性に設定を追加します。レシピは、それらの属性からデータを取得し、必要に応じてサーバーを設定できます。
**Domain Settings**
このセクションには、ドメインを指定するためのオプションの [**Add Domains**] フィールドがあります。詳細については、「[カスタムドメインの使用](workingapps-domains.md)」を参照してください。
**SSL Settings**
このセクションの [**SSL Support**] トグルを使用して、SSL の有効と無効を切り替えることができます。[**Yes**] をクリックした場合は、SSL 証明書の情報を指定する必要があります。詳細については、「[SSL の使用](workingsecurity-ssl.md)」を参照してください。
# アプリケーションのデプロイ
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
デプロイの主な目的は、アプリケーションサーバーインスタンスにアプリケーションコードと関連ファイルをデプロイすることです。デプロイ操作は、インスタンスのレイヤーによって決まる各インスタンスのデプロイレシピによって処理されます。
インスタンスを起動すると、Setup レシピが完了すると、 OpsWorks Stacks は自動的にインスタンスの Deploy レシピを実行します。ただし、アプリケーションを追加または変更するときには、オンラインインスタンスすべてに手動でデプロイする必要があります。アプリケーションをデプロイするには、Manage 権限または Deploy 権限が必要です。詳細については、「[ユーザー許可の管理](opsworks-security-users.md)」を参照してください。
**アプリケーションをデプロイするには**
1. [**Apps**] ページで、アプリケーションの [**deploy**] アクションをクリック します。
![\[Apps page showing SimplePHP app with deploy, edit, and delete action options.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/apps_with_content.png)
**注記**
ナビゲーションペインの [**Deployments**] をクリックしてアプリケーションをデプロイすることもできます。[**Deployments & Commands**] ページで、[**Deploy an app**] をクリックします。この操作を行う場合、デプロイするアプリケーションを選択することもできます。
1. 次を指定します:
+ (必須) [**Command:**] を [**deploy**] に設定します（まだ選択されていない場合)。
+ (オプション) コメントを入力します。
1. **Advanced >>** をクリックしてカスタム JSON を指定します。 OpsWorks スタックは、一連の[スタック設定とデプロイ属性](workingcookbook-json.md)をノードオブジェクトに追加します。`deploy` 属性にはデプロイの詳細が含まれており、Deploy レシピでこれらの属性を使用して、インストールと設定を処理できます。Linux スタックでは、カスタム JSON フィールドを使用して[デフォルトの OpsWorks スタック設定を上書き](workingcookbook-json-override.md)したり、カスタム設定をカスタムレシピに渡すことができます。カスタム JSON の使用方法の詳細については、「[カスタム JSON の使用](workingstacks-json.md)」を参照してください。
**注記**
カスタム JSON をここで指定する場合は、このデプロイのみのスタック設定およびデプロイ属性に追加されます。カスタム JSON を永続的に追加する場合は、[スタックに追加](workingstacks-json.md)する必要があります。カスタム JSON は 120 KB に制限されています。さらに容量が必要な場合は、 Amazon S3 でデータの一部を保存することをお勧めします。カスタムレシピで AWS CLI または [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/) を使用して、バケットからインスタンスにデータをダウンロードできます。例については、[ SDK for Ruby を使用する](cookbooks-101-opsworks-s3.md)を参照してください。
1. [**Instances**] で、[**Advanced >>**] をクリックし、デプロイコマンドを実行するインスタンスを指定します。
デプロイコマンドは Deploy イベントをトリガーし、これによって選択したインスタンスでデプロイレシピが実行されます。関連付けられたアプリケーションサーバーのデプロイレシピは、リポジトリからコードと関連ファイルをダウンロードし、インスタンスにインストールします。したがって、ユーザーは通常、関連付けられたアプリケーションサーバーのインスタンスをすべて選択します。ただし、他のインスタンスタイプでは、新しいアプリケーションに対応するように設定の変更を要求する場合があります。そのため、通常、それらのインスタンスでもデプロイレシピを実行することをお勧めします。それらのレシピは、必要に応じて設定を更新しますが、アプリケーションのファイルはインストールしません。recipe の詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。
1. [**Deploy**] をクリックして、指定したインスタンスでデプロイレシピを実行します。これにより、[Deployment] ページが表示されます。プロセスが完了すると、 OpsWorks Stacks はデプロイが成功したことを示す緑色のチェックでアプリをマークします。デプロイが失敗した場合、 OpsWorks スタックはアプリを赤い X でマークします。その場合、**デプロイ**ページに移動し、デプロイログを調べて詳細を確認できます。
![\[Deployment status page showing successful deployment of PHPTestApp with details.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/deployed_app.png)
**注記**
JPS アプリケーションの更新プログラムをデプロイする際に、Tomcat は更新プログラムを認識せず、アプリケーションの既存のバージョンを継続して実行する可能性があります。これが発生するのは、JSP ページのみが含まれている .zip ファイルとしてアプリケーションをデプロイする場合などです。Tomcat が、デプロイされた最新バージョンを確実に実行するようにするには、プロジェクトのルートディレクトリに、`web.xml` ファイルを含む WEB-INF ディレクトリを含める必要があります。`web.xml` ファイルはさまざまなコンテンツを含むことができますが、Tomcat が確実に更新プログラムを認識し、現在デプロイされているアプリケーションのバージョンを実行するようにするには、次のコンテンツで十分です。各更新プログラムのバージョンを変更する必要はありません。Tomcat は、バージョンが変更されていない場合でも更新プログラムを認識します。
```
appVersion
0.1
```
## 他のデプロイコマンド
[**Deploy app**] ページには、アプリケーションと関連サーバーを管理するためのその他のコマンドがいくつか含まれています。次のコマンドのうち、Chef 12 スタックのアプリで利用できるのは **Undeploy** のみです。
**Undeploy**
Undeploy [ライフサイクルイベント](workingcookbook-events.md)をトリガーし、指定されたインスタンスからアプリケーションのすべてのバージョンを削除するデプロイ解除レシピを実行します。
**ロールバック**
以前にデプロイされたアプリケーションのバージョンを復元します。たとえば、アプリケーションを 3 回デプロイした後、[**Rollback**] を実行した場合、サーバーは 2 回目のデプロイからアプリケーションを提供します。再度 [**Rollback**] を実行すると、サーバーは最初のデプロイからアプリケーションを提供します。デフォルトでは、 OpsWorks スタックには最新の 5 つのデプロイが保存されるため、最大 4 つのバージョンをロールバックできます。保存されているバージョンの数を超えた場合、このコマンドは失敗し、最も古いバージョンのままになります。このコマンドは、Chef 12 スタックでは使用できません。
**Start Web Server**
指定されたインスタンスでアプリケーションサーバーを起動するレシピを実行します。このコマンドは、Chef 12 スタックでは使用できません。
**Stop Web Server**
指定されたインスタンスでアプリケーションサーバーを停止するレシピを実行します。このコマンドは、Chef 12 スタックでは使用できません。
**Restart Web Server**
指定されたインスタンスでアプリケーションサーバーを再起動するレシピを実行します。このコマンドは、Chef 12 スタックでは使用できません。
**重要**
[**Start Web Server**]、[**Stop Web Server**]、[**Restart Web Server**]、および [**Rollback**] は、基本的には [[Execute Recipes] スタックコマンド](workingstacks-commands.md)のカスタマイズされたバージョンです。これらのコマンドは、指定されたインスタンスでタスクを実行する一連のレシピを実行します。
これらのコマンドはライフサイクルイベントをトリガーしないため、カスタムコードを実行するためにフックすることはできません。
これらのコマンドは、組み込みの [[application server layers](workinglayers-servers.md)] (アプリケーションサーバーレイヤー) に対してのみ機能します。
特に、これらのコマンドはカスタムレイヤーに影響を及ぼしません。アプリケーションサーバーがサポートされている場合でも同様です。カスタムレイヤーでサーバーを起動、停止、または再起動するには、これらのタスクを実行するカスタムレシピを実装し、[[Execute Recipes stack command](workingstacks-commands.md)] (レシピスタックコマンドの実行) を使用してカスタムレシピを実行する必要があります。カスタムレシピを実装およびインストールする方法の詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。
# アプリケーションの編集
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
アプリケーションを編集することで、設定を更新できます。たとえば、新しいバージョンをデプロイする準備ができたら、アプリケーションの OpsWorks スタック設定を編集して新しいリポジトリブランチを使用できます。アプリケーションの設定を編集するには、Manage または Deploy 権限が必要です。詳細については、「[ユーザー許可の管理](opsworks-security-users.md)」を参照してください。
**アプリケーションを編集するには**
1. [**Apps**] (アプリケーション) ページで、詳細ページを開くアプリケーションの名前をクリックします。
1. [**Edit**] (編集) をクリックして、アプリケーションの設定を変更します。
+ アプリの名前を変更すると、 OpsWorks スタックは新しい名前を使用してコンソールでアプリを識別します。
名前を変更しても、関連する短縮名は変更されません。短縮名はアプリケーションがスタックに追加された時に設定され、その後に修正はできません。
+ 保護された環境変数を指定した場合は、値を表示または変更することはできません。ただし、[**Update value**] (値を更新) をクリックして新しい値を指定できます。
1. [**Save**] (保存) をクリックして新規設定を保存し、[**Deploy App**] (デプロイアプリケーション) をクリックしてアプリケーションをデプロイします。
アプリケーションを編集すると、 OpsWorks スタックの設定は変更されますが、スタックのインスタンスには影響しません。初めて [[deploy an app](workingapps-deploying.md)] (アプリケーションをデプロイ) すると、デプロイレシピによりアプリケーションサーバーのインスタンスにコードと関連ファイルがダウンロードされます。それにより、ローカルコピーが実行されます。リポジトリでアプリを変更したり、他の設定を変更したりする場合は、次のようにアプリをデプロイして、アプリサーバーインスタンスに更新をインストールする必要があります。 OpsWorks スタックは、起動時に現在のアプリバージョンを新しいインスタンスに自動的にデプロイします。ただし、既存のインスタンスは事情が異なります。
+ OpsWorks スタックは、起動時に現在のアプリケーションバージョンを新しいインスタンスに自動的にデプロイします。
+ OpsWorks スタックは、再起動時に、[ロードベースおよび時間ベースの](workinginstances-autoscaling.md)インスタンスを含むオフラインインスタンスに最新のアプリケーションバージョンを自動的にデプロイします。
+ 更新されたアプリケーションをオンラインインスタンスに手動でデプロイする必要があります。
アプリケーションのデプロイ方法の詳細については、「[アプリケーションのデプロイ](workingapps-deploying.md)」を参照してください。
# アプリケーションのデータベースサーバーへの接続
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
[[create the app](workingapps-creating.md) (アプリケーションを作成する) ] とき、または後で [[editing the app](workingapps-editing.md) (アプリケーションを編集する) ] ことで、 Amazon RDS データベースサーバーをアプリケーションと関連付けることができます。その後、アプリケーションはデータベース接続情報 (ユーザー名、パスワードなど) を使用してデータベースサーバーに接続することができます。[アプリケーションをデプロイ](workingapps-deploying.md)すると、 OpsWorks Stacks は 2 つの方法でこの情報をアプリケーションに提供します。
+ Linux スタックでは、 OpsWorks スタックにより、各組み込みアプリケーションサーバーインスタンスに、アプリケーションがデータベースサーバーへの接続に使用できる接続データを含むファイルが作成されます。
+ OpsWorks スタックには、各インスタンスにインストールされている[スタック設定とデプロイ属性](workingcookbook-json.md)の接続情報が含まれます。
カスタムレシピを実装してこれらの属性から接続情報を取得し、任意の形式でファイルに配置することができます。詳細については、「[アプリケーションへのデータの引き渡し](apps-data.md)」を参照してください。
**重要**
Linux スタックでは、 Amazon RDS サービス レイヤーをアプリケーションと関連付ける場合は、次の手順に従って、関連付けたアプリケーションサーバーレイヤーに適切なドライバパッケージを追加する必要があります。
ナビゲーションペインで [**Layers**] (レイヤー) をクリックし、アプリケーションサーバーの [**Recipes**] (レシピ) タブを開きます。
[**Edit**] をクリックして適切なドライバパッケージを [**OS Packages**] に追加します。たとえば、レイヤーに Amazon Linux のインスタンスが含まれている場合は [`mysql`] を、レイヤーに Ubuntu インスタンスが含まれている場合は [`mysql-client`] を指定する必要があります。
変更を保存してアプリケーションを再デプロイします。
## カスタムレシピの使用
アプリケーションの [`deploy` 属性](workingcookbook-json.md#workingcookbook-json-deploy)から接続データを取得するカスタムレシピを実装し、YAML ファイルなど、アプリケーションが読み取ることができる形式で保存できます。
[アプリケーションを作成する](workingapps-creating.md)際、または後で[アプリケーションを編集する](workingapps-editing.md)際に、データベースサーバーをアプリケーションにアタッチします。アプリケーションをデプロイすると、 OpsWorks スタックはデータベース接続情報を含む[スタック設定とデプロイ属性](workingcookbook-json.md)を各インスタンスにインストールします。その後、アプリケーションは適切な属性を取得できます。詳細は、Linux スタックと Windows スタックのどちらを使用しているかによって異なります。
### Linux スタックのデータベースサーバーへの接続
Linux スタックでは、[スタック設定およびデプロイ属性の](workingcookbook-json.md) `deploy` 名前空間に、デプロイされた各アプリケーションの属性が含まれており、アプリケーションの短縮名が付いています。データベースサーバーをアプリケーションにアタッチすると、 OpsWorks Stacks はアプリケーションの `[:database]` 属性に接続情報を入力し、後続のデプロイごとにスタックのインスタンスにインストールします。属性値はユーザーが指定する値または OpsWorks スタックにより生成される値です。
**注記**
OpsWorks スタックを使用すると、データベースサーバーを複数のアプリケーションにアタッチできますが、各アプリケーションにアタッチできるデータベースサーバーは 1 つだけです。アプリケーションを複数のデータベースサーバーに接続する場合は、サーバーの 1 つをアプリケーションにアタッチし、アプリケーションの `deploy` 属性の情報を使用してそのサーバーに接続します。カスタム JSON を使用して、他のデータベースサーバーの接続情報をアプリケーションに渡します。詳細については、「[アプリケーションへのデータの引き渡し](apps-data.md)」を参照してください。
アプリケーションはインスタンスの `deploy` 属性の接続情報を使用してデータベースに接続します。ただし、アプリケーションはその情報に直接アクセスすることはできません。レシピだけが `deploy` 属性にアクセスできます。カスタムレシピを実装し、`deploy` 属性から接続情報を取得してアプリケーションで読み取り可能なファイルに保存すれば、この問題は解決します。
# 環境変数の使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
**注記**
このトピックの推奨事項は、Chef 11.10 およびそれ以前のバージョンの Chef に適用されます。Chef 12 以降で環境変数を取得するには、アプリケーションデータバッグを使用する必要があります。詳細については、「[AWS OpsWorks データバッグのリファレンス](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bags.html)」および「[アプリケーションデータバッグ (aws\$1opsworks\$1app)](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bag-json-app.html)」を参照してください。
[アプリケーションの環境変数を指定すると](workingapps-creating.md#workingapps-creating-environment)、 OpsWorks スタックは変数定義をアプリケーションの[`deploy`属性](workingcookbook-json.md#workingcookbook-json-deploy)に追加します。
カスタムレイヤーでは、レシピを使用して標準ノード構文によって変数の値を取得し、その値をレイヤーのアプリがアクセスできる形式で保存することができます。
インスタンスの `deploy` 属性から環境変数の値を取得するカスタムレシピを実装する必要があります。これにより、レシピではアプリケーションからアクセスできる形式のデータ (YAML ファイルなど) をインスタンスに保存できます。アプリケーションの環境変数の定義は、アプリケーションの `deploy` 内の `environment_variables` 属性に保存されます。以下の例は、属性構造を表す JSON を使用して、`simplephpapp` という名前のアプリケーションのそれらの属性の位置を示しています。
```
{
...
"ssh_users": {
},
"deploy": {
"simplephpapp": {
"application": "simplephpapp",
"application_type": "php",
"environment_variables": {
"USER_ID": "168424",
"USER_KEY": "somepassword"
},
...
}
}
```
レシピでは、標準ノード構文を使用して変数の値を取得できます。以下の例では、前述の JSON から `USER_ID` 値を取得してそれを Chef ログに記録する方法を示します。
```
Chef::Log.info("USER_ID: #{node[:deploy]['simplephpapp'][:environment_variables][:USER_ID]}")
```
スタック設定およびデプロイメント JSON から情報を取得し、それをインスタンスに保存する方法の詳細については、「[アプリケーションへのデータの引き渡し](apps-data.md)」を参照してください。
# アプリケーションへのデータの引き渡し
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
多くの場合、サーバーのアプリケーションにキーと値のペアなどのデータを渡すと便利です。そのためには、[カスタム JSON](workingstacks-json.md) を使用してデータをスタックに追加します。 OpsWorks スタックは、ライフサイクルイベントごとに各インスタンスのノードオブジェクトにデータを追加します。
ただし、Chef 属性を使用したノードオブジェクトからのカスタム JSON データの取得は、レシピからはできますが、アプリケーションからはできないことに注意してください。カスタム JSON データを 1 つ以上のアプリケーションに渡すためには、`node` オブジェクトのデータを抽出して、それをアプリケーションが読み取ることができるファイルに書き込むカスタムレシピを実装する方法があります。このトピックの例では YAML ファイルにデータを書き込む方法を示しますが、同じ基本手順を JSON や XML などの他の形式にも使用できます。
スタックのインスタンスにキーと値のデータを渡すには、スタックに次のようなカスタム JSON を追加します。カスタム JSON をスタックに追加する方法の詳細については、「[カスタム JSON の使用](workingstacks-json.md)」を参照してください。
```
{
"my_app_data": {
"app1": {
"key1": "value1",
"key2": "value2",
"key3": "value3"
},
"app2": {
"key1": "value1",
"key2": "value2",
"key3": "value3"
}
}
}
```
この例では、`app1` と `app2` という短縮名の 2 つのアプリケーションそれぞれに 3 つのデータ値があることを前提としています。添付のレシピでは、関連付けられたデータを識別するためにアプリケーションの短縮名を使用しており、他の名前は任意であることを前提としています。アプリケーションの短縮名の詳細については、「[設定](workingapps-creating.md#workingapps-creating-settings)」を参照してください。
次の例のレシピでは、`deploy` 属性から各アプリケーション用のデータを抽出し、`.yml` ファイルに保存する方法を示しています。レシピは、カスタム JSON に各アプリケーション用のデータが含まれていることを前提としています。
```
node[:deploy].each do |app, deploy|
file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do
content YAML.dump(node[:my_app_data][app].to_hash)
end
end
```
`deploy` 属性には、各アプリケーションの属性が含まれています (アプリケーションの短縮前が付いています)。各アプリケーション属性には、アプリケーションに関するさまざまな情報を表す一連の属性が含まれます。この例では、`[:deploy][:app_short_name][:deploy_to]` 属性で表されるアプリケーションのデプロイメントディレクトリを使用しています。`[:deploy]` の詳細については、「[deploy 属性](attributes-json-deploy.md)」をご参照ください。
`deploy` の各アプリケーションに対して、レシピは以下のことを行います。
1. `app_data.yml` という名前のファイルを、アプリケーションの `[:deploy_to]` ディレクトリの `shared/config` サブディレクトリに作成します。
OpsWorks スタックがアプリケーションをインストールする方法の詳細については、「」を参照してください[Deploy レシピ](create-custom-deploy.md)。
1. アプリケーションのカスタム JSON 値を YAML に変換し、YAML 形式のデータを `app_data.yml` に書き込みます。
**アプリケーションにデータを渡すには**
1. スタックにアプリケーションを追加し、その短縮名を書き留めます。詳細については、「[アプリケーションの追加](workingapps-creating.md)」を参照してください。
1. 前述のように、カスタム JSON とアプリケーションのデータを `deploy` 属性に追加します。スタックにカスタム JSON を追加する方法の詳細については、「[カスタム JSON の使用](workingstacks-json.md)」を参照してください。
1. クックブックを作成し、レシピを追加します。レシピのコードは、前述の例をベースにして、必要に応じてカスタム JSON に使用した属性名に変更してください。クックブックとレシピの作成方法の詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。このスタック用のカスタムクックブックがすでにある場合は、既存のクックブックにレシピを追加することも、既存の Deploy レシピにコードを追加することもできます。
1. スタックにクックブックをインストールします。詳細については、「[カスタムクックブックのインストール](workingcookbook-installingcustom-enable.md)」を参照してください。
1. レシピをアプリケーションサーバーレイヤーのデプロイライフサイクルイベントに割り当てます。 OpsWorks スタックは、起動後に新しいインスタンスごとにレシピを実行します。詳細については、「[レシピの実行](workingcookbook-executing.md)」を参照してください。
1. アプリケーションをデプロイすると、データが含まれたスタック設定とデプロイメント属性もインストールされます。
**注記**
アプリケーションのデプロイ前にデータファイルが用意できている場合は、レイヤーの Setup ライフサイクルイベントにレシピを割り当てることもできます。このイベントは、インスタンスの起動直後に 1 回のみ発生します。ただし、 OpsWorks スタックはデプロイディレクトリをまだ作成していないため、レシピはデータファイルを作成する前に必要なディレクトリを明示的に作成する必要があります。次の例では、アプリケーションの `/shared/config` ディレクトリを明示的に作成し、次にそのディレクトリにデータファイルを作成しています。
```
node[:deploy].each do |app, deploy|
directory "#{deploy[:deploy_to]}/shared/config" do
owner "deploy"
group "www-data"
mode 0774
recursive true
action :create
end
file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do
content YAML.dump(node[:my_app_data][app].to_hash)
end
end
```
データをロードするには、次に示すような [Sinatra](http://www.sinatrarb.com/) コードを使用できます。
```
#!/usr/bin/env ruby
# encoding: UTF-8
require 'sinatra'
require 'yaml'
get '/' do
YAML.load(File.read(File.join('..', '..', 'shared', 'config', 'app_data.yml')))
End
```
次のようにカスタム JSON を更新することで、いつでもアプリケーションのデータ値を更新することができます。
**アプリケーションのデータを更新するには**
1. データ値を更新するには、カスタム JSON を編集します。
1. アプリケーションを再度デプロイします。これにより、スタック OpsWorks はスタックのインスタンスで Deploy レシピを実行するように指示されます。レシピでは更新されたスタック設定とデプロイメント属性の属性が使用されるため、カスタムレシピによってデータファイルが現在の値で更新されます。
# Git リポジトリの SSH キーの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Git リポジトリの SSH キー (デプロイ SSH キーと呼ばれることもある) は、プライベート Git リポジトリへのアクセスを提供するパスワードのない SSH キーです。この SSH キーは、特定の開発者に固有のものではないことが理想的です。その目的は、スタックが Git OpsWorks リポジトリからアプリケーションやクックブックを非同期的にデプロイできるようにすることです。ユーザーからの入力は必要ありません。
次に、リポジトリ SSH キーを作成するための基本的な手順について説明します。詳細については、使用しているリポジトリのドキュメントを参照してください。例えば、「[Managing deploy keys](https://help.github.com/articles/managing-deploy-keys)」(デプロイキーの管理) では、GitHub リポジトリのリポジトリ SSH キーを作成する方法が説明されており、「[Deployment Keys on Bitbucket](http://blog.bitbucket.org/2012/06/20/deployment-keys/)」(Bitbucket のデプロイキー) では、Bitbucket リポジトリのリポジトリ SSH キーを作成する方法が説明されています。一部のドキュメントでは、サーバーにキーを作成する方法が記載されていることに注意してください。 OpsWorks スタックの場合は、手順の「サーバー」を「ワークステーション」に置き換えるだけです。
**リポジトリ SSH キーを作成するには**
1. `ssh-keygen` などのプログラムを使用して、ワークステーションに Git リポジトリ用のデプロイ SSH キーペアを作成します。
**重要**
OpsWorks スタックは SSH キーパスフレーズをサポートしていません。
1. リポジトリにパブリックキーを割り当てて、プライベートキーをワークステーションに保存します。
1. アプリケーションを追加する場合や、クックブックリポジトリを指定する場合は、[**Repository SSH Key**] ボックスにプライベートキーを入力します。詳細については、「[アプリケーションの追加](workingapps-creating.md)」を参照してください。
OpsWorks スタックはリポジトリ SSH キーを各インスタンスに渡し、組み込みレシピはそのキーを使用してリポジトリに接続し、コードをダウンロードします。キーは [`deploy` 属性](workingcookbook-json.md)に [`node[:deploy]['appshortname'][:scm][:ssh_key]`](attributes-json-deploy.md#attributes-json-deploy-app-scm-key) として保存され、ルートユーザーに対してのみアクセス可能になります。
# カスタムドメインの使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
サードパーティでドメイン名をホストしている場合、そのドメイン名をアプリケーションにマッピングできます。基本的な手順は次のとおりです。
1. サブドメインを DNS レジストラで作成し、ロードバランサーの Elastic IP アドレスまたはアプリケーションサーバーのパブリック IP アドレスにマッピングします。
1. アプリケーションの設定を更新して、サブドメインを指定し、アプリケーションを再デプロイします。
**注記**
非修飾ドメイン名 (myapp1.example.com など) が、修飾ドメイン名 (www.myapp1.example.com など) に転送されることを確認します。これにより、どちらもアプリケーションにマッピングされます。
アプリケーション用にドメインを設定すると、サーバー設定ファイルのサーバーエイリアスとして一覧表示されます。ロードバランサーを使用する場合、ロードバランサーはリクエストを受け取ったときに URL のドメイン名を確認し、そのドメインに基づいてトラフィックをリダイレクトします。
**サブドメインを IP アドレスにマッピングするには**
1. ロードバランサーを使用する場合、[**Instances**] (インスタンス) ページでロードバランサーインスタンスをクリックして詳細ページを開き、インスタンスの [**Elastic IP**] アドレスを確認します。それ以外の場合、アプリケーションサーバーインスタンスの詳細ページでパブリック IP アドレスを確認します。
1. DNS レジストラが指定している手順に従って、ステップ 1 から、サブドメインを作成して IP アドレスにマッピングします。
**注記**
ある時点でロードバランサーインスタンスが終了した場合、新しい Elastic IP アドレスが割り当てられています。新しい Elastic IP アドレスにマッピングするために、DNS レジストラ設定を更新する必要があります。
OpsWorks スタックは、単にドメイン設定をアプリケーションの[`deploy`属性](workingcookbook-json.md#workingcookbook-json-deploy)に追加します。カスタムレシピを実装して、ノードオブジェクトから情報を取得し、適切にサーバーを設定する必要があります。詳細については、「[クックブックとレシピ](workingcookbook.md)」を参照してください。
# 同じアプリケーションサーバー上での複数のアプリケーションの実行
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
**注記**
このトピックの情報は、Node.js アプリケーションには適用されません。
同じタイプの複数のアプリケーションがある場合、同じアプリケーションサーバーインスタンスで実行すると、コストパフォーマンスが向上する可能性があります。
**複数のアプリケーションを同じサーバーで実行するには**
1. 各アプリケーション用スタックにアプリケーションを追加します。
1. アプリケーションごとに別々のサブドメインを取得し、アプリケーションサーバーまたはロードバランサーの IP アドレスにマッピングします。
1. 各アプリケーションの設定を編集し、適切なサブドメインを指定します。
この作業を実行する方法の詳細については、「[カスタムドメインの使用](workingapps-domains.md)」を参照してください。
**注記**
アプリケーションサーバーで複数の HTTP アプリケーションを実行している場合、 Elastic Load Balancing を使用して負荷を分散できます。複数の HTTPS アプリケーションがある場合、ロードバランサーで SSL 接続を終了するか、アプリケーションごとに別々のスタックを作成する必要があります。HTTPS リクエストが暗号化されていると、SSL 接続をサーバーで終了した場合、ロードバランサーはドメイン名を確認できず、リクエストを処理するアプリケーションを判断できません。
# SSL の使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
アプリケーションで SSL を使用するには、最初に認証機関 (CA) からデジタルサーバー証明書を取得する必要があります。簡単になるように、このチュートリアルでは、証明書を作成し、その証明書に自己署名します。自己署名した証明書は学習やテストに便利ですが、本稼働用スタックには、CA によって署名された証明書を常に使用する必要があります。
このウォークスルーでは、次の作業を行います。
1. OpenSSL をインストールおよび設定します。
1. プライベートキーを作成します。
1. 証明書署名リクエストを作成します。
1. 自己署名証明書を生成します。
1. 証明書情報を使用してアプリケーションを編集します。
**重要**
アプリケーションで SSL を使用する場合、[CVE-2014-3566](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-3566) で説明されている脆弱性に対応するため、可能であればアプリケーションサーバーレイヤーで SSLv3 を無効にすることをお勧めします。スタックに Ganglia レイヤーが含まれる場合は、そのレイヤーでも SSL v3 を無効にする必要があります。その詳細は特定のレイヤーによって異なります。詳細については、以下を参照してください。
[Java App Server OpsWorks スタックレイヤー](layers-java.md)
[Node.js App Server OpsWorks スタックレイヤー](workinglayers-node.md)
[PHP App Server OpsWorks スタックレイヤー](workinglayers-php.md)
[Rails App Server OpsWorks スタックレイヤー](workinglayers-rails.md)
[静的ウェブサーバー OpsWorks スタックレイヤー](workinglayers-static.md)
[Ganglia レイヤー](workinglayers-ganglia.md)
**Topics**
+ [ステップ 1: OpenSSL をインストールおよび設定する](#w2ab1c14c57c29c15)
+ [ステップ 2: プライベートキーを作成する](#w2ab1c14c57c29c17)
+ [ステップ 3: 証明書署名リクエストを作成する](#w2ab1c14c57c29c19)
+ [ステップ 4: CSR を認証機関に送信する](#w2ab1c14c57c29c21)
+ [ステップ 5: アプリケーションを編集する](#w2ab1c14c57c29c23)
## ステップ 1: OpenSSL をインストールおよび設定する
サーバー証明書を作成およびアップロードするには、SSL プロトコルと TLS プロトコルをサポートするツールが必要です。OpenSSL はオープンソースのツールで、RSA トークンの作成やそのトークンにプライベートキーを署名するための基本的な暗号関数を提供します。
次の手順の説明は、コンピュータにまだ OpenSSL がインストールされていないことを前提としています。
**Linux や Unix で OpenSSL をインストールするには**
1. [OpenSSL の [Source] の [Tarballs]](https://www.openssl.org/source/) に移動します。
1. 最新のソースをダウンロードします。
1. パッケージをビルドします。
**Windows へ OpenSSL をインストールするには**
1. Microsoft Visual C\$1\$1 2008 再頒布可能パッケージがシステムにインストールされていない場合は、[こちらからダウンロード](https://www.microsoft.com/en-us/download/details.aspx?id=11895)してください。
1. インストーラを実行し、Microsoft Visual C\$1\$1 2008 Redistributable のセットアップウィザードの指示に従って、再頒布可能コードをインストールします。
1. [[OpenSSL: Binary Distributions](https://www.openssl.org/community/binaries.html)] に移動し、ご利用の環境に応じたバージョンの OpenSSL バイナリをクリックして、インストーラをローカルに保存します。
1. インストーラを実行し、**OpenSSL セットアップウィザード**の指示に従ってバイナリをインストールします。
ターミナルウィンドウまたはコマンドウィンドウを開き、次のコマンドラインを使用して、OpenSSL のインストールポイントを指す環境変数を作成します。
+ Linux および UNIX の場合
```
export OpenSSL_HOME=path_to_your_OpenSSL_installation
```
+ Windows の場合
```
set OpenSSL_HOME=path_to_your_OpenSSL_installation
```
ターミナルウィンドウまたはコマンドウィンドウを開き、次のコマンドラインを使用して、コンピュータのパス変数に OpenSSL バイナリのパスを追加します。
+ Linux および UNIX の場合
```
export PATH=$PATH:$OpenSSL_HOME/bin
```
+ Windows の場合
```
set Path=OpenSSL_HOME\bin;%Path%
```
**注記**
これらのコマンドラインを使用して環境変数に加えた変更は、現在のコマンドラインセッションでのみ有効です。
## ステップ 2: プライベートキーを作成する
証明書署名リクエスト（CSR）を作成するには一意のプライベートキーが必要です。次のコマンドラインを使用してキーを作成します。
```
openssl genrsa 2048 > privatekey.pem
```
## ステップ 3: 証明書署名リクエストを作成する
証明書署名リクエスト（CSR）は、デジタルサーバー証明書を申請するために認証機関（CA）に送信されるファイルです。次のコマンドラインを使用して CSR を作成します。
```
openssl req -new -key privatekey.pem -out csr.pem
```
コマンドの出力は以下のようになります。
```
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
```
次の表は、証明書リクエストを作成する際に役立ちます。
**証明書リクエストデータ**
| 名前 | 説明 | 例 |
| --- | --- | --- |
| 国名 | 2 文字の ISO 略称 (国名コード)。 | 例 :US = アメリカ |
| 州または県 | あなたが所属する組織の所在地の州または県。省略不可です。 | ワシントン |
| 市区町村 | あなたが所属する組織の所在地の市区町村。 | Seattle |
| 組織名 | 組織の正式名称。組織名は、省略不可です。 | CorporationX |
| 部門名 | (オプション) 追加の組織情報。 | Marketing |
| 共通名 | CNAME に対する完全に適合するドメイン名。完全に一致しない場合は、証明書名チェックの警告が通知されます。 | www.example.com |
| E メールアドレス | サーバー管理者の E メールアドレス | someone@example.com |
**注記**
共通名フィールドは誤解されることが多く、間違って入力されることがよくあります。共有名とは通常の場合、ホスト名にドメイン名を付け加えたものです。"www.example.com" または "example.com" のようになります。正しい共有名を使用して CSR を作成しなければなりません。
## ステップ 4: CSR を認証機関に送信する
本稼働環境で使用する場合は、認証機関 (CA) に CSR を送信してサーバー証明書を取得します。この場合、他の認証情報や識別の根拠が必要になることがあります。申請が正常に処理された場合、CA はデジタル署名されたアイデンティティ証明書と、場合によっては証明書チェーンファイルを返します。AWS が特定の CA を推奨することはありません。利用可能な CA の一覧 (一部のみ) については、Wikipedia の [Certificate Authority - Providers](https://en.wikipedia.org/wiki/Certificate_authority#Providers) を参照してください
また、テスト目的でのみ使用できる自己署名証明書を生成することもできます。この例では、次のコマンドラインを使用して自己署名証明書を生成します。
```
openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt
```
出力は以下のようになります。
```
Loading 'screen' into random state - done
Signature ok
subject=/C=us/ST=washington/L=seattle/O=corporationx/OU=marketing/CN=example.com/emailAddress=someone@example.com
Getting Private key
```
## ステップ 5: アプリケーションを編集する
証明書を生成して署名したら、SSL を有効化して証明書情報を指定するために、アプリケーションを更新します。[**Apps (アプリ)**] ページで、アプリを選択して詳細ページを開き、[**Edit App (アプリの編集)**] をクリックします。SSL サポートを有効化するには、[**Enable SSL (SSL の有効化)**] を [**Yes (はい)**] に設定します。次の設定オプションが表示されます。
**SSL 証明書**
ボックスにパブリックキー証明書 (.crt) ファイルの内容を貼り付けます。証明書の例を次に示します。
```
-----BEGIN CERTIFICATE-----
MIICuTCCAiICCQCtqFKItVQJpzANBgkqhkiG9w0BAQUFADCBoDELMAkGA1UEBhMC
dXMxEzARBgNVBAgMCndhc2hpbmd0b24xEDAOBgNVBAcMB3NlYXR0bGUxDzANBgNV
BAoMBmFtYXpvbjEWMBQGA1UECwwNRGV2IGFuZCBUb29sczEdMBsGA1UEAwwUc3Rl
cGhhbmllYXBpZXJjZS5jb20xIjAgBgkqhkiG9w0BCQEWE3NhcGllcmNlQGFtYXpv
...
-----END CERTIFICATE-----
```
Nginx を使用していて、証明書チェーンファイルがある場合は、その内容をパブリックキー証明書ファイルに追加する必要があります。
既存の証明書を更新する場合は、次のようにします。
+ 証明書を更新するには [**Update SSL certificate (SSL 証明書の更新)**] を選択します。
+ 新しい証明書が既存のプライベートキーと一致しない場合は、[**Update SSL certificate key (SSL 証明書キーの更新)**] を選択します。
+ 新しい証明書が既存の証明書チェーンと一致しない場合は、[**Update SSL certificates (SSL 証明書の更新)**] を選択します。
[**SSL Certificate Key**]
ボックスにプライベートキーファイル (.pem ファイル) の内容を貼り付けます。次のようになります。
```
----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQC0CYklJY5r4vV2NHQYEpwtsLuMMBhylMrgBShKq+HHVLYQQCL6
+wGIiRq5qXqZlRXje3GM5Jvcm6q0R71MfRIl1FuzKyqDtneZaAIEYniZibHiUnmO
/UNqpFDosw/6hY3ONk0fSBlU4ivD0Gjpf6J80jL3DJ4R23Ed0sdL4pRT3QIDAQAB
AoGBAKmMfWrNRqYVtGKgnWB6Tji9QrKQLMXjmHeGg95mppdJELiXHhpMvrHtpIyK
...
-----END RSA PRIVATE KEY-----
```
[**SSL certificates of Certification Authorities**]
証明書チェーンファイルがある場合は、ボックスにその内容を貼り付けます。
Nginx を使用している場合は、このボックスを空にしておく必要があります。証明書チェーンファイルがある場合は、これを [**SSL Certificate (SSL 証明書)**] のパブリックキー証明書ファイル に追加します。
![\[SSL Settings interface with options for SSL サポート, Certificate, Key, and Certification Authorities.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/app_ssl_settings.png)
[**Save**] をクリックしたら、[アプリケーションを再デプロイ](workingapps-deploying.md)して、オンラインインスタンスを更新します。
[組み込みアプリケーションサーバーレイヤー](workingcookbook-json.md#workingcookbook-json-deploy)の場合、 OpsWorks Stacks はサーバー設定を自動的に更新します。デプロイが完了したら、以下のようにして OpenSSL のインストールが成功したことを確認できます。
**OpenSSL のインストールを検証するには**
1. [**Instances**] ページに移動します。
1. アプリケーションサーバーのインスタンスの IP アドレス (または、ロードバランサーを使用している場合はロードバランサーの IP アドレス) をクリックして、アプリケーションを実行します。
1. IP アドレスのプレフィックスを **http://** から **https://** に変更し、ブラウザを更新して、SSL でページが正しく読み込まれることを検証します。
アプリが Mozilla Firefox で作動するように設定されていると、「`SEC_ERROR_UNKNOWN_ISSUER`」という証明書エラーが表示されることがあります。このエラーは、お客様の組織のウイルス対策およびマルウェア対策プログラムに搭載されている証明書交換機能、一部の種類のネットワークトラフィックモニタリングおよびフィルタリングソフトウェア、またはマルウェアのいずれかが原因で発生することがあります。このエラーのトラブルシューティング方法の詳細については、Mozilla Firefox Support ウェブサイトに掲載されている、「[安全なウェブサイトでの「安全な接続ではありません」エラーコードをトラブルシュートするには](https://support.mozilla.org/en-US/kb/error-codes-secure-websites?redirectlocale=en-US&redirectslug=troubleshoot-SEC_ERROR_UNKNOWN_ISSUER#w_monitoringfiltering-in-corporate-networks)」を参照してください。
カスタムレイヤーも含めてすべてのレイヤーに対して、 OpsWorks スタックによって SSL 設定がアプリケーションの [`deploy` 属性](workingcookbook-json.md#workingcookbook-json-deploy)に追加されるだけです。カスタムレシピを実装して、ノードオブジェクトから情報を取得し、適切にサーバーを設定する必要があります。