お名前.comでのドメイン取得とRoute 53との連携(お名前.comへのRoute 53DNS登録)
概要
やりたいこと
この記事では「お名前.com」で取得したドメインに任意のサブドメインを作成し、そのサブドメインの管理をAmazon Route53に委任する手順を説明しています。
お名前.comで取得したドメイン:nopipi.work
Route53に委任するサブドメイン名:poc.nopipi.work
関連記事
- 全体概要
- ドメイン取得とRoute53との連携(この記事)
- Let's Encryptで無料の証明書を取得する
大まかな手順
手順
(1) お名前.comでのドメイン取得
お名前.comでのドメイン取得手順は、いろいろなサイトが説明記事を書いているのでこことでは細かい説明はしません。googleで「お名前 ドメイン 取得手順」で検索すると色々情報が出ますので基本そちらを参照してください。
また、お名前.comでドメイン取得する場合の留意事項を以下に列挙します。
(2) Amazon Route 53で取得したドメイン名のPublic Hosted Zoneを登録する*1
- AWS マネージメントコンソールにログインしてRoute 53サービスに移動する
- 初めてRoute53を利用する場合はDNS managementを選択、すでに利用がある場合は"Hosted zones"を選択する
- "Create Hosted"で、お名前.comで取得したドメイン(今回は、poc.nopipi.work)のパブリックホステットゾーンを作成する
- 作成したPublic Hosted ZoneのNSレコード(DNSサーバ情報)を控える
(3) お名前.comへのroute53 DNSサーバ情報登録
Route 53のPublic Hosted Zoneで控えたNSレコードを、お名前.comにて、取得ドメインのDNSサーバとして登録します。
- Route53で控えた4つのNSレコードを下図のように登録する
(4)確認
(参考)Route53との連携方法
お名前.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が起動しない時の対処方法
起動しなくて困ったので、そんな時の対処方法をメモしておきます。
対処方法
(1) SMCのリセット
Macのハードウェアを管理するSMC(System Management Controller)をリセットする。SMCはバッテリー、熱管理、各種センサー管理をしているユニット。
support.apple.com
(2) NVRAM または PRAM をリセット
NVRAM には、音量、画面解像度、選択されている起動ディスク、時間帯、最近起きたカーネルパニックの情報などが保存されています。この情報をリセットします。
support.apple.com
(3) セーフモードを使って Mac の問題を切り分け
上記でダメなら、セーフモードで原因切り分け。切り分けできなかったらサポートへ。
support.apple.com
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サポートされていないため、その点は留意下さい。
確認環境
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のような一貫性のある命名をします*2。RHELのAMIから起動した場合は従来のeth0のようなデバイス名称を継続利用するために、このデバイス命名の一貫性の機能を無効化します。
(a) Grubのテンプレートファイルに設定を追加
起動オプションに、"net.ifnames=0"を追加します。
- /etc/default/grub
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をとって確かめてみた。
→結果、差異はなかった。
確認方法
確認手順詳細
(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パッケージファイルの中身には差分なし
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
2.手順
2.1 代替えインスタンでのrpmパッケージダウンロード
(1)作業用インスタンスとして、RHEL7.2のインスタンスを作成する
インターネット接続が可能なVPCのパブリックサブネット状に、コミュニティAMI(RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2 )からインスタンスを作成する。
(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”が、依存関係をチェックして必要なパッケージをまとめてダウンロードするオプションです。
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の話の延長でレプリケーションの遅延時間てどれぐらいなんだろうねぇ〜という話があって、そんなにかからないだろうなという感覚はありつつ、確認したことがなかったので試しに測定してみました。
検証結果
検証手順
VPCに作成したインスタンスから検証用のファイルをS3バケットにPUTします。クロスリージョンレプリケーションの転送処理は、オブジェクトのレプリケーション状態をチェックしてPENDIG状態になっていた時間を測定し、その時間をレプリケーションの転送時間と皆しています。
(1)S3クロスリージョンレプリケーションの設定
下記のドキュメントなどを参考にS3バケット作成&バージョニング有効化と、クロスリージョンレプリケーションの設定をします。下記の手順ではIAMロールを手動作成するようになっていますが、マネージメントコンソールで設定する場合、IAMロース選択で「Create new role」を選ぶと必要なIAMロールを自動作成してくれます。
(2)インスタンスの準備
(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
(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}/": 証明書作成時に対話で聞かれる内容を指定する
openssl x509のオプション
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
利用方法
- (1) boto3をインストールする
- インストールは下記ドキュメントを参照
- Quickstart — Boto 3 Docs 1.9.9 documentation
- (2) スクリプトをcloneする
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の全体像が理解できなく、結構苦労し
- botoのバージョン: botoが古いver2、boto3が2015年にGAされたver3
- 低レベル実装と、高レベル実装
- 明示的にセッションを取得する場合は、"boto3.session.Session"を利用する。
- わからなかったらBoto 3 Documentation — Boto 3 Docs 1.9.9 documentation公式ドキュメントのここを見る
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
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 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アクセス方法
- ForwardProxy(URLフィルタで制限)を利用する
- 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を置き換えます