のぴぴのメモ

自分用のLinuxとかの技術メモ

RHEL7.1でENA(Elastic Network Adapter)を利用する手順

はじめに

概要

ENA(Elastic Network Adapter)は、シングルルート I/O 仮想化 (SR-IOV) を使用したAWSの拡張ネットワーキングです。RHEL7.1にはこのENAのドライバが含まれていないため、RHEL7.1環境でENAを利用する場合は個別にインストールする必要があります。この記事は、RHEL7.1環境にENAドライバをインストールして利用可能にする手順をまとめたものです。

留意事項

RHEL7でENAがサポートしているのは、RHEL7.4以降になります。RHEL7.1ではENAサポートされていないため、その点は留意下さい。

確認環境

  • リージョン: 東京リージョン
  • 利用AMI: RHEL-7.1_HVM_GA-20150225-x86_64-1-Hourly2-GP2 (ami-b1b458b1)
  • 利用インスタンス: m4.16xlarge

ENAドライバインストール手順

RHEL7.1をm4インスタンスで起動してenaをインストールします。

RHEL7.1の初期状態の確認

(1)RHELカーネルバージョン、AMI/インスタンスタイプ確認

$ cat /proc/version 
Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015

$  curl http://169.254.169.254/latest/meta-data/ami-id;echo
ami-b1b458b1

$ curl http://169.254.169.254/latest/meta-data/instance-type;echo
m4.16xlarge

(2) enaドライバの確認
RHEL7.1でAMIからインスタンスを起動した状態では、enaドライバがないことを確認します。

$ sudo modinfo ena
modinfo: ERROR: Module ena not found.

enaドライバのビルドとインストール

(1)必要なrpmパッケージのインストール

git、 makeコマンド、gccコマンドなど必要なrpmパッケージをインストールします。また、gitが内部で利用するcurlのバージョンが古くgitが動作しないので、curlだけrpmをアップデートします。

$ sudo yum -y update curl
$ sudo yum -y install git make gcc
$ sudo yum -y install kernel-devel-$(uname -r)
(2)enaドライバのソースをgitから取得

マニュアル*1の内容に従いgitからコードをダウンロードします。

$ git clone https://github.com/amzn/amzn-drivers
(3)ビルド
$ cd amzn-drivers/kernel/linux/ena
$ make
(4)動作確認
$ sudo insmod ena.ko
$ lsmod |grep ena
ena                    98319  0  <==ドライバが組み込まれていることを確認
$ sudo rmmod ena
$ lsmod |grep ena
(5)インストール

(a) modprobeのカーネルモジュールロード設定追加

$ sudo sh -c 'cat >  /etc/modules-load.d/ena.conf'
ena

(b) モジュールのコピー・依存関係の更新・dracutの更新

$ sudo cp ena.ko /lib/modules/$(uname -r)/
$ sudo depmod
$ sudo dracut -f -v
(6)動作確認
$ sudo shutdown -r 0
<SSHログイン後>
$ cat /proc/version 
Linux version 3.10.0-229.el7.x86_64 (mockbuild@x86-035.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Thu Jan 29 18:37:38 EST 2015
$ lsmod|grep ena
ena                    98319  0 
(7)起動オプションの追加

最近のsystemdやudevでのデバイス命名は、enp5s0のような一貫性のある命名をします*2RHELのAMIから起動した場合は従来のeth0のようなデバイス名称を継続利用するために、このデバイス命名の一貫性の機能を無効化します。
(a) Grubのテンプレートファイルに設定を追加
起動オプションに、"net.ifnames=0"を追加します。

GRUB_TIMEOUT=1
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto console=ttyS0,115200n8 console=tty0 net.ifnames=0"
GRUB_DISABLE_RECOVERY="true"

(b)grub2設定更新

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sudo shutdown -r 0

インスタンスのENA有効化

インスタンスがstopの状態で、modify-instance-attributeでENAを有効化します。そして有効化後にインスタンスを起動します。

$ aws ec2 modify-instance-attribute --instance-id i-0180f9795f32bf2c1 --ena-support
$ aws --profile dev1 ec2 start-instances  --instance-ids i-0180f9795f32bf2c1

確認

dmesgやmessagesで状態を確認します。

(1)dmesg
[   22.879003] ena: module verification failed: signature and/or required key missing - tainting kernel
[   22.883928] ena: Elastic Network Adapter (ENA) v2.0.2g
[   22.884033] ena 0000:00:03.0: Elastic Network Adapter (ENA) v2.0.2g
[   22.890297] ena: ena device version: 0.10
[   22.890299] ena: ena controller version: 0.0.1 implementation version 1
[   22.938296] ena 0000:00:03.0: LLQ is not supported Fallback to host mode policy.
[   22.938397] ena 0000:00:03.0: creating 8 io queues. rx queue size: 1024 tx queue size. 1024 LLQ is DISABLED
[   22.943929] ena 0000:00:03.0: Elastic Network Adapter (ENA) found at mem f3000000, mac addr 06:b9:68:b9:70:b2 Queues 8, Placement policy: Regular

"ena: Elastic Network Adapter (ENA) v2.0.2g"以下の行で、enaがロードされ初期化されているのがわかります。

(2)/var/log/messages
Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info>  (eth0): carrier is OFF (but ignored)
Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info>  (eth0): new Ethernet device (driver: 'ena' ifindex: 2)
Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info>  (eth0): exported as /org/freedesktop/NetworkManager/Devices/0
Dec 10 01:13:54 ip-10-0-0-136 NetworkManager[1190]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(3) sysfs
$ ll /sys/class/net/eth0/
total 0
-r--r--r--.  1 root root 4096 Dec 10 02:23 addr_assign_type
-r--r--r--.  1 root root 4096 Dec 10 02:23 address
-r--r--r--.  1 root root 4096 Dec 10 02:28 addr_len
-r--r--r--.  1 root root 4096 Dec 10 02:28 broadcast
-rw-r--r--.  1 root root 4096 Dec 10 02:28 carrier
lrwxrwxrwx.  1 root root    0 Dec 10 02:23 device -> ../../../0000:00:03.0
-r--r--r--.  1 root root 4096 Dec 10 02:23 dev_id
-r--r--r--.  1 root root 4096 Dec 10 02:23 dev_port
-r--r--r--.  1 root root 4096 Dec 10 02:28 dormant
-r--r--r--.  1 root root 4096 Dec 10 02:28 duplex
-rw-r--r--.  1 root root 4096 Dec 10 02:28 flags
-rw-r--r--.  1 root root 4096 Dec 10 02:28 ifalias
-r--r--r--.  1 root root 4096 Dec 10 02:23 ifindex
-r--r--r--.  1 root root 4096 Dec 10 02:23 iflink
-r--r--r--.  1 root root 4096 Dec 10 02:28 link_mode
-rw-r--r--.  1 root root 4096 Dec 10 02:28 mtu
-rw-r--r--.  1 root root 4096 Dec 10 02:28 netdev_group
-r--r--r--.  1 root root 4096 Dec 10 02:28 operstate
-r--r--r--.  1 root root 4096 Dec 10 02:23 phys_port_id
drwxr-xr-x.  2 root root    0 Dec 10 02:28 power
drwxr-xr-x. 18 root root    0 Dec 10 02:23 queues
-r--r--r--.  1 root root 4096 Dec 10 02:28 speed
drwxr-xr-x.  2 root root    0 Dec 10 02:28 statistics
lrwxrwxrwx.  1 root root    0 Dec 10 02:23 subsystem -> ../../../../../class/net
-rw-r--r--.  1 root root 4096 Dec 10 02:28 tx_queue_len
-r--r--r--.  1 root root 4096 Dec 10 02:23 type
-rw-r--r--.  1 root root 4096 Dec 10 02:23 uevent

eth0に対応するハードウェアが、PCIの"0000:00:03.0”であることを確認し、次じそのデバイス情報を参照します。すると下記の通り、”driver -> ../../../bus/pci/drivers/ena”をドライバとして利用していることがわかり、結果eht0はenaであることが確認できます。

$ ll /sys/devices/pci0000\:00/0000\:00\:03.0/
total 0
-rw-r--r--. 1 root root  4096 Dec 10 02:26 broken_parity_status
-r--r--r--. 1 root root  4096 Dec 10 02:23 class
-rw-r--r--. 1 root root   256 Dec 10 02:23 config
-r--r--r--. 1 root root  4096 Dec 10 02:26 consistent_dma_mask_bits
-rw-r--r--. 1 root root  4096 Dec 10 02:26 d3cold_allowed
-r--r--r--. 1 root root  4096 Dec 10 02:23 device
-r--r--r--. 1 root root  4096 Dec 10 02:26 dma_mask_bits
lrwxrwxrwx. 1 root root     0 Dec 10 02:23 driver -> ../../../bus/pci/drivers/ena
-rw-r--r--. 1 root root  4096 Dec 10 02:26 enable
lrwxrwxrwx. 1 root root     0 Dec 10 02:26 firmware_node -> ../../LNXSYSTM:00/device:00/PNP0A03:00/device:1b
-r--r--r--. 1 root root  4096 Dec 10 02:26 irq
-r--r--r--. 1 root root  4096 Dec 10 02:26 local_cpulist
-r--r--r--. 1 root root  4096 Dec 10 02:23 local_cpus
-r--r--r--. 1 root root  4096 Dec 10 02:26 modalias
-rw-r--r--. 1 root root  4096 Dec 10 02:26 msi_bus
drwxr-xr-x. 2 root root     0 Dec 10 02:23 msi_irqs
drwxr-xr-x. 3 root root     0 Dec 10 02:23 net
-r--r--r--. 1 root root  4096 Dec 10 02:23 numa_node
drwxr-xr-x. 2 root root     0 Dec 10 02:26 power
--w--w----. 1 root root  4096 Dec 10 02:26 remove
--w--w----. 1 root root  4096 Dec 10 02:26 rescan
-r--r--r--. 1 root root  4096 Dec 10 02:26 resource
-rw-------. 1 root root 16384 Dec 10 02:26 resource0
-rw-r--r--. 1 root root  4096 Dec 10 02:26 rx_copybreak
lrwxrwxrwx. 1 root root     0 Dec 10 02:23 subsystem -> ../../../bus/pci
-r--r--r--. 1 root root  4096 Dec 10 02:26 subsystem_device
-r--r--r--. 1 root root  4096 Dec 10 02:26 subsystem_vendor
-rw-r--r--. 1 root root  4096 Dec 10 02:23 uevent
-r--r--r--. 1 root root  4096 Dec 10 02:23 vendor

RHUIとredhat社のインストールメディアのrpmパッケージファイルの中身に差異があるか確認してみた→結果差異はない

概要

RHUIとredhat社がカスタマーポータルで提供しているrpmパッケージの中身に差異があるのかどうかという話があったので、2つのファイルのdiffをとって確かめてみた。
→結果、差異はなかった。

確認方法

  • redhat社のカスタマーポータルRHEL7.5のDVDを取得(Red Hat Enterprise Linux 7.5 Binary DVD)
  • DVDの/Packagesの下にあるrpmパッケージファイルをを一覧化
  • その一覧を元に、AWS上のRHELインスタンスからyumdownloaderでRHUIの同じ種類・バージョン・アーキテクチャのファイルをダウンロード
  • DVDとRHUIのファイルをdiffコマンドで差分の有無を確認

確認手順詳細

(1)redhatのカスタマーポータルからISOを落とす
f:id:nopipi:20181208174231p:plain
ここから、下記のisoをダウンロード
f:id:nopipi:20181208174235p:plain
(2)ISOをループバックマウントして、rpmファイルをリスト化
RHELのサーバにダウンロードしたisoをコピーして、

mkdir dvd
sudo mount -o loop rhel-server-7.5-x86_64-dvd.iso dvd
find dvd/Packages/ -name '*.rpm' > rpmlist

(3)RHUIから同じrpmをダウンロード
リストを元にyumdownloaderでRHUIからrpmファイルを取得する以下のようなスクリプトを作成

sudo yumdownloader 389-ds-base-1.3.7.5-18.el7.x86_64
sudo yumdownloader 389-ds-base-libs-1.3.7.5-18.el7.x86_64
sudo yumdownloader ElectricFence-2.2.2-39.el7.x86_64
sudo yumdownloader ElectricFence-2.2.2-39.el7.i686
sudo yumdownloader GConf2-3.2.6-8.el7.i686
sudo yumdownloader GConf2-3.2.6-8.el7.x86_64
sudo yumdownloader GeoIP-1.5.0-11.el7.i686
sudo yumdownloader GeoIP-1.5.0-11.el7.x86_64
sudo yumdownloader ImageMagick-c++-6.7.8.9-15.el7_2.i686
sudo yumdownloader ImageMagick-c++-6.7.8.9-15.el7_2.x86_64
sudo yumdownloader ImageMagick-perl-6.7.8.9-15.el7_2.x86_64
以下略

上記スクリプトを適用に分割して、パラレル実行してrpmパッケージをダウンロード
(4)ダウンロードしたファイルをrpmディレクトリに移動

mkdir rpm
mv *.rpm rpm

(5)diffで差分があるか確認

for i in $(cat rpmlist);do file=$(basename $i);diff $i rpm/$file;done

結果

rpmパッケージファイルの中身には差分なし

yumで特定のバージョンのrpmパッケージとそのパッケージの依存パッケージをダウンロードする

RHELで、yumレポジトリに接続できない環境のRHELを、最新版でない特定バージョンのカーネルにあげたいという話があり検証した結果です。

1.検証概要

  • やること:隔離された環境のRHEL7.2(3.10.0-327.el7)をRHEL7.5相当のカーネル(3.10.0-862.14.4)にアップデートする
  • 検証利用AMI:RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2

検証概要:代替えインスタンスでRHUIからrpmをyumdownloaderでダウンロードして、転送してrpmコマンドでアップロードする

2.手順

2.1 代替えインスタンでのrpmパッケージダウンロード

(1)作業用インスタンスとして、RHEL7.2のインスタンスを作成する

インターネット接続が可能なVPCのパブリックサブネット状に、コミュニティAMI(RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2 )からインスタンスを作成する。

(2) yumdownloaderのインストール

代替えインスタンスログイン後、まずは必要なコマンドをインストールする

sudo yum -y install yum-utils
(3) rpm作業用ディレクトリ作成
mkdir update_packages
cd update_packages && pwd
(4) 対象カーネルrpmを確認

(a) アップデートしたいカーネルバージョンがRHUIにあるかを確認

sudo yum --showduplicate list kernel
  • "--showduplicate"はリポジトリで利用可能な全てのバージョンを表示するオプションです(通常は最新バージョンのみ表示)

(b) 該当バージョンのパッケージ名称の確認

sudo yum list kernel-3.10.0-862.14.4.el7
(5)対象rpmパッケージをダウンロードする
sudo yumdownloader --resolve kernel-3.10.0-862.14.4.el7
  • "--resolve”が、依存関係をチェックして必要なパッケージをまとめてダウンロードするオプションです。
(6)対象rpmパッケージを対象インスタンスに転送
cd ..
tar czf update_packages.tar.gz update_packages

なんらかの方法で作成したupdate_packages.tar.gzを、アップデート対象インスタンスに持ち込む

2.2 アップデート対象インスタンでアップデート

(1)現状のカーネルバージョンの確認

アップデート対象インスタンスログイン後に、

cat /proc/version 
Linux version 3.10.0-327.el7.x86_64 (mockbuild@x86-034.build.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Oct 29 17:29:29 EDT 2015
(2)rpmパッケージの準備
tar xzf update_packages.tar.gz 
cd update_packages
(3) カーネルアップデート
sudo rpm -U *.rpm
(4) リブートしてバージョンを確認
sudo shutdown -r 0
<再ログイン後>
cat /proc/version
Linux version 3.10.0-862.14.4.el7.x86_64 (mockbuild@x86-040.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Fri Sep 21 09:07:21 UTC 2018

EC2 A1(ARM base:AWS Graviton Processors)インスタンスを見てみる

今日Re:Inventで発表されたA1インスタンスのcpuinfoとかを見てみますた。
こちらのインスタンスの特徴は、AWS Graviton ProcessorsというAWS謹製のARMプロセッサを利用し、低消費電力

確認環境

  • インスタンスタイプ: a1.xlarge
  • AMI:amzn2-ami-hvm-2.0.20181114-arm64-gp2 (ami-00d2a06d6dd390d70) ARM版のAMZ2
  • リージョン: N.Virginia

まずはdmesg

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.77-81.59.amzn2.aarch64 (mockbuild@ip-10-0-3-22) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Mon Nov 12 21:28:57 UTC 2018
[    0.000000] Boot CPU: AArch64 Processor [410fd083]

AArch64 Processorとあって、まあ”ARM 64bit”てことがわかりますね。当たり前ですが。

/proc/cpuinfo

[ec2-user@ip-172-31-27-144 ~]$ cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 166.66
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

以下略

ここで注目すべきは"CPU part : 0xd08"。ARM社のページ情報によると、こちらは"Cortex-A72 processor”の設計を利用していることがわかります。"Cortex-A72 processor"は、こちらwikipediaページによると" ARMv8-A 64-bit instruction set designed by ARM Holdings. "とあるので、ARMが設計した64bit ARM(ARMv8-A 64-bit instruction set)のプロセッサをベースとしていそうですね。
"Cortex-A72 processor”は、2015年にARMが発表した64bitのARMのCPU コア IP で、Android携帯のCPUで有名な Qualcomm, Inc.のSnapdragon(Snapdragon 650)で利用されてたりします。 こちらをみると、Xperiaの一部機種で採用されているようで、スマートホンのCPUがサーバに入っていると考えると、オッ!!と思いますよね。

ECRにdockerログインしてImageをpush/pullしたりリポジトリやイメージ一覧取得)する手順

ECRにログインする

awsコマンドでECRにログインするためのdockerの認証情報を取得してログインします。

$(aws ecr get-login --no-include-email)

実行すると認証用のdockerコマンドの文字列(docker login ....)が出力されるので、それをシェルのコマンド置換"$(...)"を利用してそのまま実行してdockerログインします。

ECRにリポジトリを作成する

awsコマンドの"aws ecr create-repository"でECRのリポジトリを作成します。その際に後続のpushで利用するので、 "repositoryUri"を控えておきます。

aws ecr create-repository --repository-name sample-app
{
    "repository": {
        "registryId": "xxxxxxxxxxxx", 
        "repositoryName": "sample-app", 
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxxxxxxxxx:repository/sample-app", 
        "createdAt": xxxxxxxxxxxx.0, 
        "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app"
    }
}

ECRにイメージをpushする

(1)dockerイメージの確認
"docker images"コマンドでイメージ一覧を取得しpushするdockerイメージを確認する。今回は、sample-appをpushする。

docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
sample-app          latest              688a2109cc33        23 minutes ago      368MB
php                 7.0-apache          8e2efe9163dd        10 days ago         368MB
centos              latest              75835a67d134        2 weeks ago         200MB

(2)push用のtag付け
リポジトリにプッシュするイメージにタグを付けます。 "sample-app:latest"を"[repositoryUri]:latest"にタグ付けします。

docker tag sample-app:latest xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app:latest

(3)ECRへのdockerイメージpush
作成したタグを利用してECRのレポジトリにpushします。

docker push xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app:latest

(4)ECRレポジトリのイメージ確認
awsコマンド”aws ecr describe-images”でpushしたイメージを確認します。

aws ecr describe-images --repository-name sample-app

(5)(オプション)ローカルのdockerイメージ削除
必須でないですが、ローカルのdockerイメージを削除する場合は"docker rmi -f [Image ID] [Image ID] [Image ID]"コマンドで削除します。

ECRからイメージをpullする

ECRのレポジトリとイメージを確認する

(1)ECRレポジトリを確認する
aws ecr describe-repositories”コマンドでレポジトリ一覧を取得して、"repositoryUri"を確認します。

aws ecr describe-repositories
{
    "repositories": [
        {
            "registryId": "xxxxxxxxxxxx", 
            "repositoryName": "sample-app", 
            "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxxxxxxxxx:repository/sample-app", 
            "createdAt": xxxxxxxxxxxx.0, 
            "repositoryUri": "xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app"
        }
    ]
}

(2)対象レポジトリ内のイメージを確認する
aws cliの”aws ecr describe-images --repository-name php-sample”コマンドでレポジトリ一覧を取得して"imageTags"を確認します。

aws ecr describe-images --repository-name sample-app
{
    "imageDetails": [
        {
            "imageSizeInBytes": 133346056, 
            "imageDigest": "sha256:8401bb0035eedc2f101d96eabdf9ed37269f76f14daed080fe924d54d9772037", 
            "imageTags": [
                "latest"
            ], 
            "registryId": "xxxxxxxxxxxx", 
            "repositoryName": "sample-app", 
            "imagePushedAt": xxxxxxxxxxxx.0
        }
    ]
}

docker pullする

(1)dockerコマンドで、"docker pull [repositoryUri]:[Tag]"でイメージをpullします。

docker pull xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app:latest

(2)"docker images"でpullしたイメージを確認する

docker images
REPOSITORY                                                     TAG                 IMAGE ID            CREATED             SIZE
xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-app   latest              688a2109cc33        About an hour ago   368MB

S3クロスリージョンレプリケーションのレプリ時間を計測してみた

はじめに

あるシステムで東京リージョンとシンガポールリージョンで、S3のクロスリージョンレプリケーション構成を組んだディザスターリカバリーを検討しているのですが、DR計画のRPOの話の延長でレプリケーションの遅延時間てどれぐらいなんだろうねぇ〜という話があって、そんなにかからないだろうなという感覚はありつつ、確認したことがなかったので試しに測定してみました。

検証結果

(1)オブジェクトサイズとレプリケーション時間の関係

f:id:nopipi:20181112234614p:plain

  • オブジェクトサイズとレプリケーションの転送時間は比例関係であることを確認(リージョン間のネットワーク帯域に依存するということですね。当然ですが)
  • 1GBのオブジェクトで20秒〜1分程度、10GBのオブジェクトで3〜4分、80GBのオブジェクトになると15〜30分程度
(2)測定結果から見えるインスタンスからのPUTとレプリケーションの挙動

測定結果を見ると、インスタンスのPUT完了時間と、レプリケーションの状態がPENDINGになるのがほぼ同時刻になっていました。そのことから、インスタンスからS3バケットへのPUT処理が完了し、バケット上で新しいオブジェクトにアクセスできるようになったタイミングからレプリケーション処理が始まっているように見えます。

f:id:nopipi:20181112235946p:plain:w500

構成概要

検証構成は以下の通りです。(新しいシンプルアイコンで書いてみました)

f:id:nopipi:20181112223110p:plain:w450

検証手順

VPCに作成したインスタンスから検証用のファイルをS3バケットにPUTします。クロスリージョンレプリケーションの転送処理は、オブジェクトのレプリケーション状態をチェックしてPENDIG状態になっていた時間を測定し、その時間をレプリケーションの転送時間と皆しています。

(1)S3クロスリージョンレプリケーションの設定

下記のドキュメントなどを参考にS3バケット作成&バージョニング有効化と、クロスリージョンレプリケーションの設定をします。下記の手順ではIAMロールを手動作成するようになっていますが、マネージメントコンソールで設定する場合、IAMロース選択で「Create new role」を選ぶと必要なIAMロールを自動作成してくれます。

(2)インスタンスの準備

(a)インスタンスの選択

今回はインスタンスのネットワーク帯域やディスクIOネックならないようにするため、m5d.24xlargeを選択しています。

  • m5d.24xlargeの特徴
    • ネットワーク帯域: 25Gbps*1
    • ディスク:SSD インスタンスストアボリュームによる高IO性能

またcrr-source-bucket-xxバケットへのフルアクセスを行うIAMロールをこのインスタンスに付与しています。

(b)jqのインストール

jqをインストールします。(検証用ツール(シェルスクリプト)の中でjq コマンドを使っているので)

sudo yum -y install jq
(c)作業用インスタンスストアボリュームのフォーマット

インスタンスストアボリュームはインスタンス起動時に初期化しなければならないため、初期化します。

sudo mkfs -t xfs /dev/nvme1n1
mkdir a
sudo mount /dev/nvme1n1 ./a
sudo chown -R ec2-user:ec2-user a

(3)検証用ダミーファイル(S3へのPut用)の準備

10MBから2倍づつサイズを増やし80GBまでのS3へのPut用ファイルを作成します。ファイルはOSやVP内部の何らかの圧縮処理による影響(があった場合)を排除するために、urandomデバイスかの乱数データから作成しています。(乱数は情報のエントロピーが高く圧縮率が低くなるため、圧縮効果を極力排除することができます。逆にゼロが連続するようなデータは情報エントロピーが低くく圧縮効率が高いため、検証結果に圧縮効果の影響が出る可能性が高くなります)

cd a && mkdir data && cd data
nohup dd if=/dev/urandom  of=test_data-10M bs=1048576 count=10 &
nohup dd if=/dev/urandom  of=test_data-20M bs=1048576 count=20 &
nohup dd if=/dev/urandom  of=test_data-40M bs=1048576 count=40 &
nohup dd if=/dev/urandom  of=test_data-80M bs=1048576 count=80 &
nohup dd if=/dev/urandom  of=test_data-160M bs=1048576 count=160 &
nohup dd if=/dev/urandom  of=test_data-320M bs=1048576 count=320 &
nohup dd if=/dev/urandom  of=test_data-640M bs=1048576 count=640 &
nohup dd if=/dev/urandom  of=test_data-1.3G bs=1048576 count=1280 &
nohup dd if=/dev/urandom  of=test_data-2.5G bs=1048576 count=2560 &
nohup dd if=/dev/urandom  of=test_data-5G bs=1048576 count=5120 &
nohup dd if=/dev/urandom  of=test_data-10G bs=1048576 count=10240 &
nohup dd if=/dev/urandom  of=test_data-20G bs=1048576 count=20480 &
nohup dd if=/dev/urandom  of=test_data-40G bs=1048576 count=40960 &
nohup dd if=/dev/urandom  of=test_data-80G bs=1048576 count=81920 &
cd ..

(4)検証用スクリプトの準備

下記のスクリプトを "a"フォルダに格納し、実行権限を付与(chmod +x *.sh)します

(a)検証用コード
  • test.sh
#!/bin/sh

DATADIR="./data"
LOGGINGSH="./logging.sh"
SRCBUCKET="crr-source-bucket-xx"
SRCBUCKETURI="s3://${SRCBUCKET}"


for t in $(seq 1 10)
do
    for size in 10M 20M 40M 80M 160M 320M 640M 1.3G 2.5G 5G 10G 20G 40G 80G
    #for size in 10M 20M
    do
        TFILE="test_data-${size}-${t}"
        REPLILOG="replicate-${TFILE}.log"
        PUTLOG="put-${TFILE}.log"
        nohup ${LOGGINGSH} ${SRCBUCKET} ${TFILE} > replicate-${TFILE}.log &

        # put object
        date > ${PUTLOG}
        echo aws s3 cp "${DATADIR}/test_data-${size}" ${SRCBUCKETURI}/${TFILE}
        echo aws s3 cp "${DATADIR}/test_data-${size}" ${SRCBUCKETURI}/${TFILE} >> ${PUTLOG}
        aws s3 cp "${DATADIR}/test_data-${size}" ${SRCBUCKETURI}/${TFILE} 
        date >> ${PUTLOG}
    done
done
(b)検証コードから呼び出されるレプリケーション状態をロギングするコード
  • logging.sh
#!/bin/sh

bucket=$1
file=$2
stat=NULL

while true;
do
    A=$(date); 
    B=$(aws s3api head-object --bucket ${bucket} --key ${file} |jq '.ReplicationStatus')
    if [ "A${stat}" = "ANULL" -a "A${B}" = "A\"PENDING\"" ]; then stat="PENDING";fi

    echo ${A} ${B} ${file}

    if [ "A${stat}" = "APENDING" -a "A${B}" = "A\"COMPLETED\"" ]; then break; fi
done
(c)検証事前準備
  • put_zerofiles.sh
#!/bin/sh

DATADIR="./data"
LOGGINGSH="./logging.sh"
SRCBUCKET="s3://crr-source-bucket-xx"
ZEROFILE="dummy.dat"

touch dummy.dat

for t in $(seq 1 10)
do
    for size in 10M 20M 40M 80M 160M 320M 640M 1.3G 2.5G 5G 10G 20G 40G 80G
    do
        TFILE="test_data-${size}-${t}"
        REPLILOG="replicate-${TFILE}.log"
        PUTLOG="put-${TFILE}.log"

        # put object
        aws s3 cp ${ZEROFILE} ${SRCBUCKET}/${TFILE} 
        date >> ${PUTLOG}
    done
done

(5)ファイルの設置

測定の関係で同名称のファイルをcrr-source-bucket-xxバケットに事前配置します。

./put_zerofiles.sh

(6)測定

測定します。2〜3時間がかかるので寝かせておきます。

nohup ./test.sh

(7)結果の集計

測定が終わったら、下記の分析シェルで実行ログを分析します。

(a) インスタンスからS3へのオブジェクトput時間の分析シェル
  • analysis1.sh
#!/bin/sh

for size in 10M 20M 40M 80M 160M 320M 640M 1.3G 2.5G 5G 10G 20G 40G 80G
#for size in 10M 20M
do
    for t in $(seq 1 10)
    do
        TFILE="test_data-${size}-${t}"
        REPLILOG="replicate-${TFILE}.log"
        PUTLOG="put-${TFILE}.log"

        S=$(head -1 ${PUTLOG})
        E=$(tail -1 ${PUTLOG}) 
        echo "${TFILE}, $S, $E"
    done
done
(b) レプリケーションPENDIG時間の分析
  • analysis2.sh
#!/bin/sh

for size in 10M 20M 40M 80M 160M 320M 640M 1.3G 2.5G 5G 10G 20G 40G 80G
#for size in 10M 20M
do
    for t in $(seq 1 10)
    do
        TFILE="test_data-${size}-${t}"
        REPLILOG="replicate-${TFILE}.log"
        PUTLOG="put-${TFILE}.log"

        grep PENDING $REPLILOG > /tmp/xxx
        S=$(head -1 /tmp/xxx)
        E=$(tail -1 /tmp/xxx) 
        echo "${TFILE}, $S, $E"

    done
done

AWS CloudFormationで、インスタンスのUserDataにクロススタックリファレンスの値を埋め込む方法

自分用のメモです。
こちらのAWS CloudFormationのヘルパーのコマンド実行文字列にクロススタックリファレンスの値を埋め込む方法 - のぴぴのメモの記事の応用です。

方法

Fn::Joinの文字列結合で、Fn::Sub(!Sub)や、Fn::ImportValueのクロススタックリファレンスを組み合わせる。
また改行コードは、"\n"で入力できる。

サンプル

      UserData:
        Fn::Base64:
          Fn::Join:
            - ""
            - - !Sub |
                #!/bin/bash -xe

                #set /etc/httpd/conf.d/ssl.conf
                cat > /etc/httpd/conf.d/ssl.conf << EOL
               
                  SSLProxyEngine On
                  SSLProxyCheckPeerCN off
                  SSLProxyCheckPeerExpire off

                  # Targets web server
              - "ProxyPass / https://"
              - Fn::ImportValue: !Sub ${Environment}-${Stack}-TargetUrl
              - "\nProxyPassReverse / https://"
              - Fn::ImportValue: !Sub ${Environment}-${Stack}-TargetUrl
              - "\n"
              - !Sub |
                </VirtualHost>

                # Application-B
                <VirtualHost _default_:1234>
                  ErrorLog logs/proxy_hogehoge_error_log
                <以下略>

オレオレ証明書をワンライナーで作る方法

自己署名証明書(オレオレ証明書)を作る時、コマンドを3回叩いたり、コマンド実行したら対話的に入力したりで簡単にバッチ化できないかなぁ〜と調べたメモです。
ほぼ、こちらの内容の抜粋です。
blog.hifumi.info

手順

(1)自己署名証明書

export URLNAME=hoge.com
openssl req -x509 -days 36500 -newkey rsa:2048 -nodes -out ${URLNAME}.crt -keyout ${URLNAME}.key -subj "/C=JP/ST=Tokyo/L=null/O=null/OU=null/CN=${URLNAME}/"

(2)作成した自己署名証明書の確認

openssl x509 -text -noout -in ${URLNAME}.crt

openssl reqのオプション

  • -x509 : 証明書要求の代わりに自己署名証明書を出力する
  • -days 日数:証明書の有効期間の日数(デフォルトは30日)
  • -newkey rsa:2048 : 新しい証明書署名要求と秘密鍵を作成する。形式は"rsa:2048"。
  • -nodes : 秘密鍵作成時にパスフレーズを要求しない(暗号化しない)
  • -out ${URLNAME}.crt :標準出力の出力先ファイルの指定(上記手順では、自己署名証明書が出力される)
  • -keyout ${URLNAME}.key :秘密鍵の出力先
  • -subj "/C=JP/ST=Tokyo/L=null/O=null/OU=null/CN=${URLNAME}/": 証明書作成時に対話で聞かれる内容を指定する
    • C=国(JPとか)*1
    • ST=州/都道府県
    • L=住所
    • O=組織
    • OU=組織部
    • CN=FQDNや個人名
    • 補足:C、ST、Lなどの略語は、”openssl x509 -text -noout -in ${URLNAME}.crt”で参照した時の"Issuer:"の略称と一致します。

openssl x509のオプション

  • text:テキスト表示
  • -noout:符号化されたデータ(自己署名証明書ファイルそのもの)は表示しない
  • -in ${URLNAME}.crt:入力ファイルの指定(ここでは自己署名証明書を指定)

*1:指定できるCountory codesはこちら

AWS CloudFormationのヘルパーのコマンド実行文字列にクロススタックリファレンスの値を埋め込む方法

自分用のメモです。
CloudFormationのヘルパーに埋め込む実行コマンドの文字列に、他のスタックで作成した値をクロススタックリファレンスで埋め込む方法が、なかなか分からなかったので。

方法

Fn::Joinの文字列結合とFn::ImportValueのクロススタックリファレンスを組み合わせる

サンプル

        Metadata:
            AWS::CloudFormation::Init:
                config:
                    packages:
                        yum:
                            awslogs: []
                    commands:
                        01_add_proxy_to_ecs_agent1:
                            command:
                                Fn::Join:
                                    - ""
                                    - - "echo HTTP_PROXY="
                                      - Fn::ImportValue: !Sub ${ProxyStack}-Proxy1PrivateDns
                                      - ":"
                                      - Fn::ImportValue: !Sub ${ProxyStack}-Proxy1PortNumber 
                                      - " >> /etc/ecs/ecs.config"
  • "01_add_proxy_to_ecs_agent1:"のブロックがその例
  • クロススタックリファレンスは下記の2つ
    • Fn::ImportValue: !Sub ${ProxyStack}-Proxy1PrivateDns
    • Fn::ImportValue: !Sub ${ProxyStack}-Proxy1PortNumber
  • 上記を含め Fn::Join:で文字列結合する

結果

完成するとこんな感じのコマンド実行用の文字列になる

  • "echo HTTP_PROXY=ip-10-203-64-147.ap-northeast-1.compute.internal:3128 >> /etc/ecs/ecs.config"

AWS 各リージョンのデフォルトVPCをまとめて削除するpythonスクリプト(boto3利用)

AWS SDK for Python (Boto3)の練習用に、各リージョンのデフォルトVPCをまとめて削除するpythonツールを作りました。
github.com

前提環境

利用方法

git clone https://github.com/Noppy/delete_default_vpc.git
  • (3)実行する
cd delete_default_vpc
./delete_default_vpc.py -a 'AWS_ACCESS_KEY_ID' -s 'AWS_SECRET_KEY_ID'
  • 引数でアクセスキー&シークレットキーを渡すのはセキュリティの観点から正直バットプラクティスなので、実用化する場合はセッション取得周りの実装を見直したほうが良いと思います。

蛇足

boto3の全体像が理解できなく、結構苦労し

vimの設定と操作時のTips

vimを利用する時の設定と操作時のメモです。

1. ~/.vimrc設定

" setting
set fenc=utf-8 "文字コードをUFT-8に設定
set nobackup   " バックアップファイルを作らない
set noswapfile " スワップファイルを作らない
set showcmd    " 入力中のコマンドをステータスに表示する

" 見た目系
set number           "行番号を表示
set smartindent      " インデントはスマートインデント
set visualbell       " ビープ音を可視化
set showmatch        " 括弧入力時の対応する括弧を表示
set laststatus=2     " ステータスラインを常に表示
set wildmode=list:longest " コマンドラインの補完
"set cursorline       " 現在の行を強調表示
"set cursorcolumn     " 現在の行を強調表示(縦)
:syntax on           "構文解析に基づいて色を付ける

" Tab系
set list listchars=tab:\▸\- " 不可視文字を可視化(タブが「▸-」と表示される)
set expandtab               " Tab文字を半角スペースにする
set tabstop=4               " 行頭以外のTab文字の表示幅(スペースいくつ分)
set shiftwidth=4            " 行頭でのTab文字の表示幅

" 検索系
set ignorecase  " 検索文字列が小文字の場合は大文字小文字を区別なく検索する
set smartcase   " 検索文字列に大文字が含まれている場合は区別して検索する
set incsearch   " 検索文字列入力時に順次対象文字列にヒットさせる
set wrapscan    " 検索時に最後まで行ったら最初に戻る
set hlsearch    " 検索語をハイライト表示
" ESC連打でハイライト解除 
nmap <Esc><Esc> :nohlsearch<CR><Esc>

多分こちらのページの内容をベースに多少カスタマイズしたものです。

2. vim操作のTips

2.1 カット&ペーストするとずれる問題

vimで、:a! を実行し挿入モードにしてから貼り付ける。*1

  • 手順
    • ESCを押してカーソルが最終行に移動したら、 ":a!"を入力
    • そのまま貼り付けたい内容をペーストする
    • 貼り付けが完了し、ESCでモード終了すると反映される

VPC 閉域空間でCloudFormationのcfnヘルパーを使うときは、CFnのEndpointがいる話

インターネット接続していないVPC環境で、CloudFormationのcfnヘルパーを使ってインスタンスの中のセットアップをしたら、インスタンスの作成がエラーになってハマった話です。

原因

cfnヘルパーでの設定完了を通知するcfn-signalがCloudFormationのエンドポイントと通信できず、完了通知ができなかったため

対処

VPCにCloudFormationのVPC Endpoint(Private Link)を設置する。


ちなみに、CloudFormationのPrivate Link(VPC EndpointのInterface型)がサポートされたのは、2018年8月22日でつい先日の話でした。

参考情報

Creating the VPC EndPoint for AWS CloudFormation

To create the VPC endpoint for the AWS CloudFormation service, use the Creating an Interface Endpoint procedure in the Amazon VPC User Guide to create the following endpoint:

com.amazonaws.region.cloudformation

region represents the region identifier for an AWS region supported by AWS CloudFormation, such as us-east-2 for the US East (Ohio) Region.

VPC閉塞網からyumリポジトリにアクセスする(Amazon Linux & RHEL)

はじめに

セキュリティなどの理由で、VPCからインターネットへの外の通信をさせないようにしている環境を想定した検証環境で、必要なパッケージ追加をしようとしてハマったのでまとめました。

  • 結論
    • Amazon Linux : S3のVPC Endpointを設ける
    • RHEL : ForwardProxy(URLフィルタリング)を利用する
  • 変更履歴
    • 2018.10.28 update: AL2の場合の設定がなかったので追記しました
    • 2020.9.20 update: RHELのRHUIのURLが変更されていたのでアップデートしました。
    • 2021.6.27 Amazon Linux2で、"arn:aws:s3:::amazonlinux-2-repos-/*"バケットへのアクセスも必要になっていたのでポリシーに追加しました。

Amazon Linux1&2の場合

概要

Amazon Linuxのyumリポジトリは、S3が利用されています。ですので、S3用のVPC Endpointを作ることでInternet Gatewayを介さずにyumリポジトリにアクセスすることができるようになります。


VPC Endpoint(S3)の設定

VPCに、S3用のVPC Endpointを作成して、yumリポジトリ用のS3バスケット(下記の2個)にからオプジェクトをGetできるようにします。

  • (AmazonLinux)yumリポジトリのS3バスケット
    • packages.Region Code.amazonaws.com/*",
    • repo.Region Code.amazonaws.com/*"
  • (AmazonLinux2)yumリポジトリのS3バスケット
    • amazonlinux.Region Code.amazonaws.com
    • amazonlinux-2-repos-Region Code ※2021.6頃以降はこちらに変更された模様

Endpointのポリシーには以下のような設定をします。より厳密にするためには、amazonの前の"*"を各リージョンのコード(例えば東京リージョンの場合、ap-northeast-1)とします。

{
  "Statement": [
    {
      "Sid": "Amazon Linux AMI Repository Access",
      "Principal": "*",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::packages.*.amazonaws.com/*",
        "arn:aws:s3:::repo.*.amazonaws.com/*",
        "arn:aws:s3:::amazonlinux.*.amazonaws.com/*",
        "arn:aws:s3:::amazonlinux-2-repos-<B>Region Code</B>/*""
      ]
    }
  ]
}

公式情報は、Amazon Linuxのよくある質問をご覧ください。

上記のVPCエンドポイントポリシーを作成するCloudFormationのサンプルです

  S3VpcEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId:  !Ref Vpc
      ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
      RouteTableIds:
        - !Ref RouteTable1
        - !Ref RouteTable2
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal: '*'
            Action:
              - 's3:*'
            Resource:
              # Allow connections to the Amazon Linux yum repositories
              - "arn:aws:s3:::packages.*.amazonaws.com/*"
              - "arn:aws:s3:::repo.*.amazonaws.com/*"
              # Allow connections to the Amazon Linux2 yum repositories
              - "arn:aws:s3:::amazonlinux.*.amazonaws.com/*"
              - Fn::Join:
                  - ""
                  - - "arn:aws:s3:::amazonlinux-2-repos-"
                    - !Sub "${AWS::Region}"
                    - "/*"

RHELの場合

概要

License includedなRHELを利用した場合のパッケージ管理は、Red Hat Update Infrastructure (RHUI) を利用します。

Q: Red Hat Enterprise Linux を実行中の Amazon EC2 インスタンス用に、更新や定期的なパッチを受け取るにはどのようにすればよいですか?

Red Hat Update Infrastructure (RHUI) が Red Hat によってそれぞれの AWS リージョンでメンテナンスされており、定期的なアップデートとパッチを利用できます。Red Hat Enterprise Linux インスタンスはリージョンごとのリポジトリにアクセスして差分更新を受信することができます。またすべては料金に含まれています。

AWSのRHUIの場合、パブリックなネットワーク上にRHUIサーバーがいるようで、どうしてもインターネットアクセスが必要になります。VPCに閉じることに拘らない場合は、NATGWをつけてしまえば良いですが、要件的にそれが難しい場合取りうる手段としては以下の2つが考えられると思います。

  • VPCの外に簡単に出れない環境でのRHUIアクセス方法
    1. ForwardProxy(URLフィルタで制限)を利用する
    2. RHUIのyumリポジトリのコピーをVPC内に設ける

ただ「yumリポジトリのコピーをVPC内に設ける」案は、(1)RHUIからのリポジトリコピーをどうやるかという技術的課題と、(2)コピーしたyumリポジトリ上のrpmパッケージのredhatライセンス上の解釈が判断つかない、という理由から今回は「RHUIのyumリポジトリのコピーをVPC内に設ける」方法を取っています。
具体的には、public subnetにproxyを構成して、RHELのyum設定(/etc/yum.conf)にプロキシ設定を追加しています。

Forward Proxy設定

フィルタリング対象URL

公式な情報はなさそうで、私が実機を確認した範囲の情報ですがRHELインスタンスの/etc/yum.repos.d/rhui-load-balancers.confを見ると、以下のURLにアクセスしているように見えます。

  • rhui2-cds01..aws.ce.redhat.com
  • rhui2-cds02..aws.ce.redhat.com

[2020.9.20追記]
詳細わかりませんが、最近動かしたらRHUIのURLが以下に変更されてたので追記します。(URLから推測するに、RHUI2からRHUI3にアップデートしたんですかね)

  • rhui3.REGION.aws.ce.redhat.com
Forward Proxy設定

今回は手っ取り早く、squidを利用しています。

  • (1) squidのrpmのインストール
sudo yum -y install squid
  • (2) squid設定
    • /etc/squid/squid.conf
# define ip address
acl localnet src 127.0.0.0/8
acl localnet src ::1/128

acl SSL_ports port 443
acl Safe_ports port 443		# https
acl CONNECT method CONNECT

# Deny CONNECT to other than secure SSL ports
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# from where browsing should be allowed
http_access allow localnet

# include url white list
acl whitelist dstdomain "/etc/squid/whitelist"
http_access allow whitelist

# And finally deny all other access to this proxy
http_access deny all
#------------------------------------------
http_port 0.0.0.0:3128

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# anonymouse host name 
visible_hostname unknown

# change log format
logformat squid %tl %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt
    • /etc/squid/whitelist(東京リージョンの場合*1 )
#For RHUI2
rhui2-cds01.ap-northeast-1.aws.ce.redhat.com
rhui2-cds02.ap-northeast-1.aws.ce.redhat.com

#For RHUI3( Added on Sep. 20, 2020)
rhui3.ap-northeast-1.aws.ce.redhat.com
  • (3) squidの再起動
sudo systemctl restart squid
RHELのyumへのProxy設定
  • /etc/yum.conf (下記の設定を追記します。3128の部分は、squid.confのhttp_portの設定に従います)
proxy=http://<forward proxyのFQDNまたはIP>:3128

インスタンスのユーザデータや、CloudFormationのcnf-initヘルパーなどでこの設定を追加するようにしておくと便利だと思います。

*1:他リージョンは、ap-northeast-1を置き換えます

AWS 特定のAMIの各リージョンのImageID一覧を取得するシェル

1.概要

特定の種類のAMIについて、各リージョンのImageIDを取得し、CSV形式で出力するシェルスクリプトです。
例えば、SQL Server Web Editionが含まれているLicense-includeなwindowsインスタンスの各リージョンのImageIDを知りたいとかいうときに利用します。
作成したCSVフィルをExcelとかで開くとこんな感じで情報を確認できます。
f:id:nopipi:20180819201357p:plain:w800

2.使い方

2.1 前提

このツールは下記のコマンドが使えることが前提となります。

  • aws cli
  • シェル環境(bash, awk)
  • gitコマンド(セットアップに利用。なくてもなんとかはなる)

手元の環境ですが、Linux環境とMacOS環境で動くことは確認しています。

2.2 ソースコードの取得とセットアップ

ソースコードはこちらのgithubになります。
github.com

  • (1) GitHubからコードをcloneする
$ git clone https://github.com/Noppy/aws_list_amis.git
  • (2) 必要に応じて適切なフォルダにシェルをコピーする
$ cp aws_list_amis/list_amis.sh DEST_DIRECTORY_PATH

2.3 実行

  • (1)マネジメントコンソールなどで、取得したいAMIの名前を確認する
    • (a)「EC2」サービスに移動
    • (b)「インスタンスの作成」を押し、「コミュニティーAMI」を選択する
    • (c)検索などを利用し目的のAMIを見つけて、名前をコピーする

f:id:nopipi:20180819202725p:plain:w800

  • (2)シェルを実行する

取得したAMIの名前を引数にしてシェルを実行する。結果は標準出力に出力されるので、必要に応じてファイルにリダイレクトする。

./list_amis.sh "Windows_Server-2012-R2_RTM-English-64Bit-SQL_2016_SP1_Web-2018.07.11" > Win_SQL_WebEdition.csv

AWS リージョンのコードと名称の一覧を取得する

結論

例えば「”Asia Pacific (Tokyo)", "ap-northeast-1"」という感じに、リージョン名称とリージョンコードの一覧を取得するのは、下記のAWSのEC2ユーザーズガイドの"Regions and Availability Zones"のリージョン一覧表から取得するのが良さそう。(結局手作業ですが)
docs.aws.amazon.com

(補足)aws cliでのリージョン一覧取得

aws cliで、"aws ec2 describe-regions"でもリージョン一覧が取得できますが、リージョンコード(ap-northeast-1とか)と、EC2のエンドポイント (ec2.ap-south-1.amazonaws.comとか)しか取得できず、ap-northeast-1が”Asia Pacific (Tokyo)"というのは自動では取れないんですね。

aws cli取得例1 アジアのリージョンを取得する

aws ec2 describe-regions  --output json --filters 'Name=region-name, Values=ap-*'
{
    "Regions": [
        {
            "Endpoint": "ec2.ap-south-1.amazonaws.com", 
            "RegionName": "ap-south-1"
        }, 
        {
            "Endpoint": "ec2.ap-northeast-2.amazonaws.com", 
            "RegionName": "ap-northeast-2"
        }, 
        {
            "Endpoint": "ec2.ap-northeast-1.amazonaws.com", 
            "RegionName": "ap-northeast-1"
        }, 
        {
            "Endpoint": "ec2.ap-southeast-1.amazonaws.com", 
            "RegionName": "ap-southeast-1"
        }, 
        {
            "Endpoint": "ec2.ap-southeast-2.amazonaws.com", 
            "RegionName": "ap-southeast-2"
        }
    ]
}

取得例2 リージョンコード一覧を抜き出す

aws ec2 describe-regions --output text --query 'Regions[].{Name:RegionName}'
ap-south-1
eu-west-3
eu-west-2
eu-west-1
ap-northeast-2
ap-northeast-1
sa-east-1
ca-central-1
ap-southeast-1
ap-southeast-2
eu-central-1
us-east-1
us-east-2
us-west-1
us-west-2

取得例3 シェルで、抜き出したリージョンコード一覧をREGIONSという配列にセットする

declare -a REGIONS=( $(aws --output text ec2 describe-regions --query 'Regions[].{Name:RegionName}'|sort) )

取得したREGIONS配列を利用する例

for i in ${REGIONS[@]}; do echo "region code = $i";done
region code = ap-northeast-1
region code = ap-northeast-2
region code = ap-south-1
region code = ap-southeast-1
region code = ap-southeast-2
region code = ca-central-1
region code = eu-central-1
region code = eu-west-1
region code = eu-west-2
region code = eu-west-3
region code = sa-east-1
region code = us-east-1
region code = us-east-2
region code = us-west-1
region code = us-west-2