インスタンスIDの一覧をPythonのリスト内包表記で取得する

概要

EC2インスタンスのIDの一覧をPythonのリスト内包表記をつかってかんたんに取得してみます。

前提

いずれも以下の様な感じで宣言してあるとする。

import boto3
ec2 = boto3.client('ec2')
response = ec2.describe_instances()

リスト内包表記の場合

こんなかんじでかんたんにできる

instance_id_list  = [response['Instances'][0]['InstanceId'] for response in response['Reservations']]

print(instance_id_list)
# ['i-XXXXXX', 'i-YYYYYY']

リスト内包表記じゃない場合

こんなかんじでループさせて配列のなかに入れあげる必要があった。

instance_id_list = []
for reservations in response['Reservations']:
    instance_id_list.append(reservations['Instances'][0]['InstanceId'])

print(instance_id_list)
# ['i-XXXXXX', 'i-YYYYYY']

おわりに

多少わかりにくいみたいなところはあるけれどね

AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト

特定のタグがついたロールにスイッチロールするIAMポリシー

概要

特定のタグがついたロールにスイッチロールするようなIAMポリシーです。

IAMポリシー

かんたんな説明

このポリシーの場合だと、environmentタグにdevという値が設定されているロールにスイッチロールすることを許可しています。

こんなかんじにタグでスイッチロール許可を与えることで、スイッチロールしたいロールのARNをポリシーに書く必要がなくなります。
なのでスイッチロールしたいロールが増えてもこのポリシーを書き換える必要はなく、スイッチロールしたいロールにタグを付けてあげるだけでよくなります。

おわりに

ひさびさに書いた

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

AnsibleでIAMポリシーを作成する

概要

Ansibleを利用してIAMポリシーを作成してみたいと思います。

playbook

playbookとそれでつかうJSONはこんなかんじ。

JSONに記載したポリシーのとおりにIAMポリシーが作成されます。

実行結果確認

ポリシーができている。

$ aws iam list-policies --query 'Policies[].PolicyName' | grep admin_policy
    "admin_policy", 

なかみもplaybookで指定したJSONとおなじであることがわかる。

$ aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/admin_policy --version-id v1
{
    "PolicyVersion": {
        "CreateDate": "2019-03-05T14:31:43Z", 
        "VersionId": "v1", 
        "Document": {
            "Version": "2012-10-17", 
            "Statement": [
                {
                    "Action": "*", 
                    "Resource": "*", 
                    "Effect": "Allow"
                }
            ]
        }, 
        "IsDefaultVersion": true
    }
}

おわりに

まあべんりよね。

Ansible実践ガイド第2版 impress top gearシリーズ

AWSのEC2のLinuxにssh接続するときのユーザ名まとめ

AWSのEC2のLinuxにssh接続するときのユーザ名をまとめてみた。

まとめ

こんなかんじ。

ディストリビューション	ユーザ名
Amazon Linux	ec2-user
CentOS	centos
Debian	admin または root
Fedora	ec2-user または fedora
RHEL	ec2-user または root
SUSE	ec2-user または root
Ubuntu	ubuntu

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 徹底攻略シリーズ

CloudFormationで作ったインスタンスを削除したときにEBSがそのまま残ることがある

CloudFormationで作成したインスタンスにアタッチされていたEBSが削除されずにそのまま残ってしまうことがあります。
その対処法です。

template

これの15行目みたいなかんじでDeleteOnTermination: Trueを設定してあげる。

おわりに

わすれがち。

クラウドエンジニア養成読本［クラウドを武器にするための知識＆実例満載！］ Software Design plus

EFSを作成してEC2のCentOSでマウントする(EFSマウントヘルパーつかわない)

EFSを作成して、EC2インスタンスのCentOSでマウントしてみたいと思います。
(EFSマウントヘルパーはつかわないバージョンです。)

手順

EFS用のセキュリティグループをつくる

まずEFSにアタッチするためのセキュリティグループを作成します。
インバウンドの2049ポートを開放してあげます。

EFSを作成する

マネジメントコンソールのEFSのファイルシステムの作成から、EFSの作成を開始します。

先ほど作成したセキュリティグループを選び、次のステップへすすみます。

適当に名前だけつけてあげて次のステップへすすみます。

内容を確認して、ファイルシステムを作成します。

EFSが無事にできあがりました。

CentOSにNFSクライアントをインストールする

EC2インスタンス上のCentOSにssh接続し、以下のコマンドを実行します。

$ sudo yum install -y nfs-utils

マウントポイントとしてディレクトリをつくっておきます。

$ sudo /mnt/efs

以下コマンドを実行してマウントします。
fs-XXXXXXXXの部分は作成したEFSのIDに書き換えてあげてください

$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-XXXXXXXX.efs.ap-northeast-1.amazonaws.com:/ /mnt/efs

無事にマウントできました！！！！
最後の8エクサバイトのやつです。

$ df -h
Filesystem                                      Size  Used Avail Use% Mounted on
/dev/xvda1                                      8.0G  937M  7.1G  12% /
devtmpfs                                        473M     0  473M   0% /dev
tmpfs                                           495M     0  495M   0% /dev/shm
tmpfs                                           495M   13M  482M   3% /run
tmpfs                                           495M     0  495M   0% /sys/fs/cgroup
tmpfs                                            99M     0   99M   0% /run/user/1000
fs-XXXXXXXX.efs.ap-northeast-1.amazonaws.com:/  8.0E     0  8.0E   0% /mnt/efs

おわりに

今回はEFSマウントヘルパーをつかわないバージョンでした。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 徹底攻略シリーズ

CloudFormationでAn error occurred (InsufficientCapabilitiesException)が出たときの対処法

AWSCLIでCloudFormationのスタックを作成またはアップデートしようとしたときにこんなかんじのエラーがでた。

An error occurred (InsufficientCapabilitiesException) when calling the CreateStack operation: Requires capabilities : [CAPABILITY_NAMED_IAM]

こんなかんじで--capabilities CAPABILITY_NAMED_IAMを指定してあげれば良い。

$ aws cloudformation create-stack --stack-name kabegiwa-stack --template-url https://s3-ap-northeast-1.amazonaws.com/kabegiwa-bucket/wawawa.yml --capabilities CAPABILITY_NAMED_IAM

IAMリソースが作成されますけどいいですか？っていう確認のやつ。
よければ実行してしまおう。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書 徹底攻略シリーズ

CloudFormationでDependencyViolationが出たときの対処法

CloudFormationでもう使わないスタックを削除しようとしたらこんなかんじのエラーがでて、セキュリティグループが削除できなかった。

resource sg-XXXXXXXX has a dependent object (Service: AmazonEC2; Status Code: 400; DependencyViolation; Request ID: XXXXXXXXXX)

原因としてはCloudFormationで作成したセキュリティグループを手動で他のリソースにアタッチしたりすると発生する可能性がある。
そのリソースと依存関係になって削除できなくなっちゃたりとか。

消せないセキュリティグループをデタッチしてあげればこのエラーも解消される。

AWSによるサーバーレスアーキテクチャ

CodePipelineでGitHub上のコードをS3にデプロイする

概要

CodePipelineを利用してGitHub上のコードをS3にデプロイしてみたいと思います。

やりたいことはだいたい以下のようなかんじ。

手順

こんなかんじでできます。

マネジメントコンソールのCodePipelineから「パイプラインの作成」を選択します。

適当にパイプライン名をつけてあげて「次へ」を選択します。

ソースプロバイダをGitHubにし、「GitHubに接続」します。

新たにウインドウが立ち上がるので「Authorize aws-codesuite」を選択してAWSとGitHubを接続してあげます。

デプロイしたいリポジトリとブランチをえらんで「次へ」を選択します。

今回はビルドは行わないのでスキップします。
「ビルドステージのスキップ」を選択します。スキップしますか？みたいな確認メッセージが出ますが、かまわずスキップします。

デプロイプロバイダにS3を選択し、デプロイしたいバケットを選びます。
また、「デプロイする前にファイルを展開する」にチェックを入れておきます。これにチェックをしておかないと、リポジトリの中身がzip圧縮されてS3にデプロイされます。
えらんだら「次へ」を選択します。

内容に間違いがないことを確認して「パイプラインを作成」します。

作成が完了すると自動でデプロイが開始されます。
GitHubからS3にデプロイが行われたようです。
以後、このリポジトリにPushされるたびに自動でS3にデプロイしてくれます。

S3を見に行くと、デプロイされていることがわかります。

ちなみにつかったリポジトリはこれ。

GitHub - takakabe/blog_python

おわりに

べんりよねー

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する (DEV Engineer’s Books)

CloudFormationでIAMロールアタッチしたEC2インスタンスを作成する

概要

CloudFormationを利用してIAMロールをアタッチした状態のEC2インスタンスを構築してみたいと思います。

template

CloudFormationのテンプレートはこんなかんじ。

ちょっとした説明

マネジメントコンソールをポチポチしているとなにも意識しませんが、EC2インスタンスに紐付けられるのはIAMロールではなく、インスタンスプロファイルです。

おわりに

たまにハマる。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

Cannot delete entity, must detach all policies firstの対処法

CloudFormation Stackを削除しようと思ったらこんなかんじのエラーがでてスタックが削除されなくなった。(DELETE_FAILEDになった)

のでその対処法です。

Cannot delete entity, must detach all policies first. (Service: AmazonIdentityManagement; Status Code: 409; Error Code: DeleteConflict; Request ID: d1eaf41d-2aa)

原因

CloudFormationのIAMロールの内容と、実際のIAMロールの内容がちがうときにこのエラーがでます。

CloudFormationで作成したあとにマネジメントコンソールで新たにIAMポリシーをアタッチするとか。

対処法

手作業で追加したであろうポリシーをマネジメントコンソールかなにかでデタッチしてあげる。
そうすればOK！！！！！！

おわりに

書いてあることそのままだけどね。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

Ansibleでgoofysをインストールする

概要

AnsibleでgoofysをインストールするPlaybookを書いた。

playbook

こんなかんじ。

おわりに

epel-releaseとfuse,golangを分けたのはなんかそうしないとうまくいかなかったんだよね。

Ansible実践ガイド 第2版 (impress top gear)

CentOS7にgoofysをインストールしてS3をマウントしてみる

概要

CentOS7にS3をマウントできるツールであるgoofysをインストールして、S3バケットをマウントしてみたいと思います。

インストール手順

epelリポジトリを追加する

$ sudo yum install epel-release

fuseをインストールする

$ sudo yum install fuse

goをインストールする

$ sudo yum install golang

GitHubからgoofysをもってくる
(ちょっとじかんかかります)

$ go get github.com/kahing/goofys

goofysをインストールする
(ちょっとじかんかかります)

$ go install github.com/kahing/goofys

無事にgoofysがインストールできました！

$ ls -l ~/go/bin/goofys 
-rwxrwxr-x. 1 vagrant vagrant 15201906 Feb  5 12:00 /home/vagrant/go/bin/goofys

goofysでS3をマウントする

マウントする場所用にディレクトリをつくります。

$ mkdir kabegiwa-bucket

goofysでS3バケットをマウントします。
goofys バケット名 マウント先です。

$ ~/go/bin/goofys kabegiwa-bucket ./kabegiwa-bucket/

無事にマウントできました！！！

$ df -h | grep kabegiwa
kabegiwa-bucket  1.0P     0  1.0P   0% /home/vagrant/kabegiwa-bucket

バケットの中身をいじることもできます

$ ls -l kabegiwa-bucket/
total 1
-rw-r--r--. 1 vagrant vagrant 6 Feb  5 11:53 wawawa.txt

おわりに

べんりだよね。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

CloudFormationでセキュリティグループとそれをアタッチしたインスタンスをつくる

こんなかんじでつくれます。

セキュリティグループの指定のところで!RefをつかってあげるとそのリソースID(sg-xxxxxxみたいなやつ)がわたされます。

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書

CloudFormationでセキュリティグループをつくる

こんなかんじでつくれる。

SecurityGroupIngressがインバウンドでSecurityGroupEgressがアウトバウンド

徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書