開始方法 - AWS CloudFormation
ステップ 1: テンプレートの選択ステップ 2: スタックに必要な項目の準備ができたことの確認ステップ 3: スタックの作成ステップ 4: スタックの作成状況の監視ステップ 5: スタックリソースの使用ステップ 6: クリーンアップする

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

開始方法

適切なテンプレートを使用すると、アプリケーションに必要なすべての AWS リソースを迅速にデプロイすることができます。このセクションでは、WordPress ブログのリソースの宣言、スタックとしての WordPress ブログの作成、スタック作成プロセスの監視、スタック上のリソースの検査、およびスタックの削除を行うテンプレートについて詳しく説明します。これらのタスクを行うには、AWS Management Console を使用します。

ステップ 1: テンプレートの選択

まず、スタックで必要なリソースを指定するテンプレートが必要です。この手順では、既に用意されているサンプルテンプレートを使用します。サンプルテンプレートは、ストレージ用ローカル MySQL データベースを使って、単一の Amazon EC2 インスタンスを使用する基本 WordPress ブログを作成します。このテンプレートでは、Amazon EC2 インスタンスのファイアウォール設定を制御するために Amazon EC2 セキュリティグループを作成します。

重要

AWS CloudFormation は無料ですが、CloudFormation が作成する AWS リソースは実動のものです (サンドボックス環境では実行されません)。このチュートリアルの最後のタスクでリソースを終了させるまで、これらのリソースの標準使用料が発生します。合計料金はごくわずかです。料金を最小限に抑える方法については、「http://aws.amazon.com/free/」を参照してください。

テンプレートを表示するには

  • JSON、または YAML の WordPress サンプルテンプレートを表示できます。テンプレートの URL は、このガイドの後半で使用するため、ここでダウンロードする必要はありません。テンプレート形式の詳細については、「AWS CloudFormation テンプレート形式」を参照してください。

テンプレートは、スタックで作成する AWS リソースの構成情報を含む JSON または YAML テキストファイルです。このチュートリアルでは、6 つの最上位セクション (AWSTemplateFormatVersion、Description、Parameters、Mappings、Resources、Outputs) がありますが、必要なのは Resources セクションだけです。

Resources セクションには、テンプレートで作成する AWS リソースの定義が含まれます。各リソースは個別にリストされ、その特定のリソースの作成に必要なプロパティを指定します。次のリソース宣言は、EC2 インスタンスの構成です。この例では論理名 WebServer が含まれています。

例 JSON
"Resources" : {
  ...    
  "WebServer": {
    "Type" : "AWS::EC2::Instance",
    "Properties": {
      "ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" },
                        { "Fn::FindInMap" : [ "AWSInstanceType2Arch", { "Ref" : "InstanceType" }, "Arch" ] } ] },
      "InstanceType"   : { "Ref" : "InstanceType" },
      "SecurityGroups" : [ {"Ref" : "WebServerSecurityGroup"} ],
      "KeyName"        : { "Ref" : "KeyName" },
      "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
                     "#!/bin/bash -xe\n",
                     "yum update -y aws-cfn-bootstrap\n",

                     "/opt/aws/bin/cfn-init -v ",
                     "         --stack ", { "Ref" : "AWS::StackName" },
                     "         --resource WebServer ",
                     "         --configsets wordpress_install ",
                     "         --region ", { "Ref" : "AWS::Region" }, "\n",

                     "/opt/aws/bin/cfn-signal -e $? ",
                     "         --stack ", { "Ref" : "AWS::StackName" },
                     "         --resource WebServer ",
                     "         --region ", { "Ref" : "AWS::Region" }, "\n"
      ]]}}
    },
    ...
  },
  ...  
  "WebServerSecurityGroup" : {
    "Type" : "AWS::EC2::SecurityGroup",
    "Properties" : {
      "GroupDescription" : "Enable HTTP access via port 80 locked down to the load balancer + SSH access",
      "SecurityGroupIngress" : [
        {"IpProtocol" : "tcp", "FromPort" : 80, "ToPort" : 80, "CidrIp" : "0.0.0.0/0"},
        {"IpProtocol" : "tcp", "FromPort" : 22, "ToPort" : 22, "CidrIp" : { "Ref" : "SSHLocation"}}
      ]
    }
  },
  ...    
},
例 YAML
Resources: 
  ...    
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [AWSRegionArch2AMI, !Ref 'AWS::Region', !FindInMap [AWSInstanceType2Arch, !Ref InstanceType, Arch]]      
      InstanceType:
        Ref: InstanceType
      KeyName:
        Ref: KeyName
      SecurityGroups:
      - Ref: WebServerSecurityGroup
      UserData:
        Fn::Base64: !Sub |
           #!/bin/bash -xe
           yum update -y aws-cfn-bootstrap
           /opt/aws/bin/cfn-init -v --stack ${AWS::StackId} --resource WebServer --configsets wordpress_install --region ${AWS::Region}
           /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackId} --resource WebServer --region ${AWS::Region}
    ...
  ...
  
  WebServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: "Enable HTTP access via port 80 locked down to the load balancer + SSH access"
      SecurityGroupIngress:
      - CidrIp: 0.0.0.0/0
        FromPort: 80
        IpProtocol: tcp
        ToPort: 80
      - CidrIp: !Ref SSHLocation
        FromPort: 22
        IpProtocol: tcp
        ToPort: 22
  ...

以前に EC2 インスタンスを作成したことがある場合は、インスタンスの構成を決定する、ImageId、InstanceType、KeyName などのプロパティに気が付くでしょう。リソース宣言は、これらすべての構成を一度に指定するための効率的な方法です。テンプレートでリソースを宣言すると、テンプレートを使用してスタックを作成することによって、宣言したすべてのリソースを作成および設定できます。同じテンプレートを使用してリソースの同じ構成を起動する新しいスタックを作成します。

リソース宣言は、リソースの論理名を指定する文字列で開始されます。後で説明するように、テンプレート内のリソースを参照するために、論理名を使用できます。

スタックを作成する際にテンプレートに渡すことができる値を宣言するために、Parameters セクションを使用します。パラメーターは、ユーザー名やパスワードなど、テンプレート自体には格納したくない機密情報を指定する方法としても効果的です。これは、特定のアプリケーションに固有の情報や、デプロイしている構成 (例えば、ドメイン名やインスタンスタイプ) を指定する方法でもあります。このセクションの後の方で WordPress スタックを作成するときに、テンプレートで宣言されている一連のパラメータが [Create Stack] (スタックの作成) ウィザードの [Specify Details] (詳細の指定) ページに表示されます。このページで、スタックを作成する前にパラメータを設定できます。

テンプレートでは、EC2 インスタンスのプロパティで使用される値を指定するために、次のパラメーターが使用されています。

例 JSON
"Parameters" : {
  ...      
  "KeyName": {
    "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the instances",
    "Type": "AWS::EC2::KeyPair::KeyName",
    "ConstraintDescription" : "must be the name of an existing EC2 KeyPair."
  },

  "InstanceType" : {
    "Description" : "WebServer EC2 instance type",
    "Type" : "String",
    "Default" : "t2.small",
       "AllowedValues": [
        "t1.micro",
        "t2.nano",
        "t2.micro",
        "t2.small",
        "t2.medium",
        "t2.large",
        "m1.small",
        "m1.medium",
        "m1.large",
        "m1.xlarge",
        "m2.xlarge",
        "m2.2xlarge",
        "m2.4xlarge",
        "m3.medium",
        "m3.large",
        "m3.xlarge",
        "m3.2xlarge",
        "m4.large",
        "m4.xlarge",
        "m4.2xlarge",
        "m4.4xlarge",
        "m4.10xlarge",
        "c1.medium",
        "c1.xlarge",
        "c3.large",
        "c3.xlarge",
        "c3.2xlarge",
        "c3.4xlarge",
        "c3.8xlarge",
        "c4.large",
        "c4.xlarge",
        "c4.2xlarge",
        "c4.4xlarge",
        "c4.8xlarge",
        "g2.2xlarge",
        "g2.8xlarge",
        "r3.large",
        "r3.xlarge",
        "r3.2xlarge",
        "r3.4xlarge",
        "r3.8xlarge",
        "i2.xlarge",
        "i2.2xlarge",
        "i2.4xlarge",
        "i2.8xlarge",
        "d2.xlarge",
        "d2.2xlarge",
        "d2.4xlarge",
        "d2.8xlarge",
        "hi1.4xlarge",
        "hs1.8xlarge",
        "cr1.8xlarge",
        "cc2.8xlarge",
        "cg1.4xlarge"
       ],
    "ConstraintDescription" : "must be a valid EC2 instance type."
  },
...
例 YAML
Parameters:
  ...      
  KeyName:
    ConstraintDescription: must be the name of an existing EC2 KeyPair.
    Description: Name of an existing EC2 KeyPair to enable SSH access to the instances
    Type: AWS::EC2::KeyPair::KeyName
  InstanceType:
    AllowedValues:
    - t1.micro
    - t2.nano
    - t2.micro
    - t2.small
    - t2.medium
    - t2.large
    - m1.small
    - m1.medium
    - m1.large
    - m1.xlarge
    - m2.xlarge
    - m2.2xlarge
    - m2.4xlarge
    - m3.medium
    - m3.large
    - m3.xlarge
    - m3.2xlarge
    - m4.large
    - m4.xlarge
    - m4.2xlarge
    - m4.4xlarge
    - m4.10xlarge
    - c1.medium
    - c1.xlarge
    - c3.large
    - c3.xlarge
    - c3.2xlarge
    - c3.4xlarge
    - c3.8xlarge
    - c4.large
    - c4.xlarge
    - c4.2xlarge
    - c4.4xlarge
    - c4.8xlarge
    - g2.2xlarge
    - g2.8xlarge
    - r3.large
    - r3.xlarge
    - r3.2xlarge
    - r3.4xlarge
    - r3.8xlarge
    - i2.xlarge
    - i2.2xlarge
    - i2.4xlarge
    - i2.8xlarge
    - d2.xlarge
    - d2.2xlarge
    - d2.4xlarge
    - d2.8xlarge
    - hi1.4xlarge
    - hs1.8xlarge
    - cr1.8xlarge
    - cc2.8xlarge
    - cg1.4xlarge
    ConstraintDescription: must be a valid EC2 instance type.
    Default: t2.small
    Description: WebServer EC2 instance type
    Type: String
...

WebServer リソース宣言では、次のように、KeyName プロパティが KeyName パラメーターで指定されています。

例 JSON
"WebServer" : {
  "Type": "AWS::EC2::Instance",
  "Properties": {
    "KeyName" : { "Ref" : "KeyName" },
    ...
  }
},
例 YAML
WebServer:
  Type: AWS::EC2::Instance
  Properties:
    KeyName:
      Ref: KeyName
    ...

中括弧には、 KeyName を入力とする Ref 関数への呼び出しが含まれています。Ref 関数は、参照するオブジェクトの値を返します。ここでは、Ref 関数は KeyName プロパティを、スタックの作成時に KeyName に指定された値に設定します。

また、Ref 関数は、リソースのプロパティを別のリソースの値に設定することもできます。たとえば、リソース宣言 WebServer には、以下のプロパティ宣言が含まれています。

例 JSON
"WebServer" : {
  "Type": "AWS::EC2::Instance",
  "Properties": {
    ...
    "SecurityGroups" : [ {"Ref" : "WebServerSecurityGroup"} ],
    ...
  }
},
例 YAML
WebServer:
  Type: AWS::EC2::Instance
  Properties:
    SecurityGroups:
    - Ref: WebServerSecurityGroup
    ...

SecurityGroups プロパティは、EC2 セキュリティグループのリストを受け取ります。Ref 関数は入力として WebServerSecurityGroup(テンプレート内のセキュリティグループの論理名) を受け取り、WebServerSecurityGroup プロパティに SecurityGroups の名前を追加します。

テンプレートには、Mappings セクションもあります。マッピングを使用すると、ルックアップテーブルステートメントと同じように評価される条件値を宣言できます。テンプレートはマッピングを使用して、リージョンの適切な Amazon マシンイメージ (AMI) やインスタンスタイプのアーキテクチャタイプを選択します。[Outputs] (出力) は、aws cloudformation describe-stacks コマンドで返されたり、スタック作成後に CloudFormation コンソールの [Outputs] (出力) タブで返されたりするカスタム値を定義します。出力値を使用すると、スタック内のリソースの情報 (テンプレートで作成したウェブサイトの URL など) を返すことができます。マッピング、出力や、テンプレートに関するその他のことの詳細については、「テンプレートの基礎に関する説明」で説明しています。

ここでは、テンプレートについてはこれで十分です。スタックの作成を始めましょう。

ステップ 2: スタックに必要な項目の準備ができたことの確認

テンプレートからスタックを作成する前に、テンプレートに必要なすべての依存リソースが利用できることを確認する必要があります。テンプレートは、既存の AWS リソースと、テンプレート自体で宣言されたリソースの両方を使用または参照できます。CloudFormation によって、テンプレート内のリソースへの参照が確認され、既存のリソースへの参照についても、スタックを作成するリージョンにリソースが存在していることが確認されます。存在しない依存リソースをテンプレートが参照している場合、スタックの作成は失敗します。

サンプル WordPress テンプレートには、入力パラメータである KeyName が含まれています。このパラメータは、テンプレートで宣言された Amazon EC2 インスタンスに使用されるキーペアを指定します。テンプレートからスタックを作成するユーザーは、KeyName パラメータの有効な Amazon EC2 キーペアを指定する必要があります。有効なキーペア名を指定すると、スタックが正常に作成されます。有効なキーペア名を指定しないと、スタックはロールバックされます。

スタックを作成する前に、有効な Amazon EC2 キーペアがあることを確認し、キーペア名を記録しておきます。

キーペアを表示するには、Amazon EC2 コンソールを開き、ナビゲーションペインで [Key Pairs] (キーペア) を選択します。

注記

Amazon EC2 キーペアがない場合は、スタックを作成するのと同じリージョンでキーペアを作成する必要があります。キーペアの作成については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「Getting an SSH key pair」(SSH キーペアの取得) を参照してください。

有効なキーペアができたので、WordPress テンプレートを使用してスタックを作成しましょう。

ステップ 3: スタックの作成

前に説明した WordPress-1.0.0 ファイルに基づいてスタックを作成します。テンプレートには、EC2 インスタンスなど、いくつかの AWS リソースが含まれています。

WordPress スタックを作成するには

  1. AWS Management Console にサインインし、AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。

  2. [Create Stack] (スタックの作成) を選択します。

  3. [テンプレートを指定] セクションで、[Amazon S3 テンプレート URL] を選択してサンプルテンプレート WordPress の URL を入力または貼り付けた後、[次へ] を選択します。

    https://s3.us-west-2.amazonaws.com/cloudformation-templates-us-west-2/WordPress_Single_Instance.template

    注記

    S3 バケットに保存されている AWS CloudFormation テンプレートは、スタックを作成するユーザーがアクセスできる必要があり、作成されているスタックと同じリージョンに配置されている必要があります。したがって、S3 バケットが us-east-2 リージョンにある場合は、スタックも us-east-2 に作成する必要があります。

  4. [スタックの詳細を指定] セクションでは、[スタックの名前] フィールドに名前を入力します。この例では MyWPTestStack を使用します。スタック名にスペースを含めることはできません。

  5. [パラメータ] セクションでは、[DBUser]、[DBPassword]、[DBRootPassword]、[KeyName] など、デフォルト値を持たないすべてのパラメータの値を指定する必要があります。[KeyName] フィールドに、スタックを作成するのと同じリージョン内の有効な Amazon EC2 ペアの名前を入力します。

  6. [Next] (次へ) をクリックします。

  7. このシナリオでは、タグは追加しません。[Next] (次へ) をクリックします。キーと値のペアであるタグは、スタックの識別に役立ちます。詳細については、「CloudFormation スタックへのタグの追加」をご参照ください。

  8. スタックの情報を確認します。設定が適切であることを確認したら、[Submit (送信)] を選択します。

スタックの作成には数分かかることがありますが、ただぼんやりと座って待っていたくはないでしょう。その場合は、スタックの作成状況を確認することができます。

ステップ 4: スタックの作成状況の監視

[Create Stack] (スタックを作成) のウィザードを完了すると、CloudFormation はテンプレートで指定されているリソースの作成を開始します。新しいスタックである MyWPTestStack が、CloudFormation コンソールの上部のリストに表示されます。そのステータスは、CREATE_IN_PROGRESS である必要があります。スタックの詳細なステータスは、イベントを表示して確認できます。

スタックのイベントを表示するには

  1. CloudFormation コンソールのリストで、スタック MyWPTestStack を選択します。

  2. スタックの詳細ペインで、[Events] (イベント) タブを選択します。

    コンソールは自動的に更新され、60 秒ごとに最新のイベントがイベントリストに表示されます。

[イベント] タブには、スタックの作成の主要な各ステップが、最新のイベントが一番上になるように時間順に表示されます。

最初のイベント (イベントリストの一番下のイベント) は、スタック作成プロセスの開始です。

2013-04-24 18:54 UTC-7 CREATE_IN_PROGRESS AWS::CloudFormation::Stack MyWPTestStack User initiated

続いて、各リソースの作成の開始と終了を示すイベントが表示されます。たとえば、EC2 インスタンスの作成は、次のようなエントリになります。

2013-04-24 18:59 UTC-7 CREATE_COMPLETE AWS::EC2::Instance...

2013-04-24 18:54 UTC-7 CREATE_IN_PROGRESS AWS::EC2::Instance...

CloudFormation がリソースの作成を開始したことがレポートされると、CREATE_IN_PROGRESS イベントが記録されます。リソースが正常に作成されると、CREATE_COMPLETE イベントが記録されます。

CloudFormation によって正常にスタックが作成されると、[Events] (イベント) タブの上部に次のイベントが表示されます。

2013-04-24 19:17 UTC-7 CREATE_COMPLETE AWS::CloudFormation::Stack MyWPTestStack

CloudFormation がリソースを作成できない場合は、CREATE_FAILED イベントがレポートされます。また、デフォルトではスタックがロールバックされて、作成されたリソースがある場合はすべて削除されます。[状況の理由] 列には、失敗の原因となった問題が表示されます。

ステップ 5: スタックリソースの使用

スタック MyWPTestStack のステータスが CREATE_COMPLETE になっていれば、CloudFormation はスタックの作成を完了しており、リソースを使い始めることができます。

サンプル WordPress スタックは、WordPress ウェブサイトを作成します。WordPress インストールスクリプトを実行すると、WordPress の設定を続けることができます。

WordPress のインストールを完了するには

  1. [Outputs] (出力) タブの [WebsiteURL] 行で、[Value] 列のリンクを選択します。

    WebsiteURL 出力値は、スタックで作成した WordPress ウェブサイトのインストールスクリプトの URL です。

  2. WordPress インストールのウェブページで、WordPress の設定を完了するための画面の手順に従います。WordPress のインストールの詳細については、https://wordpress.org/support/article/how-to-install-wordpress/ を参照してください。

    インストールとログインが完了するとダッシュボードが表示されるので、ここで WordPress ブログに追加オプションを設定することができます。その後、CloudFormation テンプレートを使用して、正常に作成されたブログへの投稿を開始できます。

ステップ 6: クリーンアップする

CloudFormation の基本的なタスクを完了しました。不要なサービスに対して課金されていないことを確認するために、スタックとそのリソースを削除して、クリーンアップすることができます。

スタックとそのリソースを削除するには

  1. CloudFormation コンソールから、MyWPTestStack スタックを選択します。

  2. [Delete Stack] を選択します。

  3. 表示された確認メッセージで、[Yes, Delete] (はい、削除します) を選択します。

MyWPTestStack のステータスが DELETE_IN_PROGRESS に変わります。スタックの作成を監視したのと同じ方法で、[イベント] タブを使用して削除を監視できます。CloudFormation がスタックの削除を完了すると、リストからスタックが削除されます。

お疲れ様でした。テンプレートの選択、スタックの作成、リソースの表示と使用、スタックとそのリソースの削除を正常に行うことができました。それだけでなく、CloudFormation テンプレートを使用して WordPress ブログを設定することもできました。その他のテンプレートは、AWS CloudFormation サンプルテンプレートライブラリで見つけることができます。

次は、既存のテンプレートを変更したり独自のテンプレートを作成したりできるように、「テンプレートの基礎に関する説明」でテンプレートについてより詳しく知る必要があります。