読者です 読者をやめる 読者になる 読者になる

ようへいの日々精進XP

よかろうもん

PowerShell で操作する Azure メモ(1)

Azure 雑なメモ

ども、かっぱです。

tl;dr

mva.microsoft.com

上記の資料を参考に操作したメモ。

尚、操作する環境は以下の通り。

PS C:\Users\Administrator\Downloads> [System.Environment]::OSVersion

                          Platform ServicePack                        Version                            VersionString
                          -------- -----------                        -------                            -------------
                           Win32NT                                    6.3.9600.0                         Microsoft Windows NT 6.3.9600.0

PS C:\Users\Administrator\Downloads> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.42000
BuildVersion                   6.3.9600.17400
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2

仮想マシンを操作する

要件

クラウドサービスを作成する

run

New-AzureService -ServiceName "oreno-cloudservice" -Location "Japan West" -Label "oreno-cloudservice"

output

OperationDescription                    OperationId                             OperationStatus
--------------------                    -----------                             ---------------
New-AzureService                        xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx    Succeeded

Ubuntu Server 16.04 の OS イメージを取得する

run

$ImageName = @(Get-AzureVMImage `
| ? {$_.OS -eq "Linux" -and $_.ImageFamily -eq "Ubuntu Server 16.04 LTS"} `
| Sort-Object PublishedDate –Descending `
| Select-Object -First 1).ImageName

confirm

PS C:\Users\Administrator> $ImageName
b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-16_04-LTS-amd64-server-20160815-en-us-30GB

以下のように実行すると OS イメージの各種情報が一覧で取得することが出来る。(参考:Windows Azure 仮想マシンの展開可能なイメージ一覧を取得する

run

Get-AzureVMImage | Sort-Object OS,Label,PublishedDate | Format-Table OS,Label,PublishedDate,ImageName -AutoSize

New-AzureQuickVM を利用して仮想マシンを起動する

run

New-AzureQuickVM `
  -Linux `
  -ImageName $ImageName `
  -LinuxUser "ubuntu" `
  -Password "xxxxxxxxxxxxxxxxxxx" `
  -ServiceName "oreno-cloudservice" `
  -Name "vm01" `
  -InstanceSize "ExtraSmall" `
  -Location "Japan West" `
  -Verbose

New-AzureQuickVM `
  -Linux `
  -ImageName $ImageName `
  -LinuxUser "ubuntu" `
  -Password "xxxxxxxxxxxxxxxxxxx" `
  -ServiceName "oreno-cloudservice" `
  -Name "vm02" `
  -InstanceSize "ExtraSmall" `
  -Location "Japan West" `
  -Verbose
#
# 気付いた点
# - ログインユーザー名に admin は利用出来ない
# - パスワードには、小文字 / 大文字 / 数字 / 記号のうち 3 種類の文字を含める必要がある
#

output

警告: No deployment found in service: 'oreno-cloudservice'.
詳細: 9:36:33 - Begin Operation: New-AzureQuickVM
詳細: 9:36:33 - Completed Operation: New-AzureQuickVM
詳細: 9:36:34 - Begin Operation: New-AzureQuickVM - Create Deployment with VM vm01

OperationDescription                    OperationId                             OperationStatus
--------------------                    -----------                             ---------------
New-AzureQuickVM                        xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx    Succeeded
詳細: 9:37:39 - Completed Operation: New-AzureQuickVM - Create Deployment with VM vm01

インスタンスサイズの指定

インスタンスサイズは以下のような指定を行う。(参考:Azure の仮想マシンのサイズ

  • Basic_A0: Basic_A0
  • Basic_A1: Basic_A1...(A4 まで Basic_A4)
  • Standard_A0: ExtraSmall
  • Standard_A1: Small
  • Standard_A2: Medium
  • Standard_A3: Large
  • Standard_A4: ExtraLarge
  • Standard_A5: A5
  • Standard_A6: A6...(A11 まで A11)
  • D1: Standard_D1
  • D2: Standard_D2...(D14 まで Standard_D14)

仮想マシンを確認する

confirm

PS C:\Users\Administrator> Get-AzureVM

ServiceName                             Name                                    Status
-----------                             ----                                    ------
oreno-cloudservice                      vm01                                    RoleStateUnknown
oreno-cloudservice                      vm02                                    RoleStateUnknown

仮想マシンを停止する

confirm

PS C:\Users\Administrator\Downloads> Stop-AzureVM -ServiceName "oreno-cloudservice" -Name "vm03"

確認
The specified virtual machine is the last virtual machine in this deployment. Continuing will result in a new IP address for your
deployment. To shut down without losing the deployment IP use -StayProvisioned.
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): Y

OperationDescription                           OperationId                                    OperationStatus
--------------------                           -----------                                    ---------------
Stop-AzureVM                                   xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx           Succeeded


PS C:\Users\Administrator\Downloads> Stop-AzureVM -ServiceName "oreno-cloudservice" -Name "vm02" -Force

OperationDescription                           OperationId                                    OperationStatus
--------------------                           -----------                                    ---------------
Stop-AzureVM                                   xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx           Succeeded

仮想マシンを削除する

confirm

PS C:\Users\Administrator\Downloads> Remove-AzureVM -ServiceName "oreno-cloudservice" -Name "vm01"

OperationDescription                           OperationId                                    OperationStatus
--------------------                           -----------                                    ---------------
Remove-AzureVM                                 xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx           Succeeded


PS C:\Users\Administrator\Downloads> Remove-AzureVM -ServiceName "oreno-cloudservice" -Name "vm02"

OperationDescription                           OperationId                                    OperationStatus
--------------------                           -----------                                    ---------------
Remove-AzureVM                                 xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx           Succeeded

memo

New-AzureQuickVM : CurrentStorageAccountName is not accessible. エラーの対処

エラー

New-AzureQuickVM 実行時に以下のようなエラーを確認。

  • output
警告: No deployment found in service: 'oreno-cloudservice'.
New-AzureQuickVM : CurrentStorageAccountName is not accessible. Ensure the current storage account is accessible and in the same location or affinity group as your cloud service.
発生場所 行:1 文字:1
+ New-AzureQuickVM `
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureQuickVM]、ArgumentException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.PersistentVMs.NewQuickVM

サブスクリプションCurrentStorageAccountName が以下のように未定義な為に発生する。ストレージアカウントを作成して CurrentStorageAccountNameStorageAccountName を定義する必要がある。

  • confirm
PS C:\Users\Administrator\Downloads> Get-AzureSubscription


SubscriptionId            : 123456789-1234-1234-1234-123456789012
SubscriptionName          : XXXXXXXXXXXX
Environment               : AzureCloud
DefaultAccount            : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
IsDefault                 : True
IsCurrent                 : True
TenantId                  :
CurrentStorageAccountName :

サブスクリプションを Import した直後は上記のように CurrentStorageAccountName が空欄になっていた。

ストレージアカウントを作成

  • run
New-AzureStorageAccount `
  -StorageAccountName "xxxxxxxxxxxx" `
  -Label "xxxxxxxxxxxx" `
  -Location "Japan West" `
  -Type "Standard_LRS"

ストレージアカウントタイプ(-type)は以下の何れかを指定する。

-type で指定する値 ストレージタイプ
Standard_LRS 標準的なローカル冗長ストレージ
Standard_ZRS 標準ゾーン冗長ストレージ
Standard_GRS 標準的な地理冗長ストレージ
Standard_RAGRS 標準の読み取りアクセス地理冗長ストレージ
  • output
OperationDescription                    OperationId                             OperationStatus
--------------------                    -----------                             ---------------
New-AzureStorageAccount                 xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx    Succeeded
  • confirm
PS C:\Users\Administrator\Downloads> Get-AzureStorageAccount


Context                   : Microsoft.WindowsAzure.Commands.Common.Storage.LazyAzureStorageContext
StorageAccountDescription :
AffinityGroup             :
Location                  : Japan West
GeoPrimaryLocation        : Japan West
GeoSecondaryLocation      :
Label                     : xxxxxxxxxxxx
StorageAccountStatus      : Created
StatusOfPrimary           : Available
StatusOfSecondary         :
Endpoints                 : {https://xxxxxxxxxxxx.blob.core.windows.net/, https://xxxxxxxxxxxx.queue.core.windows.net/,
                             https://xxxxxxxxxxxx.table.core.windows.net/, https://xxxxxxxxxxxx.file.core.windows.net/}
AccountType               : Standard_LRS
LastGeoFailoverTime       :
MigrationState            :
StorageAccountName        : xxxxxxxxxxxx
OperationDescription      : Get-AzureStorageAccount
OperationId               : xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
OperationStatus           : Succeeded

カレントサブスクリプションにストレージアカウントを設定

  • run
Set-AzureSubscription `
  -SubscriptionName "XXXXXXXXXXXX" `
  -CurrentStorageAccountName (Get-AzureStorageAccount).StorageAccountName `
  -PassThru
  • output
Id          : 123456789-1234-1234-1234-123456789012
Name        : XXXXXXXXXXXX
Environment : AzureCloud
Account     : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
State       :
Properties  : {[Default, True], [StorageAccount, BlobEndpoint=https://xxxxxxxxxxxx.blob.core.windows.net/;QueueEndpoint
              =https://xxxxxxxxxxxx.queue.core.windows.net/;TableEndpoint=https://xxxxxxxxxxxx.table.core.windows.net/;
              FileEndpoint=https://xxxxxxxxxxxx.file.core.windows.net/;AccountName=xxxxxxxxxxxx;AccountKey=xxxxxxxxxxxx
              xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]}
  • confirm
PS C:\Users\Administrator\Downloads> Get-AzureSubscription


SubscriptionId            : 123456789-1234-1234-1234-123456789012
SubscriptionName          : XXXXXXXXXXXX
Environment               : AzureCloud
DefaultAccount            : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
IsDefault                 : True
IsCurrent                 : True
TenantId                  :
CurrentStorageAccountName : xxxxxxxxxxxx

仮想マシンの階層とサイズ

基本階層

- A シリーズ
 - 負荷分散機能と自動スケール機能が無い
 - ディスクの IOPS は 300

標準階層

- 負荷分散機能が利用可能
- 高可用セットを設定することで、自動スケールを構成が可能
- A / D / G シリーズ
- A シリーズ
 - IOPS は 500
- D シリーズ
 - A シリーズの 2 倍のメモリ構成
 - 一時ディスクに SSD を使用
- G シリーズ
 - Xeon プロセッサ E5 v3 と D シリーズの 2 倍のメモリ
 - データディスクにプレミアムストレージを使用出来る(最大で 6.59TB x 64 まで) 

Amazon ECR が東京リージョンで利用出来るようになったのでメモ

aws ECR 雑なメモ

ども、かっぱです。

YOKOSO 東京へ

待ちにまった ECR が東京リージョンで利用出来るようになったのでメモ。

うんちくは割愛、CLI のチートみたいな感じで。

ちなみに、今までの ECR 遍歴については本ブログの ECR カテゴリをご覧くさい。

memo

試した環境

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G31

$ aws --version
aws-cli/1.10.41 Python/2.7.10 Darwin/15.6.0 botocore/1.4.31

docker login する為のトークンを取得

  • run
$ aws --region ap-northeast-1 ecr get-login
  • output
docker login -u AWS -p xxx -e none https://xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com

ECR にログインする

  • run
$ docker login -u AWS -p xxx -e none https://xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com
  • output
WARNING: login credentials saved in /Users/xxxxx/.docker/config.json
Login Succeeded
  • run / output
$ cat ~/.docker/config.json
{
        "auths": {
                "https://xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com": {
                        "auth": "yyyy",
                        "email": "none"
                },
                "https://xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com": {
                        "auth": "xxxx",
                        "email": "none"
                }
        }
}

ECR にリポジトリを作成

  • run
$ aws --region ap-northeast-1 ecr create-repository --repository-name oreno-image
  • output
{
    "repository": {
        "registryId": "xxxxxxxxxxxx",
        "repositoryName": "oreno-image",
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxxxxxxxxx:repository/oreno-image",
        "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/oreno-image"
    }
}

タグ付けからの docker push

  • run
$ docker tag busybox xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/oreno-image
$ docker push xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/oreno-image
  • output
The push refers to a repository [xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/oreno-image]
5f70bf18a086: Pushed
1834950e52ce: Pushed
latest: digest: sha256:xxx size: 1920

ECR 上のリポジトリを確認

  • run
$ aws --region ap-northeast-1 ecr describe-repositories
  • output
{
    "repositories": [
        {
            "registryId": "xxxxxxxxxxxx",
            "repositoryName": "oreno-image",
            "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxxxxxxxxx:repository/oreno-image",
            "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/oreno-image"
        }
    ]
}

リポジトリ上のイメージを確認

  • run
$ aws --region ap-northeast-1 ecr list-images --repository-name oreno-image
  • output
{
    "imageIds": [
        {
            "imageTag": "latest",
            "imageDigest": "sha256:xxx"
        }
    ]
}

以上

メモでした。

Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ(2)〜 AWS CLI で試す 〜

aws ECS ALB 雑なメモ

エブリデイ試した系ですいません。かっぱです。

tl;dr

inokara.hateblo.jp

の続き。

AWS CLI で ALB を作成して ECS の Service を作成して ALB と組み合わせてみる。尚、ALB を操作するには elbv2 というサブコマンドを利用する。

メモ

ちょっとウンチク

ここまで試してきて Amazon ECS と AWS Application Load Balancer は以下のような構成になっていると理解。

f:id:inokara:20160816092039p:plain

  • Listner で ALB がインターネットからの接続を何番ポートで Listen するか定義する
  • Path Pattern 毎に Target Group を定義する
  • Target Group には EC2 インスタンスやコンテナをぶら下げることが出来る(バックエンドへのルーティングやヘルスチェックについて定義する)

ALB の詳細については以下の Blog 記事はドキュメントと並んでとても参考になる。

dev.classmethod.jp

また、ALB についての制限事項については以下のドキュメントには目を通しておきたい。

docs.aws.amazon.com

試した環境

Amazon ECS や AWS Application Load Balancer を操作する環境としては...

% sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G24b

% aws --version
aws-cli/1.10.56 Python/2.7.6 Darwin/15.6.0 botocore/1.4.46

ECS については...

  • クラスタ作成済み(コンテナインスタンスは 2 台)
  • Task Definition は ecscompose-ecs-app:22 を利用
  • Container Name は app とする
  • コンテナアプリケーションはコンテナ内で Port 4567 で Listen する
  • Task は /hostname という URL にアクセスするとコンテナのホスト名を返す

ざっくり流れ

  1. ALB ロードバランサの作成
  2. ALB ターゲットグループの作成
  3. ALB リスナーの作成
  4. ALB ターゲットグループを指定して ECS Service を作成

ALB の作成

% cat alb.json
{
    "Name": "alb-demo", 
    "Subnets": [
        "subnet-12345678",
        "subnet-abcdefgh"
    ], 
    "SecurityGroups": [
        "sg-12345678"
    ] 
}
  • run
% ELB_ARN=$(aws --debug \
  elbv2 create-load-balancer \
    --cli-input-json file://alb.json | jq -r '.LoadBalancers[].LoadBalancerArn')
  • 確認
% aws \
  elbv2 describe-load-balancers
  • 念のため削除(消す必要が無ければ叩かない)
% aws \
  elbv2 delete-load-balancer \
    --load-balancer-arn ${ELB_ARN}

ターゲットグループ作成

% cat target-group.json
{
    "Name": "default", 
    "Protocol": "HTTP", 
    "Port": 80, 
    "VpcId": "vpc-xxxxxxxx",
    "HealthCheckPath": "/hostname", 
    "HealthCheckIntervalSeconds": 30, 
    "HealthCheckTimeoutSeconds": 15, 
    "HealthyThresholdCount": 3, 
    "UnhealthyThresholdCount": 3, 
    "Matcher": {
        "HttpCode": "200"
    }
}

以下のように HealthCheckPort を指定しない場合には traffic-port という値が入る。Amazon ECS のコンテナをぶら下げる場合には Docker から払いだされたポートに対するヘルスチェックとなるので HealthCheckPort は指定しない。

% aws elbv2 describe-target-groups
{
    "TargetGroups": [
        {
            "HealthCheckPath": "/hostname", 
            "HealthCheckIntervalSeconds": 30, 
            "VpcId": "vpc-xxxxxxxxx", 
            "Protocol": "HTTP", 
            "HealthCheckTimeoutSeconds": 15, 
            "HealthCheckProtocol": "HTTP", 
            "LoadBalancerArns": [
                "arn:aws:elasticloadbalancing:ap-northeast-1:1234567890123:loadbalancer/app/alb-demo/1234567890123456"
            ], 
            "UnhealthyThresholdCount": 3, 
            "HealthyThresholdCount": 3, 
            "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:1234567890123:targetgroup/default/1234567890123456", 
            "Matcher": {
                "HttpCode": "200"
            }, 
            "HealthCheckPort": "traffic-port", 
            "Port": 80, 
            "TargetGroupName": "default"
        }
    ]
}
  • run
% TARGET_GROUP=$(aws --debug \
  elbv2 create-target-group \
    --cli-input-json file://target-group.json | jq -r '.TargetGroups[].TargetGroupArn')
  • 確認
% echo ${TARGET_GROUP}

リスナーの作成

  • run
% aws \
  elbv2 create-listener \
    --load-balancer-arn ${ELB_ARN} \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=${TARGET_GROUP}

ECS Service の作成

  • ecs-simple-service-elb.json
% cat ecs-simple-service-elb.json
{
    "serviceName": "ecs-simple-service-elb",
    "taskDefinition": "ecscompose-ecs-app:22",
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxxxx:targetgroup/default/zzzzzzzzzzzzzzzz",
            "containerName": "app",
            "containerPort": 4567
        }
    ],
    "desiredCount": 2,
    "role": "ecsServiceRole"
}
  • run
aws \
  ecs create-service \
    --cluster ecs-demo \
    --service-name ecs-simple-service-elb \
    --cli-input-json file://ecs-simple-service-elb.json

ここまでで...

  • ALB とリスナー

f:id:inokara:20160813233133p:plain

  • ターゲットグループ(ヘルスチェックが適切では無かったので unhealthydraining を繰り返している... )

f:id:inokara:20160813233346p:plain

  • ECS Service

f:id:inokara:20160813233821p:plain

確認

  • run
% URL=$(aws \
  elbv2 describe-load-balancers \
    --query 'LoadBalancers[].DNSName' \
    --output text)

% echo ${URL}
% curl ${URL}
% curl ${URL}/hostname
  • output
% curl ${URL}/hostname
e80f74a9026f%
% curl ${URL}/hostname
af8647af702e%
% curl ${URL}/hostname
5963b959e447%

その他メモ

ecs-cli で ECS クラスタ作成

--subnets--azs 等の複数指定出来るパラメータの値はカンマで区切ること。スペースでは無いので注意。(aws cli はスペースで区切るという違いがある。)

% ecs-cli up \
  --keypair ${KEY_NAME} \
  --capability-iam \
  --size 1 \
  --vpc vpc-xxxxxxxx \ 
  --instance-type t2.micro \
  --subnets subnet-xxxxxxxx,subnet-zzzzzzzz \
  --azs ap-northeast-1a,ap-northeast-1c \
  --security-group sg-xxxxxxxx

ecs-agent が止まるとどうなるのか

ALB と ECS を連携させた状態で ecs-agent を止めてみると...

  • 起動している Task(コンテナ)は維持される
  • ALB にぶら下がっている Task(コンテナ)にも正常にアクセス出来る

更にこの状態で一つの Task を Stop Container してみると...

  • ALB のヘルスチェックが失敗して停止したコンテナは unhealthydraining に状態が変化する(ALB から切り離される)
  • draining に遷移したタイミングで Running tasks count が 1 つ減る

ここで疑問、ecs-agent が動いていない状態でもクラスタの状態は何らかの方法で管理されている?

Amazon ECS と AWS Application Load Balancer の組み合わせを試しているメモ

ECS aws 雑なメモ ALB

ども、ECS は最近全然触れていないかっぱです。

追記

AWS CLI のでも操作してみた。

inokara.hateblo.jp

tl;dr

先日、AWS Application Load Balancer がリリースされて、Amazon ECS の Dynamic Port Mapping にも対応されたとのことで、ECS と Application Load Balancer の組み合わせを試行錯誤している。内容な認識等に誤りがあるかもしれないのでご容赦下さい。

試した環境

手元の環境

% sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.6
BuildVersion:   15G24b

% ecs-cli --version
ecs-cli version 0.4.2 (9159726)

ECS

  • amzn-ami-2016.03.f-amazon-ecs-optimized (ami-ed26e78c)
  • ECS のクラスタは ecs-cli で作成済み
  • マネジメントコンソールより ECS の Service を作成していく
  • Service 内で起動する Task はコンテナ自身のホスト名を返す Sinatra アプリケーション(コンテナ内で 4567 ポートで Listen する)

memo

以下、殴り書き。(後で整理するかも)

  • 事前に Application Load Balancer を作っておく(以後、Application Load Balancer を ALB と記す)
  • ALB 作成の際にはターゲットグループを一つ作る必要がある(ターゲットにインスタンスを登録する必要は無い)
  • ターゲットグループを消す時にはALB を消してからターゲットグループを削除した方が良さそう(リスナーの定義を先に消せば良い)
  • 下図のように ECS の Service 作成時に ALB を指定することが出来る(ターゲットグループが生成される)

f:id:inokara:20160813103607p:plain

f:id:inokara:20160813103618p:plain

ecsServiceRole という IAM Role が付与される。この Role には AmazonEC2ContainerServiceRole というマネジメントポリシーが適用されている。

f:id:inokara:20160813103632p:plain

f:id:inokara:20160813103648p:plain

f:id:inokara:20160813103833p:plain

  • 既存の ECS Service には追加出来ない?(Service 作成時のみ ELB 定義が出来るようだ)
  • Container Instance に付ける Security Group は ALB に付与した Security Group から Container の Dynamic Port にアクセス出来るようなルールを定義しておく
source: public-access
protocol: TCP
port range: 0-65535

f:id:inokara:20160813101535p:plain

  • ルーティングのルールはロードバランサーの一覧にて該当の ALB を指定してリスナーで修正する

f:id:inokara:20160813102651p:plain

/* としておくとクライアントのリクエストをそのままバックエンドに流すような挙動になった。

  • ALB に登録されたコンテナにアクセスしてみる
% curl -v alb-ecs-demo-xxxxxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com/hostname
*   Trying 54.xx.xxx.xxx...
* Connected to alb-ecs-demo-xxxxxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com (54.xx.xxx.xxx) port 80 (#0)
> GET /hostname HTTP/1.1
> Host: alb-ecs-demo-xxxxxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sat, 13 Aug 2016 01:39:01 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 12
< Connection: keep-alive
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< * Connection #0 to host alb-ecs-demo-xxxxxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com left intact
59294f32f412
  • 当たり前だのクラッカーだけど Task のスケールアウトにも追随してくれる
#
# Task を 3 つに増やした後にアクセス
#
% curl alb-ecs-demo-1930795025.ap-northeast-1.elb.amazonaws.com/hostname
79a796b62150%                                                                                                                                                                                    
% curl alb-ecs-demo-1930795025.ap-northeast-1.elb.amazonaws.com/hostname
68cb8177a441%
% curl alb-ecs-demo-1930795025.ap-northeast-1.elb.amazonaws.com/hostname                                                                               59294f32f412% 

まとまってないけどまとめ

  • まさに産業革命
  • Dynamic Port Mapping やりくりする為に HAProxy とか入れなくても良くなったのは嬉しい
  • 後で CLI でもやってみる

ラムダこりゃ(Amazon Lambda チュートリアル 6)〜 AWS Lambda で JRuby を 30 分位試したメモ 〜

Lambda JRuby Ruby 雑なチュートリアル 雑なメモ

まったく筆が乗らないかっぱです。

tl;dr

aws.typepad.com

8/9 の AWS上でのサーバーレスアーキテクチャ入門 を何気なく聞いていたら JRuby という単語が聞こえてきたので、「あー、確かに Lambda で Java は動くから JRuby を使えば内部処理は Ruby で書けるんぢゃないかな」と思ってググッてみたら...

github.com

qiita.com

株式会社ソラコムの片山さん が既に上記のようなプロジェクトを作られていたので、参考にさせて頂きつつ試してみることにした。

memo

git clone してくる

git clone https://github.com/c9katayama/aws-lambda-jruby.git 

Ruby で内部処理を書く

src/main/resources/main.rb に Ruby で以下のような内部処理を書く。Lambda が受け取った引数を使って足し算して結果を返すだけ。(せっかくなので定数で定義されている Ruby のバージョン等も出力するようにしてみた。)

require "yaml"
require "json"
require "java"

json = JSON.load $lambda_arg
# json = JSON.load '{"a": 1, "b": 2, "c": 3}'

hash = java.util.HashMap.new

result = json["a"] + json["b"] + json["c"]

hash.put("ruby_version", RUBY_VERSION)
hash.put("ruby_description", RUBY_DESCRIPTION)
hash.put("ruby_platform", RUBY_PLATFORM)
hash.put("result", result)

return hash
# return { ruby_version: RUBY_VERSION, result: result.to_s }

Java の HashMap クラスを呼べたりするのが新鮮。

ビルドする

cd aws-lambda-jruby
./gradlew build

Lambda Function を作ってアップロードする

f:id:inokara:20160811183334p:plain

メモリ容量は 512MB 以上を指定しておかないとメモリ不足のエラーとなるので注意。

動作確認

以下のようにテストデータを用意。

f:id:inokara:20160811183724p:plain

Test ボタンをポチッとな。

f:id:inokara:20160811185351p:plain

API Gateway を絡める

せっかくなので API Gateway と絡めてみる。

f:id:inokara:20160811184029p:plain

以下のように curl で呼んでみる。

% curl -s -d '{"a": 1000, "b": 2, "c": 4}' https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/jruby-test
"{result=1006, ruby_description=jruby 9.0.0.0 (2.2.2) 2015-07-21 e10ec96 OpenJDK 64-Bit Server VM 25.77-b03 on 1.8.0_77-b03 +jit [linux-amd64], ruby_platform=java, ruby_version=2.2.2}"

最後に

出来なかったこと

結局

Lambda Funciton を直接 Ruby で書けるというわけではないけど、内部処理を Java よりちょっと身近な Ruby で書けるのは色々と夢が広がりそうな気がした。


Lambda 関係無いけど

@yoshidashingo さんのツイートで確認。ELB にアプリケーションロードバランサの昨日が追加されてて驚いた。

f:id:inokara:20160812005102p:plain

Docker for Windows をあと 10 分位使ってみた(Shared Drives を触る)

Docker Windows 雑なメモ

tl;dr

Docker for Windows の Settings... に Shared Drives という設定があったので触ってみた。

f:id:inokara:20160807220753p:plain

どうやらホスト OS のドライブ(フォルダ)を Docker のボリュームオプションを使ってマウントする為の設定らしい。


メモ

Shared Drives を有効にする

f:id:inokara:20160807221250p:plain

コンテナからマウントして操作する

docker run のボリュームオプションを利用してホスト OS のフォルダをマウントする。

PS C:\Users\kappa> dir .\Documents\tmp\docker\


    ディレクトリ: C:\Users\kappa\Documents\tmp\docker


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2016/08/07     22:06                test01
d-----       2016/08/07     22:06                test02
d-----       2016/08/07     22:06                test03
-a----       2016/08/07     22:06              0 テスト.txt


PS C:\Users\kappa> docker run -v C:/Users/kappa/Documents/tmp/docker:/data alpine ls /data
PS C:\Users\kappa>
PS C:\Users\kappa> docker run -v C:/Users/kappa/Documents/tmp/docker:/data alpine ls /data
test01
test02
test03
テスト.txt

マウントしたフォルダにコンテナからファイルを作成。

PS C:\Users\kappa> docker run -v C:/Users/kappa/Documents/tmp/docker:/data alpine touch /data/test.txt
PS C:\Users\kappa> dir .\Documents\tmp\docker


    ディレクトリ: C:\Users\kappa\Documents\tmp\docker


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2016/08/07     22:06                test01
d-----       2016/08/07     22:06                test02
d-----       2016/08/07     22:06                test03
-a----       2016/08/07     22:17              0 test.txt
-a----       2016/08/07     22:06              0 テスト.txt

おお。

以上

プラス 10 分位使ってみたメモでした。

Docker for Windows を 15 分くらい使ってみた

Docker Windows 超メモ

tl;dr

Docker for Windows が 7/28 位に正式にリリースされたらしいので試してみたメモ。

blog.docker.com

docs.docker.com

興味深いのが Docker for Windows仮想マシンHyper-V を利用している点。普通に使う分には Hyper-V を使っていることはユーザーは意識することは無いと思うけど。

導入

要件

  • 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later). In the future we will support more versions of Windows 10.
  • The Hyper-V package must be enabled. The Docker for Windows installer will enable it for you, if needed. (This requires a reboot).

64 ビット版の Windows 10 で Pro / Enterprise / Education で Hyper-V が有効になっていること。

今回利用する OS は...

f:id:inokara:20160807213609p:plain

ざっくりとしたハードウェア構成は...

f:id:inokara:20160807213736p:plain

導入手順

以下のページのまま。

docs.docker.com

インストールが完了後、再起動すると Docker Engine が起動し、タスクバーに Docker アイコンが登録される。

f:id:inokara:20160807103948p:plain

右クリックすると以下のようなメニューが出てくる。

f:id:inokara:20160807105126p:plain

About Docker を選択してみる。

f:id:inokara:20160807104218p:plain

Settings.. を選択してみる。

f:id:inokara:20160807105208p:plain

色々と...PowerShell を使って触ってみる

docker version

PS C:\Users\kappa> docker version
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:15:28 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:15:28 2016
 OS/Arch:      linux/amd64

docker info

PS C:\Users\kappa> docker info
Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 2
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 13
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null bridge overlay host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.15-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952 GiB
Name: moby
ID: FZB3:32TQ:3MCG:MYMU:ES7Z:HRVA:3BQB:VDR3:7YXR:F3HL:B5S6:XSUJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

お、Alpine Linux が動いているのか。

仮想マシン

Hyper-V 上で動いている仮想マシンの状態を確認してみる。

PS C:\WINDOWS\system32> Get-VM

Name        State   CPUUsage(%) MemoryAssigned(M) Uptime           Status     Vers
----        -----   ----------- ----------------- ------           ------     ----
MobyLinuxVM Running 0           2048              01:34:33.4740000 正常稼働中 8.0

管理者権限で起動した PowerShellGet-VM コマンドレットで稼働中の仮想マシンを確認することが出来る。

また、Hyper-V マネージャで確認することも出来る。

f:id:inokara:20160807111739p:plain

Hello World

PS C:\Users\kappa> docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world

c04b14da8d14: Already exists
Digest: sha256:0256e8a36e2070f7bf2d0b0763dbabdd67798512411de4cdcf9431a1feb60fd9
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
 https://hub.docker.com

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

nginx コンテナ

PS C:\Users\kappa> docker run -d -p 80:80 nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx

51f5c6a04d83: Already exists
a3ed95caeb02: Already exists
51d229e136d0: Already exists
bcd41daec8cc: Already exists
Digest: sha256:0fe6413f3e30fcc5920bc8fa769280975b10b1c26721de956e1428b9e2f29d04
Status: Downloaded newer image for nginx:latest
2389477365e93f7e57ae930d2bdb351b05b032124814e050c617cb05ee8d2a0e
PS C:\Users\kappa> docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                         NAMES
2389477365e9        nginx               "nginx -g 'daemon off"   3 seconds ago       Up 2 seconds        0.0.0.0:80->80/tcp, 443/tcp   silly_roentgen

PS C:\Users\kappa>
PS C:\Users\kappa> Invoke-RestMethod -Uri "http://localhost" -outfile nginx.txt
PS C:\Users\kappa> cat nginx.txt
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

おお、普通に Docker だ。

以上

15 分位触ってみたメモでした。

Bash も使えるようになってるし、Docker も動くし、もう Windows でいいんぢゃないかなって思ったり。

福岡は Ruby に縁がある街なので、その県民として Ruby Association Certified Ruby Programmer Silver version 2.1 を受験してきた

ruby 資格試験

ども、かっぱです。

tl;dr

福岡は Ruby に縁がある街だと勝手に思っているので、県民の義務だと思って Ruby Association Certified Ruby Programmer Silver version 2.1 を受験してきたのでメモ。

www.ruby.or.jp

ちなみに、福岡には以下のような Ruby の名前を冠した施設がある。

frac.jp

また、以下のような組織もある。

www.digitalfukuoka.jp

Ruby の故郷は島根県の松江かもしれないけど、第二の故郷は福岡なのかもしれない(と勝手に思っている)。


試験結果は

合否

90 点で合格。(100 点満点で 75 点以上が合格)


なんで受けたか

  • 冒頭にも書いたように福岡県民としての義務だと感じたのが一つ
  • 初老のおっさんが普通自動車免許以外にも免許が欲しかったのが一つ
  • インフラエンジニアでも Ruby 等のプログラム言語に直面する機会が増えてきたので、せめて基本は抑えておきたいと思ったのが一つ

どんな風に勉強したか

勉強した期間

  • トータルで一ヶ月分位

参考書籍

Ruby技術者認定試験合格教本 Silver/Gold対応 Ruby公式資格教科書

Ruby技術者認定試験合格教本 Silver/Gold対応 Ruby公式資格教科書

カスタマーレビューでは評価はイマイチだけど、受験に必要な知識がコンパクトに纏まっているし、模擬試験 50 問 + 基礎知識問題が 30 問ついているので、この本をザーッと一回読んで、模擬試験を解きまくった。

www.ruby.or.jp

上記に掲載されている模擬試験も同じように解きまくった。

模擬試験丸覚えにならない工夫

模擬試験を繰り返しているうちに答えを覚えてしまったので、自分なりに模擬試験の選択肢を pry で実行しながら誤った選択肢の挙動も確認するようにした。

やっぱり pry

模擬試験を解きながら、本を読みながら、掲載されているコードは出来るだけ pry で実行して結果を確認した。


最後に

ちょっとだけ...どんな感じで出題されたか

詳しくは書けないけど、こちらの「試験実施要項 」に書かれているように、主要なクラス(Array や Hash や String)の各メソッドの挙動については抑えておくべきだと思う。あと、演算子、これはかなり覚えるに苦労した...。今でも覚えられていないけど。

次は

メタプログラミングRuby」を読んでゴールド頑張りたい。

メタプログラミングRuby 第2版

メタプログラミングRuby 第2版

cron + α が欲しい時には ts(Task Spooler) のご利用をご検討下さいというメモ

雑なメモ Linux

おひさしブリーフ、かっぱです。

tl;dr

下図のように cron ジョブで定期的にスクリプトを生成して実行させようとした時、スクリプト完了する前に次の cron ジョブが走ってスクリプトが生成されて、そのスクリプトが実行されてしまうような状況に遭遇してどうしたもんかなと悩んでいたら ts というツールを見つけたので試してみた。

f:id:inokara:20160807074518p:plain


memo

ts とは

スクリプトやコマンドを ts コマンド経由で実行することで、それらをジョブとしてキューに放り込んで順次実行してくれるツール。冒頭の構成に ts を加えると下図のようになり、cron の開始時間とスクリプトの実行時間の依存関係は切り離される。

f:id:inokara:20160807082925p:plain

導入

CentOS 6 に導入するにはソースコードを取得してビルドする必要がある。

$ cat /etc/redhat-release
CentOS release 6.7 (Final)

$ sudo yum install gcc
$ wget http://vicerveza.homeunix.net/~viric/soft/ts/ts-0.7.6.tar.gz
$ tar zxvf ts-0.7.6.tar.gz
$ cd ts-0.7.6
$ make
$ mkdir ~/bin
$ cp ts ~/bin/ts

サンプル

以下のような雑なシェルスクリプトを cron で実行させる。

$ cat demo.sh
#!/bin/sh

DATE=`date +%s`
echo "echo $DATE && sleep 300" > /tmp/test.sh.$DATE
${HOME}/bin/ts logger -t ts_demo "スクリプトを作成しました"
sleep 3
logger -t ts_demo "スクリプトを実行します"
${HOME}/bin/ts sh /tmp/test.sh.$DATE
${HOME}/bin/ts -d logger -t ts_demo "スクリプトの実行が完了しました"

$ crontab -l
*/3 * * * * /home/centos/demo.sh >/dev/null 2>&1

暫く放置してから ts コマンド(ts -l でも同等)を実行すると以下のように ts コマンド経由で実行したコマンド(スクリプト)がジョブとしてキューイングされている。

$ ts
ID   State      Output               E-Level  Times(r/u/s)   Command [run=1/1]
0    running    /tmp/ts-out.b5xJat                           sh /tmp/test.sh.1470470326
1    queued     (file)                                       [0]&& logger -t ts_demo スクリプトの実行が完了しました
2    queued     (file)                                       logger -t ts_demo スクリプトを作成しました
3    queued     (file)                                       sh /tmp/test.sh.1470470342
4    queued     (file)                                       [3]&& logger -t ts_demo スクリプトの実行が完了しました

さらに暫く放置してからジョブ一覧を確認すると...

$ ts -l
ID   State      Output               E-Level  Times(r/u/s)   Command [run=1/1]
6    running    /tmp/ts-out.FSSSnL                           sh /tmp/test.sh.1470470581
7    queued     (file)                                       [6]&& logger -t ts_demo スクリプトの実行が完了しました
8    queued     (file)                                       logger -t ts_demo スクリプトを作成しました
9    queued     (file)                                       sh /tmp/test.sh.1470470761
10   queued     (file)                                       [9]&& logger -t ts_demo スクリプトの実行が完了しました
11   queued     (file)                                       logger -t ts_demo スクリプトを作成しました
12   queued     (file)                                       sh /tmp/test.sh.1470470941
13   queued     (file)                                       [12]&& logger -t ts_demo スクリプトの実行が完了しました
14   queued     (file)                                       logger -t ts_demo スクリプトを作成しました
15   queued     (file)                                       sh /tmp/test.sh.1470471121
16   queued     (file)                                       [15]&& logger -t ts_demo スクリプトの実行が完了しました
0    finished   /tmp/ts-out.b5xJat   0        300.00/0.00/0.00 sh /tmp/test.sh.1470470326
1    finished   /tmp/ts-out.js0Oq6   0        0.00/0.00/0.00 [0]&& logger -t ts_demo スクリプトの実行が完了しました
2    finished   /tmp/ts-out.6Jjrf6   0        0.00/0.00/0.00 logger -t ts_demo スクリプトを作成しました
3    finished   /tmp/ts-out.fotDb6   0        300.00/0.00/0.00 sh /tmp/test.sh.1470470342
4    finished   /tmp/ts-out.8y6fdL   0        0.00/0.00/0.00 [3]&& logger -t ts_demo スクリプトの実行が完了しました
5    finished   /tmp/ts-out.lMTR8K   0        0.00/0.00/0.00 logger -t ts_demo スクリプトを作成しました

finished となっているのは完了したジョブ。logger で吐いているログを見ると...

$ sudo tail -f /var/log/messages
Aug  6 08:03:04 ip-xxx-xx-xx-xx ts_demo: スクリプトを実行します
Aug  6 08:03:49 ip-xxx-xx-xx-xx ts_demo: スクリプトの実行が完了しました
Aug  6 08:03:49 ip-xxx-xx-xx-xx ts_demo: スクリプトを作成しました
Aug  6 08:06:04 ip-xxx-xx-xx-xx ts_demo: スクリプトを実行します
Aug  6 08:08:49 ip-xxx-xx-xx-xx ts_demo: スクリプトの実行が完了しました
Aug  6 08:08:49 ip-xxx-xx-xx-xx ts_demo: スクリプトを作成しました
Aug  6 08:09:04 ip-xxx-xx-xx-xx ts_demo: スクリプトを実行します
Aug  6 08:12:04 ip-xxx-xx-xx-xx ts_demo: スクリプトを実行します
Aug  6 08:13:49 ip-xxx-xx-xx-xx ts_demo: スクリプトの実行が完了しました
Aug  6 08:13:49 ip-xxx-xx-xx-xx ts_demo: スクリプトを作成しました

ts の操作

以下は ts の主な操作。

  • ジョブの一覧確認
$ ts -l
  • 完了したジョブをジョブ一覧から削除
$ ts -C
  • ジョブの一括削除(タスクスプーラーサーバープロセスを kill する)
$ ts -K
  • 前のジョブが完了したら実行する

以下のように -d オプションをつけてジョブを登録することで、${command-1} が正常終了したら ${command-2} が実行される。

$ ts ${command-1}
$ ts -d ${command-2}
  • ジョブの標準出力を確認
$ ts -t ${JOB_ID}

その他、以下が ts のヘルプ。

$ ts -h
usage: ts [action] [-ngfmdE] [-L <lab>] [-D <id>] [cmd...]
Env vars:
  TS_SOCKET  the path to the unix socket used by the ts command.
  TS_MAILTO  where to mail the result (on -m). Local user by default.
  TS_MAXFINISHED  maximum finished jobs in the queue.
  TS_MAXCONN  maximum number of ts connections at once.
  TS_ONFINISH  binary called on job end (passes jobid, error, outfile, command).
  TS_ENV  command called on enqueue. Its output determines the job information.
  TS_SAVELIST  filename which will store the list, if the server dies.
  TS_SLOTS   amount of jobs which can run at once, read on server start.
  TMPDIR     directory where to place the output files and the default socket.
Actions:
  -K       kill the task spooler server
  -C       clear the list of finished jobs
  -l       show the job list (default action)
  -S [num] get/set the number of max simultaneous jobs of the server.
  -t [id]  "tail -n 10 -f" the output of the job. Last run if not specified.
  -c [id]  like -t, but shows all the lines. Last run if not specified.
  -p [id]  show the pid of the job. Last run if not specified.
  -o [id]  show the output file. Of last job run, if not specified.
  -i [id]  show job information. Of last job run, if not specified.
  -s [id]  show the job state. Of the last added, if not specified.
  -r [id]  remove a job. The last added, if not specified.
  -w [id]  wait for a job. The last added, if not specified.
  -k [id]  send SIGTERM to the job process group. The last run, if not specified.
  -u [id]  put that job first. The last added, if not specified.
  -U <id-id>  swap two jobs in the queue.
  -B       in case of full queue on the server, quit (2) instead of waiting.
  -h       show this help
  -V       show the program version
Options adding jobs:
  -n       don't store the output of the command.
  -E       Keep stderr apart, in a name like the output file, but adding '.e'.
  -g       gzip the stored output (if not -n).
  -f       don't fork into background.
  -m       send the output by e-mail (uses sendmail).
  -d       the job will be run only if the job before ends well
  -D <id>  the job will be run only if the job of given id ends well.
  -L <lab> name this task with a label, to be distinguished on listing.
  -N <num> number of slots required by the job (1 default).

最後に

ts の使いドコロ

  • 分散キューシステムでは無いので、一台のサーバー上でしか動かせないのは注意が必要
  • 遅延処理はしたいけど、処理の実行順序は出来るだけ守りたい場合
  • SQS や RabbitMQ 等を導入する程でもなくて、一台のサーバーで完結するようなバッチ処理

今まで知らずにすいません

本当にすいません。

AWS Game Day に参加して優勝してしまったくさ #AWSGameDayJapan‬

aws

tl;dr

AWS Game Day というイベントに初老、初老界隈のメンバー三人で参加した。

gameday-japan.connpass.com

AWS Game Day とは...上記のサイトを抜粋。

AWS GameDayはAWS上に構築されたシステムのトラブルシュートコンテストのようなものです。
主催者より皆さんに、"ある"AWS環境を払い出します。皆さんは払い出された環境を、どんな負荷ににも耐えられる最強の環境にするコンテストです。
参加者の中で最も優れた環境に育て上げたチームがチャンピオンになります!いわば、ドラゴンボールの天下一武道会のようなものです。

詳細な内容は書くことは出来ないけど、イタズラ好きな CTO のもとで働くインフラエンジニアというシチュエーションで、高負荷に耐えうる環境を構築するミッションをそれぞれのチームで競うというもの。参加者には ISUCON 入賞者の方を擁するチームもいらっしゃたりして、我々はアルコタワーに何かちょっとした爪跡でも残せたらいいやという気持ちで挑んだところ...

優勝してしまった。

感想とか

勝因

他のチームの方からお話しを伺う限りだと、パケットキャプチャしたり、しっかりと調査を行った上で様々な対処を検討されていたので、何故、我々のチームがあんなに大きく差を付けて勝つことが出来たのか未だにナゾである。

模範解答は?

運営者が期待している模範解答を知りたかった。

教訓(もしかしたら、次の Game Day でチームに勝利をもたらすかもしれない三つの何か)を三行で

すごく当たり前のようなことなんだけど、実際にその状況が目の前にあらわれた時にちゃんと守れるかが勝敗(実務でも)の鍵だったりするのかなと。

  • インフラリソースの把握は必須、インフラだけでなくアプリケーションも出来る限り把握する
  • 慌てない、とにかくお茶でも飲んで落ち着く
  • チーム内での役割分担を明確に(司令塔、調査班、作業班)

途中、参加者には福利厚生としてアルコール類が振る舞われるが、ここでアルコールが良いガソリンとなるのか、手元や判断を狂わす劇薬になるかは貴方次第。

最後に

謝辞

  • 主催の AWS メンバーの皆さん、裏方として環境の構築等を行ってくれた Scott さん、Dave さん
  • チームロゴをその達筆な腕前で認めて下さった cloudpack の酒井さん
  • チームメンバーの cloudpack 武川さん、工藤さん
  • 東京への長期滞在を快く送り出してくれた奥さん

本当にありがとうございました。

目標とする漢、ジェイソン・ステイサムの一言

自分が目標とする漢、ジェイソン・ステイサムの一言で〆たいと思う。