AWS Fargate の環境をコンテナ内部から確認してみた #reinvent

AWS re:Invent 2017

#AWS Fargate

#AWS

下田祐士

2017.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

sshd を Fargate で起動すれば、コンテナ内部から環境に関する情報が少しでも確認できるのでは？という淡い期待のもと本記事で検証してみました。SSH サービスのコンテナ化については Docker 公式ドキュメントを参考に作業を実施しております。

Dockerize an SSH service | Docker Documentation

確認してみた

sshd-task というタスク定義を作成し、Launch type FARGATE で sshd-service を起動しました。

タスク起動後は、タスクネットワークに構成された ENI のパブリックIP に向けて ssh ログインを行います。 uname,lscpu,free,ip コマンドの実行結果をご覧ください。

root@eddf908af5f7:~# uname -a
Linux eddf908af5f7 4.9.62-21.56.amzn1.x86_64 #1 SMP Thu Nov 16 05:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root@eddf908af5f7:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
Stepping: 1
CPU MHz: 2702.191
CPU max MHz: 3000.0000
CPU min MHz: 1200.0000
BogoMIPS: 4600.10
Hypervisor vendor: Xen
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 46080K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology aperfmperf eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx xsaveopt

root@eddf908af5f7:~# free -m
total used free shared buff/cache available
Mem: 3953 111 3617 0 224 3614
Swap: 0 0 0
root@eddf908af5f7:~# apt install iproute2
:
root@eddf908af5f7:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: ecs-eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 0a:58:a9:fe:ac:2a brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 169.254.172.42/22 scope global ecs-eth0
valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 02:84:14:44:98:a8 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.150/24 scope global eth1
valid_lft forever preferred_lft forever

上記のログを確認した所感は、以下のとおりです。

起動した ECS タスクを起動する環境（ECS インスタンス？）には、2 vCPU と 4GB 近いメモリが構成されている
Linux カーネルのバージョン情報から推測すると Amazon ECS 最適化 AMI の最新バージョン（※）が利用されている気がする
タスクネットワークに構成された ENI(eth1)とは別の仮想インターフェース（ecs-eth0@if6）が確認できる
＃多分、グローバルネームスペースに作成されている ecs の Linux bridge と Veth Pair 接続されている片側のインターフェースではないかと推測

※ 2017/12/4 現在の最新バージョンは、us-east-1 の amzn-ami-2017.09.d-amazon-ecs-optimized （ami-fad25980）

Amazon ECS 対応 AMI については、下記の公式ドキュメントをご参照ください。