NATゲートウェイの設定 / AWSのプライベートサブネットから、インターネットに接続する

◆ 今日やること

AWSのプライベートサブネットから、インターネットに接続する場合、NATゲートウェイが必要です。
プライベートサブネットに配置したEC2インスタンスからyum installとか実行する時に必要ですよね。

NATゲートウェイの設定がないと、インターネットに出て行けません。


$ sudo yum install -y mongodb-org
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest                                                                          | 2.1 kB     00:00
amzn-updates/latest                                                                       | 2.3 kB     00:00
https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: (28, 'Connection timed out after 30000 milliseconds')
Trying other mirror.

failure: repodata/repomd.xml from mongodb-org-3.2: [Errno 256] No more mirrors to try.

◆ 実装編

> NATゲートウェイの作成

サブネットの選択は、Publicサブネットにしましょう

NATゲートウェイの作成.png

> ルートテーブルの設定をします

0.0.0.0/0の送信先ターゲットを上記で作成したNATテーブルに変更します。

ルートテーブル.png

> 確認

AWSのプライベートサブネットから、インターネットに接続できるようになったかと思います。
以下を実行して、インストールが完了すればOKです。


$ sudo yum install -y mongodb-org

続きを読む

AWS EC2にMongoDBインストールとレプリケーション設定

MongoDBインストールとレプリケーション設定について、簡易的な抜粋メモとして書いています。
詳細に関しては、記事の最後の参考サイトを確認するようにしてください。

◆ 今日やること

  • MongoDBをEC2にインストール
  • レプリケーションの設定と確認
    • 今回せっていするレプリケーションの形式は、以下の図の通り、「Primary with Secondary Members」です。

mongorepl.png
引用元:Replication — MongoDB Manual 3.4

◆ バージョン

  • MongoDB 3.2
  • Linux 4.4.30-32.54.amzn1.x86_64 #1 SMP Thu Nov 10 15:52:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

◆ 実装編

> EC2へのインストール

sudo yum update -y
sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc
sudo yum install -y mongodb-org
sudo service mongod start

sudo chkconfig mongod on

> 設定周り

  • WoredTigerストレージエンジンの主な設定

    • cacheSizeGB: システムメモリの6、7割
    • blockCompressor:デフォルトはsnappy(中間です)
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
       cacheSizeGB: 1
       journalCompressor: snappy
    collectionConfig:
       blockCompressor: snappy

> EBSボリュームをAttach

  • EBSボリュームにmongoのデータを溜めるようにする。

Amazon EBS ボリュームを使用できるようにする – Amazon Elastic Compute Cloudに従って、EBSボリュームをアタッチする

  • パーミッションを変更するのを忘れないように。
sudo chown -R mongod:mongod /data
  • /etc/mongod.conf
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data

> レプリケーションの設定

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。
MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

  • ネットワークインターフェイスの設定で、レプリケーションを組むサーバのIPを記述しておくこと

レプリケーション設定前には、お互いに通信できることを確認しないといけません
Troubleshoot Replica Sets — MongoDB Manual 3.4

mongodb が listen するIPアドレスはデフォルトでは 127.0.0.1 に設定されており、ローカルからのみアクセスを許可するようになっています
mongod.conf の bind_ip に設定されたIPアドレスで listen するのでこれを変更することで外部からの接続を許可します
ここに 0.0.0.0 を設定すると全てのIPアドレスからの接続を許可します

/etc/mongod.conf
# network interfaces
net:
  port: 27017
  bindIp: [127.0.0.1,10.1.52.111,10.1.51.227,10.1.51.68]


  • レプリケーション名を決める
  • Oplogのサイジングと設定サイズを決める
/etc/mongod.conf
replication:
   oplogSizeMB: 500
   replSetName: testRepl

第4回 MongoDBのレプリケーションを構築してみよう:MongoDBでゆるふわDB体験|gihyo.jp … 技術評論社

OplogはCapped Collectionなので,作成時以外にサイズ変更することができません。 デフォルトのOplogのサイズは「1GBまたは,ディスクの空き領域の5%」
Staleを避けるために,Oplogのサイジングは非常に重要となります。
Oplogのサイズは,mongodの初回起動時にoplogSizeオプションで変更可能です。
Oplogの適切なサイズを見積もる方法のひとつに,本番を想定した書き込みテストを実施し,作成されたOplogのサイズを取得する方法があります。
1時間程度,本番想定と同程度の書き込みテストを行った後,以下のコマンドでレプリケーションの最新情報を取得します。

> db.getReplicationInfo()

1時間で作成されたOplogのサイズがわかれば,Oplogのサイジングの目安となります。
少なくとも8時間のセカンダリのダウンタイムに耐えられるようにしておくことが推奨されています。

  • レプリケーションの設定

どれかのサーバに入って、以下のコマンドを実行

config = {
  _id : "testRepl",
  members : [
    { _id : 0, host : "10.1.51.227:27017" },
    { _id : 1, host : "10.1.51.68:27017" },
    { _id : 2, host : "10.1.52.111:27017"} ] }

rs.initiate(config)
  • スレーブの読み取り専用動作設定

そのままだと、スレーブが読み取り専用としてアクセスできないので以下の設定を行っておく。

スレーブノードで、以下のコマンドを実行

 db.getMongo().setSlaveOk()
  • レプリケーションステータスの確認
testRepl:PRIMARY> rs.status();
{
    "set" : "connobaRepl",
    "date" : ISODate("2017-01-12T07:03:05.556Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "members" : [
        {
            "_id" : 0,
            "name" : "10.1.51.227:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 100310,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "electionTime" : Timestamp(1484104344, 1),
            "electionDate" : ISODate("2017-01-11T03:12:24Z"),
            "configVersion" : 3,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "10.1.51.68:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 100245,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:04.017Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:04.020Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        },
        {
            "_id" : 2,
            "name" : "10.1.52.47:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 99751,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:05.025Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:05.022Z"),
            "pingMs" : NumberLong(2),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        }
    ],
    "ok" : 1
}

> mongoログインの時の警告メッセージを消す方法

[ec2-user@ip-10-1-52-47 ~]$ mongo
MongoDB shell version: 3.2.11
connecting to: test
Server has startup warnings:
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
testRepl:SECONDARY>

◆ 参考サイト

続きを読む

S3を使って独自ドメインで、「安く」HTTPS通信してBasic認証させたい

いろんな要求が来る年の瀬です。2016年も、もうすぐ終わりですね。

今日のお悩み

  • 公開ドキュメントはS3におきたい。
  • 独自ドメインでhttps通信したいが、cloudfrontは高いので安い方法で
  • Basic認証するサイトとかあるから、それも実現させて欲しい

はて、そんなことできるのかな。

解決

今回は以下の構成で実現させました。

Route53 -> ALB -> EC2(Nginx) -> S3

  • サイトの内容はS3においておきます。
  • EC2のマイクロインスタンスかナノインスタンスを立てて、Nginxをインストールしてリバースプロキシを設定します。
  • ALBはドメイン毎に作成します。紐付け予定の証明書はここで紐付けします。(ACM)
  • Route53でドメインとALBを紐付けします

参考サイト

とはいえ、いろんな方法があるかと思います。
今回、実装するにあたって、いろいろな記事を参考にしました。
その上で予算や今後の運用に合わせて選ぶのがベストだと思います。

手順

> S3でサイトの公開準備

> EC2にNginxを設定する

  • Nginxのインストール
sudo yum update
sudo yum install -y nginx
sudo chkconfig nginx on
sudo /etc/init.d/nginx start
  • Basic認証用のパスワードファイルの作成
sudo htpasswd -cb .htpasswd_test <User> <PassWord>
  • confファイルの設定

    • Basic認証ありの場合

      • Basic認証用のパスワードファイルのパスを設定します。

server {
  listen       80;
  server_name  test.example.net;
  location / {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd_test;
    proxy_pass test.example.net.s3-website-ap-northeast-1.amazonaws.com/;
  }
}
  • Basic認証なしの場合

server {
  listen       80;
  server_name  static.example.com;
  location / {
    proxy_pass static.example.com.s3-website-ap-northeast-1.amazonaws.com/;
  }
}

> ALBの設定

  • ターゲットグループを作成します

    • 上記で作成したEC2インスタンスを登録します
    • ヘルスチェックは80/HTTP
  • ロードバランサを作成します
    • リスナーは443/HTTPS
    • この時に取得済みのサーバ証明書を設定します。
    • 上記で作成したターゲットグループを設定します。

> Route53の設定

紐付けしたいドメインに対して、上記で作成したALBを設定します。

route53.png

> 確認

それぞれアクセスしてみます。
OKですね!

続きを読む

Route 53 でS3のエンドポイントを選択しようとしても「No Targets Available」ターゲットがありません と出てしまう

▪️ 本日のお悩み

Route 53 でS3のエンドポイントを選択しようとしても「No Targets Available」ターゲットがありません と出てしまう
(S3での公開のための設定は問題なく終了済み)

Route53

▪️ 結果

1時間くらいしたら、ターゲットが出てきた・・・。時間の問題だったのか。。というところで落ち着きました。

> 焦って色々調べました

Amazonには上記のようになった場合のトラブルシュートが書かれています。

既に作成しているオブジェクトが [Alias Target] リストに表示されない場合は、[Alias Target] リストに適切な名前を手動で入力します。

ウェブサイトエンドポイントとして設定されている Amazon S3 バケット – Amazon S3 ウェブサイトエンドポイントのドメイン名を以下の形式で入力します。
s3-website-region.amazonaws.com
region 値は、バケットがホストされている Amazon S3 リージョンを表します (たとえば、us-east-1)。

▪️ S3をWebホストとして公開する手順

> ポイント

この手順についてはたくさんのっています。のでそちらを参考に。

ちょっとはまるかなと思ったポイントだけ。

  • バケットポリシーの付与

    • Principalの値は「*」
    • Actionは「s3:GetObject」
    • Resourceは「arn:aws:s3:::{自分がつけたs3バゲット名}/」で「/」を忘れないように!
{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"AddPerm",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::example.com/*"
      ]
    }
  ]
}

▪️ 静的コンテンツ配信パターン

この解説が一番役に立ちました。

cloudfrontは独自ドメインのSSLで使うとなると高いので料金表に注意です。

続きを読む

ECSからcloudwatchにながしたログをtailでみたい

1.png初学者向け
ECSことはじめ中に出会って、調べて活用したことを書いています。

今回のお悩み

AWS Solutions Architect ブログ: Amaozn ECSがawslogs Logging Driver(Amazon CloudWatch Logs)に対応しました

awslogsというLogging DriverをECSでタスク定義をした際に使えば、Dockerコンテナでログとして残しておきたい内容をstdout/stderrに吐き出す様にしておくだけで、自動的にCloudWatch Logsに保存されていきます。

便利!
と思ったんですが、cloudwatchログのロググループに蓄積されたストリームを見て、絶望します。

あれ?これファイル一つづつクリックするんですか?
これ、tailで見たいのですが、と言うお悩みです。

cloudwatch-log

無理です

> awslogsで解決

自分のマシンにawslogsをインストールしましょう!pipで簡単に導入可能です。

pip install awslogs

tailしたい場合はオプションつけてこんな感じで、みたいロググループのログを見ることができます。

awslogs get {ロググループ名} --watch
20:42:19 ~/  $ awslogs get api-logs -w -G --timestamp
6bdd60a3ac787a11fc07db4d8f549c3590f997ebba3aa52b458a1e9acb81c109 2016-12-17T11:41:14.662Z npm info it worked if it ends with ok
6bdd60a3ac787a11fc07db4d8f549c3590f997ebba3aa52b458a1e9acb81c109 2016-12-17T11:41:14.663Z npm info using npm@2.14.12
6bdd60a3ac787a11fc07db4d8f549c3590f997ebba3aa52b458a1e9acb81c109 2016-12-17T11:41:14.663Z npm info using node@v4.3.1
6bdd60a3ac787a11fc07db4d8f549c3590f997ebba3aa52b458a1e9acb81c109 2016-12-17T11:41:15.045Z npm info prestart api@0.0.0
6bdd60a3ac787a11fc07db4d8f549c3590f997ebba3aa52b458a1e9acb81c109 2016-12-17T11:41:15.051Z npm info start api@0.0.0
  • -w/–watch オプション

    • いわゆるtailです
  • -G/–no-group オプション
    • グループ名を非表示に
  • –timestampオプション
    • イベントが発生した時間を表示します

私は上記のような形で使っていますが、次に紹介するリンクではもっと詳しい使い方が載っているので、参考にしてください!

>> インストールや使い方

こちらに詳しく載っています。

>> 事前にcredentialやプロファイルの設定はしておこう

さて、あなたが実行したい環境はどの環境に対してですか?
自分の実験環境なのか、お客さんAなのかBなのか、ターミナルを開いたら、以下で確認しておきましょう。

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                 bohelabo           manual    --profile
access_key     ****************TTVQ shared-credentials-file
secret_key     ****************TTfQ shared-credentials-file
    region                us-east-1      config-file    ~/.aws/config

私は、.bashrcで主に使う環境はセットしています。ただし、コマンド実行前には必ず確認が必要!

export AWS_DEFAULT_PROFILE=bohelabo

ECSからcloudwatchにログを流す設定方法

そもそもECSからcloudwatchにログを流す設定方法についてってどうするんですか?という追加解説。

> ECS->タスク定義作成->ログ設定

タスク定義の作成のログ設定のところで、そのタスクと紐付けるログをどこに流すかを設定します。

awslogs

  • awslogs-group

    • cloudwatchログのログググループ名。これは事前に、cloudwatch側で作成しておきましょう。タスク実行時にないとエラーになってしまいます
  • awslogs-region

    • 使っているリージョンを指定します
  • awslogs-stream-prefix

    • ストリームにプリフィックスをつけることができます。これを設定すると、ストリームの名称は以下のようになります。スクリーコンテナの名前とプリフィックスにつける名前を工夫すると、フィルタリング等にお役立ちになりそうです
prefix-name/container-name/ecs-task-id

> cloudwatchログ

上記のような設定で、ECSのサービスを実行すると、以下のようなログストリームが作成されます。

cloudwatch-logs

>>> 参考サイト

続きを読む

AWSと出会って過ごした2016年

dots.女子部 Advent Calendar 2016の15日目担当のぼへぼへです。
@sao_rio さん、漫画を読んでいただいていて、ありがとうございます!

さて、アドベントカレンダー何書こうかと迷って、今年のまとめとして、初めてAWSを仕事で使う機会ができて、いろいろと経験したことのTIPSをまとめてみました。

年の初め

JAWS-UG CLI専門支部との出会い

JAWS-CLI.jpeg

いきなりCLIですが・・・・
この頃フリーランスとして、コワーキングスペース茅場町Co-Edoを利用していて、ここで、隔週月曜にJAWS-UG CLI専門支部が開催されていました。
そこで、たまたま夜の時間までいたので、試しに出てみようかな、と思って出たのがきっかけでした。

この専門支部では、AWSのサービスの一つを取り上げて、その概要の説明後は、みんなでハンズオンという形式。Qiitaに毎回、細かいハンズオンの説明が載っていて、(これがすごい詳細で分かりやすい!)それをひたすらコピーペーストで実行します。

え?それだけ?って思うことなかれ。

習うより、慣れろ。

という部分を強化してくれます。そして、GUIでは見えない、サービスの設定値をCLIで見ることによって、より理解が深まります。
私は、最初はGUI中心だったのですが、この設定はどうなっているのだろう?とか思ったりした場合はCLIで参照することで、すんなりとできるようになりました。

この勉強会に数回出ているうちに、CLIで操作する一連の流れに慣れてくるので、ターミナル操作がそもそも苦手だな、と思っている人も積極的に出てみて、まずは慣れるところから始めるのにオススメです。

毎回扱うサービスも変わりますし、時にAWSのSAさんが概要説明に来てくれたりという贅沢な勉強会でもあります。

開催予定イベントリスト – JAWS-UG CLI専門支部 | Doorkeeper

docker-machineとして使っていたEC2

さて、AWS使い始めといえばEC2インスタンスですが、最初はEC2じゃなくてもいいじゃんという使い方をしていました。
そう、docker-machineです。

以下のようなシェルを準備しておいて

docker-create-virgina.sh
#!/bin/bash

if [ $# -ne 2 ]; then
    echo "docker-create-virgina instance-type name" 1>&2
    exit 1
fi

docker-machine create --driver amazonec2 
    --amazonec2-access-key XXXXXXXXXX --amazonec2-secret-key XXXXXXXXXXX 
    --amazonec2-security-group docker-machine 
    --amazonec2-vpc-id vpc-fXXXXXXX 
    --amazonec2-subnet-id subnet-XXXXXXXX 
    --amazonec2-region us-east-1 
    --amazonec2-zone b 
    --amazonec2-instance-type $1 
    $2

ターミナルから実行して、docker-machineを稼動させて、開発環境として使っていました。

./docker-create-virgina.sh {instance-type}  {name}

長いコマンドはシェルにしておくと便利ですよね。

Qiitaに手順を残してありました。
Docker環境をEC2でアップして開発環境をつくる – Qiita

思ったように仕事も取れず、今やっている仕事なくなったら、フリーランスという名のニートですよね、と思いつつ過ごす切ない春でした。

まずはネットワーク

Amazonには、もともとデフォルトVPCが用意されていますが、実際にサービスを構築する際には、セキュリティやアクセス経路を考えなくてはいけません。

VPCを用いる事でネットワークをプライベートに作成したり、IPアドレス等でのアクセス制限やプロトコルの制御等、セキュリティ上の要件をまとめて設定する事が可能です。

コラム – 知っておきたい Amazon Web Services のキホン | 第2回 AWSの仮想データセンタ「VPC」を理解する|CTC教育サービス 研修/トレーニング

でも、一体どういう手順で構築すれば・・・という時は、「Amazon Web Services パターン別構築・運用ガイド  一番大切な知識と技術が身につく」という書籍がとても参考になりました。
ここで「Chapter2-4 VPCネットワークの作成」、「Chapter3-1 EC2を利用した動的サイトの構築」に一通り以下の手順があるので、一度手を動かしてみると、なるほど!と理解できます。

  • VPCの作成
  • パブリックサブネットとプライベートサブネットの作成
  • インターネットゲートウェイの作成
  • ルートテーブルの作成

私の例

10.1.0.0/16でVPCを作成して、サブネットを以下のように組みました。
リージョンは東京です。アベイラビリティゾーンも分けて、どちらかがダウンしても大丈夫なようにしています。

Subnet Name AZ kind
PublicSubnetA 10.1.11.0/24 1a DMZ
PublicSubnetB 10.1.12.0/24 1c DMZ
PrivateSubnetA 10.1.51.0/24 1a Private
PrivateSubnetB 10.1.52.0/24 1c Private

NATゲートウェイ・・・

プライベートサブネットにした場合、プライベートサブネット内はインターネットには接続していないゆえ、一つ困ったことが起きました。
当然といえば、当然なんですが、yum installができない、とかです。
インターネットから、入ってきてほしくはないけど、インターネットにとりにいかなきゃいけないのでNATゲートウェイを設置してあげましょう。

ちなみに、NAT ゲートウェイを作成するには、NAT ゲートウェイの常駐先のパブリックサブネットが必要となります。というか、NATゲートウェイはパブリックサブネットに立てましょう。(プライベートに作ってしまってハマった人)

初夏とともに起業

AWSとは関係ないのですが、6月10日にFirstFourNotes,LLCとして、会社を始めました。
夏の期間は、起業の事務処理やらなんやら+この時期は主にフロント側の開発案件をしていたので、AWS関連の仕事はおやすみしていました。

秋の訪れとともにECS

さて、dockerは単一ホストの時はいいのですが、マルチコンテナ、マルチインスタンスにして、スケールさせたい!というのがあったので、この頃docker-swamを使うか、ECSを使うかと色々と検証していましたが、ECSの方がハンドリングしやすいなという感触だったので、ECSを使い始めました。

ちょうど、この検証を始めたのが10月ごろだったのですが、re:invent前後でかなりECSの機能がアップデートされましたよね。。うれしいアップデートが多かったのですが、あれ?2ヶ月前に見たのと違う・・っていう戸惑いが現在隠せませんw。

使いやすくなったECSとタイミングよく出てくれたALB

12月現在、クラスターを立ち上げる時に、クラスター内に立ち上げるインスタンスも指定できるようになりましたね。
10月ごろに、クラスター作ったはいいけど、インスタンスとか、AutoScaleとかどうするの?とかドキュメント読み漁ったのが嘘のような気がするのは私だけでしょうか。。。

さて、実際のECRの立ち上げについては、dosts女子部アドベントカレンダー1日目で、@bboobbaa さんが書いてくれていますので、こちらを参考にしてください!

タスクに対する適正なRoleの設定について

AWSの認証情報をコードの中にゴリゴリ書くのってちょっと・・・なので、ECSのタスクに適正なタスクを付与してあげるとそんなことは必要ありません。

ECSのタスクに適正なロールを付与して、実行させるって具体的にどうするの?っていうのが、以下のデモンストレーションに書かれていて、一度やってみると、なるほどと体感できました。

基本、上記のデモンストレーションの流れに沿ってやればOKなのですが、幾つか前提となっている知識があるので、そこでつまづくことがありました。

  • クラスターにEC2インスタンスを作成するってどうするの?

    • 12月現在のGUIでは、クラスター作成時にインスタンスタイプを選択して、すぐに用意できるので問題ないかと思います。10月頃に試した時はクラスターは作成できたけど、EC2インスタンス追加するのどうするの?という状態だったので、詰まりました。その時に参考にしたのはこちらでした。 → Launching an Amazon ECS Container Instance – Amazon EC2 Container Service
  • タスクのためのIAMロールの作成ってどうするの?

    • IAMを選択して、ロールの作成で、AWS Service Roles では Amazon EC2 Container Service Task Roleを選択 、Attach Policy画面ではAmazonS3FullAccessというIAM管理ポリシーを選択します。

スクリーンショット 2016-12-15 8.16.02.png

スクリーンショット 2016-12-15 8.15.44.png

ECRではなく直接docker-hubにあるものを使いたい場合

ちょっとした動作テストの時は、docker-hubにあるものを使うこともできます。
タスク定義の作成のコンテナの追加の、イメージのところに、docker-hubにあがっている名称+versionでOKです。

スクリーンショット 2016-12-13 14.46.21.png

ポートの設定

コンテナ追加時のポートの設定ですが、(紐付けを行うEC2ホストのポートと、コンテナ側のポートを指定)80:80とやってしまうと、ホスト内に複数のタスクを立ち上げることができません。すでに80は別コンテナに使われているよ、となってしまいます。

ホスト側のポートを0か何も入れないようにしておくと、エフェメラルポートが動的に割り当てられます

サービスのAutoScaleとインスタンスのAutoScale

現在では少し、操作が変わっていますが、基本的な流れは同じかと思います。

インスタンスのAutoScaleのチュートリアル

Note
If you configure your Auto Scaling group to remove container instances, any tasks running on the removed container instances are killed. If your tasks are running as part of a service, Amazon ECS restarts those tasks on another instance if the required resources are available (CPU, memory, ports); however, tasks that were started manually will are not restarted automatically.

もし、コンテナーインスタンスを削除するためのAutoScaleの設定をしたのであればインスタンスに乗っているタスクは全てkillされますと。
サービスの一部としてタスクを走らせている場合で、もし要求されているリソースが十分にあれば、ECSはそれらのタスクを別のインスタンスで再起動させることができる。
ただ、マニュアルで起動させているタスクは自動起動しないとのことなので、注意が必要ということでした。

ApacheBenchで実際に負荷をかけてみて、スケールイン、スケールアウトしてみて、設定に間違いがないかを検証しておきましょう。いざという時に機能しないと、このあたりはしんどいことになります。

CommingSoon!

re:inventで発表されたCommingSoonなECSの機能

12/14のJAWS-UG コンテナ支部 #7で、情報仕入れてきました。

  • TaskPlacementEngine
  • Task Placement Strategies
  • Future of Task Placement

タスクの配置をハンドリングできるようになるようです!

ちなみにJAWS-UG コンテナ支部勉強会も3ヶ月毎くらいに開催されています。
ECSをやっている方にはとてもおすすめな勉強会なので、JAWS-UG コンテナ支部に登録しておきましょう!

docker.jpeg

初雪を見ながらCloudwatch

11月に初雪でしたね。寒さと締め切りが堪える今日この頃です。

ECSのログをCloudwatchに流す

タスクのログ設定のところで、「awslogs」を設定して、以下の設定を行います。

awslogs-groupの名称は、この名称でcloudwatchでロググループを事前に作成しておく必要があります。
awslogs-regionは、自分が今使っているリージョンで。
awslogs-stream-prefixは、お好みです。

ログ設定.png

cloudwatchに流れてきたログを見るのに、awslogsコマンドが便利

さて、ECSのコンテナから流れてくるログですが、GUIで見るのはとても大変です。
ターミナルからawslogsコマンドで見るのがベストです。

画面から見ると山盛り状態・・・いちいち開いてられませんよね。

logstream.png

Nginxのログなどであれば、awslogsコマンドのフィルターパターンを使うことで、ステータスコード毎のイベントをざっと見ることができます。

詳しい設定方法などは、クラメソさんの資料にまとまってありました。

気をつけるべき点は、プロファイルを多数持っている場合、プロファイルが、自分の使いたいものになっているか確認しておくことが大事です。

~/  $ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                 hogehoge           manual    --profile
access_key     ****************RTVQ shared-credentials-file
secret_key     ****************iTYQ shared-credentials-file
    region           ap-northeast-1              env    AWS_DEFAULT_REGION
16:58:10 ~/  $

(小噺)ElastiCache使おうとしたけど

error.png

mongo小噺、Lambda小噺もあるのですが、時間切れなので、またぼちぼちQiitaに投稿していこうかと思います・・・・・・。

やってきたことまとめ

  • 公式のドキュメントを読む。(英語)
  • それについているチュートリアルを試す。
  • 試したことについては、Privateなissueに全てキャプチャと解説つきで、自分のためにログを取っておく。
  • AWS Solutions Architect ブログのチェック
  • Amazon Web Services のチェック
  • AWS Compute Blog のチェック
  • JAWS-UGに積極的に参加して仲間を増やすと、流入してくる情報量がFBやtwitter経由で増えますし励みにもなります

AWSのブログ系は、日本語訳されているエントリは限られているので、英語を読むほうが情報量は圧倒的に増えます。
自分がガチで使っているAWSサービスはもっと追っかけなくては、と思っています。

あとがき

ちょっと2015年の話。
2015年9月末で会社を退職し、仕事もなくふらふらとベトナムあたりをふらついていた矢先に、とある案件の話をいただいて、11月くらいからjoinすることになりました。

そこで、初めて使うことになったのが、AWS。

数年間はWeb関連企業でインフラ担当として勤務していた経験はありますが、絶賛オンプレで、クラウドに憧れを抱きつつも、無料枠ではなかなか大胆なこともできず、AWS素敵かもなと思いつつ静観だったので、すごくいい機会をもらえた!と喜びました。
ですが、フリーランスとして成果ベースでjoinしたからには、とにかく使えるようにならなければとキャッチアップするのにアップアップした一年でした。

今年一年は、個人的に、個人事業主始めたかと思ったら、ビジネスパートナーにめぐり合うことができて、起業して・・・
とにかく会社として、何かできるようにしようと走り続けた激動の一年でした。
ポエム的なことも書けなくはないですが、それは、また機会があれば・・

来年は、アラフィフに突入するので、今年に引き続き健康には人一倍気をつけていこうと思いますw

ここ数年、集中力や体力が落ちていて、昔よりかなり仕事のスピードが遅くなってしまいました。
ですが、来年も自分なりのスピードで、言語やプラットフォーム両方で、新しい技術に積極的に取り組むのは変わらず続けていきます。

来年も素敵な年にしていきましょう。
みなさま良いお年を

次は、@chikubasayaka さんです!

続きを読む

dockerいろいろ陥った時のメモ

このメモ

多くの人はこんなことではまらないと思うので、自分の備忘録です。

その1:なぜか嵌った罠:dockerのネットワークに接続できない。それに気付けなかったこと。

MacOSXでDockerToolBoxを使って、Dockerコンテナを作成していた。
作成したコンテナがbridgeにつながっていない。

教科書通りにrunしたら普通はbridgeに入るのではないか・・・。
なぜか環境が異常をきたしていたのか、それで作成したコンテナにローカル側からアクセスできなかった。
というわけで、他にそういう事に遭遇した人がいれば教えてください。

正常であれば、以下のようにできると思う。

  • docker-machineを作成する
  • docker runする

以下の例ではMYSQLとNginxを起動してみている


docker run --name test-mysql -e MYSQL_ROOT_PASSWORD=password -p 3308:3306 -d mysql:latest

docker run --name ok-nginx -d -p 8080:80 nginx
  • ホスト側から接続して確認する

    • nginxであれば、「//192.168.99.100:8080/」に接続して「Welcome to nginx!」の画面が見れる
    • MySQLであれば、「mysql -u root -p -h 192.168.99.100 -P 3308」でmysqlコンソールに入れる

今回はここで躓いた。
ホスト側から何度アクセスを試みても、繋がらない、どうしてだろうと、破棄と作成ばかりを繰り返して、時間を浪費してしまった。やっぱりきちんとドキュメントを読み切れていない。反省。
ここでやるべきことは、次にあげる「dockerのネットワーク確認する」でした。

  • dockerのネットワーク確認する
    これが大事だった!!
    ここでちゃんtネットワークの「 docker network inspect bridge」でbridgeにつながっているかどうかを確認しておけば、すぐに何かがおかしいと気付けたはず。

正常であれば、bridgeに接続するdockerを確認できる。


[~/bohelabo 21:34:28]$ docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "df96314c72193f670d28a72e606e498da7be7b3a3801c211196416b6a747ac83",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16"
                }
            ]
        },
        "Internal": false,
        "Containers": {
            "4232a9941faf07ed39b59c2d60fd7bb64bde09715fef2b918d46e42b47436c23": {
                "Name": "some-mysql",
                "EndpointID": "463fa0ddddb8a7e22050665438261df06141ef47d1b9d54ea5f501046db92682",
                "MacAddress": "02:42:ac:11:00:05",
                "IPv4Address": "172.17.0.5/16",
                "IPv6Address": ""
            },
            "6036acde79451e62cc11771b6c662f06545a6e336bd8c12def68a13118722360": {
                "Name": "some-nginx",
                "EndpointID": "eafc8ad714fbb375c383cdf2702e00e715437763f87cf8906ed13acf4009f2d3",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            },
            "6c26bccf68cb8b1cb92c287381027841799ae2ec8fb6db508aef2df43cc1bc49": {
                "Name": "test-mysql",
                "EndpointID": "3fb03ecbb55329cbb22ffce0ea71b59f5a079e995ee1a4e9246c1f1bfff7e708",
                "MacAddress": "02:42:ac:11:00:06",
                "IPv4Address": "172.17.0.6/16",
                "IPv6Address": ""
            },
            "890efad657df5f2bf6b14f15cc67f826262bd5a121df88675195c55ad8299643": {
                "Name": "test-nginx",
                "EndpointID": "46ee088ec228baef74f52ee62a3c962da2e95d2592c41183c351e845ecbb4b0d",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.17.0.3/16",
                "IPv6Address": ""
            },
            "f864809cb7e68701ce2cbb9524ba5d0f3a8b221b914a237a4a31bb7d73bf0569": {
                "Name": "ok-nginx",
                "EndpointID": "ebe040a8487cb5c83521bcab7c70b7f9a75172aa895d15d5d644ff2068cfc934",
                "MacAddress": "02:42:ac:11:00:04",
                "IPv4Address": "172.17.0.4/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

コンテナ全部落としたい、消したい

実験をたくさんやるとコンテナが蓄積されるので、以下のコマンドで一気にお掃除できます


docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
docker rmi $(docker images  -q)

その2:AWS EC2に作成したdocker-nachineの状況が見れない?

docker-machine sshで、作成したdockerのインスタンスに入って、「docker ps」をやるとですね、
[Cannot connect to the Docker daemon. Is the docker daemon running on this host?]で怒られます。

sudoしないと見れないですよ。


docker-machine ssh docker-bohe

ubuntu@docker-bohe:~$ whoami
ubuntu
ubuntu@docker-bohe:~$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
ubuntu@docker-bohe:~$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
7a8ccadb7e0d        api_hapi            "/bin/sh -c 'cd /src "   2 days ago          Up 2 days           0.0.0.0:3333->3333/tcp   api_hapi_1
f5574efbd1c1        api_mroonga         "/root/entrypoint.sh"    2 days ago          Up 2 days           0.0.0.0:3306->3306/tcp   api_mroonga_1
ubuntu@docker-bohe:~$

その3:aws configure list とdocker-machine createの関係(未解決)

さて、以下のような状態だったとしてます。
ここで、docker-machineを立ち上げてみましょう。

~/bohelabo 21:47:28]$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                 bohelabo           manual    --profile
access_key     ****************FJIA shared-credentials-file
secret_key     ****************+ifS shared-credentials-file
    region                us-east-1      config-file    ~/.aws/config

ここで

$ export AWS_ACCESS_KEY_ID=AKID1234567890
$ export AWS_SECRET_ACCESS_KEY=MY-SECRET-KEY

[~/bohelabo 22:04:59]$ docker-machine create  --driver amazonec2  docker-bohe2
Running pre-create checks...
Error with pre-create check: "unable to find a subnet in the zone: us-east-1a"

us-east-1aなるサブネットはないとな。


[~/bohelabo 22:41:31]$ docker-machine create --driver amazonec2 --amazonec2-vpc-id vpc-c5d5d2a1 aws01
Running pre-create checks...
Error with pre-create check: "unable to find a subnet in the zone: us-east-1a"

[~/bohelabo 22:48:25]$ docker-machine create --driver amazonec2 --amazonec2-vpc-id vpc-c5d5d2a1 --amazonec2-subnet-id us-east-1b aws01
Error setting machine configuration from flags provided: unexpected EOF


[~/bohelabo 22:51:41]$ docker-machine --version
docker-machine version 0.7.0, build a650a40

ここで、一旦、aws configure listがクリアな状態で実行してみた

~/bohelabo 22:55:57]$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key                <not set>             None    None
secret_key                <not set>             None    None
    region                <not set>             None    None
[~/bohelabo 22:56:06]$ export AWS_ACCESS_KEY_ID=XXXXXXX
[~/bohelabo 22:57:24]$ export AWS_SECRET_ACCESS_KEY=XXXXXXX

[~/bohelabo 22:57:30]$ docker-machine create --driver amazonec2  aws01
Running pre-create checks...
Error with pre-create check: "unable to find a subnet in the zone: us-east-1a"

[~/bohelabo 22:57:41]$ docker-machine create --driver amazonec2 --amazonec2-subnet-id us-east-1b aws01
Error setting machine configuration from flags provided: unexpected EOF

結果、やっぱり実行できない。

あれ、何かissue上がっている。。。でも解決してなさそうなんだけど、どうなのこれ・・・。

unexpected EOF · Issue #2661 · docker/machine
https://github.com/docker/machine/issues/2661

というわけで、続debug中です。何でこんなに地雷が・・・。

あとがき

そんなこんなで先週はロス時間長すぎて、泣きそうです。
そもそも、もっとこういう方法があるよ、などご指摘ありましたら、よろしくお願いします。

ぼへぼへ.jpeg

続きを読む

MacOS (El Capitan) でのaws-cliアップデート

これは?

MacOS (El Capitan) でaws-cliをアップデートするときのコマンドです。

El Capitanアップデートの実行

普通にupdateするとエラーになるので、以下のコマンドでupdateします。

sudo pip install awscli --upgrade --ignore-installed six

普通に実行すると、以下のエラーに遭遇します


[~/bohelabo 19:06:42]$ sudo pip install -U awscli
Password:
The directory '/Users/bohebohechan/Library/Caches/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/Users/bohebohechan/Library/Caches/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting awscli
  Downloading awscli-1.10.19-py2.py3-none-any.whl (919kB)
    100% |████████████████████████████████| 921kB 634kB/s
Requirement already up-to-date: rsa<=3.3.0,>=3.1.2 in /Library/Python/2.7/site-packages (from awscli)
Requirement already up-to-date: s3transfer==0.0.1 in /Library/Python/2.7/site-packages (from awscli)
Requirement already up-to-date: colorama<=0.3.3,>=0.2.5 in /Library/Python/2.7/site-packages (from awscli)
Collecting botocore==1.4.10 (from awscli)
  Downloading botocore-1.4.10-py2.py3-none-any.whl (2.3MB)
    100% |████████████████████████████████| 2.3MB 249kB/s
Requirement already up-to-date: docutils>=0.10 in /Library/Python/2.7/site-packages (from awscli)
Requirement already up-to-date: pyasn1>=0.1.3 in /Library/Python/2.7/site-packages (from rsa<=3.3.0,>=3.1.2->awscli)
Requirement already up-to-date: futures<4.0.0,>=2.2.0 in /Library/Python/2.7/site-packages (from s3transfer==0.0.1->awscli)
Requirement already up-to-date: jmespath<1.0.0,>=0.7.1 in /Library/Python/2.7/site-packages (from botocore==1.4.10->awscli)
Collecting python-dateutil<3.0.0,>=2.1 (from botocore==1.4.10->awscli)
  Downloading python_dateutil-2.5.2-py2.py3-none-any.whl (201kB)
    100% |████████████████████████████████| 204kB 2.6MB/s
Collecting six>=1.5 (from python-dateutil<3.0.0,>=2.1->botocore==1.4.10->awscli)
  Downloading six-1.10.0-py2.py3-none-any.whl
Installing collected packages: six, python-dateutil, botocore, awscli
  Found existing installation: six 1.4.1
    DEPRECATION: Uninstalling a distutils installed project (six) 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 six-1.4.1:
Exception:
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/basecommand.py", line 209, in main
    status = self.run(options, args)
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/commands/install.py", line 317, in run
    prefix=options.prefix_path,
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/req/req_set.py", line 725, in install
    requirement.uninstall(auto_confirm=True)
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/req/req_install.py", line 752, in uninstall
    paths_to_remove.remove(auto_confirm)
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/req/req_uninstall.py", line 115, in remove
    renames(path, new_path)
  File "/Library/Python/2.7/site-packages/pip-8.0.2-py2.7.egg/pip/utils/__init__.py", line 266, in renames
    shutil.move(old, new)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 302, in move
    copy2(src, real_dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 131, in copy2
    copystat(src, dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 103, in copystat
    os.chflags(dst, st.st_flags)
OSError: [Errno 1] Operation not permitted: '/tmp/pip-EupUTB-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six-1.4.1-py2.7.egg-info'
You are using pip version 8.0.2, however version 8.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

続きを読む

AWS-CLI EC2でおなじものをつくるよ

ある日のこと。
現在稼動しているEC2インスタンスと同じものを作ってね。という依頼がきました。

「GUIは中学生まで・・」※
という言葉を胸にとりあえず、CLIでチャレンジしてみました。

※正しくは・・・「本番環境で変更を伴う作業をマネジメントコンソールでやって良いのは中学生かAWS経験半年まで」です!

bohebohe_ec2.jpg

EC2のコマンドライン操作

こちらのリファレンスを片手にやるとよいです。最新の使えるコマンドが列挙されています。
http://docs.aws.amazon.com/cli/latest/reference/ec2/index.html#cli-aws-ec2

コマンドは、いきなりやるとコワイので、ドライランをつけてやりましょう。

--dry-run

おなじものをつくるよSTEP

やり方は複数あると思いますが、今回はコピー元のEC2インスタンスのAMIを取得して、それを元にインスタンスを作成します。

IAMイメージを作成する

まず、コピーしたいEC2インスタンスのIAMイメージを作成します。
このときに、マシンはとめておきましょう。メモリ上にデータが残っていたりします。

http://docs.aws.amazo.com/cli/latest/reference/ec2/create-image.html

aws ec2 create-image --instance-id i-XXXXXX --no-reboot --name test_20160106100726

この時、うーん自分のコピーしたいIAMインスタンスのインスタンスIDはなんだろうっていうのを調べる時は、以下のコマンドを使います。

  • リージョン内で稼働している全インスタンスの情報を取得する場合
$ aws ec2 describe-instances
  • また、インスタンスIDがわかって、そのインスタンスの情報を知りたい場合は、以下のコマンドで情報を取得していきます。
$ aws ec2 describe-instances --instance-ids ${instance-id}

参考URL: http://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html

さて実行

dry-runをつけていると、いろんなエラーにあたりつつ、前進していけます。

  • エラーその1:セキュリティグループとサブネットがあっていないようです。
% aws ec2 run-instances  --dry-run --image-id test_20160106100726 --key-name demo --count 1 --security-group-ids sg-XXXX  --instance-type t1.micro

A client error (InvalidParameter) occurred when calling the RunInstances operation: Security group sg-XXXX and subnet subnet-XXXX belong to different networks.
  • エラーその2:指定するAMIの名前がちがうようです
% aws ec2 run-instances  --dry-run --image-id test_20160106100726 --key-name demo --count 1 --security-group-ids sg-XXXX  --subnet-id subnet-XXXX --instance-type t1.micro

A client error (InvalidAMIID.Malformed) occurred when calling the RunInstances operation: Invalid id: "test_20160106100726" (expecting "ami-...")
  • エラーその3:どうやら、このインスタンスタイプ( –instance-type t1.micro)の実行はGUIからのみのようです。
% aws ec2 run-instances  --dry-run --image-id ami-XXXX  --key-name demo --count 1 --security-group-ids sg-XXXX  --subnet-id subnet-XXXX --instance-type t1.micro

A client error (InvalidParameterCombination) occurred when calling the RunInstances operation: Non-Windows instances with a virtualization type of 'hvm' are currently not supported for this instance type.
  • お、うまく通ったようです。
% aws ec2 run-instances  --dry-run --image-id ami-XXXX  --key-name demo --count 1 --security-group-ids sg-XXXX  --subnet-id subnet-XXXX --instance-type t2.micro

A client error (DryRunOperation) occurred when calling the RunInstances operation: Request would have succeeded, but DryRun flag is set.
  • では、dry-runを外して実行してみましょう。
% aws ec2 run-instances  --image-id ami-XXXX --key-name demo --count 1 --security-group-ids sg-XXXX  --subnet-id subnet-XXXX --instance-type t2.micro

813931856455    r-cf4d9167
INSTANCES   0   x86_64      False   xen ami-XXXX    i-df1e7d5e  t2.micro    demo    2016-01-06T01:34:05.000Z    ip-10-0-0-57.ec2.internal   10.0.0.57       /dev/xvda   ebs True        subnet-XXXX hvm vpc-XXXX
MONITORING  disabled
NETWORKINTERFACES       12:1d:84:4d:fe:83   eni-XXXX    813931856455    ip-10-0-0-57.ec2.internal   10.0.0.XX   True    in-use  subnet-XXXX vpc-XXXX
ATTACHMENT  2016-01-06T01:34:05.000Z    eni-attach-XXXX True    0   attaching
GROUPS  sg-XXXX berio-api-security-group
PRIVATEIPADDRESSES  True    ip-10-0-0-XX.ec2.internal   10.0.0.XX
PLACEMENT   us-east-1b      default
SECURITYGROUPS  sg-XXXX     XXXX-security-group
STATE   0   pending
STATEREASON pending pending
OK  ~/.aws

インスタンスの情報設定

  • できあがったインスタンスの情報を取得してみましょう
aws ec2 describe-instances --instance-id i-XXXX --output json
  • タグの名前をつけてみましょう
aws ec2 create-tags --resources  i-XXXX --tags '[{"Key": "Name", "Value": "Test"}]'
  • 固定IPを付与してみましょう
aws ec2 associate-address --allocation-id eipalloc-XXX --network-interface-id eni-XXXXX

最後に

dry-runをつけながら、すこしずつコマンドを実行してデバッグしながら、前進しましょう。
最初はうまくいかないけど、やっていくうちにアタリをつける能力がすこしづつあがります。

Let’s enjoy your AWS-CLI Life!

続きを読む