最近(今日から)、Elastic BeanstalkのDockerランタイムで遊びはじめている。 公式ドキュメントによれば、公開されたDockerリポジトリからイメージを引っ張ってくるためには、Dockerrun.aws.json ファイル内で、 Docker コンテナを作成するときにベースとなる既存の Docker リポジトリの Docker ベースイメージを指定します。Name キーの値を、Docker Hub のイメージの場合は / 形式、その他のサイトの場合は // 形式で指定します。 とのことである。 Docker Hubでイメージを検索し、例えばghostのイメージだと、 な感じなわけだから、Dockerrun.aws.jsonファイルの記述は例えば { “AWSEBDockerrunVersion”: “1”, “Image” : { “Name” : “ptimof/ghost” }, “Ports” : [{ “ContainerPort”: “2368” }] } でいける。 じゃあ例えばJenkinsさんのオフィシャルイメージ(つまり組織名が明記されていない)場合はどうする？ { “AWSEBDockerrunVersion”: “1”, “Image” : { “Name” : “jenkins” }, “Ports” : [{ “ContainerPort”: “8080” }] }   単純に組織名を省略すればいいのであった。 いろいろいじってみるか。   Docker実践入門――Linuxコンテナ技術の基礎から応用まで (Software Design plus) posted with amazlet at 15.10.29 中井 悦司 技術評論社 売り上げランキング: 3,777 Amazon.co.jpで詳細を見る

  Elastic BeanstalkのCLI管理ツールであるawsebcliだが、インストールすべく公式ページのコマンドを頭から実行していくと、若干つまづく。 https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/eb-cli3-install.html pip install awsebcli を実行すると、 Found existing installation: PyYAML 3.10 DEPRECATION: Uninstalling a distutils installed project (pyyaml) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project. Uninstalling PyYAML-3.10: Exception: Traceback (most recent call last): File “/usr/lib/python2.7/dist-packages/pip/basecommand.py”, line 246, in main status = self.run(options, args) File “/usr/lib/python2.7/dist-packages/pip/commands/install.py”, line 352, in run root=options.root_path, File “/usr/lib/python2.7/dist-packages/pip/req/req_set.py”, line 687, in install requirement.uninstall(auto_confirm=True) File “/usr/lib/python2.7/dist-packages/pip/req/req_install.py”, line 730, in uninstall paths_to_remove.remove(auto_confirm) File “/usr/lib/python2.7/dist-packages/pip/req/req_uninstall.py”, line 126, in remove renames(path, new_path) File “/usr/lib/python2.7/dist-packages/pip/utils/__init__.py”, line 292, in renames shutil.move(old, new) File “/usr/lib64/python2.7/shutil.py”, line 303, in move os.unlink(src) […]

  VPC定義等、様々なシーンで共通的に使用するようなテンプレートを再利用し、CloudFormationのスタックをネストして使用するのはベストプラクティスの１つである。 VPC用のテンプレートを用意した後、AWS::CloudFormation::Stackリソースを使って別テンプレートからVPCのリソースを参照し、VPC上にEC2インスタンスを立ててみる。 この際、表題のエラーにぶちあたったのであった。 AWS::EC2::Instanceの作成のステップのところでエラーとなっている。 The parameter groupName cannot be used with the parameter subnet 色々調べて試行錯誤したが、セキュリティグループの参照を”SecurityGroup”ではなく、”SecurityGroupIds”にしたら通った。 “EC2Instance” : { “Type” : “AWS::EC2::Instance”, “Properties” : { “InstanceType” : { “Ref” : “InstanceType” }, “SecurityGroupIds” : { “Ref” : “InstanceSecurityGroup” }, “KeyName” : { “Ref” : “KeyName” }, “SubnetId” : { “Fn::GetAtt” : [ “CloudFormationVpcStack”, “Outputs.SubnetDmzAzBId” ] }, “ImageId” : { “Fn::FindInMap” : [ “AWSRegionArch2AMI”, { “Ref” : “AWS::Region” }, { “Fn::FindInMap” : [ “AWSInstanceType2Arch”, { “Ref” : “InstanceType” }, “Arch” ] } ] } } }, 他にもいくつかハマったところがあって、VPC上のEC2にEIPを付与する際は、 “AWS::EC2::EIP”にDomainとして明示的に”vpc”を指定しないといけなかった点と、 “AWS::EC2::EIPAssociation”にAllocationIdをプロパティ指定しないといけなかった点を、 1つずつデバッグして潰していった。 “IPAddress” : { “Type” : “AWS::EC2::EIP”, “Properties” : { “Domain” : “vpc” } }, “IPAssoc” : { “Type” : “AWS::EC2::EIPAssociation”, “Properties” […]