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

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

はじめに

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

確認してみた

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

TaskDefinition-640x411.png

タスク起動後は、タスクネットワークに構成された 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 については、下記の公式ドキュメントをご参照ください。

さいごに

タスクを稼働させる環境(ECS インスタンス?)の情報を確認してきましたが、そんな事は気にせずにコンテナを起動させるだけ(インフラ側の管理は AWS 側が行う)というのが AWS Fargate の素晴らしいところですよね。 月並みではありますが、東京リージョンで利用出来る日が待ち遠しいです。

ではでは