AWS Lambdaデプロイ方法を求めて: Codeship

このドキュメントレベル:初めて学ぶ人向け

Lambdaの良いデプロイフローはないかと思って調べた記録です。
Lambdaのデプロイにはいくつか種類があるようです。

Serveless
Apex
Lamvery
LambCI
CodeShip

前回は「Serveless」AWS Lambdaデプロイ方法を求めて:Serverlessフレームワーク – Qiitaについて調べましたが、
今回は「CodeShip」について、どんなものかを触りだけ調べています。

Codeship

stackshareのDevOpsでなかなか人気もののようです

Codeship

無料枠で使いましょう。

スクリーンショット 2017-05-11 7.16.13.png

■ 注意しないといけない点

Codeshipでは Lambda関数を事前に作っておかなくてはいけません!
あと、エイリアス「PROD」も作っておかないと、後半のデプロイで失敗してしまいます。

■ AWSコンソールで、lambda関数を作成

ここで、コミットするハンドラー名称と関数名と合わせておくようにしましょう

lambda関数

  • sample-lambda関数
  • handler.jsのhelloを呼び出します、なのでハンドラ名は「handler.hello」にします
  • エイリアス「PROD」を作成
  • テスト実行

use strict';

module.exports.hello = (event, context, callback) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Good Good Morning CodeShip!!Your function executed successfully!',
      input: event,
    }),
  };

  callback(null, response);

};

■ Codeshipにサインアップでプロジェクトを作成します

プロジェクトタイプはBasicを選択

プロジェクトタイプの洗濯

今回はGitHubと連携してデプロイします
GitLabとも連携できますね!

GitHub連携

テストのパイプラインも設定できます。
今回は、「npm test」だけ実行します

なので、「package.json」側にとりあえず通るダミーを設定しています。

テストパイプライン

package.json


{
  "name": "sample-lambda",
  "version": "1.0.0",
  "description": "",
  "main": "handler.js",
  "scripts": {
    "test": "echo "OK" && exit 0" ★無理やりテスト通していますw
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/bohebohe/sample-lambda.git"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/bohebohe/sample-lambda/issues"
  },
  "homepage": "https://github.com/bohebohe/sample-lambda#readme"
}

gitHubのsample-lambdaリポジトリのマスターと連携します

gitHubのマスターと連携します

連携するgitHub
今回はserverless.ymlは不要です・・・。前回の実験の名残です。

連携するgitHub

準備できました!

sample-lambda

■ Codeshipでのデプロイ設定

デプロイできるIAMユーザーを作成します。
そのユーザーに対して、以下のポリシーをアタッチしてください。
ARNの部分を書き換えてください

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lambda:UpdateFunctionCode",
                "lambda:UpdateFunctionConfiguration",
                "lambda:InvokeFunction",
                "lambda:GetFunction",
                "lambda:PublishVersion",
                "lambda:UpdateAlias"
            ],
            "Resource": [
                "arn:aws:lambda:YOUR_AWS_REGION:YOUR_AWS_ACCOUNT_ID:function:YOUR_FUNCTION_NAME"
            ]
        }
    ]
}

作成したユーザーのAWSのアクセスキーをCodeShipの環境変数に設定します

CodeShipの環境変数

デプロイのためのCustomScriptを書きます

CustomScript

CustomScript

■ gitHubにpush

gitHubのpushをトリガーにして、テストが実行され、OKであればデプロイされて、結果が表示されます。

ダッシュボード

感想

お手軽感はありますね。ただ、事前にlambda関数を作成したりと一手間かかるので、全てyamlでというserverless方式とはちょっと違います。
コードを苦手な人向け?なのかな。

参考サイト

続きを読む

AWS Lambdaデプロイ方法を求めて:Serverlessフレームワーク

このドキュメントレベル:初めて学ぶ人向け

Lambdaの良いデプロイフローはないかと思って調べた記録です。
Lambdaのデプロイにはいくつか種類があるようです。

  • Serveless
  • Apex
  • Lamvery
  • LambCI
  • CodeShip

今回は「Serverless」について、どんなものかを触りだけ調べています。

Serverless

サーバーレスなアーキテクチャを容易に作成、管理できるフレームワークです
AWS Lambda, Apache OpenWhisk, Microsoft Azureなどをサポートしているようです。

デプロイイメージをつかむ

  • このnode.jsのサンプルを実際にやってみると感じがよくわかります。事前のAWSのCredentialsの設定をやっておきましょう

Hello World Node.js Example

Serverless Framework – AWS Lambda Guide – Credentials

豊富なサンプルコード

gutHubにサンプルコードがアップされているので、これを実行するだけでも感じがつかめます

serverless/examples: Serverless Examples – A collection of boilerplates and examples of serverless architectures built with the Serverless Framework and AWS Lambda

例)aws-node-rest-api-with-dynamodb/

cloneしてきて、deployしてみます

14:45:35 aws-node-rest-api-with-dynamodb/  $ ls
README.md   package.json    serverless.yml  todos


14:46:01 aws-node-rest-api-with-dynamodb/  $ npm install
aws-rest-with-dynamodb@1.0.0 /Users/bohebohechan/devel/src/gitlab.com/FirstFourNotes/serverless/aws-node-rest-api-with-dynamodb
└── uuid@2.0.3

npm WARN aws-rest-with-dynamodb@1.0.0 No repository field.

11:23:44 aws-node-rest-api-with-dynamodb/  $ sls deploy
Serverless: Packaging service...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (22.45 KB)...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
......................................................................................................
Serverless: Stack update finished...
Service Information
service: serverless-rest-api-with-dynamodb
stage: dev
region: us-east-1
api keys:
  None
endpoints:
  POST - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/todos
  GET - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  PUT - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
  DELETE - https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/todos/{id}
functions:
  create: serverless-rest-api-with-dynamodb-dev-create
  list: serverless-rest-api-with-dynamodb-dev-list
  get: serverless-rest-api-with-dynamodb-dev-get
  update: serverless-rest-api-with-dynamodb-dev-update
  delete: serverless-rest-api-with-dynamodb-dev-delete
11:25:19 aws-node-rest-api-with-dynamodb/  $

RestAPIができてしまったようです。

AWSコンソールで確認

実際にコンソールで確認してみましょう

> Lambda

lambda.png

> DynamoDB

キャプチャ撮り忘れたので割愛・・・

> API Gateway

apigateway.png

> S3

s3.png

> CloudFormation

cloudformation.png

> CloudWatch Logs

cloudwatchlogs.png

PostmanでAPIを実行してみます

> Post

postman-post.png

> Get

postman-list.png

後片付け

消しておきましょう

11:44:47 aws-node-rest-api-with-dynamodb/  $ sls remove
Serverless: Getting all objects in S3 bucket...
Serverless: Removing objects in S3 bucket...
Serverless: Removing Stack...
Serverless: Checking Stack removal progress...
..............................................................
Serverless: Stack removal finished...

このようなサンプルをカスタマイズしていくことで、自分の欲しい機能を簡単に作っていけそうです。

serverless.yml

先ほどの例)aws-node-rest-api-with-dynamodb/を参考にして、serverless.ymlの中身を紐解いてみましょう
解説はざっくりなので、詳細は公式ページで確認のことです。

AWSをプロバイダーにセットしたときに有効となるプロパティ一覧が載っています
Serverless Framework – AWS Lambda Guide – Serverless.yml Reference

  • service

プロジェクト名

  • frameworkVersion

フレームワークの対応バージョン

service: serverless-rest-api-with-dynamodb

frameworkVersion: ">=1.1.0 <2.0.0"
  • provider

AWS CloudFormation stack
サービスがデプロイされる対象について書きます。ここでは、AWSですよね 
 
– iamRoleStatements
How it works iamRoleStatements configuration section? – Serverless Framework – Serverless Forums

Lambda Functionで、AWSのリソースにアクションする際の許可をAWS IAM Roleで記述します。
「provider.iamRoleStatements」のプロパティに必要となる許可ステートメントを設定します。
今回は、Lambdaからdynamodbへの許可が必要ですね。

provider:
  name: aws
  runtime: nodejs6.10
  environment:
    DYNAMODB_TABLE: ${self:service}-${opt:stage, self:provider.stage}
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource: "arn:aws:dynamodb:${opt:region, self:provider.region}:*:table/${self:provider.environment.DYNAMODB_TABLE}"

-Functions

Lambdaに作成するFunctionの定義を書きます

  • Events

Lambda Function の起動するトリガーを書きます
S3バケットへのアップロードや、SNSトピック受信や、HTTPのエンドポイントですね

サポートしているイベントの一覧はこちら
Serverless – AWS Lambda – Events

functions:
  create:
    handler: todos/create.create
    events:
      - http:
          path: todos
          method: post
          cors: true

  list:
    handler: todos/list.list
    events:
      - http:
          path: todos
          method: get
          cors: true

  get:
    handler: todos/get.get
    events:
      - http:
          path: todos/{id}
          method: get
          cors: true

  update:
    handler: todos/update.update
    events:
      - http:
          path: todos/{id}
          method: put
          cors: true

  delete:
    handler: todos/delete.delete
    events:
      - http:
          path: todos/{id}
          method: delete
          cors: true
  • Resources

AWS CloudFormation stackに追加することができます。
以下では、TodosDynamoDbTableを追加しています。
特定のCloudFormationのリソースに対して、値を上書きすることもできます

resources:
  Resources:
    TodosDynamoDbTable:
      Type: 'AWS::DynamoDB::Table'
      DeletionPolicy: Retain
      Properties:
        AttributeDefinitions:
          -
            AttributeName: id
            AttributeType: S
        KeySchema:
          -
            AttributeName: id

ワークフロー

Serverless Framework Guide – AWS Lambda – Workflow

Development Workflowとして以下の手順で回しましょう、といったことが書かれています。

  1. Write your functions
  2. Use serverless deploy only when you’ve made changes to serverless.yml and in CI/CD systems.
  3. Use serverless deploy function -f myFunction to rapidly deploy changes when you are working on a specific AWS Lambda Function.
  4. Use serverless invoke -f myFunction -l to test your AWS Lambda Functions on AWS.
  5. Open up a separate tab in your console and stream logs in there via serverless logs -f myFunction -t.
  6. Write tests to run locally.

参考になるドキュメント

続きを読む

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.

続きを読む