“ChefがキライでもOpsWorksはキライにならないでくださいっ!!” カスタムAMIとAWS OpsWorksの使い方：AWS OpsWorksアプリケーション運用の勘所（3）（3/3 ページ）

» 2013年08月06日 17時38分公開

アプリケーションのデプロイ

　ちょっとデプロイしてみましょう。その前にインスタンスを起動する必要があるので、start-stackでstack内のインスタンスをすべて起動しておきます。

$ aws opsworks start-stack --stack-id 6c03c68c-46d7-4cb6-bc03-b1dc8b9e0010

インスタンスが起動する前にデプロイしようとすると

$ aws opsworks create-deployment 
--app-id c5048f90-f0b5-4fbc-91b4-0afe773ec733 \
--stack-id 6c03c68c-46d7-4cb6-bc03-b1dc8b9e0010  \
--command " { \"name\":\"deploy\"}" 
{
    "Errors": [
        {
            "Message": "", 
            "Code": "ValidationException", 
            "Type": "ValidationException"
        }
    ]
}

　といったエラーが出ます。何かしらメッセージを出してくれてもいいのに、と思うのですが、ただ「ValidationException」とだけ出ます。インスタンスが立ち上がっているかの確認をして、立ち上がったらもう一度実行しましょう。インスタンスの確認は以下のようにできます。

$ aws opsworks describe-instances  --instance-ids 8e1340cc-f529-4c89-87c0-eeb24c33b605
{
    "Instances": [
        {
            "PrivateDns": "ip-10-148-5-178.ap-northeast-1.compute.internal", 
            "StackId": "6c03c68c-46d7-4cb6-bc03-b1dc8b9e0010", 
            "SshHostRsaKeyFingerprint": "77:5e:1d:80:75:5e:55:8b:49:e6:03:05:38:34:65:56", 
            "SshHostDsaKeyFingerprint": "a3:05:d6:00:2d:92:c5:09:c6:5f:18:d1:c7:7c:25:0d", 
            "Status": "setup_failed", 
            "InstanceId": "8e1340cc-f529-4c89-87c0-eeb24c33b605", 
            "SshKeyName": "id_rsa", 
            "RootDeviceVolumeId": "vol-c29321e7", 
            "InstanceProfileArn": "arn:aws:iam::038072554641:instance-profile/aws-opsworks-ec2-role", 
            "InstanceType": "t1.micro", 
            "CreatedAt": "2013-08-05T22:55:30+00:00", 
            "AmiId": "ami-173fbf16", 
            "Hostname": "1", 
            "Ec2InstanceId": "i-ac737aa9", 
            "PublicDns": "ec2-54-249-159-230.ap-northeast-1.compute.amazonaws.com", 
            "SecurityGroupIds": [
                "sg-efe3a3ee", 
                "sg-7f77017e", 
                "sg-8d77018c"
            ], 
            "Architecture": "x86_64", 
            "RootDeviceType": "ebs", 
            "Os": "Amazon Linux", 
            "AvailabilityZone": "ap-northeast-1a", 
            "PrivateIp": "10.148.5.178", 
            "PublicIp": "54.249.159.230", 
            "LayerIds": [
                "65dcd8f3-f642-473b-bc4d-08449a7c32a9"
            ]
        }
    ]
}

　もし、インスタンスのセットアップに失敗していると、Statusが「setup_failed」などになっているので、ログなどを確認して問題点を修正し、再度立ち上げます。失敗さえしなければ、非常にあっさりとしたものです。

$ aws opsworks create-deployment --app-id c5048f90-f0b5-4fbc-91b4-0afe773ec733 --stack-id 6c03c68c-46d7-4cb6-bc03-b1dc8b9e0010  --command " { \"name\":\"deploy\"}"
{
    "DeploymentId": "710077c7-04f5-4892-adb0-4fc63a8d953b"
}

　このデプロイの進捗状況は下のように確認することができます。

$ aws opsworks describe-deployments --deployment-ids 6dac090b-d304-4786-82ca-5efea909017a
{
    "Deployments": [
        {
            "StackId": "6c03c68c-46d7-4cb6-bc03-b1dc8b9e0010", 
            "Status": "successful", 
            "CompletedAt": "2013-08-06T01:06:25+00:00", 
            "IamUserArn": "arn:aws:iam::038072554641:user/tempuse", 
            "DeploymentId": "6dac090b-d304-4786-82ca-5efea909017a", 
            "Command": {
                "Args": {}, 
                "Name": "deploy"
            }, 
            "InstanceIds": [
                "8e1340cc-f529-4c89-87c0-eeb24c33b605"
            ], 
            "AppId": "c5048f90-f0b5-4fbc-91b4-0afe773ec733", 
            "Duration": 54, 
            "CreatedAt": "2013-08-06T01:05:31+00:00"
        }
    ]
}

　Statusが「Success」になっていれば　デプロイは完了です。文章にすると長くなってしまいますが、作業自体はものすごく簡単です。

git pushしたら全プロセスで自動デプロイが可能に！

　これができるということは……？

　そう、自動デプロイが可能になるんです。自動デプロイができるというよりも、人間にデプロイさせなくて済むということができます。なんて素敵なんでしょう！

　例えば、Jenkinsを使って、ユニットテストが終わったら、テスト環境にデプロイし、結合テストを行って、それもOKならば、すぐ本番環境にデプロイなんていうことが、開発者からすると、git pushだけでできてしまうんです。たまらないですね。

カスタムAMIの実力：構築はAMI、デプロイはOpsWorksで自動化

　今まで、OpsWorks環境では、Chefを使う前提だったこともあり、これを期にChefを学んだ方もいらっしゃるかと思いますが、一方で、それが要因でOpsWorksを「見て見ぬふり」してきた人の方が大多数なのではないでしょうか。今までの前提環境では、Chefが使えなければ余計な学習コストが増えるだけだったのですから。

　しかし、2013年7月24日のリリースで、ついにカスタムAMI――そうオリジナルのAMIを使ったインスタンスを立ち上げることができるようになりました。これは素晴らしいです。何が素晴らしいかというと、環境構築はAMIで行い、アプリケーションのデプロイはOpsWorksに任せるといったことができるようになったのです。

　「構成はAMIでできているんだけど、デプロイだけでもいいから自動化したい！」そんな夢が叶うようになったのです。

　単なるWebアプリケーションならBeanstalkでも十分かもしれませんが、そういうワケにもいかない要件であることがほとんどでしょう。そんなときに、カスタムAMIを作るのです。

　カスタムAMIの作り方はここに書いてある通り、EC2から作成するか、OpsWorksで立ち上がったインスタンスから作る方法があるようです。

　OpsWorksで立ち上げたインスタンスであれば、リポジトリからどこにファイルが置かれるかなど確認できると思うので、それにあわせてシンボリックリンクを張るなりすればよいので、OpsWorksで立ち上げてやる方が簡単そうに思いました。

　このカスタムAMIでインスタンスを立ち上げれば、構成はいままでの知識で作ることができ、一方で手間のかかる複数サーバへのデプロイはOpsWorksが実行してくれるようになります。

　ただ、非常に残念なことにまだCLIツールではカスタムAMIは使えません。仕方ないので、Management Consoleで用意することになります（面倒ですね）。早くCLIツールが対応することが望まれます。

　Management Consoleで作る場合はインスタンスを作るところで、OSにuse Custom AMIを選択し、AMIを指定すればカスタムAMIで始められるようになります。