Windowsインスタンスの停止時にログをS3に転送する

概要

Windowsインスタンスの停止時にS3にローカルのログファイルを転送する処理をご紹介します！

前提

• Windows Server 2016
• AWSCLIが利用可能な環境

シャットダウンスクリプトの設定手順

• スタートメニューの「ファイル名を指定して実行」に「gpedit.msc」と入力してOK
• コンピューターの構成→Windowsの設定→スクリプト（スタートアップ/シャットダウン）
• シャットダウンをダブルクリック
• 追加ボタンを押してスクリプト名に実行したいプログラムを設定

これでWindowsのシャットダウン時に指定のプログラムが実行されます。

基本的には以下URL見ればわかります。　　

www.attrise.com

スクリプト例

こんなかんじのスクリプト(batファイル)をシャットダウンスクリプトに設定してあげればS3へログを転送することができます。
AWSCLIでS3にローカルのファイルをコピーしています。

aws s3 cp C:\Users\Administrator\Desktop\wawawa2.log s3://kabegiwa-bucket/wawawa.log

実行契機

以下の実行契機でシャットダウンスクリプトが実行されるようです。 - リモートデスクトップで接続して、スタートメニューから停止または再起動した場合 - マネジメントコンソールから、停止/再起動/削除した場合(削除は起動中のものを削除した場合のみ)

注意点

ただし、マネジメントコンソールから停止した場合と、スタートメニューから停止した場合では動きが少し異なっています。

スタートメニューから停止した場合はなにも考えなくても大丈夫ですが、 マネジメントコンソールからインスタンスを停止した場合、シャットダウンスクリプトの処理が長いと、停止時に問題が発生したとみなされてAWSから強制停止されてしまいます。

おわりに

終了時にログを退避することでインスタンスがいつ削除されてもいいようにしておくことがImmutableなインフラへの近道だと思います。
よくわかっていないですけれど…

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

最大公約数を求めるLambda(Python3)

なんかまったく需要がなさそうだけど気の迷いでつくりました。

概要

変数のxとyに整数を入力してあげると、printで結果を返してくれます。
以下のコードでは84と16の最大公約数を求めています。

かんたんな説明

最大公約数は以下のようにして求めることができます。

84 mod 16 = 4 
16 mod 4 = 0

あまりが0になったから最大公約数は4だ！！！！

84 mod 16を計算します。 答え(あまり)は4です。
つづいて、右辺の16と先程の答えの4で16 mod 4を計算します。
16 mod 4 = 0なので最大公約数は0です！！！

おわりに

説明下手感

Python 1年生 体験してわかる！会話でまなべる！プログラミングのしくみ

IAMロールの権限でCyberduckを利用してS3とファイルをやりとりしてみる

今回はCyberduckというGUIのFTPクライアントツールを利用してAWS上のS3バケットとIAMロールを付与したWindowsインスタンス上でファイルのやり取りをしてみたいと思います。

この方法を利用することでアクセスキーを発行しなくてもCyberduckを利用することが可能です。

手順

以下の手順はすべてS3へアクセス可能なIAMロールがアタッチされているWindowsインスタンス内で作業していることを想定しています。

Cyberduckのダウンロード

以下からダウンロードできます。

https://cyberduck.io/index.ja.html?l=ja

S3のIAMロール用のCyberduckのprofileをダウンロード

IAMロール用のCyberduckのprofileをダウンロードしてきます。

以下のリンクの上のほうに「Connecting with temporary access credentials (Token) from EC2」という項目があります。
そこにIAMロール用のCyberduckのprofileがありますので、Downloadを選択して、ダウンロードします。

https://trac.cyberduck.io/wiki/help/en/howto/s3

画像でいうと赤枠のところ

profileの編集

テキストエディタでダウンロードしてきたprofileを開き、 http://169.254.169.254/latest/meta-data/iam/security-credentials/s3accessとなっている箇所の、s3accessの部分を現在作業中のインスタンスにアタッチされているIAMロールの名前に書き換えます。
それ以外のところは、なにも編集せず保存します。

CyberduckでS3に接続してみる

さきほど編集したprofileをダブルクリックしてCyberduckを起動します。

すると、S3へ接続が行われ、バケットの一覧がでてきます。

バケット名をダブルクリックするとバケットの中身がみれます。

おわりに

アクセスキーを発行しなくてもこういったGUI系のツールを利用できる。というのは結構便利だと思います。
(AWSCLIつかいかたわからないみたいなこともあるので…)

おためしあれ！！！

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

AnsibleでWindowsにAWS CLIをインストールする

今回はAnsibleでWindows環境にAWS CLIをインストールしてみたいと思います。

事前準備

AWS公式からAWS CLIのインストーラをダウンロードしてきます。

aws.amazon.com

以下の赤枠から32ビットまたは64ビットのものをダウンロードします。

Ansibleを実行する

さて、実際にAnsibleを実行してAWS CLIをインストールしてみます。

実行コマンド

$ ansible-playbook -i hosts/target-hosts install_AWSCLI.yml

playbookは以下のような感じです。

win_copyでインストーラをターゲットノード(AWS CLIをインストールしたいサーバ)にコピーしたあと、win_msiを利用してインストールしています。

おわりに

Ansibleを利用してAWS CLIをインストールすることができました。
msi形式のインストーラであればwin_msiでインストーラのPATHを指定してあげるだけでインストールを行うことができます！

便利ですね！

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

AnsibleでEC2インスタンスを作成してみる

AnsibleでEC2インスタンスを作成してみようと思います。

環境

• Ansible 2.4.2
• python 2.7

インスタンスを作成してみる

インスタンスを作成してみます。

実行コマンド

$ ansible-playbook -i ansible_hosts instance_create.yml

playbookは以下のようにしています。

Ansible

インベントリファイルは以下のようなかんじ。

$ cat ansible_hosts
[local]
localhost

実行確認

インスタンスが作成できました！

おわりに

インスタンスを作成するところからAnsibleで実行することができます。
構成管理がはかどりますね！！！

初めてのAnsible

Auto Scalingでスケールインしたときの動作まとめ

概要

Auto Scalingを利用していて、スケールインしたときの動きについてまとめてみます。
AWSドキュメントによると、スケールイン時のうごきが以下の通り。

Auto Scaling は、選択したアベイラビリティーゾーンで、保護されていないどのインスタンスが最も古い起動設定を使用しているかを判断します。このよう title:なインスタンスが 1 つある場合、そのインスタンスを終了します。

docs.aws.amazon.com

つまり、古いものから停止されていくので、グループ内で稼働し続けるようなインスタンスは存在しないということになります。

実際に試してみる

Auto Scalingを設定して、実際に動きを確認してみます。

Auto Scaling(スケジュールされたイベント) の設定

設定は以下ようなかんじで設定してみました。

名前	繰り返し	最小	最大
start	5,15,25,35,45,55 * * * *	4	4
stop	0,10,20,30,40,50 * * * *	3	3

startとstopがcronに従って実行され、startで4台にスケールアウト、stopで3台にスケールインするような動きになります。

これでしばらく放置してみます。

実行結果確認

ログを見て、本当に古いインスタンスから削除されているのかを確認します。 ログは以下の実行ログのとおりです。
例えば、直近("StartTime": "2018-02-01T08:10:56.120Z")で停止されたi-ddddddddddddddddを見てみます。

このインスタンスが作成されたのは"StartTime": "2018-01-29T07:35:52.259Z"です。 その時点でのAuto Scaling Groupのインスタンスの起動時刻をそれぞれ表すと以下になります。

インスタンスID	起動時刻
i-ggggggggggggggggg	2018-02-03T08:05:31.933Z
i-fffffffffffffffff	2018-02-03T07:55:38.692Z
i-eeeeeeeeeeeeeeeee	2018-02-03T07:45:45.317Z
i-dddddddddddddddd	2018-02-03T07:35:52.259Z

実際に古いものから削除されているようです！

実行ログ

$  aws autoscaling describe-scaling-activities --auto-scaling-group-name kabegiwa_scaling_group --query 'Activities[].{StartTime:StartTime,Descriprtion:Description}'

[
    {
        "Descriprtion": "Terminating EC2 instance: i-dddddddddddddddd", 
        "StartTime": "2018-02-03T08:10:56.120Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T08:10:26.252Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-ggggggggggggggggg", 
        "StartTime": "2018-02-03T08:05:31.933Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T08:05:00.074Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-ccccccccccccccccc", 
        "StartTime": "2018-02-03T08:00:33.408Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T08:00:03.635Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-fffffffffffffffff", 
        "StartTime": "2018-02-03T07:55:38.692Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:55:07.006Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-bbbbbbbbbbbbbbbbb", 
        "StartTime": "2018-02-03T07:50:40.344Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T07:50:10.562Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-eeeeeeeeeeeeeeeee", 
        "StartTime": "2018-02-03T07:45:45.317Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:45:13.995Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-aaaaaaaaaaaaaaaaa", 
        "StartTime": "2018-02-03T07:40:47.193Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T07:40:17.326Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-dddddddddddddddd", 
        "StartTime": "2018-02-03T07:35:52.259Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:35:20.733Z"
    } 
 ]

おわりに

Auto Scalingでインスタンスを管理すれば、それだけで長期間稼働するインスタンスをなくすことができそうです。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

boto3でDynamoDBのテーブルの内容をscanしてすべて取得してみる

boto3を利用してDynamoDBのテーブルの内容をscanしてすべて取得してみたいと思います。

前提

以下のようなテーブルを用意しています。
これをすべてscanして取得します。

コード

コードは以下の通りです。単純ですね！

python

　
以下のような結果が返ってくるはずです。 (見やすいように整形済み)

{
    'Items': [{
        'name': {
            'S': 'kenkokukinen_no_hi'
        },
        'date': {
            'S': '0211'
        }
    }, {
        'name': {
            'S': 'seijin_no_hi'
        },
        'date': {
            'S': '0108'
        }
    }, {
        'name': {
            'S': 'gantan'
        },
        'date': {
            'S': '0101'
        }
    }],
    'Count': 3,
    'ScannedCount': 3,
}

おわりに

DynamoDBのテーブルの内容をすべて取得することができました。
テーブルの内容を変数に入れて、その内容を参照しに行けばDynamoDBへのアクセスを減らすことができます。

ただし、DynamoDBのデータが多い場合は、scanした際の負荷がかなり高くなると思います。
そこらへんは要検討です。

RDB技術者のためのNoSQLガイド

PackerでWindowsServerのAMIを作成する

PackerでWindowsServerのAMIをつくってみます。 これが考えられる最小構成だと思います。 これに肉付けすることでカスタムAMIを作成することができると思います。

環境

• Packer v1.1.3
• Packerが動いているサーバ : Amazon Linux 2
• PackerがつくるWindowsServerのAMI : Microsoft Windows Server 2016 Base

概要

Packerを利用してWindowsServer 2016のAMIを作成します。
もととなるAMIとして使ったのはAWSが提供しているMicrosoft Windows Server 2016 Baseです。

うごきとしては以下のような感じです。

• PackerがWindows Server 2016 Baseのインスタンスを作成/起動
• WinRMで接続してEC2Launchを実行
• AMI作成
• インスタンス削除

WinRMで接続して～のところでいろいろやるように肉付けするとお好みのカスタムAMIを作成することができます。

実際にやってみる

実行コマンド

$ packer build ./template.json 

実行ログ

amazon-ebs output will be in this color.
==> amazon-ebs: Prevalidating AMI Name: kabegiwa-test-windows-server
    amazon-ebs: Found Image ID: ami-157fe573
==> amazon-ebs: Creating temporary keypair: packer_5a6ac1d4-c926-1c2c-fb7e-f0cf78d180cb
==> amazon-ebs: Creating temporary security group for this instance: packer_5a6ac1d8-b367-106b-ea1b-bd7f142b710a
==> amazon-ebs: Authorizing access to port 5985 from 0.0.0.0/0 in the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
==> amazon-ebs: Adding tags to source instance
    amazon-ebs: Adding tag: "Name": "Packer Builder"
    amazon-ebs: Instance ID: i-02c873d6d7833d311
==> amazon-ebs: Waiting for instance (i-02c873d6d7833d311) to become ready...
==> amazon-ebs: Waiting for auto-generated password for instance...
    amazon-ebs: It is normal for this process to take up to 15 minutes,
    amazon-ebs: but it usually takes around 5. Please wait.
    amazon-ebs:  
    amazon-ebs: Password retrieved!
==> amazon-ebs: Waiting for WinRM to become available...
    amazon-ebs: WinRM connected.
    amazon-ebs: #< CLIXML
    amazon-ebs: <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04"><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>
==> amazon-ebs: Connected to WinRM!
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /tmp/packer-powershell-provisioner631511055
    amazon-ebs:
    amazon-ebs: TaskPath                                       TaskName                          State
    amazon-ebs: --------                                       --------                          -----
    amazon-ebs: \                                              Amazon Ec2 Launch - Instance I... Ready
==> amazon-ebs: Stopping the source instance...
    amazon-ebs: Stopping instance, attempt 1
==> amazon-ebs: Waiting for the instance to stop...
==> amazon-ebs: Creating the AMI: kabegiwa-test-windows-server
    amazon-ebs: AMI: ami-xxxxxxxx
==> amazon-ebs: Waiting for AMI to become ready...
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
ap-northeast-1: ami-xxxxxxxx
{/code}
** template.json
{code}
{
    "builders": [{
        "type": "amazon-ebs",
        "region": "ap-northeast-1",
        "source_ami": "ami-157fe573",
        "instance_type": "m4.medium",
        "ami_name": "kabegiwa-test-windows-server",
        "user_data_file": "{{template_dir}}/setup_winrm.txt",
        "communicator": "winrm",
        "winrm_username": "Administrator"
    }],
    "provisioners": [
        {
            "type": "powershell",
            "inline": [
                "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\InitializeInstance.ps1 -Schedule",
                "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\SysprepInstance.ps1 -NoShutdown"
            ]
        }
    ]
}
{/code}
** setup_winrm.txt
{code}
<powershell>
winrm quickconfig -q
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
winrm set winrm/config '@{MaxTimeoutms="1800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow
netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow
net stop winrm
sc config winrm start=auto
net start winrm
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
</powershell>

結果確認

実行ログを見るとami-xxxxxxxxというAMIが作成されたことがわかります。 それをもとにインスタンスを作成します。

インスタンス作成

$ aws ec2 run-instances \
--image-id ami-xxxxxxxx \
--subnet-id subnet-yyyyyyyy \
--security-group-ids sg-12345678 sg-abcdefgh \
--count 1 \
--instance-type t2.micro \
--key-name himitsu-key  \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=kabegiwa-test}]'

インスタンス起動確認

$ aws ec2 describe-instances --instance-id i-abcdefghijklmnop --query 'Reservations[]
.Instances[].State.Name'
[
    "running"
]

おわりに

無事にWindows ServerのAMIを作成、インスタンスを起動することができました！

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

Amazon Linux 2でPacker を実行したところ/usr/share/cracklib/pw_dict.pwd: Permission deniedのエラーがでる

事象

Amazon Linux 2 でPackerを実行しようとしたところ、以下のようなエラーが出てしまいました。

$ packer
/usr/share/cracklib/pw_dict.pwd: Permission denied
/usr/share/cracklib/pw_dict: Permission denied

原因

どうやら以下のPackerを実行してしまっているらしい。

$ which packer
/usr/sbin/packer

これはなにかとおもったらどうやらパスワードチェックなどに利用されるcracklib-packerのシンボリックリンクみたいです。

$ ls -l /usr/sbin/packer
lrwxrwxrwx 1 root root 15 Jan 16 18:44 /usr/sbin/packer -> cracklib-packer

解決法

シンボリックリンクを消してしまいます。

$ sudo rm /usr/sbin/packer

$ packer -v
Packer v1.1.3

無事Packerが実行できました。

AWSによるサーバーレスアーキテクチャ

EC2 External InventoryでプライベートIPで取得したい

AnsibleのEC2 External InventoryでEC2インスタンスの情報を取得したとき、デフォルトのままだと以下のようにIPアドレスがパブリックIPで表示されるかと思います。

$ ./ec2.py 
{
"_meta": {
  "ap-northeast-1a": [
    "54.xxx.xxx.xxx", 
    "13.yyy.yyy.yyy"
  ], 
  "tag_Name_kabegiwa_ansible_server": [
    "54.xxx.xxx.xxx"
  ], 
  "tag_Name_kabegiwa_ansible_client": [
    "13.yyy.yyy.yyy"
  ]

そして、パブリックIPを設定していないインスタンスについては情報がとれていませんでした。

解決法

設定ファイルであるec2.iniのvpc_destination_variableをprivate_ip_addressに変更したところ、うまくいきました。

以下のように変更

vpc_destination_variable = private_ip_address
# vpc_destination_variable = ip_address

こんなかんじで無事に表示されるようになります。

$ ./ec2.py 
{
"_meta": {
  "ap-northeast-1a": [
    "172.140.1.1", 
    "172.140.1.2",
    "172.140.1.3"
  ], 
  "tag_Name_kabegiwa_ansible_server": [
    "172.140.1.1"
  ], 
  "tag_Name_kabegiwa_ansible_client": [
    "172.140.1.2"
  ],
  "tag_Name_kabegiwa_private": [
    "172.140.1.3"
  ]

おわりに

以下のように両方設定を残してしまうと下にある項目の設定になってしまうようです。(パブリックIPしか表示されないような状態になってしまう)

vpc_destination_variable = private_ip_address
vpc_destination_variable = ip_address

Ansible完全読本

EC2 External Inventoryを利用してAnsibleのhostsを動的に管理する

Ansibleを利用した構成管理では、実行対象のホストをインベントリファイルと呼ばれるファイルに記載しておく必要があります。

以下のようなかんじ

[local]
localhosts

[test_server]
192.140.1.1
192.140.1.2

[web_server]
192.140.2.1

これだと、AWSでAutoScalingを利用した際や、新たにインスタンスをたてたときなどにこのインベントリファイルをメンテナンスし続けなければならなくなり、非常に面倒です。

これを解決するために、Ansible公式でEC2 External Inventoryというスクリプトが提供されています。
以下のec2.pyとec2.iniがそのEC2 External Inventoryで利用するスクリプトと設定ファイルです。

github.com

実際に動かしてためしてみる

実際にEC2 External InventoryをEC2インスタンス上からためしてみます。

事前準備

ファイルのダウンロード

まず、Ansibleサーバ上にec2.pyとec2.iniをダウンロードします。

$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.py

$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.ini

アクセス権限の設定

つづいて、AnsibleがAWSの環境を見に行くことができるようにAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを環境変数に設定します。

$ export AWS_ACCESS_KEY_ID='AKIA1234567890'
$ export AWS_SECRET_ACCESS_KEY='secretkey1234567890'

AnsibleサーバもAWSで動いていて、インスタンスに適切にロールが適用されている場合はこの作業は必要ありません。

以上で事前準備は完了です！

ためしにec2.pyを動かしてみる

ec2.pyを単体で動かすと、以下のような情報がかえってきました。

$ ./ec2.py 
{
"_meta": {
  "ap-northeast-1a": [
    "172.140.1.1", 
    "172.140.1.2"
  ], 
  "tag_Name_kabegiwa_ansible_server": [
    "172.140.1.1"
  ], 
  "tag_Name_kabegiwa_ansible_client": [
    "172.140.1.2"
  ], 
  "type_t2_micro": [ 
    "172.140.1.2"
  ], 
  "type_t2_large": [ 
    "172.140.1.2"
  ], 
  "vpc_id_vpc_12345678": [
    "172.140.1.1", 
    "172.140.1.2"
  ]

AZやリージョン、タグ名などでまとまった情報がJSON形式で応答されていることがわかります。
このひとつひとつがAnsibleでいうグループになります。

Ansibleコマンドを実行する

実際にAnsibleを実行してみます。
Ansibleの-iオプションでec2.pyをわたしてあげるだけです。
たとえば、Nameタグがkabegiwa_ansible_clientのものにpingを実行してみます。

$ ansible -i ec2.py tag_Name_kabegiwa_ansible_client -u ec2-user --private-key='./himitsukagi.pem' -m ping
172.140.1.2 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

無事実行できました！

おわりに

このようにEC2 External Inventoryをつかうことで動的にAnsibleのインベントリファイルを作成することができます。

インフラのコード化と自動化がはかどりますね！！！

入門Ansible

AnsibleでS3からファイルをダウンロードする3つの方法

AnsibleでS3からファイルをダウンロードする方法を紹介します！

① s3_getを利用する

AnsibleのCloudModuleであるs3_getを利用する方法です。

前提条件

• ターゲットノードにS3へのアクセス許可が必要

実行コマンド

$ ansible-playbook -i ansible_hosts s3_get.yml

ansible_hosts

[test_server]
172.140.1.1

s3_get.yml

- name: s3_get
  hosts: test_server
  tasks:
   - aws_s3:
       bucket: kabegiwa-bucket
       object: /test.txt
       dest: /home/ec2-user/test.txt
       mode: get

② get_urlを利用する

S3バケットに静的Webサイトホスティングの設定またはオブジェクトごとにPublicアクセスの許可設定を実施し、ダウンロードを行う方法です。

前提条件

• S3上のファイルは静的WebホスティングまたはPublicアクセスの許可が必要

  実行コマンド

$ ansible-playbook -i ansible_hosts geturl.yml

ansible_hosts

[test_server]
172.140.1.1

geturl.yml

- name: get_url_test
  hosts: test_server
  tasks:
    - get_url: url=https://s3-ap-northeast-1.amazonaws.com/kabegiwa-bucket/test.txt dest=/home/ec2-user/

③ AWSCLIを利用する方法

単純にAnsibleのcommandを利用してAWSCLIを実行させます。

前提条件

• ターゲットノードにS3へのアクセス許可がなければならない
• ターゲットノードにAWSCLIがインストールされていなければならない

  実行コマンド

$ ansible-playbook -i ansible_hosts awscli.yml

ansible_hosts

[linux]
172.22.69.51

awscli.yml

- name: awscli_test
  hosts: test_server
  tasks:
    - command: 'aws s3 cp s3://kabegiwa-bucket/test.txt /home/ec2-user/test.txt'

入門Ansible

S3上のテキストファイルをLambda(Python)で取得する

今回はS3の中に入っているテキストファイルの内容をLambda(Python)で取得してみたいと思います。

S3上には内閣府が公表している国民の休日のcsvファイルの文字コードをutf-8に変換したものを格納しています。

↓これをsjisからutf-8に変換
http://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv

コード

python

以下のような結果が返ってくるはずです。

['国民の祝日月日,国民の祝日名称', '2016-01-01,元日', '2016-01-11,成人の日', '2016-02-11,建国記念の日', '2016-03-20,春分の日', '2016-04-29,昭和の日', '2016-05-03,憲法記念日', '2016-05-04,みどりの日', '2016-05-05,こどもの日', '2016-07-18,海の日', '2016-08-11,山の日', '2016-09-19,敬老の日', '2016-09-22,秋分の日', '2016-10-10,体育の日', '2016-11-03,文化の日', '2016-11-23,勤労感謝の日', '2016-12-23,天皇誕生日', '2017-01-01,元日', '2017-01-09,成人の日', '2017-02-11,建国記念の日', '2017-03-20,春分の日', '2017-04-29,昭和の日', '2017-05-03,憲法記念日', '2017-05-04,みどりの日', '2017-05-05,こどもの日', '2017-07-17,海の日', '2017-08-11,山の日', '2017-09-18,敬老の日', '2017-09-23,秋分の日', '2017-10-09,体育の日', '2017-11-03,文化の日', '2017-11-23,勤労感謝の日', '2017-12-23,天皇誕生日', '2018-01-01,元日', '2018-01-08,成人の日', '2018-02-11,建国記念の日', '2018-03-21,春分の日', '2018-04-29,昭和の日', '2018-05-03,憲法記念日', '2018-05-04,みどりの日', '2018-05-05,こどもの日', '2018-07-16,海の日', '2018-08-11,山の日', '2018-09-17,敬老の日', '2018-09-23,秋分の日', '2018-10-08,体育の日', '2018-11-03,文化の日', '2018-11-23,勤労感謝の日', '2018-12-23,天皇誕生日']

解説

s3_get_objectでバケットとファイル名を指定してskyujitsu.csvを取得します。
その結果はresponseのBody部に格納されますのでそれをreadしてデコード、改行コードでsplitしています。

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング

LambdaのトリガにCloudWatchを設定した際にWe currently do not support adding policies for $LATEST. のエラーがでた場合の対処法

LambdaのトリガにCloudWatchを設定した際にWe currently do not support adding policies for $LATEST.のエラーがでた場合の対処法をご紹介します。

事象

バージョンが$LATESTのLambda関数のトリガにCloudWatch Eventsを追加しようとしたところ以下のようなエラーが出てしまいました。

We currently do not support adding policies for $LATEST. (Service: AWSLambda; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 70ce2637-f806-11e7-91e6-098e8967446a)

原因

雑な日本語訳をすると「$LATESTのポリシーの追加はサポートされていない」といったようなメッセージのようです。

これの原因はCloudWatchルールにデフォルトの場合、以下のように設定されているためです。

バージョン/エイリアスの設定の箇所がデフォルトになっており、エイリアスが非修飾のLambda関数を呼び出すようになっているためです。
CloudWatchルールのターゲットはLambda関数のバージョンまたはエイリアス単位で設定してあげる必要あります。
つまり、$LATESTなんてバージョンはしらねーぞというエラーみたいです。

解決策

このエラーを解決するためにはCloudwatchルールのターゲットでこのLambdaの$LATESTの設定を入れてあげればいいわけですが、そのままでは以下のように「項目がありません」と言われてしまいます。

これを解決するためにLambdaで$LATESTのエイリアスをつくってあげる必要があります。

Lambdaの設定(エイリアス作成)

マネジメントコンソールでLambdaのページに戻り、バージョンで$LATESTを選び、アクションから「エイリアスの作成」を選択します。

新しいエイリアスの作成ウインドウが開きますのでエイリアスの名前を適当に決め、バージョンで$LATESTを選択します。

CloudWatchの設定

上記のLambdaの設定を行うと、ターゲットで先程追加したエイリアスが選択できるようになっています。

これでバージョンが$LATESTのLambda関数のトリガにCloudWatch Eventsを追加することができます！

おわり

まあ言われてみれば当たり前といえば当たり前なんですが、わすれがちです。
デフォルトのエイリアスで非修飾のエイリアスが$LATESTになっているので、特に意識しなくてもいいようにはなっているんですが、特殊な設定をしたいといったときには有効です。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

停止中のインスタンスのIAMロールを置換するとエラーになる

だいたいタイトルのとおりです。
停止中のEC2インスタンスのIAMロールを置換しようとするとエラーがでて、置換することができません。

以下のようなエラーがでます。

when calling the ReplaceIamInstanceProfileAssociation operation: The association iip-assoc-000000000012345678 is not the active association

そんなときは一度IAMロールをデタッチしてあげる必要があります。
IAMロールA→ロールなし→IAMロールB
といったかんじです。
　

なんでこんなことしなきゃいけないんだと思って調べていたらIAMロールの置換ができるのは実行中のインスタンスのIAMロールだけとのこと。

IAM ロールを置き換える 実行中のインスタンスの IAM ロールを置き換えることができます。

docs.aws.amazon.com

CLIなどでスクリプトを組む際は注意しなきゃいけませんね！

Amazon Web Services 業務システム設計・移行ガイド