はじめに
検証で自己署名証明書(オレオレ証明書)でない証明書が必要だったのですが、お金がかけられなかったのでお名前.comで安いドメインを取得し、Let's Encryptで無料証明書を取得してAWS上で検証をしました。この記事はその時の手順をまとめたものです。
関連記事
- 全体概要(この記事)
- ドメイン取得とRoute53との連携
- Let's Encryptで無料の証明書を取得する
検証で自己署名証明書(オレオレ証明書)でない証明書が必要だったのですが、お金がかけられなかったのでお名前.comで安いドメインを取得し、Let's Encryptで無料証明書を取得してAWS上で検証をしました。この記事はその時の手順をまとめたものです。
この記事では、Let's Encryptから無料のサーバ証明書(ワイルドカード証明書)を取得し、(複数の)apacheサーバに証明書を組み込む手順を説明してます。
Amazon Linux2でLet's EncryptをググるとCertbotを改造するケースが多いですが、この手順では引数を工夫することで改造なしを実現してます。
Let's Encryptの証明書の有効期限は90日で、この記事の手順では更新毎に利用している全apacheサーバに証明書を再配布しなければならないので、PoCや検証などで一時的に正規の証明書が必要なケースを想定した手順になります。
なお、この手順の前提として証明書用のドメインを取得している必要があります。
Let's Encrypt は、「SSL/TLSサーバ証明書」を無料で発行してくれる認証局(CA)で、以下の特徴があります。
非営利団体の ISRG (Internet Security Research Group) が運営しており、シスコ(Cisco Systems)、Akamai、電子フロンティア財団(Electronic Frontier Foundation)、モジラ財団(Mozilla Foundation)などの大手企業・団体が、ISRG のスポンサーとして Let's Encrypt を支援しています。
詳しくは公式サイトを参照してください。
letsencrypt.org
Certbotが稼働可能なLinux、MacOS、Unixを準備してください。Certbotが稼働可能な環境は、Certbotの公式ページを確認してください。
今回は、CertbotではサポートされていないですがAmazon Linux 2上でCertbotを動かします。
Certbotのセットアップは、こちらのCertbotの公式ページに説明があります。
ただAmazonLinux2はこの手順ではできませんので、以下ではAmazonLinux2で動作するように手順をカスタマイズしています。
(a)前提パッケージのインストール
pythonのvirtualenvというツールを内部で利用しているようなのでそれをインストールします。
sudo yum -y install python-virtualenv
(b)Certbotのインストール
今回は、/usr/local/binにインストールします。
$ sudo wget --directory-prefix=/usr/local/bin https://dl.eff.org/certbot-auto $ sudo chmod a+x /usr/local/bin/certbot-auto
(c)Certbotのインストレーション実行
$ sudo /usr/local/bin/certbot-auto --no-bootstrap --install-only Upgrading certbot-auto 0.29.1 to 0.30.0... Replacing certbot-auto... Creating virtual environment... Installing Python packages... Installation succeeded. Certbot is installed.
準備が整ったらサーバ証明書を取得します。Certbotはengixやapacheなど証明書を利用したいwebソフトと連携させることができますが、今回は複数のサーバに配布するためマニュアルモードで証明書を取得します。
(a)Certbotの実行
証明書取得のためコマンドを実行します。モードはマニュアルで、ドメイン使用権の認証方法としてDNSを利用(DNS サーバのTXT レコードに指定されたキーを設定)しています。*3コマンドの詳細は、"certbot-auto --help all"で参照できます。
$ sudo /usr/local/bin/certbot-auto --no-bootstrap certonly \ --manual \ --manual-public-ip-logging-ok \ --domains '*.poc.nopipi.work' \ --email admin@poc.nopipi.work \ --agree-tos;
(b)DNSレコードの登録
上記(a)を実行すると、下記のようにpoc.nopipi.workのドメインに、_acme-challengeという名前のTXTレコードで、"nmdZ・・・"という値を設定するよう指定がありますので、指示に従ってDNSサーバにTXTレコードを登録します。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please deploy a DNS TXT record under the name _acme-challenge.poc.nopipi.work with the following value: nmdZGYXDo6J0DVtfKMCHwhCaXdjtl0eJuYGN4J0XMQk Before continuing, verify the record is deployed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
今回poc.nopipi.workはRoute53を利用しているので、Route53でレコード登録します。
$ dig TXT _acme-challenge.poc.nopipi.work ; <<>> DiG 9.8.3-P1 <<>> TXT _acme-challenge.poc.nopipi.work ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19405 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3 ;; QUESTION SECTION: ;_acme-challenge.poc.nopipi.work. IN TXT ;; ANSWER SECTION: _acme-challenge.poc.nopipi.work. 60 IN TXT "nmdZGYXDo6J0DVtfKMCHwhCaXdjtl0eJuYGN4J0XMQk" <以下略>
(c)作成された証明書の確認
"/etc/letsencrypt/live/ドメイン名" のディレクトリ配下にファイルが作成されますので、確認してください。
sudo ls /etc/letsencrypt/live/poc.nopipi.work cert.pem chain.pem fullchain.pem privkey.pem README
ファイル名 | 項目 |
---|---|
cert.pem | サーバ証明書 |
privkey.pem | 秘密鍵 |
chain.pem | 中間証明書 |
fullchain.pem | 証明書と中間証明書を連結したファイル |
作成した証明書を、apacheをセットアップしているインスタンス内にコピーします。
この手順では、他インスタンスへ証明書をコピーする時作成時と同じディレクトリにデプロイされるものと仮定します。
sslの設定ファイル.ssl.confに取得したサーバ証明書関連のファイルを展示します。
<VirtualHost _default_:443> 中略 SSLCertificateFile /etc/letsencrypt/live/poc.nopipi.work/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/poc.nopipi.work/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/poc.nopipi.work/chain.pem SSLCACertificateFile /etc/letsencrypt/live/poc.nopipi.work/fullchain.pem 中略 </VirtualHost>
この記事を書いた後に気づきましたが、AWSのEC2のユーザガイドにも利用手順ありましたね。
docs.aws.amazon.com
*1:公式:Getting Started - Let's Encrypt - Free SSL/TLS Certificates、非公式解説:Let's Encrypt の使い方 - Let's Encrypt 総合ポータル
*2:公式:ACME v2 Production Environment & Wildcards - API Announcements - Let's Encrypt Community Support、非公式解説:よくある質問 - Let's Encrypt 総合ポータル
*3:この記事などを参考にしています。Let's Encryptでワイルドカード証明書発行してみた · D
この記事では「お名前.com」で取得したドメインに任意のサブドメインを作成し、そのサブドメインの管理をAmazon Route53に委任する手順を説明しています。
お名前.comで取得したドメイン:nopipi.work
Route53に委任するサブドメイン名:poc.nopipi.work
お名前.comでのドメイン取得手順は、いろいろなサイトが説明記事を書いているのでこことでは細かい説明はしません。googleで「お名前 ドメイン 取得手順」で検索すると色々情報が出ますので基本そちらを参照してください。
また、お名前.comでドメイン取得する場合の留意事項を以下に列挙します。
Route 53のPublic Hosted Zoneで控えたNSレコードを、お名前.comにて、取得ドメインのDNSサーバとして登録します。
お名前.comで取得したドメインをAWS上で利用する方法はいくつかあります。3つの例を下に示します。
管理 主体 | 方法 | メリット | デメリット |
---|---|---|---|
お名前.com | お名前.comのレコードへAWSのFQDNをCNAME登録する |
| |
AWS | Amazon Route53にドメインを移管する |
| 下記制約があって移管面倒 |
サブドメインをRoute53に委任 | サブドメインしか管理できない |
*1:参考:お名前.comのドメインをAWSで使用する4つの方法 - Qiita
*2:Public Hosted Zoneは外部からドメイン情報が参照される。Private Hosted Zoneは、関連づけられたVPCにのみ情報が参照できる
起動しなくて困ったので、そんな時の対処方法をメモしておきます。
Macのハードウェアを管理するSMC(System Management Controller)をリセットする。SMCはバッテリー、熱管理、各種センサー管理をしているユニット。
support.apple.com
NVRAM には、音量、画面解像度、選択されている起動ディスク、時間帯、最近起きたカーネルパニックの情報などが保存されています。この情報をリセットします。
support.apple.com
上記でダメなら、セーフモードで原因切り分け。切り分けできなかったらサポートへ。
support.apple.com
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サポートされていないため、その点は留意下さい。
RHEL7.1をm4インスタンスで起動してenaをインストールします。
(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.
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)
マニュアル*1の内容に従いgitからコードをダウンロードします。
$ git clone https://github.com/amzn/amzn-drivers
$ cd amzn-drivers/kernel/linux/ena $ make
$ sudo insmod ena.ko $ lsmod |grep ena ena 98319 0 <==ドライバが組み込まれていることを確認 $ sudo rmmod ena $ lsmod |grep ena
(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
$ 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
最近のsystemdやudevでのデバイス命名は、enp5s0のような一貫性のある命名をします*2。RHELの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
インスタンスが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で状態を確認します。
[ 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がロードされ初期化されているのがわかります。
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]
$ 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パッケージの中身に差異があるのかどうかという話があったので、2つのファイルのdiffをとって確かめてみた。
→結果、差異はなかった。
(1)redhatのカスタマーポータルからISOを落とす
ここから、下記のisoをダウンロード
(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パッケージファイルの中身には差分なし
RHELで、yumレポジトリに接続できない環境のRHELを、最新版でない特定バージョンのカーネルにあげたいという話があり検証した結果です。
インターネット接続が可能なVPCのパブリックサブネット状に、コミュニティAMI(RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2 )からインスタンスを作成する。
(a) アップデートしたいカーネルバージョンがRHUIにあるかを確認
sudo yum --showduplicate list kernel
(b) 該当バージョンのパッケージ名称の確認
sudo yum list kernel-3.10.0-862.14.4.el7
sudo yumdownloader --resolve kernel-3.10.0-862.14.4.el7
アップデート対象インスタンスログイン後に、
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
tar xzf update_packages.tar.gz cd update_packages
sudo rpm -U *.rpm
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
今日Re:Inventで発表されたA1インスタンスのcpuinfoとかを見てみますた。
こちらのインスタンスの特徴は、AWS Graviton ProcessorsというAWS謹製のARMプロセッサを利用し、低消費電力
[ 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”てことがわかりますね。当たり前ですが。
[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がサーバに入っていると考えると、オッ!!と思いますよね。
awsコマンドでECRにログインするためのdockerの認証情報を取得してログインします。
$(aws ecr get-login --no-include-email)
実行すると認証用のdockerコマンドの文字列(docker login ....)が出力されるので、それをシェルのコマンド置換"$(...)"を利用してそのまま実行してdockerログインします。
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" } }
(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]"コマンドで削除します。
(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 } ] }
(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のクロスリージョンレプリケーション構成を組んだディザスターリカバリーを検討しているのですが、DR計画のRPOの話の延長でレプリケーションの遅延時間てどれぐらいなんだろうねぇ〜という話があって、そんなにかからないだろうなという感覚はありつつ、確認したことがなかったので試しに測定してみました。
VPCに作成したインスタンスから検証用のファイルをS3バケットにPUTします。クロスリージョンレプリケーションの転送処理は、オブジェクトのレプリケーション状態をチェックしてPENDIG状態になっていた時間を測定し、その時間をレプリケーションの転送時間と皆しています。
下記のドキュメントなどを参考にS3バケット作成&バージョニング有効化と、クロスリージョンレプリケーションの設定をします。下記の手順ではIAMロールを手動作成するようになっていますが、マネージメントコンソールで設定する場合、IAMロース選択で「Create new role」を選ぶと必要なIAMロールを自動作成してくれます。
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 ..
下記のスクリプトを "a"フォルダに格納し、実行権限を付与(chmod +x *.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
#!/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
#!/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
測定します。2〜3時間がかかるので寝かせておきます。
nohup ./test.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
#!/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のヘルパーのコマンド実行文字列にクロススタックリファレンスの値を埋め込む方法 - のぴぴのメモの記事の応用です。
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
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}/"
openssl x509 -text -noout -in ${URLNAME}.crt
自分用のメモです。
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"
完成するとこんな感じのコマンド実行用の文字列になる
AWS SDK for Python (Boto3)の練習用に、各リージョンのデフォルトVPCをまとめて削除するpythonツールを作りました。
github.com
git clone https://github.com/Noppy/delete_default_vpc.git
cd delete_default_vpc ./delete_default_vpc.py -a 'AWS_ACCESS_KEY_ID' -s 'AWS_SECRET_KEY_ID'
boto3の全体像が理解できなく、結構苦労し
vimを利用する時の設定と操作時のメモです。
" 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>
多分こちらのページの内容をベースに多少カスタマイズしたものです。