AWS Lambda + Serverless Framework + Slackで作るカスタマイズ可能なfeedリーダー その1

概要

AWS Lambda + Serverless Framework + Slackを使ってカスタマイズ出来るfeedリーダーを作ろうという記事のその1です。
(最初は一つの記事で完結させようとしていたのですがやることが多すぎました…なお続編があるかどうかは不明)

こんなの作ったよ系の記事なので、ツールとかフレームワークの説明は少なめかも。

feedの例:
slack.png

そもそもfeedリーダーを作ろうと思った動機

実はfeedの機能自体はSlackにあって、各チャンネルで

/feed subscribe https://hoge/feed 

のように打つとそのチャンネルに定期的にフィードの記事が流れてきます。ただ

  • 一つ一つの記事のdescriptionがとても長い
  • feedによっては大きいサイズの画像が表示される

などの理由から、流れてくる記事をカスタマイズしたいなーという思いから作り始めました。

Serverless Frameworkの説明

Serverless Frameworkは、AWS Lambdaなどの、関数単位で提供されているサービスの環境準備やデプロイ、パッケージング、バージョン管理、ローカルでのデバッグなどをやってくれるフレームワーク・ツールです。
3か4つぐらいのコマンドさえ覚えておけばなんとかなるので、非常に使いやすいです。
詳しくは以下の記事が分かりやすいかと思います。

具体的なデプロイのコマンドなどは後述のhttps://github.com/yudetamago/my_rss_to_slack_service
を参照のこと。

今回の記事で出来たもの

とりあえず

  • Serverless Frameworkを使ったデプロイ
  • デプロイした関数をデバッグ実行するとfeed(今のところRSSのみ)を取ってきてSlackのwebhookに送信する

という最低限feedの内容をSlackに引っ張ってこれるところまで出来ました。
コードではサンプルとしてAmazon Web Services ブログのfeedを取ってきています。

コードの仕組み・説明

出来たもの
https://github.com/yudetamago/my_rss_to_slack_service

全体としてはfeedをHTTP GETで取ってきて、Slack通知用に変換して送信しているだけだったりします。
(今回は最低限のところしか作っていないので、自分で関数を呼び出してfeed内容を取得してくるだけです。。)

Lambda Functionの機能自体に関連する部分

まず serverless.yml で指定した feedToSlack という関数を handler.jsmodule.exports で定義します。そして後述するfeedの処理を終えてレスポンスを返すときには、引数の callbackにレスポンス内容を入れて callback(null, response) のように呼び出すとLambdaの処理は終了します。

feedの処理

今回はfeedParserというライブラリを使っていて、リクエストをそのまま pipe でパーサーのほうに流しています。記事を読み込むと parser.on('readable') のコールバック関数が呼ばれるので、そこで読み込んだ記事を items に入れたあと、slackのattachmentsに入れています。

これからやること/やりたいこと

  • descriptionにHTMLタグが入っているときの処理

    • 現状ではタグがそのままplain textで表示されるので、どうしようかな…という気持ち。
  • RSSやAtomなどフィードの種類に依存しないようにする
    • item["rss:description"]["#"] が依存している部分だけれど、これは正直頑張るしかない。
  • 同じitemが2回以上送られないよう重複管理
    • これだけはステートフルになってしまうので、何らかの方法で楽したい…
  • 定期的にフィードを取ってくるようにする
  • 複数のフィードに対応する
    • 1つのLambda Functionで並列にHTTP GETする(そもそも出来るの?)か、フィードごとにLambda Function作るかみたいなところから検討する感じ。

まとめ

とりあえず最低限のところまでは出来たので、気力があれば続き作ります!

続きを読む

Go言語でDynamoDB接続を試みたときの備忘録

前提

最近、Go言語を触り始めた。

GoからDynamoDBに接続するにあたって、 aws-sdk-go/aws/service/dynamodb を使おうとし、ドキュメントを読んでたら結構難しそうだったので、 guregu/dynamo を使うことにした。

また、DynamoDBも触ったことがなかった。

ゴールは、GoでDynamoDBに読み書きすること!

DynamoDBの設定

まず、AWSコンソール画面からDynamoDBのテーブルを作ります。

スクリーンショット 2017-06-17 16.47.12.png

上記の画面で、「テーブル名」を Test とします。

「プライマリーキー」を user_id とします。型は「数値」にします。

他のattributeにかんしては、時間に関する値を想定してますが、実際にGoからItemをPUTするときに足されるので、定義する必要はありません。(そもそも登録もできない。)

(キャメルケースがいいのか、パスカルケースがいいのか等の命名規則もあるかと思いますが、一旦これでいきます。)

これでAWS側の用意は出来ました。

あと、もう一つ大事なこととして
IAMで、DynamoDBにアクセスできる権限をもったユーザーを作成し、

  • アクセスキー
  • シークレットキー

を入手しましょう。

Go言語をかく!

user_dynamo.goという名前でファイルを作成します。

必要なモジュール

以下のリアブラリをimportします。

user_dynamo.go
import (
  "fmt"
  "time"
  "github.com/aws/aws-sdk-go/aws"
  "github.com/aws/aws-sdk-go/aws/session"
  "github.com/aws/aws-sdk-go/aws/credentials"
  "github.com/guregu/dynamo"
)
ライブラリ名 説明
fmt 標準出力に使う。
time 現在時刻を取得するのに使う。
github.com/aws/aws-sdk-go/aws configに関するオブジェクト作成につかう
github.com/aws/aws-sdk-go/aws/session sessionに関するオブジェクト作成につかう
github.com/aws/aws-sdk-go/aws/credentials awsへのアクセス情報に関するオブジェクト作成につかう
github.com/guregu/dynamo github.com/aws/aws-sdk-go/aws/service/dynamodbに対する操作を便利にしてくれるライブラリ

DynamoDBのスキーマ定義

この言い回しが正しいかわかりませんが、DynamoDBのUserテーブルに登録する予定の項目を構造体として定義します。

user_dynamo.go
type User struct {
  UseId int `dynamo:"use_id"`
  CreatTime time.Time `dynamo:"created_time"`
}

inttime.Time のあとのバッククウォートで囲まれた部分はGoで「タグ情報」と呼ばれるものになります。

DynamoDBのUserテーブルにアクセス

user_dynamo.go
func main(){
  c := credentials.NewStaticCredentials("<アクセスキー>", "<シークレットキー>", "") // 最後の引数は[セッショントークン]

  db := dynamo.New(session.New(), &aws.Config{
      Credentials: c,
      Region: aws.String("<region名>"), // "ap-northeast-1"等
  })
  table := db.Table("User")

 // 続く
}

のように書きます。

データをPUTする

user_dynamo.go
func main(){
  // 続き

  u := User{UserId: 3, CreatTime: time.Now().UTC()}
  fmt.Println(u)

  if err := table.Put(u).Run(); err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

上記をまとめると

user_dynamo.go
package main

import (
  "fmt"
  "time"
  "github.com/aws/aws-sdk-go/aws"
  "github.com/aws/aws-sdk-go/aws/session"
  "github.com/aws/aws-sdk-go/aws/credentials"
  "github.com/guregu/dynamo"
)


type User struct {
  UseId int `dynamo:"use_id"`
  CreatedTime time.Time `dynamo:"created_time"`
}


func main(){
  cred := credentials.NewStaticCredentials("<アクセスキー>", "<シークレットキー>", "") // 最後の引数は[セッショントークン]

  db := dynamo.New(session.New(), &aws.Config{
      Credentials: cred,
      Region: aws.String("<region名>"), // "ap-northeast-1"等
  })

  table := db.Table("User")

  u := User{UserId: 100, CreatedTime: time.Now().UTC()}
  fmt.Println(u)

  if err := table.Put(u).Run(); err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

それではterminalから

$ go run user_dynamo.go

とうってみてください。DynamoDBに

user_id created_time
100 2017-06-02T09:25:56.000147134Z

と登録されたかと思います。これで、DynamoDBへのデータ登録は完了です。

データの読み取り

DynamoDBより

「user_idが100のデータ全て」

データを読み取る場合は以下のようになります。

user_dynamo.go
func main(){
  // 続き
  var users []User
  err := table.Get("user_id", 100).All(&users)
  if err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

  fmt.Println(users) // [{100 2017-06-02T09:25:56.000147134 +0000 UTC}]と出力される。

  for i, _ := range users {
    fmt.Println(users[i]) // {100 2017-06-02T09:25:56.000147134 +0000 UTC}
  }
}

また全データを取得したい場合は

err := table.Get("user_id", 1).All(&users)

というところを

err := table.Scan().All(&users)

とすれば大丈夫です。

さらに created_time によって、絞りたい場合は以下のようにすれば大丈夫です。

err := table.Get("user_id", 1).Filter("created_time >= ?", "2017-06-01 00:00:00").All(&users)

注意点

DynamoDBでは、プライマリーキーは、DBで一つしか存在できないので、本コードでは書き込みをするたびに書き換わります。

参考にしたサイト

http://www.geocities.jp/m_hiroi/golang/abcgo07.html
https://github.com/guregu/dynamo
http://qiita.com/guregu/items/2e9ac305791935b86f5d
https://developers.eure.jp/tech/aws-sdk-go-tutorial-sqs-dynamodb/

続きを読む

EC2上にhubotを設置してslackと連携させる

最近ChatOpsに興味が出てきたので、とりあえずEC2上にhubotが動作する環境を作り、slackと連携出来るようにしました。

前提

以下の環境が既にあること。

  • EC2
  • slack

環境構築

  • nvm〜hubotの起動までは全てEC2上での作業です。

nvmのインストール

  • curlでインストールします
sudo curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
  • .bash_profileに以下を追記します
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
  • nvmコマンドが実行できることを確認します
nvm help

nodejsのインストール

  • nvmでnodejsのv6.11.0をインストールします
  • 公式サイトを見ると includes npm 3.10.10 と書いてあるのでnpmも一緒にインストールされます
nvm install 6.11.0
  • インストールされたことを確認します
node -v
npm -v

redisのインストール

  • elasticacheは使わずAmazon Linux上にredisをインストールします
  • epelだとバージョンが古いようなのでremiを利用します
sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
sudo yum --enablerepo=remi install redis
  • redisを起動させます
sudo service redis start

hubotのインストール

  • hubotの環境を構築します
  • npmでhubot,coffescript,redis,yo,generator-hubotをインストールします
npm install -g hubot coffee-script redis yo generator-hubot
  • hubotをインストールします
mkdir -p ~/deploy-sushi
cd deploy-sushi
yo hubot
  • 対話式で色々聞かれるので自身の環境に合わせて入力してください
? ==========================================================================
We're constantly looking for ways to make yo better!
May we anonymously report usage statistics to improve the tool over time?
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== Y/no


省略


? Owner (User <user@example.com>)
? Bot name (deploy-sushi)
? Description (A simple helpful robot for your Company)
? Bot adapter (campfire)
  • 今回は?4つに以下のように答えました
? Owner {MY_EMAIL}
? Bot name deploy-sushi
? Description this is deploy boy
? Bot adapter slack
  • hubotを立ち上げて動作確認をします
bin/hubot
  • いろんなメッセージが出た後にEnterを押せば deploy-sushi> という対話が始まります
deploy-sushi> deploy-sushi ping
deploy-sushi> PONG
  • hubot-slackをnpmでインストールします
npm install hubot-slack

slackと連携させる

  • slack上の操作に変わります
  • slackのサイドメニューを開き Configure Apps を開きます

スクリーンショット 2017-06-17 14.12.32.png

  • 画面上部に Hubot を入力し、検索結果をクリックします

スクリーンショット 2017-06-17 14.16.11.png

  • Installボタンをクリックします

スクリーンショット 2017-06-17 14.17.17.png

  • hubotの名前を入力して Add Hubot Integrationをクリックします

スクリーンショット 2017-06-17 14.18.21.png

  • 作成が完了したらhubotの詳細画面に遷移するので画面上部の Setup Instructions のところに記載されている HUBOT_SLACK_TOKEN={YOUR_API_TOKEN} をコピーしておきます
  • 画像を変更する・・・など何か編集を加えた場合、画面下部の保存ボタンをクリックして更新してください

  • EC2に戻り以下の環境変数をexportします

echo 'export HUBOT_SLACK_TOKEN={YOUR_API_TOKEN}' >> ~/.bash_profile
source ~/.bash_profile
  • アダプタを指定してhubotを起動します
bin/hubot --adapter slack
  • slackのどこかのチャンネルにhubotをinviteして動作確認します

スクリーンショット 2017-06-17 14.29.14.png

  • 動作確認ができたらEC2起動時に自動でhubotが立ち上がるようにします

hubotの永続実行

  • foreverをnpmでインストールします
npm install -g forever
  • bin/hubot を書き換えます
以下を追記
forever start -w -c coffee node_modules/.bin/hubot --adapter slack


以下をコメントアウト
exec node_modules/.bin/hubot --name "deploy-sushi" "$@"

  • バックグラウンドで動くことを確認します
bin/hubot
ps aux | grep hubot

EC2起動時のスクリプト作成

sudo vi /etc/init.d/start_deploy_hubot
#!/bin/bash
#chkconfig: 2345 99 10
#descpriction: start deploy hubot
DIR="/home/ec2-user/deploy-sushi"
cd $DIR
bin/hubot
  • 実行権限を付与します
sudo chmod 755 /etc/init.d/start_deploy_hubot
  • サービスに追加します
sudo chkconfig --add start_deploy_hubot
  • EC2インスタンスを再起動してhubotが立ち上がっていることを確認してください

hubotが起動しなかった・・・

  • npm,foreverのパスがec2-userにしか通っていないかったのでrootでnpm,foreverするとコマンドが見つからない。
  • トークンもec2-userの .bash_profile に記述していたので見つからない。
  • とりいそぎ bin/hubot に以下を追記しました
    • npm install よりも前に追記してください
export PATH="/home/ec2-user/.nvm/versions/node/v6.11.0/bin:$PATH"
export HUBOT_SLACK_TOKEN={YOUR_API_TOKEN}
  • EC2を再起動して、hubotが立ち上がっていることを確認してください

    • プロセスの確認をします
ps aux | grep hubot
  • slackのチャンネルでもpingして返答があることを確認してください

おわり

hubotがサーバ上で動き続けるようになったので、次回はslackからgit操作を出来るようにしようと思います。

続きを読む

WebpackでAWS SDKをバンドルするとサイズが大きいのでダイエットする

経緯

サーバレス、流行ってますね。
ウェブホスティングしたS3上にReactやRiot.jsなどでSPAを作って、認証はCognito UserPoolというのがテッパン構成でしょう。

そして、SPAを作るならWebpackでES6で書いたソースをトランスパイルして、バンドル(ひとつの*.jsファイルにまとめること)して…というのが通例ですね。(サーバーサイドの人にはこの辺がツラい)

しかしながら、いざやってみると…でかいよバンドルされたJSファイル。minifyして2MB近くとか…。

何が大きいのかwebpack-bundle-size-analyzerを使って見てみましょう。

$ $(npm bin)/webpack --json | webpack-bundle-size-analyzer 
aws-sdk: 2.2 MB (79.8%)
lodash: 100.65 KB (3.56%)
amazon-cognito-identity-js: 94.85 KB (3.36%)
node-libs-browser: 84.87 KB (3.00%)
  buffer: 47.47 KB (55.9%)
  url: 23.08 KB (27.2%)
  punycode: 14.33 KB (16.9%)
  <self>: 0 B (0.00%)
riot: 80.64 KB (2.85%)
jmespath: 56.94 KB (2.02%)
xmlbuilder: 47.82 KB (1.69%)
util: 16.05 KB (0.568%)
  inherits: 672 B (4.09%)
  <self>: 15.4 KB (95.9%)
crypto-browserify: 14.8 KB (0.524%)
riot-route: 8.92 KB (0.316%)
debug: 8.91 KB (0.316%)
events: 8.13 KB (0.288%)
uuid: 5.54 KB (0.196%)
process: 5.29 KB (0.187%)
querystring-es3: 5.06 KB (0.179%)
obseriot: 4.43 KB (0.157%)
<self>: 27.78 KB (0.983%)

なるほど、AWS SDKですね、やっぱり。

なぜ大きくなっちゃうのか

Webpackによるバンドルではnpm installしたモジュールが全て闇雲にバンドルされるわけではありません。
結構賢くて実際に使われているものだけがバンドルされるように考えられています。具体的にはimport(require)されているモジュールだけを再帰的にたどって1つのJSファイルにまとめていきます。
つまり、importしているファイル数が多ければ多いほどバンドルされたファイルは大きくなります。

import AWS from "aws-sdk"

普通のサンプルだとAWS SDKを使うときはこのようにimportすると思います。これが大きな罠なのです。
AWS SDKのソースを見てみましょう。

lib/aws.js
// Load all service classes
require('../clients/all');

ここがサイズを肥大化させる要因となっています。全てのモジュールを読み込んでいるので使いもしないAWSの機能も含めて全て読み込んでしまっているのです。

どうしたらダイエットできるのか

http://docs.aws.amazon.com/ja_jp/sdk-for-javascript/v2/developer-guide/webpack.html#webpack-importing-services

を見てみると書いてあります。

The require() function specifies the entire SDK. A webpack bundle generated with this code would include the full SDK but the full SDK is not required when only the Amazon S3 client class is used.

require("aws-sdk")と書いてしまうと、たとえS3しか使わなくても全部の機能を読み込んでしまいます。
注) import from "aws-sdk"と書いても同じ意味になります。

その下の方に、

Here is what the same code looks like when it includes only the Amazon S3 portion of the SDK.

// Import the Amazon S3 service client
var S3 = require('aws-sdk/clients/s3');

// Set credentials and region
var s3 = new S3({
    apiVersion: '2006-03-01',
    region: 'us-west-1', 
    credentials: {YOUR_CREDENTIALS}
  });

と答えが載っています。

clientsディレクトリ以下のファイルを個別にimportすることができるようになっているということです。

なるほど、試してみた

https://github.com/NewGyu/riot-sample/compare/cognito-login…fat-cognito-login

$ $(npm bin)/webpack --json | webpack-bundle-size-analyzer 
aws-sdk: 325.01 KB (36.3%)
lodash: 100.65 KB (11.2%)
amazon-cognito-identity-js: 94.85 KB (10.6%)
 :

2.2MB -> 325KB と激ヤセです!

続きを読む

大量アクセスを捌けるシンプルなインフラ構成

◎はじめに

・今更ながら大量アクセスを捌けるシンプルなインフラ構成って、なんじゃらほい。
というわけで考えてみました。

01. 前提

・モデルは定期的に大量流入があるポータルサイト
・第一にアクセスを捌けること、第二に運用保守のことも(少し)考慮

02. 構成図

・それで考えてみた構成がコチラ(※1)
→ 利用ツールはCacoo。直感で書くことが出来便利、いつもお世話になっております。
構成案_20170615.png
(※1) 社内にある事例を参考にしておりますmm また、先輩に相談しながら作成しました。多謝!
→ けれど、この構成に矛盾や不備があれば私の責任ですmm

03. 説明

・上記構成図の簡単な補足になります。

03-1. CloudFrontってそんなに便利だったんですね。。

・画像や動画などコンテンツの配信はキャッシュサーバでもあるCloudFrontを使うのが定石。
ただITリテラシーの低い私は当初、CFへアクセスを振り分けるためにはHAProxyなどのリバースプロキシーが必要と考えていました。

が、不要でした。
シンプルにCloudFrontのDistributionにDNSを向け、アクセス毎に振り分け先を変更できるマルチオリジン機能があったからです。(※2)
これで画像や動画を指すURI(例: /img/*、 /*.mp4 など)を判別し適切なオリジン(今回は用途毎に別けたS3 bucket)へ振り分けてくれるようです。
その判別ルールに該当しなかったリクエストはELBに渡し、web/appサーバ側で処理するようにしています。

▽参考
・AWS Documentation – Amazon CloudFront

(※2)ははっ、最近実装された機能なんでしょ(汗)と思ったら、2012/05のAWSブログに当該機能の記載がありました。。反省

03-2. RDS(見たままです)

・RDSの便利な機能でRead Replicaを参照用として作成。
MasterのDBはMulti-AZにより冗長構成としています。
この構成にはありませんが、DBへの参照が頻繁にある場合は ElastiCache(Redis / Memcached)を構成に組み込むのも手かと思います。

03-3. 運用(ログ)

・アクセスログを取得したい場合
本構成ですと、CloudFront、ELB、Webサーバいずれからも取得が可能になります。
今回はELB と 各Webサーバ側でアクセスログを収集し、S3へ集約しています。
この2つとしたのは、
ELB側は固定のフォーマットになるのに対し、Webサーバ側は出力内容やフォーマットをカスタム出来るからです。
Webサーバ側からのログ転送には、Fluentdを使っているのをよく見掛けます。

03-4. 運用(スケールアウト)

・大量のアクセス流入が予想される場合
この構成ですと対処としてフロントサーバの台数を増やすことが考えられるかと思います。
その際、日々更新されるであろうサーバ内のアプリケーションやファイルをどうするかという問題がありますが、
こちらでは定期backupとは別に、大きな更新が行われた場合などにスケールアウト用のAMIを取得しておき、そちらからスケールアウトすることを想定しています。
ちなみにAuto Scalingを導入している場合は、このAMIを都度ASGに設定しておくといいかと思います。

・断りを入れておきますと、場合によって最適解は変わってくるかと思います。
以下に例を挙げてみます。

  • GitHubなどSubversionを利用してソースコードを一元管理、Launch時にそちらから最新のソースを取得する。
    → ソースが大きい場合、Launch/deployに時間が掛かりそうです。該当ソースが小さい場合はいい方法かもしれません。

  • コールドスタンバイさせたインスタンスを利用する。
    → 定期的、もしくは起動後にサーバ内を同期処理などによって最新にする必要があるため、時間が掛かりそうです。こちらも更新内容がそれほど無ければいい手段かと思います。

  • 最新サーバのコピーから等

03-5. 監視/セキュリティ対策

・構成図の隅にちょこんと記載していますが、外部の Datadog と DSaaSを想定しています。
理由は導入が楽だからです。
上述のスケールアウト時には、監視対象のインスタンスに事前に組み込んでおいたAgent主導により、自動で監視対象となります。
どちらも他の監視ソフト同様、設定は難しいですが、一度設定が確立すれば運用が楽になるかと思います。

◎おわりに

今回は脳内の想定したものをアウトプットしてみました。
PDCAもしくはTry & Errorが大切だと思いますので、近いうちに実際に手を動かし試し体感してみたいと思います。

以上になります。

続きを読む

Terraformを利用して、AWS EC2を作成してみた

概要

Terraformを利用してAWSのEC2を作成してみました。
terraformを実行するのはIAM Roleで権限を付与したインスタンスからになります。

ドキュメントを見るといろいろと出来そうですね。
https://www.terraform.io/docs/

コードは下記になります。
同じ階層のディレクトリに変数の設定を入れてあげてください。

ec2_dev.tf

provider "aws" {
  region = "${var.region}"
}

resource "aws_instance" "dev" {
    ami = "${var.ami_id}"
    instance_type = "${var.instance_type}"
    key_name = "${var.key_name}"
    iam_instance_profile = "${var.iam_role}"
    vpc_security_group_ids = [
        "${var.sg_id}"
    ]
    subnet_id = "${var.subnet_id}"
    associate_public_ip_address = "true"
    root_block_device {
        volume_type = "gp2"
        volume_size = "8"
        delete_on_termination = "true"
    }
    tags {
        Name = "${var.tag_name}"
        env = "${var.tag_env}"
    }
}

https://github.com/handa3/study/blob/master/terraform/ec2/ec2_dev.tf

続きを読む

AmazonLinuxでAWSのLocalStackインストール手順

リンク: https://github.com/atlassian/localstack

Dockerインストール

確認する:

$ sudo yum search docker
Loaded plugins: priorities, update-motd, upgrade-helper
========================================================================================= N/S matched: docker ==========================================================================================
docker-storage-setup.noarch : A simple service to setup docker storage devices
docker.x86_64 : Automates deployment of containerized applications
docker-devel.noarch : A golang registry for global request variables (source libraries)
docker-pkg-devel.noarch : A golang registry for global request variables (source libraries)

  Name and summary matches only, use "search all" for everything.


$ sudo yum info docker

Loaded plugins: priorities, update-motd, upgrade-helper
Available Packages
Name        : docker
Arch        : x86_64
Version     : 17.03.1ce
Release     : 1.50.amzn1
Size        : 22 M
Repo        : amzn-updates/latest
Summary     : Automates deployment of containerized applications
URL         : http://www.docker.com
License     : ASL 2.0 and MIT and BSD and MPLv2.0 and WTFPL
Description : Docker is an open-source engine that automates the deployment of any
            : application as a lightweight, portable, self-sufficient container that will
            : run virtually anywhere.
            :
            : Docker containers can encapsulate any payload, and will run consistently on
            : and between virtually any server. The same container that a developer builds
            : and tests on a laptop will run at scale, in production*, on VMs, bare-metal
            : servers, OpenStack clusters, public instances, or combinations of the above.

インストール:

$ sudo yum install -y docker

サービス起動

$ service docker start

LocalStackインストール

プロジェクトをクローンする

$ git clone https://github.com/atlassian/localstack.git

起動する:

make docker-run

# Or using docker-compose:

docker-compose up

続きを読む

Boto3を使ってAMIのNameのリスト一覧を取得してみた

Boto3を利用してAMIの一覧をリストで取得する処理を作成しました。
Owner_idにユーザのOwnerIDを入れると動きます。

リストの使い方などなんとなく覚えてきました。
for文で必要なところを抜き出してますが、もっと素敵があるとうれしいなと思います。

AWSのLambdaバージョンにすれば環境変数でOwnerIDも指定出来るのでGitで公開しやすいのですが・・・


# -*- coding: utf-8 -*-

# import
import boto3
from boto3.session import Session
from datetime import date, datetime, timedelta

ec2 = boto3.client('ec2')
list_ami = []
Owner_id = "ここにIDをいれる"

# def
def get_list_ami():
  response = ec2.describe_images(
    Owners = [Owner_id]
  )
  for list_id in response['Images']:
    list_ami.append(list_id['Name'])
  return list_ami

# Main
if __name__ == "__main__":
  get_list_ami()
  print list_ami

https://github.com/handa3/study/blob/master/aws/ec2/get_list_ami.py

続きを読む