ようへいの日々精進XP

おっさんの日記です。

体育会系 IDCF Cloud の仮想マシンを Vagrant 経由で起動する手順

参考

有難うございます。


事前の準備

  • 東日本又は西日本リージョンの API エンドポイントを確認しておく
  • API キーを確認しておく
  • Secret キーを確認しておく
  • SSH key にて鍵を発行しておく
  • IP アドレスの ID を確認しておく
  • Vagrant の導入、vagrant-cloudstack の導入

本記事の環境について

vagrant を実行する環境

ProductName:    Mac OS X
ProductVersion: 10.11.4
BuildVersion:   15E49a

vagrant のバージョン

Installed Version: 1.8.1
Latest Version: 1.8.1

vagrant-cloudstack の導入

vagrant plugin install vagrant-cloudstack

Vagrantfile の作成

作業ディレクトリの作成

mkdir ~/path/to/vagrant_idcf

vagrant init

cd ~/path/to/vagrant_idcf
vagrant init

vagrant init を実行すると Vagrantfile が生成される。

Vagrantfile

#
# 西日本リージョンにて仮想マシンを起動する例
#
Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider :cloudstack do |cloudstack, override|
    override.vm.box = "dummy"
    override.vm.box_url = "https://github.com/klarna/vagrant-cloudstack/raw/master/dummy.box"

    cloudstack.host                  = "compute.jp-west.idcfcloud.com"
    cloudstack.path                  = "/client/api"
    cloudstack.port                  = "443"
    cloudstack.scheme                = "https"
    cloudstack.api_key               = "API キー"
    cloudstack.secret_key            = "Secret キー"

    cloudstack.display_name          = "ubuntu"
    cloudstack.template_name         = "Ubuntu Server 14.04 LTS 64-bit"
    cloudstack.zone_name             = "augusta"
    cloudstack.service_offering_name = "light.S1"

    cloudstack.pf_ip_address_id      = "IP アドレスの ID"
    cloudstack.pf_public_port        = "22"
    cloudstack.pf_private_port       = "22"
    cloudstack.keypair               = "SSH 鍵名"
    override.ssh.private_key_path    = "SSH 秘密鍵ファイルへのパス"
    override.ssh.username            = "root"
  end
end

仮想マシンの起動、ログイン、停止、破棄

仮想マシンの起動

vagrant up --provider cloudstack 

仮想マシンへのログイン

vagrant ssh

仮想マシンの停止

vagrant halt

仮想マシンの破棄

vagrant destroy

以上

IDCF Cloud を Vagrant 経由で起動する手順でした。

弁当二十三日目

マンネリべんとぅ

マンネリべんとぅと言いつつうも新メニューを追加した。

  • ちくわとキュウリのポン酢漬け(New!!)
  • ウィンナーとしめじ、アスパラトマトの炒め
  • 俺の卵焼き

「ちくわとキュウリのポン酢漬け」が意外に好評だった。

Ansible で Windows のタスクスケジュールを登録する際のメモ(毎分のタスク登録ってどうするの?)

ども、かっぱです。

tl;dr

win_scheduled_task だけではやりたい事を実践出来なかったので、自分なりに試行錯誤したのでメモっておく。


参考


memo

試した環境

% ansible --version
ansible 2.0.1.0
  config file = 
  configured module search path = Default w/o overrides

win_scheduled_task モジュールで基本的にはなんとかなる

こちらのドキュメントのサンプルは以下の通り。

win_scheduled_task: name="TaskName" execute="cmd" frequency="daily" time="9am" description="open command prompt" path="example" enable=yes state=present user=SYSTEM

5 分ごとに実行させたいタスクの登録をどうするか

自分の探し方が悪いのかもしれないけど、上述の win_scheduled_task モジュールでは毎分で何かをさせるようなタスクを登録する方法を見つけることが出来なかった。

結局、自分は以下のような 2 種類の PowerShell スクリプトscript モジュールで叩かせるようにした。

#
# PowerShell Script(タスクの存在を確認)
# check_task.ps1 ${タスク名}
#
Get-ScheduledTask -TaskName $args[0] | select -First 1 TaskName -ExpandProperty TaskName

この PowerShell スクリプトを roles/${role_name}/files 以下に保存する。

#
# PowerShell Script(タスクの登録)
# regist_task.ps1 ${タスク名}
#
$Execute = 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
$Argument = '-Command "C:\path\to\scripts' +  $args[0] + '.ps1"'
$User = 'SYSTEM'
$Trigger = New-ScheduledTaskTrigger -Once -at '00:00:00' -RepetitionInterval '00:05:00' -RepetitionDuration ([timespan]::MaxValue)
$TaskPath = 'mytask'
$TaskName = $args[0]
$Description =  $args[0]

$Action = New-ScheduledTaskAction -Execute $Execute -Argument $Argument
$Settings = New-ScheduledTaskSettingsSet -Compatibility Win8 -Hidden
$principal = New-ScheduledTaskPrincipal -UserId $User -LogonType ServiceAccount

Register-ScheduledTask `
  -TaskPath $TaskPath `
  -TaskName $TaskName `
  -Description $Description `
  -Trigger $Trigger `
  -Action $Action `
  -Settings $Settings `
  -Principal $Principal

同じく、この PowerShell スクリプトを roles/${role_name}/files 以下に保存する。

  • 実際の Ansible タスク
#
# mytask schedule
#
- name: 登録済みタスクが無いかをチェックする
  script: files/check_task.ps1 mytask
  register: task_info

- name: デバッグ出力
  debug: var=task_info.stdout

- name: PowerShell スクリプトを利用してタスクを登録する
  script: files/regist_task.ps1 mytask
  when: task_info.stdout != "mytask\r\n"

実際に登録してみる

以下のように Playbook を実行してタスクを登録する。

% ansible-playbook -i inventories/hosts default.yml

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [my-sandbox]

TASK [regist_task : 登録済みタスクが無いかをチェックする] ****************************************
changed: [my-sandbox]

TASK [regist_task : デバッグ出力] ****************************************************
ok: [my-sandbox] => {
    "task_info.stdout": ""
}

TASK [regist_task : PowerShell スクリプトを利用してタスクを登録する] *****************************
changed: [my-sandbox]

PLAY RECAP *********************************************************************
my-sandbox                 : ok=4    changed=2    unreachable=0    failed=0

登録後...タスクスケジューラーを確認する。

f:id:inokara:20160323232348p:plain

再度、実行してみる。

% ansible-playbook -i inventories/hosts default.yml
PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [my-sandbox]

TASK [regist_task : 登録済みタスクが無いかをチェックする] ****************************************
changed: [my-sandbox]

TASK [regist_task : デバッグ出力] ****************************************************
ok: [my-sandbox] => {
    "task_info.stdout": "mytask\r\n"
}

TASK [regist_task : PowerShell スクリプトを利用してタスクを登録する] *****************************
skipping: [my-sandbox]

PLAY RECAP *********************************************************************
my-sandbox                 : ok=3    changed=1    unreachable=0    failed=0

一応、冪等性が担保されて Skipping となっていることを確認。


以上

もっとエレガントな方法求む

毎分の処理をタスクスケジューラに追加する場合に本当に script モジュールで PowerShell を叩くしか無いのか疑わしい!

でも

勉強になりました。

弁当二十二日目

べんとぅ、まだまだ続くばい。

海苔が無かったのでキャラ弁は作れなかった...残念。

おかずいつものように...

  • 俺の卵焼き
  • アスパラとウィンナーとしめじ&トマトの炒め
  • ちくわのキュウリ詰め

春もそこまで。

JAWS-UG 福岡「また濃い目にAWSの話をしてみよう」でデモは本番で必ず失敗するという教訓を得た

追記:登壇前のルーティーン


tl;dr

久し振りの JAWS-UG でお話をさせて頂いたのと、サーバーレスアーキテクチャの実例を学んだのと、付け焼き刃のデモはだいたい本番で失敗するという教訓を得たのでメモ。

jaws-ug-kyushu.doorkeeper.jp

参加された皆さん、大変お疲れ様でした。有難うございました!


資料

月額10円から作るServerLess Website(森田さん)

SESとLambdaでメールをSlackに通知してみよう(木村さん)

Visual StudioAWS開発してみよう(藤崎さん)

Serverlessでサイト監視(安土さん)

LT:AWSで自作CGIをサーバレス実装してみた ~その2~(夏目さん)

www.slideshare.net

LT:AWS x MLB(松村さん)

www.slideshare.net

Amazon ECS & Amazon ECR 試行錯誤(かっぱ)


ハイライト

参加者の半分以上が何かしら登壇する参加型勉強会

今回、参加者(15 人位だったかな...)の半分以上が何らかの形で登壇するという全員参加型の勉強会となった。こんなに話をする人がいる勉強会って珍しいし、色々な方の多種多様な AWS への関わり方だったり、身近なトピックスを聞くことが出来てとても良い勉強会になったと思う。

サーバレスアーキテクチャ + Lambda

この 2 ワードがホットキーワードだった。このワードを聞かない発表は無かったので時流を反映した貴重な発表ばかりだった。

Serverless というフレームワークを聞いたのも初めてだったし、チャットツール全盛とはいえ、業務内でメールは未だに必要なツールであることは間違いないけど、そのメールを Lambda や SES を利用して Slack で捕捉するという発想は無かったなあ。

月額 10 円と言えば、S3 がすぐに思いつくけど、S3 以外の各種サービスの特徴を色々と抑えた上で組み合わせることにより、ちょっとした動的サイトあれば低コストで構築出来るなんて素晴らしい!

Visual Studio すげえ

この手のツールとは無縁だったけど、IDE ツールから AWS のサービスリソースが弄ることが出来るのはスゴイなあと思った。

付け焼き刃のデモは必ず失敗する

Locust のスレーブノードコンテナを ECS 上で増殖されるデモが見事に失敗したので、改めて動画でアップする。

www.youtube.com

ということで、付け焼き刃のデモは必ず失敗するので仕込みは重要ということを痛感した。


ということで...

参加された皆さん、大変お疲れ様でした!

次は何を話せるかなあ。

Serverspec on Windows の process リソースの使い方メモ

tl;dr

Windows 上で起動しているプロセスを Serverspec でテストする際に調べたので自分メモ。


参考

github.com

serverspec.org

github.com


メモ

やりたかったこと

  • 対象の Windows ホスト上で自分で作った Python スクリプトが引数も含めて正常に動いているかについてチェックしたかった

オレオレスクリプト

以下のようにオレオレスクリプトを起動する。

PS C:\path\to\scripts> start python.exe .\o-re-no-service02.py

実行すると以下のようにコマンドプロンプトが立ち上がって、その中でスクリプトが起動する。

f:id:inokara:20160320190357p:plain

Serverspec on Windows ではどんな風にプロセスの情報を取得しているのか(超ザックリと)

こちらのドキュメントに書かれているように、Serverspec の command については全て PowerShell スクリプトを実行するようになっているので、プロセスの情報を取得する場合には以下のようなスクリプトが実行される(Cmdlet が実行される)。

例えば...

describe process("python.exe") do
  it { should be_running }
end

というテストがある場合には、Serverspec の process.rb から以下のメソッドが呼ばれる。

    def running?
      pid = @runner.get_process(@name, :format => "pid=").stdout
      not pid.empty?
    end

次に Specinfra の process.rb 内の以下のメソッドが呼ばる。

    def get(process, opts)
      column = opts[:format].chomp '='

      case column
      when 'pid'
        # map 'pid' to its windows equivalent
        get_process_property(process, 'processid')
      when 'user'
        %Q!gwmi win32_process -filter "name = '#{process}'" | select -first 1 | %{$_.getowner().user}!
      when 'group'
        # no concept of process group on Windows
        raise NotImplementedError.new('Unable to get process group on Windows')
      else
        get_process_property(process, column)
      end
    end

そして、マッチャが should be_running の場合には、opts[:format] には pid が指定されているので、同じ process.rb 内の以下の private メソッドget_process_property(process, processid) で呼び出す。

    def get_process_property(process, property)
      %Q!Get-WmiObject Win32_Process -Filter "name = '#{process}'" | select -First 1 #{property} -ExpandProperty #{property}!
    end

試しに上記のメソッド内で実行される PowerShell スクリプトを実行してみる。

PS C:\path\to\scripts> Get-WmiObject Win32_Process -Filter "name = 'python.exe'" | select -First 1 processid -ExpandProperty processid

以下のようにプロセス ID が返ってくる。

PS C:\path\to\scripts> Get-WmiObject Win32_Process -Filter "name = 'python.exe'" | select -First 1 processid -ExpandProperty processid
764

ということで...

引数も含めてプロセスが起動していることを確認したい場合にどうするか。

先ほどの PowerShell スクリプトをもう一度実行してみる。但し、以下のように絞込は行わず、全てのプロパティを出力してみる。

PS C:\path\to\scripts> Get-WmiObject Win32_Process -Filter "name = 'python.exe'" | select -First 1

以下のように出力される。

__GENUS                    : 2
__CLASS                    : Win32_Process
__SUPERCLASS               : CIM_Process
__DYNASTY                  : CIM_ManagedSystemElement
__RELPATH                  : Win32_Process.Handle="764"
__PROPERTY_COUNT           : 45
__DERIVATION               : {CIM_Process, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER                   : WIN-LLA3FAS3UBE
__NAMESPACE                : root\cimv2
__PATH                     : \\WIN-LLA3FAS3UBE\root\cimv2:Win32_Process.Handle="764"
Caption                    : python.exe
CommandLine                : "C:\Python27\python.exe" .\o-re-no-service02.py
CreationClassName          : Win32_Process
CreationDate               : 20160320094741.949928+000
CSCreationClassName        : Win32_ComputerSystem
CSName                     : WIN-LLA3FAS3UBE
Description                : python.exe
ExecutablePath             : C:\Python27\python.exe
ExecutionState             :
Handle                     : 764
HandleCount                : 68
InstallDate                :
KernelModeTime             : 156001
MaximumWorkingSetSize      : 1380
MinimumWorkingSetSize      : 200
Name                       : python.exe
OSCreationClassName        : Win32_OperatingSystem
OSName                     : Microsoft Windows Server 2012 Standard|C:\Windows|\Device\Harddisk0\Partition2
OtherOperationCount        : 2233
OtherTransferCount         : 36862
PageFaults                 : 1731
PageFileUsage              : 3292
ParentProcessId            : 1032
PeakPageFileUsage          : 3292
PeakVirtualSize            : 68542464
PeakWorkingSetSize         : 6712
Priority                   : 8
PrivatePageCount           : 3371008
ProcessId                  : 764
QuotaNonPagedPoolUsage     : 7
QuotaPagedPoolUsage        : 124
QuotaPeakNonPagedPoolUsage : 7
QuotaPeakPagedPoolUsage    : 124
ReadOperationCount         : 118
ReadTransferCount          : 493182
SessionId                  : 2
Status                     :
TerminationDate            :
ThreadCount                : 1
UserModeTime               : 624004
VirtualSize                : 68542464
WindowsVersion             : 6.2.9200
WorkingSetSize             : 6873088
WriteOperationCount        : 1797
WriteTransferCount         : 83834
PSComputerName             : WIN-LLA3FAS3UBE
ProcessName                : python.exe
Handles                    : 68
VM                         : 68542464
WS                         : 6873088
Path                       : C:\Python27\python.exe

上記を見ると、CommandLine というプロパティにスクリプトを実行した際の引数も出力されているので、この CommandLine を利用すれば良さそうということで、以下のようにテストを書いた。

describe process("python.exe") do
  it { should be_running }
  its(:CommandLine) { should match /o-re-no-service02.py/ }
end

そして、テスト

以下のようにテストは無事に通った。

f:id:inokara:20160320194736p:plain

良かった。


ということで

process リソースについては

Cmdlet の Get-WmiObject Win32_Process を利用していることが解ったので、必要に応じて Get-WmiObject Win32_Process の出力結果からチェックしたいプロパティをピックアップしてテストを書けば良いと思う。

以上

メモでした! 間違ってたらごめんなさい!

ECS + ecs-cli + Locust + consul でカヂュアルにスケールする負荷試験を構築する考察

ども、かっぱです。

tl;dr

考察シリーズ第三弾。

hakobera.hatenablog.com

上記の記事で紹介されていた「AWS ECS + Docker + Locust による負荷テスト」について、どんな風に実現するんだろうなあとずーっと気になっていたので、自分なりに ECS + Locust な負荷試験環境を考えてみたのでメモ。


メモ

こんな感じになった(ゴール)

f:id:inokara:20160319042029p:plain

ソースコードとか

github.com

何をする必要があったのか

  • Locust Master と Locust Slave をそれぞれ異なるタスクに分割する
  • 同一の ECS クラスタに Master と Slave を個別にデプロイする
  • コンテナインスタンスを跨って Locust クラサバ構成を構築する必要があったので etcd や Consul にお出まし頂いた(結局は Consul を採用した)

困った点

  • Docker Compose では docker-compose.yml 内に定義されている Service 毎に scale コマンドが発行することが出来たが、ecs-cli compose 経由だと Task 毎にしか scale することが出来ない
  • Consul も Docker コンテナで立ち上げているが、Consul コンテナは必ず各コンテナインスタンス上で起動する必要があるので手動でコンテナを起動する必要があった
  • Locust の Master ノードコンテナが起動しているコンテナインスタンス IP を保存するだけのみ Consul を動かしておくのはちょっと無駄が大きい(かも)
  • Consul クラスタの構成をどうするか(Atlas で Token を発行して --atlas-join を利用した)

Demo

  • 事前に Locust Master と Locust Slave コンテナをビルドして ECR あたりに push しておく
$ aws --region us-east-1 ecr get-login
$ docker login -u AWS -p xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -e none https://xxxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com
$ git clone https://github.com/inokappa/sample-ecs-locust.git
$ cd sample-ecs-locust
$ cd docker-locust-master
$ docker build 
$ docker build -f Dockerfile.master -t docker-locust-master .
$ docker tag docker-locust-master xxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-master
$ docker push xxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-master
$ cd ../docker-locust-slave
$ docker build -f Dockerfile.slave -t docker-locust-slave .
$ docker tag docker-locust-slave xxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-slave
$ docker push docker-locust-slave xxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-slave
$ ecs-cli up --keypair ${SSH_KEY_NAME} \
  --capability-iam \
  --size 2 \
  --vpc vpc-xxxxxxxx \
  --instance-type t2.small \
  --subnets subnet-xxxxxxxx,subnet-xxxxxxxx \
  --azs ap-northeast-1a,ap-northeast-1c

Consul も利用するので、Consul Server を動かすホスト(コンテナインスタンス)の数は奇数が望ましいけど、今回は検証ということでコンテナインスタンスは 2 台で起動する。

また、ecs-cli でコンテナインスタンスを起動した場合には、セキュリティグループは 0.0.0.0/0 で HTTP ポート(80 番)が開放されたルールのみがアタッチされるが、各コンテナインスタンス間で Consul の通信を許可するルールも追加する必要があるので注意する。

  • Consul コンテナの起動(事前に Atlas で token を発行しておくこと)
#
# 一台目のコンテナインスタンスで consul server を起動
# - -bootstrap オプションは古いオプションなので基本的には利用しない
#
$ docker run --net=host -d \
-p 8300:8300 \
-p 8301:8301/tcp \
-p 8302:8302/tcp \
-p 8301:8301/udp \
-p 8302:8302/udp \
-p 8303:8303 \
-p 8400:8400 \
-p 8500:8500 \
-p 8600:8600 \
--name consul-node01 \
gliderlabs/consul-server \
-server \
-bootstrap \
-advertise $(curl -s http://169.254.169.254/latest/meta-data/local-ipv4) \
-atlas=inokappa/demo01 --atlas-join --atlas-token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#
# 二台目のコンテナインスタンスで consul server を起動
#
$ docker run --net=host -d \
-p 8300:8300 \
-p 8301:8301/tcp \
-p 8302:8302/tcp \
-p 8301:8301/udp \
-p 8302:8302/udp \
-p 8303:8303 \
-p 8400:8400 \
-p 8500:8500 \
-p 8600:8600 \
--name consul-node02 \
gliderlabs/consul-server \
-server \
-advertise $(curl -s http://169.254.169.254/latest/meta-data/local-ipv4) \
-atlas=inokappa/demo01 --atlas-join --atlas-token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#
# consul クラスタの確認(consul クラスタ自体は 3 ノード以上で奇数ノードでの構成が望ましいので注意する)
#
$ docker exec -t -i consul-node02 consul members
Node           Address          Status  Type    Build  Protocol  DC
ip-10-0-0-164  10.0.0.164:8301  alive   server  0.6.3  2         dc1
ip-10-0-1-242  10.0.1.242:8301  alive   server  0.6.3  2         dc1
  • Locust Master コンテナを起動する
#
# environment で TARGET_HOST を指定する
#
$ vi ecs-compose-master.yml
master:
  image: xxxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-master
  cpu_shares: 100
  mem_limit: 268435456
  environment:
    - TARGET_HOST=http://kome.inokara.com


#
# Task として Locust Master コンテナを起動する
#
$ ecs-cli compose -f ecs-compose-master.yml up

以下のようにブラウザからアクセスすることが出来る。

f:id:inokara:20160319023249p:plain

また、consul には Locust の Master ノードコンテナが起動しているインスタンスのプライベート IP アドレスが登録されている。

$ curl 127.0.0.1:8500/v1/kv/locust/master/ip?raw
10.0.1.242
  • Locust Slave コンテナを起動する
#
# environment で TARGET_HOST を指定する
#
$ vi ecs-compose-slave.yml
slave:
  image: xxxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/docker-locust-slave
  cpu_shares: 100
  mem_limit: 268435456
  environment:
    - TARGET_HOST=http://example.inokara.com

#
# Task として Locust Slave コンテナを起動する
#
$ ecs-cli compose -f ecs-compose-slave.yml up

以下のように Slave が追加されたことを確認する。

f:id:inokara:20160319025038p:plain

  • 負荷試験を開始する

f:id:inokara:20160319025219p:plain

  • Locust Slave をスケールアウトする
#
# 最初の Slave 1 台から 3 台に増やす
#
$ ecs-cli compose -f ecs-compose-slave.yml scale 3

以下のように出力される。

INFO[0000] Starting container...                         container=79377890-bf38-483c-a516-e865c8951372/slave
INFO[0000] Starting container...                         container=9137b17d-fb67-4d7f-9e16-92281beab362/slave
INFO[0000] Describe ECS container status                 container=79377890-bf38-483c-a516-e865c8951372/slave desiredStatus=RUNNING lastStatus=PENDING taskDefinition=ecscompose-docker-locust-slave:3
INFO[0000] Describe ECS container status                 container=9137b17d-fb67-4d7f-9e16-92281beab362/slave desiredStatus=RUNNING lastStatus=PENDING taskDefinition=ecscompose-docker-locust-slave:3
INFO[0006] Started container...                          container=79377890-bf38-483c-a516-e865c8951372/slave desiredStatus=RUNNING lastStatus=RUNNING taskDefinition=ecscompose-docker-locust-slave:3
INFO[0006] Started container...                          container=9137b17d-fb67-4d7f-9e16-92281beab362/slave desiredStatus=RUNNING lastStatus=RUNNING taskDefinition=ecscompose-docker-locust-slave:3

3 台にスケールさせるということで、2 台のコンテナが追加される。どのコンテナインスタンスに追加されるかは ECS 次第となる。

f:id:inokara:20160319025524p:plain

  • Locust Slave をスケールインする
#
# 最初の Slave 1 台から 1 台に減らす
#
$ ecs-cli compose -f ecs-compose-slave.yml scale 1

以下のように出力される。

INFO[0000] Stopping container...                         container=79377890-bf38-483c-a516-e865c8951372/slave
INFO[0000] Stopping container...                         container=9137b17d-fb67-4d7f-9e16-92281beab362/slave
INFO[0000] Describe ECS container status                 container=79377890-bf38-483c-a516-e865c8951372/slave desiredStatus=STOPPED lastStatus=RUNNING taskDefinition=ecscompose-docker-locust-slave:3
INFO[0000] Describe ECS container status                 container=9137b17d-fb67-4d7f-9e16-92281beab362/slave desiredStatus=STOPPED lastStatus=RUNNING taskDefinition=ecscompose-docker-locust-slave:3
INFO[0006] Stopped container...                          container=79377890-bf38-483c-a516-e865c8951372/slave desiredStatus=STOPPED lastStatus=STOPPED taskDefinition=ecscompose-docker-locust-slave:3
INFO[0006] Stopped container...                          container=9137b17d-fb67-4d7f-9e16-92281beab362/slave desiredStatus=STOPPED lastStatus=STOPPED taskDefinition=ecscompose-docker-locust-slave:3

1 台にスケールダウンさせるということで、2 台のコンテナが削除される。

f:id:inokara:20160319030951p:plain


最後に

課題

  • コンテナインスタンスの Auto Scaling をどうする?
  • たまに Master / Slave コンテナが正常に終了しない

ということで...

  • Quipper さんでは ECS + Locust をどのように実装し、活用しているのかめっちゃ気になる次第。機会があれば、是非お話しを伺いたい次第。