かべぎわブログ

技術的なことについてかけたらいいな…

複数のAWSマネジメントコンソールを利用するときのChromeの設定のすすめ

概要

AWSのマネジメントコンソールを複数アカウント/ユーザ分利用することがまれによくあると思います。

別のアカウントでマネジメントコンソールを立ち上げたときに以下のような画面が出てしまって、セッションが全部切り替わってしまって、あーーーーーー
というのもまれによくあるとおもいます。 f:id:kabegiwakun:20180504143433p:plain

そんなあれを解消するほうほうのご紹介です!!!!!

設定方法

単純にGoogle Chromeで別ユーザをつくってあげればそれで解決します。
f:id:kabegiwakun:20180504143705p:plain

Chromeで別ユーザを作成してあげるとクッキーなどが完全に別で管理されて別セッション扱いになるので、複数アカウント分のマネジメントコンソールを開くことが可能になります!

おわりに



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

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

Amazon Linux2 に自作サービスを追加する

今回はAmazonLinux2のSystemdに自作サービスを追加してみようと思います。

手順

AmazonLinux2に自作のサービスを追加するための手順です。

サービスとして追加するスクリプトの準備

今回は以下のような約1秒ごとにdateを出力するようなスクリプト()(wawawa.sh)をサービスとして追加してみようと思います。

#!/bin/bash
while true
do
    date >> /home/ec2-user/result.log
    sleep 1
done

ユニットファイルを作成する

/etc/systemd/system配下にユニットの定義ファイルを作成します。
wawawa.serviceのところは好きな名前に書き換えてあげてください。

$ sudo vim /etc/systemd/system/wawawa.service

ファイルの中身をこんなかんじに編集してあげます。

[Unit]
Description = wawawa_shell

[Service]
ExecStart = /home/ec2-user/wawawa.sh
Restart = always
Type = simple

[Install]
WantedBy = multi-user.target

各項目のちょっとした解説

項目 説明
Description このサービスの説明
ExecStart 起動するコマンドのPATH
Restart 停止時の起動条件alwaysを指定してあげると停止時に再起動してくれる
WantedBy 起動時に設定した.wantsディレクトリにリンクを作成する

サービスとして認識されたかどうか確認する

以下コマンドを実行してサービスとして認識されたかどうか確認します。
まだ有効化(enable)していませんのでdisaabled でOKです。

sudo systemctl list-unit-files --type=service | grep wawawa
wawawa.service                                disabled

サービスを有効化(enable)する

サービスを起動する前に有効化してあげる必要があります。
以下コマンドを実行します。

$ sudo systemctl enable wawawa
Created symlink from /etc/systemd/system/multi-user.target.wants/wawawa.service to /etc/systemd/system/wawawa.service.

念のため有効化されたかどうか確認
enableになっていればOK

$ sudo systemctl list-unit-files --type=service | grep wawawa
wawawa.service                                enabled 

サービスを起動する

さていよいよサービスを起動していきます。

$ sudo systemctl start wawawa

なにも問題なければ特に出力もありません。

続いてサービスが本当に起動できているのかどうか確認していきます。
以下のようにActive: active (running)となっていれば起動成功しています。

$ sudo systemctl status wawawa

● wawawa.service - wawawa_shell
   Loaded: loaded (/etc/systemd/system/wawawa.service; enabled; vendor preset: disabled)
   Active: active (running) since 金 2018-03-16 23:44:03 UTC; 10s ago
 Main PID: 3323 (wawawa.sh)
   CGroup: /system.slice/wawawa.service
           ├─3323 /bin/bash /home/ec2-user/wawawa.sh
           └─3346 sleep 1

ファイルにも日時がリダイレクトされ続けています!

$ tail -F result.log 
Fri Mar 16 23:46:10 UTC 2018
Fri Mar 16 23:46:11 UTC 2018
Fri Mar 16 23:46:12 UTC 2018
Fri Mar 16 23:46:13 UTC 2018

おわりに

Systemdを利用して自分でつくったサービス(シェル)を登録することができました。
マシン起動時に自動でサービスが起動されますのでデーモンとして常駐させておきたいようなシェルスクリプトがあれば登録するのがいいと思います!!!

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

Amazon Linux2 にepelリポジトリを追加する

概要

AmazonLinux2で利用できるamzn2-coreリポジトリではインストールできないものがでてきたのでリポジトリを追加する方法をメモ。

RHEL7用のリポジトリを追加しているだけ

リポジトリを追加する手順

すでに追加されているyumリポジトリを調べる

すでに追加されているyumリポジトリを調べてみます。AmazonLinux2のデフォルトの場合ですと、以下のような感じだと思います。

$ sudo yum repolist all
読み込んだプラグイン:langpacks, priorities, update-motd
リポジトリー ID                                               リポジトリー名                                                                 状態
!amzn2-core/2017.12/x86_64                                    Amazon Linux 2 core repository                                                 有効: 7,315
amzn2-core-debuginfo/2017.12/x86_64                           Amazon Linux 2 core repository - debuginfo packages                            無効
amzn2-core-source/2017.12                                     Amazon Linux 2 core repository - source packages                               無効
repolist: 7,315

epel rpmパッケージをインストールする

epelのパッケージをインストールします。
RHEL7用のepelパッケージをインストールしています。

sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

これでパッケージが追加さているはずです。

パッケージが追加さているかどうか確認する

epelリポジトリが追加できました!

$ sudo yum repolist all
読み込んだプラグイン:langpacks, priorities, update-motd
104 packages excluded due to repository priority protections
リポジトリー ID                                      リポジトリー名                                                                     状態
amzn2-core/2017.12/x86_64                            Amazon Linux 2 core repository                                                     有効:      7,315
amzn2-core-debuginfo/2017.12/x86_64                  Amazon Linux 2 core repository - debuginfo packages                                無効
amzn2-core-source/2017.12                            Amazon Linux 2 core repository - source packages                                   無効
epel/x86_64                                          Extra Packages for Enterprise Linux 7 - x86_64                                     有効: 12,319+104
epel-debuginfo/x86_64                                Extra Packages for Enterprise Linux 7 - x86_64 - Debug                             無効
epel-source/x86_64                                   Extra Packages for Enterprise Linux 7 - x86_64 - Source                            無効
epel-testing/x86_64                                  Extra Packages for Enterprise Linux 7 - Testing - x86_64                           無効
epel-testing-debuginfo/x86_64                        Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug                   無効
epel-testing-source/x86_64                           Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source                  無効
repolist: 19,634

おわりに

リポジトリが追加できましたが一応これはRHEL7向けのリポジトリなのでどこかで不具合があるかもしれないです。
もうしわけなし

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

AWSCLIですべてのLambdaについているタグの一覧を表示するシェルスクリプト

概要

AWSCLIでLambdaのすべての関数についているタグの一覧を取得するシェルスクリプトを作成してみました。

aws lambda list-tagsはARNを指定することでその関数にアタッチされているタグを表示することができます。

ARN指定ですのですべての関数を見に行くことはできません。
のでつくりました。

コード

#実行例 以下のようにARN,タグ1,タグ2...タグnといったかんじで出力されます。
1行目はヘッダです。

$ ./lambda_describe_tags_all.sh
ARN Tags1 Tags2 ...
arn:aws:lambda:ap-northeast-1:123456789012:function:clitestfunction wawawa sasasa
arn:aws:lambda:ap-northeast-1:123456789012:function:instance-controll dadada
arn:aws:lambda:ap-northeast-1:123456789012:function:kabegiwablog

おわりに

局所的限定的シェルスクリプトみ

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

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

Amazon Linux2からGitHubのリポジトリへPushする

Amazon Linux2からGitHub上のリポジトリへPushするやりかたです。

環境

  • Amazon Linux2
  • GitHub上にはリポジトリはすでに存在している

Pushするまでの手順

AmazonLinux2からGitHub上のパブリックリポジトリへPushする方法を記載していきます。

事前準備

Gitをインストールする

まずGitをインストールします。
Amazon Linux2ではGitははいっていないのでインストールしてあげる必要があります。

$ sudo yum install git

ローカルリポジトリを作成する

ローカルリポジトリを作成したいディレクトリに移動してから、git initコマンドでローカルリポジトリを作成します。

$ git init

git configでユーザ名とメールアドレスを設定する

誰がCommitしたのかを記録するためにgit configでユーザ名を設定しておきます。

$ git config --global user.name "takakabe"

メールアドレスも設定しておきます。

$ git config --global user.email kabegiwablog@example.com

GitHubにssh接続するための鍵を作成する

GitHubにssh接続するために利用するsshキーを作成します。 パスワードをきかれますので任意のパスワードを設定してあげてください。

$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ec2-user@ip-192-140-1-1.ap-northeast-1.compute.internal
The key's randomart image is:
+---[RSA 2048]----+
|       .EooO=BOO=|
|        . Xo=+=**|
|        .+.+ ++++|
|        .+.+ ++++|
|       .+.+ ++++.|
|       . o  .    |
|        + .      |
|         o       |
|                 |
+----[SHA256]-----+

鍵が作成できました。
GitHubへの登録で利用するので公開鍵をcatした結果をコピーしておきます。

$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ec2-user@ip-192-140-1-1.ap-northeast-1.compute.internal

GitHubに鍵を設定する

先ほど作成した鍵をGitHubに登録していきます。
「Setting」→「SSH and GPG keys」とすすみ、 f:id:kabegiwakun:20180314232209p:plain
「New SSH key」を選択します。
f:id:kabegiwakun:20180314232449p:plain

catでコピーした公開鍵をKeyの部分に貼り付けて「Add SSH key」を選択します。
TItleはてきとーで大丈夫です。 f:id:kabegiwakun:20180314232935p:plain

ローカルリポジトリの作業

事前準備は以上で完了ですので実際にPushしていきます。

Pushしたいファイルをローカルリポジトリにaddする

git addを利用して最終的にGitHubにPushしたいファイルをローカルリポジトリにAddします。
今回はlambda_describe_tags_all.shというシェルスクリプトをAddしています。

$ git add ./lambda_describe_tags_all.sh

ローカルリポジトリにCommitする

さきほどAddしたファイルをCommitします。

$ git commit -m "Lambda関数のタグを一覧で出力する"

リモートリポジトリを設定する

リモートリポジトリの設定としてPushしたいGitHub上のリポジトリを指定してあげます。
例えば以下のリポジトリにPushしたい場合は、

github.com

こんなかんじでコマンドを実行してあげます。

$ git remote add origin git@github.com:takakabe/blog_shellscript.git

git@github.com:takakabe/blog_shellscript.gitの記述はGitHubのリポジトリの「Clone or Download」の赤枠のところをみればわかります。
f:id:kabegiwakun:20180314224128p:plain   

GitHubのリポジトリにPushする

さて、いよいよGitHubにPushしていきます。
以下コマンドを実行することでGitHubへファイルの更新を反映させることができます。

$ git push origin master

無事できました!
f:id:kabegiwakun:20180314234515p:plain

おわりに

GitHubをうまくつかっていきたいとおもいましたまる

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

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)

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

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

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

概要

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

かんたんな説明

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

84 mod 16 = 4 
16 mod 4 = 0

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

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

おわりに

説明下手感

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

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

画像でいうと赤枠のところ f:id:kabegiwakun:20180228185339p:plain

profileの編集

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

CyberduckでS3に接続してみる

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

すると、S3へ接続が行われ、バケットの一覧がでてきます。
f:id:kabegiwakun:20171101222245p:plain

バケット名をダブルクリックするとバケットの中身がみれます。
f:id:kabegiwakun:20171101222334p:plain

おわりに

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

おためしあれ!!!

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

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

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

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

事前準備

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

aws.amazon.com

以下の赤枠から32ビットまたは64ビットのものをダウンロードします。
f:id:kabegiwakun:20180211160146p:plain

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 ―クラウドにおけるサーバ管理の原則とプラクティス

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

実行確認

インスタンスが作成できました! f:id:kabegiwakun:20180208071013p:plain

おわりに

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

初めての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)

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

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

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

前提

以下のようなテーブルを用意しています。
これをすべてscanして取得します。 f:id:kabegiwakun:20180202064012p:plain

コード

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

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ガイド

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

  • 作者: 渡部徹太郎,河村康爾,北沢匠,佐伯嘉康,佐藤直生,原沢滋,平山毅,李昌桓
  • 出版社/メーカー: 秀和システム
  • 発売日: 2016/02/24
  • メディア: 単行本
  • この商品を含むブログ (3件) を見る

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によるサーバーレスアーキテクチャ

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_variableprivate_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完全読本

Ansible完全読本