新卒1年目のSREがコンテナをデプロイできるようになるまでの道のり [JAWS DAYS 2019]

気づいたらコンテナ環境を運用することになっていた新人SREの原田くんが、Dockerでコンテナイメージをビルドするところから始まり、AWS上で実際にコンテナを動かせるようになるまでの道のりを紹介します。そもそもなぜコンテナなのか？動かしたあとのCICDをどうするかなども取り上げます。またEKSやKubernetesの概念についても合わせて解説します。

補足や当日の様子など書いた登壇レポート記事はこちら ↓
https://medium.com/eureka-engineering/deploy-docker-kubernetes-newgrad-sre-journey-1fb3f017eed7

Transcript

1. Daichi Harada & Jun Sakata
   JAWS DAYS 2019
   2019. 02 . 23
   新卒1年目のSREが
   コンテナをデプロイできるよう
   になるまでの道のり
   

   View Slide

2. はじめに
   

   View Slide

3. Docker やろうぜ
   お、おす
   

   View Slide

4. 急にどうしたんだろう
   

   View Slide

5. すべてはここから始まった
   

   View Slide

6. Daichi Haradaのクジラ漁
   

   View Slide

7. Daichi Haradaのクジラ漁
   

   View Slide

8. Daichi Haradaのコンテナとの戦い
   

   View Slide

9. この話は実話をもとにした
   フィクションです
   

   View Slide

10. 分量が多く怒涛の勢いで話が進みます
    が、スライドは後ほど公開予定なので、
    合わせてご確認ください。
    

    View Slide

11. 50分もあったので調子に乗りました
    

    View Slide

12. About Speakers
    Daichi Harada, eureka Jun Sakata, ex-eureka
    

    View Slide

13. DAICHI HARADA
    - @kai_ten_sushi / @dharada1
    - SRE at eureka, Inc.
    -
    北海道から遥々上京
    -
    気づいたら
    SRE
    に配属されてしまった！
    -
    インフラ経験ゼロからのスタート
    - Like
    - #CloudFront
    - #CostExplorer
    

    View Slide

14. JUN SAKATA
    - @sakajunquality
    -
    別のクラウドのエキスパート
    - SRE at Ubie Inc.
    - Former SRE at eureka Inc.
    - Like
    - #CodeBuild
    - #Aurora
    

    View Slide

15. Agenda
    - Part 1
    - Docker
    - Kubernetes
    - Part 2
    - Container Services on AWS
    - ECR / ECS / EKS / Fargate
    - EKS
    を使ってみた
    - Part 3
    - CI/CD
    

    View Slide

16. Part 1
    Docker and Kubernetes
    

    View Slide

17. Docker
    

    View Slide

18. Dockerってしってる？
    ローカルの開発で使ってる、
    docker-composeとかいうやつですか？
    (しらんけど・・・)
    ggrks
    

    View Slide

19. Docker
    

    View Slide

20. Dockerとは
    -
    コンテナ型の仮想環境を作成、配
    布、実行するためのプラットフォーム
    -
    ミドルウェアのインストールや各種環
    境設定をコード化して管理し、
    Docker
    イメージを作成
    - Docker
    さえある環境なら、どこでも同
    じイメージを動作させることができる
    

    View Slide

21. Build Ship Run
    

    View Slide

22. とりあえず触ってみよう
    なるほど、わからん！
    

    View Slide

23. よくあるWebアプリケーションを考えてみよ
    う
    

    View Slide

24. こんな感じのコードですね
    // main.go
    package main
    import (
    "fmt"
    "net/http"
    )
    func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World")
    }
    func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8888", nil)
    }
    

    View Slide

25. 8888でhttpリッスンして
    // main.go
    package main
    import (
    "fmt"
    "net/http"
    )
    func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World")
    }
    func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8888", nil)
    }
    

    View Slide

26. “Hello, World” と表示する
    // main.go
    package main
    import (
    "fmt"
    "net/http"
    )
    func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World")
    }
    func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8888", nil)
    }
    

    View Slide

27. まずは普通に動かしてみよう
    Docker使わなくていいんですね
    

    View Slide

28. (ふつうに go run してみる)
    $ go run main.go
    

    View Slide

29. (ログぐらい出せばよかったな・・・)
    $ go run main.go
    

    View Slide

30. (別のターミナルで curl と...)
    $ curl localhost:8888
    

    View Slide

31. うごいた！
    $ curl localhost:8888
    > Hello, World!
    

    View Slide

32. じゃあこれを Docker によう
    ふむ
    

    View Slide

33. ・・・
    

    View Slide

34. Dockerfile が必要らしい
    

    View Slide

35. // Dockerfile
    FROM golang:1.11
    WORKDIR /go/src/app
    COPY . .
    CMD ["go", “run”, “main.go”]
    こんな感じですか？
    

    View Slide

36. これでも動くんだけど、
    Go って動かすときちゃんとビルドしてるよ
    ね？
    たしかに
    

    View Slide

37. // Dockerfile
    FROM golang:1.11
    WORKDIR /go/src/app
    COPY . .
    RUN go get -d -v ./...
    RUN go install -v ./...
    CMD ["app"]
    どや
    

    View Slide

38. うごかしてみよう
    ほい
    

    View Slide

39. イメージをビルドする
    $ docker image build -t my-app .
    

    View Slide

40. ビルドしたのを動かす
    $ docker container run -p 8888:8888 my-app
    

    View Slide

41. $ curl localhost:8888
    > Hello, World!
    curl してみる
    

    View Slide

42. マルチステージビルドを使うとよいよ
    // Dockerfile
    FROM golang:1.11-alpine
    WORKDIR /go/src/app
    COPY . .
    RUN go get -d -v ./...
    RUN go install -v ./...
    FROM alpine
    COPY --from=0 /go/src/app /usr/local/bin/app
    RUN apk --no-cache add ca-certificates
    CMD ["app"]
    

    View Slide

43. イメージのサイズを比べてみよう
    $ docker images | grep my-app
    my-app latest 9ba39c3836a9 38 minutes ago 801MB
    my-app-alpine latest 3880eef6c224 5 minutes ago 401MB
    my-app-multistage latest ce94afe10faf 1 second ago 11.6MB
    

    View Slide

44. あとこのままだとrootユーザーで動いちゃ
    うので、ユーザーも指定したほうがベター
    たしかに
    

    View Slide

45. (一旦まとめよう・・・)
    

    View Slide

46. Dockerイメージとは・・・
    -
    コンテナを作成するファイルシステムや設
    定をまとめたもの
    -
    親のイメージから層のように重なっていく
    https://nvisium.com/blog/2014/10/15/docker-cache-friend-or-foe.html
    

    View Slide

47. Dockerfileとは・・・
    - Docker
    イメージの構成内容を記したもの
    -
    専用の
    DSL
    で記述する
    - FROM
    でベースイメージを指定し
    - RUN
    でビルドなどのコマンドを実行
    

    View Slide

48. Alpineとは・・・
    -
    軽量な
    Linux
    ディストリビューション
    - image
    サイズを小さくできる
    - glibc
    が入っていないので注意
    

    View Slide

49. マルチステージビルドとは・・・
    -
    アプリケーションをビルドするコンテナ
    /
    実行するコンテナ を分離する
    -
    実行するコンテナにはビルドに使うパッケージは入ってなくて
    OK
    - Docker Image
    のサイズを小さくできる
    - Go
    や
    Java
    などビルドしたらバイナリや
    jar
    が出力されるものにはピッタリ
    

    View Slide

50. Dockerレジストリとは・・・
    - DockerHub
    に代表される、
    Docker
    イメージを管理・共有するしくみ
    -
    ソースコードを
    GitHub
    などで管理するのに似てる
    

    View Slide

51. Docker Hubとは・・・
    - Docker
    社が運営する
    Docker
    レジス
    トリ
    - FROM golang:1.11
    や
    FROM alpine
    など書いて
    Pull
    される
    Image
    は
    Docker Hub
    にホストされている
    https://hub.docker.com/
    

    View Slide

52. - official
    マークのものを選ぶと良い
    DockerHubでのイメージの探し方
    

    View Slide

53. -
    クラウド
    - ECR ( AWS )
    - GCR ( Google )
    - ACR ( Azure )
    - ...
    - OSS
    - Harbor
    - ....
    DockerHub以外のレジストリ
    

    View Slide

54. 今回はローカルで動かしただけだから
    使ってないよ。それはまた今度。　
    そういえば、Dockerレジストリは使わない
    んですか？
    

    View Slide

55. コマンド多くないですか？
    docker image
    docker container
    のように何を操作するかを覚えると良いと
    思う
    

    View Slide

56. $ docker image --help
    Usage: docker image COMMAND
    Manage images
    Commands:
    build Build an image from a Dockerfile
    history Show the history of an image
    import Import the contents from a tarball to create a filesystem image
    inspect Display detailed information on one or more images
    load Load an image from a tar archive or STDIN
    ls List images
    prune Remove unused images
    pull Pull an image or a repository from a registry
    push Push an image or a repository to a registry
    ...
    テキトウに--helpすればいいのか
    

    View Slide

57. なんとなくわかりました (多分)
    そういえば、Docker は VM とは何が違うん
    ですか？
    なんだとおもう？
    

    View Slide

58. (質問に質問で答えられても )
    

    View Slide

59. VM vs Container
    

    View Slide

60. VM vs Container
    - VM
    -
    ホスト上でハードウェアが仮想化され、その上
    でゲスト
    OS
    が動作
    -
    必要とする以上のリソースを割り当ててしま
    い、オーバーヘッドが大きい
    - OS
    を立ち上げるため起動時間がかかる
    - Container
    -
    コンテナはホスト
    OS
    のカーネルを利用
    -
    リソースのオーバーヘッドが小さい
    -
    起動が速い
    

    View Slide

61. ざっくりいうと、
    「コンテナの方が軽い」
    ってことですよね？
    だいたいそう
    

    View Slide

62. Build Ship Run
    

    View Slide

63. (テキトウな先輩だな・・・ )
    

    View Slide

64. (そういえば、docker-compose.ymlって何者
    なんだろう・・・)
    

    View Slide

65. docker-compose
    -
    複数のコンテナの立ち上げを
    yaml
    で記述
    -
    ローカル開発環境で主に利用
    -
    ミドルウェアのコンテナを
    docker-compose
    で立ち上げる
    - MySQL
    - Elasticsearch
    - DynamoDB Local
    -
    ローカルの
    go
    アプリケーションから各コン
    テナを利用
    -
    いちいち
    brew install
    とかしなくていいの
    で開発者は楽
    // docker-compose.yml
    services:
    mysql:
    image: mysql:5.7
    environment:
    MYSQL_USER: datch_datch_go
    MYSQL_PASSWORD: fake_password
    ports:
    - "3306:3306"
    volumes:
    - .local/mysql5.7:/var/lib/mysql
    redis:
    image: redis:3.2-alpine
    ports:
    - "6379:6379"
    redis-cluster:
    image: "grokzen/redis-cluster"
    ports:
    - "7000-7007:7000-7007"
    elasticsearch:
    image: evalphobia/elasticsearch:2.4.0
    ports:
    - "9200:9200"
    

    View Slide

66. そうか、Docker のおかげで
    ローカルの開発でも、
    MySQLやDynamoDBが使えてたのか！！
    

    View Slide

67. 今はEC2のインスタンスがたくさんいるけ
    ど、これもコンテナにしたほうがいいんで
    すか？
    つぎにその話をしよう
    

    View Slide

68. Why Docker in Production?
    -
    アプリケーション及び、その依存関係をイメージに固めることができる
    -
    環境依存で動かないことがなくなる
    -
    イメージとして本番出す前にステージングで確認したりできる
    - ( The Twelve-Factor App https://12factor.net/ )
    - VM
    を起動するより軽量なので、起動が速い
    

    View Slide

69. Docker まとめ
    - Docker
    とは
    ?
    -
    コンテナ型の仮想化環境
    - Docker Image
    -
    構成がまとまったもの
    -
    コンテナを作成するファイルシステムや設定をまとめたもの
    - Dockerfile
    を書いて
    build & run
    - Docker Hub
    - Docker
    社が運営するリポジトリ
    -
    公式の
    Docker
    イメージは
    Docker Hub
    で探すとよい
    

    View Slide

70. Docker 完全熟知 (￣＾￣) ﾄﾞﾔｯ !
    

    View Slide

71. Kubernetes
    Google’s Borg
    

    View Slide

72. 今日は Kubernetesを触ってみよう
    最近よくきくあれですね
    (またしらんけど・・・)
    

    View Slide

73. 少し難しいかもしれないので、
    手を動かしながらやっていこう
    ほーい
    この前の Docker の続きから
    

    View Slide

74. CNCF Phippy and Friends
    https://www.cncf.io/phippy/
    を使って話を進めていく
    

    View Slide

75. こんな絵本が・・・
    

    View Slide

76. そもそものアプリケーションがあって・・・
    

    View Slide

77. コンテナとしてイメージに固める
    

    View Slide

78. 本題の Kubernetes
    

    View Slide

79. Kubernetes
    

    View Slide

80. What is Kubernetes
    https://speakerdeck.com/sakajunquality/starting-google-kubernetes-engine-2019
    

    View Slide

81. つまり、コンテナを動かすのに必要な、
    CPU / メモリ / ディスクを管理してくれるや
    つ、ってことなのかな???
    あとはコンテナをどこに配置するかとか、
    イメージのデプロイとか。
    

    View Slide

82. 養殖漁業で考えると・・・
    

    View Slide

83. View Slide

84. View Slide

85. Small Ikesu
    Large Ikesu
    Medium Ikesu
    

    View Slide

86. ...ってことだ！多分
    

    View Slide

87. どんな構造になってるんだろう
    

    View Slide

88. k8s Components (Master Node & Worker Node)
    - Master Node
    - API Server
    - k8s cluster
    のゲートウェイ
    - etcd
    -
    共有設定の保持とディスカバリに
    使う
    KVS
    - controller
    - API Server
    を利用してクラスタの
    状態を監視
    &
    操作する
    - Worker Node
    - docker
    - Pod
    を起動する
    - kubelet
    -
    マスターとの通信
    - kube-proxy
    -
    プロキシ、ロードバランス
    https://x-team.com/blog/introduction-kubernetes-architecture/
    

    View Slide

89. k8s Components (Master Node & Worker Node)
    - Master Node
    - API Server
    - k8s cluster
    のゲートウェイ
    - etcd
    -
    共有設定の保持とディスカバリに
    使う
    KVS
    - controller
    - API Server
    を利用してクラスタの
    状態を監視
    &
    操作する
    - Worker Node
    - docker
    - Pod
    を起動する
    - kubelet
    -
    マスターとの通信
    - kube-proxy
    -
    プロキシ、ロードバランス
    https://x-team.com/blog/introduction-kubernetes-architecture/
    めっちゃムズカシイ
    

    View Slide

90. 一旦内部構造は忘れよう
    

    View Slide

91. とりあえず重要なことは
    コントロールプレーン(マスター)が、リソー
    スの割当などを管理していて、
    データプレーン(ワーカー)に実際のコンテ
    ナが動いてるってことですね！
    

    View Slide

92. ワーカーノードがいけす！
    Ikesu Node
    

    View Slide

93. ワーカーに実際のコンテナがいる
    Ikesu Node
    

    View Slide

94. 次に概念を見てみよう
    

    View Slide

95. 再び
    CNCF Phippy and Friends
    https://www.cncf.io/phippy/
    

    View Slide

96. Kubernetes
    は内部のリソースをラベルで管
    理している
    e.g.
    - name: my-app
    - ver: v1
    そのコンテナをラベルで管理
    

    View Slide

97. ラベルと同時に、名前空間でも管理してい
    る
    e.g.
    - production
    - web
    - datch-area
    Namespaces
    

    View Slide

98. -
    コンテナの集合の単位
    - 1
    つ以上のコンテナを内包する
    e.g.
    - nginx
    - envoy
    - php-fpm
    - fluent-bit
    Pod
    

    View Slide

99. ReplicaSet
    -
    同じ仕様の
    Pod
    の複数集まった
    Set
    が
    ReplicaSet
    

    View Slide

100. Service
     - Pod
     にアクセスするための経路
     

     View Slide

101. - Service
     に外部からアクセスするための
     仕組み
     - e.g.
     - GCE LB
     - ALB
     - annotation
     でクラウドスペシフィックな
     設定を記載
     Ingress
     

     View Slide

102. -
     データの永続化する際に仕様
     - EC2
     に
     EBS
     をアタッチするノリ
     Volumes
     

     View Slide

103. ワケワカラン
     

     View Slide

104. 思ったより覚えること多い
     

     View Slide

105. カエリタイ
     

     View Slide

106. 例のアプリケーションを
     Kubernetes にデプロイしてみよう
     

     View Slide

107. これね
     // main.go
     package main
     import (
     "fmt"
     "net/http"
     )
     func handler(w http.ResponseWriter, r *http.Request) {
     fmt.Fprintf(w, "Hello, World")
     }
     func main() {
     http.HandleFunc("/", handler)
     http.ListenAndServe(":8888", nil)
     }
     

     View Slide

108. $ docker image tag my-app gcr.io/sakajunquality-public/my-app:v1
     $ docker image push gcr.io/sakajunquality-public/my-app:v1
     まずはイメージをレジストリに上げる
     

     View Slide

109. 今こういう状態っすね
     boku-no-macbook
     container
     my-app
     (bin)
     boku-no-cloud
     container
     my-app
     (bin)
     

     View Slide

110. チュートリアル用に Kubernetes 作成
     $ gcloud container clusters create my-cluster
     ...
     $ gcloud container clusters get-credentials my-cluster --zone asia-northeast1-c
     ...
     

     View Slide

111. 空っぽの箱を作成
     boku-no-cloud
     Kubernetes Cluster
     

     View Slide

112. チュートリアル用にname空間作成
     $ kubectl create namespace tutorial
     

     View Slide

113. 空っぽの空間を作成
     boku-no-cloud
     Kubernetes Cluster
     namespace
     

     View Slide

114. // deployment.yaml
     apiVersion: apps/v1
     kind: Deployment
     metadata:
     name: app1
     namespace: tutorial
     labels:
     app: app1
     spec:
     replicas: 3
     selector:
     matchLabels:
     app: app1
     Pod/ReplicaSetを定義
     // 続き
     template:
     metadata:
     labels:
     app: app1
     spec:
     containers:
     - name: app1
     Image: gcr.io/sakajunquality-public/my-app:v1
     ports:
     - containerPort
     : 8888
     protocol: TCP
     

     View Slide

115. // deployment.yaml
     apiVersion: apps/v1
     kind: Deployment
     metadata:
     name: app1
     namespace: tutorial
     labels:
     app: app1
     spec:
     replicas: 3
     selector:
     matchLabels:
     app: app1
     apps/v1のDeploymentでまとめて定義
     // 続き
     template:
     metadata:
     labels:
     app: app1
     spec:
     containers:
     - name: app1
     Image: gcr.io/sakajunquality-public/my-app:v1
     ports:
     - containerPort
     : 8888
     protocol: TCP
     

     View Slide

116. // deployment.yaml
     apiVersion: apps/v1
     kind: Deployment
     metadata:
     name: app1
     namespace: tutorial
     labels:
     app: app1
     spec:
     replicas: 3
     selector:
     matchLabels:
     app: app1
     push下イメージを指定
     // 続き
     template:
     metadata:
     labels:
     app: app1
     spec:
     containers:
     - name: app1
     image: gcr.io/sakajunquality-public/my-app:v1
     ports:
     - containerPort
     : 8888
     protocol: TCP
     

     View Slide

117. // deployment.yaml
     apiVersion: apps/v1
     kind: Deployment
     metadata:
     name: app1
     namespace: tutorial
     labels:
     app: app1
     spec:
     replicas: 3
     selector:
     matchLabels:
     app: app1
     replicaの数も指定
     // 続き
     template:
     metadata:
     labels:
     app: app1
     spec:
     containers:
     - name: app1
     Image: gcr.io/sakajunquality-public/my-app:v1
     ports:
     - containerPort
     : 8888
     protocol: TCP
     

     View Slide

118. $ kubectl apply -f deployment.yaml
     デプロイしてみる
     

     View Slide

119. 今こういう状態っすね
     boku-no-cloud
     Kubernetes Cluster
     namespace
     Pods
     container
     my-app
     (bin)
     

     View Slide

120. そう！
     これを外部からアクセスできるようにする
     

     View Slide

121. 次にserviceの作成
     // service.yaml
     apiVersion: v1
     kind: Service
     metadata:
     name: app1-service
     namespace: tutorial
     annotations:
     cloud.google.com/neg
     : '{"ingress": true}'
     spec:
     selector:
     app: app1
     ports:
     - protocol: TCP
     port: 8081
     targetPort: 8888
     

     View Slide

122. selectorでdeploymentのラベルを指定
     // service.yaml
     apiVersion: v1
     kind: Service
     metadata:
     name: app1-service
     namespace: tutorial
     annotations:
     cloud.google.com/neg
     : '{"ingress": true}'
     spec:
     selector:
     app: app1
     ports:
     - protocol: TCP
     port: 8081
     targetPort: 8888
     

     View Slide

123. $ kubectl apply -f service.yaml
     サービスの作成
     

     View Slide

124. 多分こんなかんじ
     boku-no-cloud
     Kubernetes Cluster
     namespace
     Pods
     container
     my-app
     (bin)
     8081:8888
     service
     

     View Slide

125. // ingress.yaml
     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
     name: my-lb
     namespace: tutorial
     spec:
     rules:
     - http:
     paths:
     - path: /
     backend:
     serviceName: app1-service
     servicePort: 8081
     ingressでロードバランサーを定義
     

     View Slide

126. $ kubectl apply -f ingress.yaml
     ingressを作成
     

     View Slide

127. $ kubectl -n tutorial get ingress
     NAME HOSTS ADDRESS PORTS AGE
     my-app * aa.bb.xxx.yyy 80 3m
     ロードバランサーのIPを確認
     

     View Slide

128. 多分こんなかんじ
     boku-no-cloud
     Kubernetes Cluster
     namespace
     Pods
     container
     my-app
     (bin)
     8081:8888
     service
     80/443:8081
     ingress
     

     View Slide

129. $ curl aa.bb.xxx.yyy
     > Hello, World!
     curl してみる
     

     View Slide

130. おー
     いんたーねっつに公開された！！！
     

     View Slide

131. Docker熟知した気持ちになってたけど、ど
     こで動かすかも考える必要があったの
     か！
     

     View Slide

132. なるほど
     環境変数はどうやって扱うんですか？
     configMapやsecretというリソースがあるよ。
     今回の場合、my-appがどのポートでリッス
     ンするか環境変数で指定できても良かっ
     たかもね
     

     View Slide

133. container == pod?
     

     View Slide

134. NO
     さっきの
     pod
     Pod
     container
     More practical pod
     Pod
     container
     my-app
     my-app
     container
     nginx
     container
     logger
     

     View Slide

135. 理解！
     

     View Slide

136. ところで何で急に教育熱心になったんで
     すか？
     恩田さん（上司）に怒られました？
     

     View Slide

137. 実は会社やめるんや・・・
     えええええええええ
     (テックリードの座はいただいた)
     

     View Slide

138. （冷静に、こんなに技術先行なのは、
     引き継ぎってことか・・・）
     

     View Slide

139. 困ったらこの本に答えがある
     https://www.amazon.co.jp/dp/B07HFS7TDT/
     https://www.amazon.co.jp/dp/B0721JNVGT/
     

     View Slide

140. さらばじゃ
     

     View Slide

141. ・・・
     

     View Slide

142. とりあえず本ポチるか・・・
     

     View Slide

143. ・・・
     

     View Slide

144. Part 2
     Containers on AWS
     

     View Slide

145. いやな先輩消えたし
     これから、やってくぞい！
     

     View Slide

146. う〜ん、パッと見た感じ
     AWS サービス多くてわからない・・・
     

     View Slide

147. とりあえず、
     調べてみよう
     

     View Slide

148. AWS Container
     Services
     

     View Slide

149. AWS Container Services
     - Registry
     - ECR
     - Orchestration
     - ECS
     - EKS
     - Compute
     - Fargate
     - EC2
     - Auto Scaling Group
     - Code*
     - CodeDeploy
     - CodeBuild
     - CodePipeline https://aws.amazon.com/jp/containers/services/
     

     View Slide

150. ざっくりAWSのコンテナサービス
     といっても、
     何するやつか分類できて
     その中でも選択肢がある。
     って感じなんだな
     

     View Slide

151. ECR
     - ECR = Elastic Container Registry
     - IAM Policy / Role
     で
     ECR
     リソースの利用を細かく制御可能
     

     View Slide

152. ECR == AWSのDocker Registry
     

     View Slide

153. ECS / EKS
     - ECS ( Elastic Container Service )
     -
     他の
     AWS
     サービスとシームレスに連携
     - Fargate
     を使えばサーバの管理が不要
     -
     起動タイプで
     EC2 or Fargate
     を選べる
     - EKS ( Elastic Container Service for Kubernetes )
     - k8s
     のマネージドサービス
     - Master
     のみマネージド
     - Worker Node
     は
     EC2
     を立てて運用する
     - Fargate
     は未対応
     - (AWS
     のサービスとしては
     ) ECS
     より後発
     

     View Slide

154. ECSとEKS、
     どっちを使うか
     悩ましい！
     

     View Slide

155. Fargateに
     対応してるとかしてないとか
     う〜ん、Fargateって、なんだろ？
     

     View Slide

156. Fargate
     - Fargate
     とは
     - ECS
     で使えるフルマネージドなコンピューティングエンジン
     -
     課金体系
     -
     実際に
     Task
     を起動していた
     vCPU /
     メモリに対する時間単位の課金
     -
     最近単価が下がったが、
     EC2
     との価格比較をすると少し割高ではある
     

     View Slide

157. Fargateのメリット
     -
     メリット
     -
     管理コストが減る
     -
     コンテナのオートスケールに合わせて
     EC2
     もオートスケールさせる手間が
     ない
     - Worker Node
     がどの
     AZ
     に配置されてるか意識する必要がない
     -
     余剰リソースがなくなる
     - EC2
     を使うときはコンテナ全体が使っているより余剰のリソースを確保する
     必要がある
     

     View Slide

158. 管理コストも考えると
     Fargateよさそう！
     

     View Slide

159. EKS / ECS / Fargate の関係を整理すると ...
     

     View Slide

160. EKSとECSのControl Plane と Data Plane
     - Control Plane
     -
     コンテナを管理する場所
     -
     どの
     Node
     に配置するかなど制御する
     - AWS
     のサービスでいうと、
     ECS / EKS
     - Data Plane
     -
     コンテナが実行される場所
     - Control Plane
     に各
     Node
     やコンテナの状態をフィードバックする
     - AWS
     のサービスでいうと、
     Fargate / FC2
     

     View Slide

161. Fargate、めっちゃいいやつだな
     

     View Slide

162. CodeBuildとかCodeDeployとかは
     コンテナに対応してるのかな？
     

     View Slide

163. Code* (CodeBuild / CodeDeploy / CodePipeline)
     - CodeBuild
     - buildspec.yaml
     に
     ecr push
     を書いて
     ECR
     への
     push
     を行う
     - CodeDeploy
     - ECS
     で
     Blue/Green Deployment
     のサポート
     - CodePipeline
     - ECR
     上のイメージをデータソースとして使える
     -
     ビルド環境として使うイメージを
     ECR
     で管理できるようになった
     -
     これまでは
     CodeBuild
     で
     Docker
     イメージを管理していた
     - Deploy Target
     に
     ECS
     も対応
     

     View Slide

164. コンテナのビルド/デプロイにもちゃんと使
     えるんだな
     

     View Slide

165. 改めてEKSを
     さわってみる
     

     View Slide

166. Kubernetes 、やりたい
     

     View Slide

167. というか前任のあいつが
     Kubernetesで作ったので、
     やらざるを得ない！！
     

     View Slide

168. Why EKS ?
     - Why not ECS ?
     -
     前任者が既に
     GKE
     で一部サービスを稼働させていた
     - yaml
     使いまわしたい
     - EKS
     でも途中まで組んだ形跡があった
     - Why not GKE ?
     -
     既存のアプリケーションが
     AWS
     で稼働しておりデータが
     AWS
     にある
     -
     また、
     AWS
     でしか使えないデータベースを使いたい
     - e.g. DynamoDB Aurora
     

     View Slide

169. クラスターを立てる
     - 公式ドキュメント
     … getting started
     を読んでみた
     -
     https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html
     

     View Slide

170. VPC / Subnet / Security Group / IAM 設定 ...
     わかるけど、クラスターが立つまでに
     やることが多いな。。。。
     

     View Slide

171. シャッと
     簡単にできる方法 ないかな〜
     

     View Slide

172. Create k8s cluster by eksctl
     - Go
     製の
     cli
     アプリ
     - eksctl create cluster
     - CloudFormation
     が裏側で動いてくれる
     -
     一通りよしなにクラスターを作成してくれる
     - VPC / Subnet
     - IAM
     - EKS Cluster
     - Worker Node (EC2 + ASG)
     - 検証用途なら最速
     -
     デフォルトだと新規の
     VPC
     が作られる
     - (
     既存の
     VPC
     を使うオプションもある
     )
     https://github.com/weaveworks/eksctl
     

     View Slide

173. ぽちっとな
     $ eksctl create cluster
     

     View Slide

174. でかいインスタンスたててもたーーーー
     ※デフォルトだとオレゴンにて
     m5.large
     が
     2
     台立つ
     

     View Slide

175. けしけし
     

     View Slide

176. $ eksctl create cluster \
     --name test-cluster \
     --region ap-northeast-1 \
     --nodes 2 \
     --nodes-min 1 \
     --nodes-max 2 \
     --node-type t2.small
     スペックをしっかり指定するの巻
     

     View Slide

177. よし、クラスターができた
     

     View Slide

178. Nodeも指定したとおり、
     t2.smallが2台できてる
     $ kubectl get nodes
     NAME STATUS ROLES AGE VERSION
     ip-192-168-38-92.ap-northeast-1.compute.internal Ready 1s v1.11.5
     ip-192-168-74-18.ap-northeast-1.compute.internal Ready 1s v1.11.5
     $ kubectl get services
     NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
     kubernetes ClusterIP 10.100.0.1 443/TCP 1s
     

     View Slide

179. 他には何が作られているんんだろう。。。
     気になる。。。
     

     View Slide

180. nodegroupとcluster、2つのCloudFormationス
     タックができてるみたいだ。
     

     View Slide

181. Clusterの方は
     EKS Clusterと、
     それが乗っかる VPC
     / Subnet / Route Table
     などなどのネット
     ワーク周りを作って
     いる。
     

     View Slide

182. NodeGroupの方は
     AsgとLaunch Template
     を作ってるんだな。
     あとは
     IAM Role / SG /
     Instance Profileとかの
     権限周りか。
     

     View Slide

183. なにが立てられたか、
     ざっくりわかったぞい
     

     View Slide

184. では、ECRにDockerイメージを
     Pushしてみよう
     

     View Slide

185. Build
     > docker image build -t my-app:1.00 .
     まずはいつものように
     docker buildして、っと
     

     View Slide

186. ECR Login
     > $(aws ecr get-login --no-include-email --region ap-northeast-1)
     Login Succeeded
     ECR への Login コマンドを
     取得 & 実行.
     

     View Slide

187. Tag
     > docker image tag my-app:1.00 \
     xxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:1.00
     docker tagコマンドで
     ECRの方にタグを切り
     

     View Slide

188. Push
     > docker image push
     xxx.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:1.00
     ECR へ Push する！
     

     View Slide

189. ECRにDocker ImageをPushできたぞい
     

     View Slide

190. Makefile化すると便利
     NAME=my-app
     TAG=1.00
     CONTAINER_PORT=8888
     LOCAL_PORT=8888
     AWS_ACCOUNT_NUMBER=1234567890
     login: ## generate `docker login` command
     aws ecr get-login --no-include-email --region ap-northeast-1
     build: ## docker build
     docker build -t $(NAME):$(TAG) .
     run: ## docker run
     docker run --rm -it -p $(LOCAL_PORT):$(CONTAINER_PORT)
     $(NAME):$(TAG)
     tag: ## tag
     docker tag $(NAME):$(TAG)
     $(AWS_ACCOUNT_NUMBER).dkr.ecr.ap-northeast-1.amazonaws.com/$(NAME
     ):$(TAG)
     push: ## push 事前にAWSコンソールでリポジトリを作っておき、そこへpushする
     docker push
     $(AWS_ACCOUNT_NUMBER).dkr.ecr.ap-northeast-1.amazonaws.com/$(NAME
     ):$(TAG)
     release: build tag push
     そういえば、
     一連のコマンドは
     こんな感じで
     Makefileにしておくと
     取り回しやすい
     

     View Slide

191. よし、つぎは
     EKS へデプロイしたい！
     

     View Slide

192. まずはdeployment.yamlを書く
     

     View Slide

193. ほんで kubectl apply -f deployment.yaml
     っと
     $ kubectl apply -f deployment.yaml
     

     View Slide

194. podが立っている。
     $ kubectl get pods
     NAME READY STATUS RESTARTS AGE
     golang-sample-app-xxxxxxxxxd-dhgj2 1/1 Running 0 1s
     golang-sample-app-xxxxxxxxxd-q6pls 1/1 Running 0 1s
     golang-sample-app-xxxxxxxxxd-zlm25 1/1 Running 0 1s
     

     View Slide

195. けどこれ、どうやってインターネットからア
     クセスするんだろう ??
     

     View Slide

196. そうだ、Serviceを使うんだった
     

     View Slide

197. えいや
     service.yaml
     

     View Slide

198. kubectl apply -f service.yaml
     $ kubectl apply -f service.yaml
     

     View Slide

199. TYPE: LoadBalancerのServiceができた！
     $ kubectl get services
     NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
     golang-sample-app LoadBalancer 10.100.17.74 hoge.ap-northeast-1.elb.amazonaws.com 80:30498/TCP 3d
     kubernetes ClusterIP 10.100.0.1 443/TCP 4d
     

     View Slide

200. EXTERNAL-IP に
     ELBのDNS名が書かれているぞ
     $ kubectl get services
     NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
     golang-sample-app LoadBalancer 10.100.17.74 hoge.ap-northeast-1.elb.amazonaws.com 80:30498/TCP 3d
     kubernetes ClusterIP 10.100.0.1 443/TCP 4d
     

     View Slide

201. コンソールで確認すると
     ELB (Classic) が作られている！
     $ kubectl get services
     NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
     golang-sample-app LoadBalancer 10.100.17.74 hoge.ap-northeast-1.elb.amazonaws.com 80:30498/TCP 3d
     kubernetes ClusterIP 10.100.0.1 443/TCP 4d
     

     View Slide

202. いったんブラウザでみると
     

     View Slide

203. (Classic LoadBalancerだけど)
     動いてる〜！
     

     View Slide

204. やったね
     

     View Slide

205. でも、あれれ、、、
     

     View Slide

206. Ingressってのが必要じゃなかったっけ？
     Serviceだけでいいの？
     Service LoadBalancerだとCLBができる
     IngressでALBができる
     時代はALBなのだよ
     

     View Slide

207. あと、
     セキュリティグループ とか
     TLS証明書 とかを
     annotationで指定できるぞい
     

     View Slide

208. なるほど〜！ありがとうございます！
     

     View Slide

209. (うるさいなあ)
     

     View Slide

210. ALBも試しておくか
     

     View Slide

211. service.yaml はこんな感じで、
     Type: NodePortに書き換える。
     

     View Slide

212. apply
     $ kubectl apply -f manifest/service.yaml
     

     View Slide

213. ingress.yaml の annotation で
     internet-facingなalbをつくる。
     

     View Slide

214. これをapplyすると、
     ingressができる。
     $ kubectl apply -f manifest/ingress.yaml
     ingress.extensions/golang-sample-app created
     $ kubectl get ing
     NAME HOSTS ADDRESS PORTS AGE
     golang-sample-app * hoge.ap-northeast-1.elb.amazonaws.com 80 2m
     

     View Slide

215. おっ、ALBが
     Provisioning … になったぞ
     

     View Slide

216. しばらく待って...
     ALBでも動いた！
     

     View Slide

217. Ingressのannotationで色々かけば
     ALBに証明書とかもあてられる (はず...)
     - alb.ingress.kubernetes.io/certificate-arn
     - alb.ingress.kubernetes.io/ssl-policy
     - etc ...
     - https://github.com/kubernetes-sigs/aws-alb-ingre
     ss-controller/blob/master/docs/guide/ingress/ann
     otation.md
     

     View Slide

218. ここまでをまとめると
     

     View Slide

219. まとめ : eksctlでEKS Clusterたててみた
     -
     クラスターをたてる
     -
     検証だけなら
     eksctl
     でパッと立てられる
     - CloudFormation
     でもろもろリソースが用意される
     - Deployment
     - Kubernetes
     なので
     GKE
     とおなじ
     - ALB
     でインターネットからアクセスさせる
     - Service:NodePort
     と
     Ingress
     でやる
     - annotation
     は
     AWS
     固有の設定を書く
     

     View Slide

220. 検証はできたので、ちゃんとやるか
     

     View Slide

221. Cluster Management
     

     View Slide

222. Terraformで、コード管理や！
     

     View Slide

223. Create k8s cluster by Terraform
     - Production Ready in eureka
     -
     既存の
     VPC
     上でクラスタ構築したい
     -
     リソースは
     terraform
     で管理されてる
     - EKS
     もなるべく
     terraform
     で管理したい
     

     View Slide

224. Terraform : VPC & Subnet
     -
     # VPC
     resource "aws_vpc" "vpc" {
     cidr_block = "10.xx.yy.zz/ww"
     instance_tenancy = "default"
     enable_dns_support = "true"
     enable_dns_hostnames = "true"
     }
     # Subnet
     ## Public Subnets
     resource "aws_subnet" "public_1a" {
     }
     resource "aws_subnet" "public_1c" {
     }
     ## Private Subnets
     resource "aws_subnet" "private_1a" {
     }
     resource "aws_subnet" "private_1c" {
     }
     resource "aws_subnet" "private_1b" {
     }
     resource "aws_subnet" "private_1d" {
     }
     VPC / Subnet は既存のやつ。
     

     View Slide

225. Terraform : EKS Cluster
     resource "aws_eks_cluster" "quality" {
     name = "cluster-quality"
     role_arn = "${aws_iam_role.quality-cluster.arn}"
     vpc_config {
     security_group_ids = ["${aws_security_group.quality-cluster.id}"]
     subnet_ids = [
     "${aws_subnet.private_1b.id}",
     "${aws_subnet.private_1d.id}",
     ]
     }
     }
     EKS Cluster
     は
     こんなかんじ
     だぜ
     ※
     IAM Role / SG
     を別途書く必要あり
     

     View Slide

226. 次にワーカーノードの追加
     

     View Slide

227. Terraform : EC2 Auto Scaling Group
     data "aws_ami" "eks-worker" {
     filter {
     name = "name"
     values = ["eks-worker-*"]
     }
     most_recent = true
     owners = ["xxxxxxxxxxxx"] # Amazon Account ID
     }
     resource "aws_launch_configuration" "quality" {
     associate_public_ip_address = true
     iam_instance_profile =
     "${aws_iam_instance_profile.quality-node.name}"
     image_id = "${data.aws_ami.eks-worker.id}"
     instance_type = "t2.medium"
     name_prefix = "terraform-eks-quality"
     security_groups = ["${aws_security_group.quality-node.id}"]
     user_data_base64 = "${base64encode(local.quality-node-userdata)}"
     lifecycle {
     create_before_destroy = true
     }
     }
     resource "aws_autoscaling_group" "quality" {
     desired_capacity = 2
     launch_configuration = "${aws_launch_configuration.quality.id}"
     max_size = 2
     min_size = 1
     name = "terraform-eks-quality"
     vpc_zone_identifier = [
     "${aws_subnet.private_1b.id}",
     "${aws_subnet.private_1d.id}",
     ]
     tag {
     key = "Name"
     value = "terraform-eks-quality"
     propagate_at_launch = true
     }
     tag {
     key = "kubernetes.io/cluster/cluster-quality"
     value = "owned"
     propagate_at_launch = true
     }
     }
     ※
     Instance Profile / SG
     などなど別途書く必要あり
     

     View Slide

228. ちょっと大変。
     できるけど、
     

     View Slide

229. https://docs.aws.amazon.com/eks/latest/user
     guide/getting-started.html
     ノードをマスターに認識させたりする
     

     View Slide

230. View Slide

231. Nodeを認識させるのにまたひと手間
     

     View Slide

232. まとめ : Terraformでクラスターを立てる
     -
     既存リソースに組み込むかたちで本番に入れたい
     -
     やや分量が増えるが、既存のインフラと同じく
     terraform
     でできる
     -
     それなりに手間はかかる
     ※Terraformで作ったALBなどをClusterに
     認識させるには、タグとかで頑張る必要
     があるので注意だよ
     

     View Slide

233. ECS
     

     View Slide

234. そういえば山本さん(別のSRE)が
     最近ECSさわってたな
     どんな感じか、
     聞いてみようっと
     

     View Slide

235. View Slide

236. ふむ
     ふむ
     https://qiita.com/marnie_ms4/items/202deb8f587233a17cca
     

     View Slide

237. ECS
     - K8S
     と似てるけどちょっとちがう概念たち
     - Cluster / Service / Task Definition / etc ...
     https://qiita.com/marnie_ms4/items/202deb8f587233a17cca
     

     View Slide

238. ECSの良さ
     - AWS
     のサービスとの密な連携
     - CodeDeploy
     で
     Blue/Green
     してくれる
     - Task (
     ≒
     k8s
     でいう
     Pod)
     ごとに異なる
     IAM Role
     を付与できる
     - Fargate
     を使えるのがでかい
     - EC2
     の面倒を見なくてすむ
     -
     スケールするとき
     Service
     のスケールだけ考えれば良い
     - EC2
     の場合
     - Service
     のスケール時に
     EC2
     もスケールさせるので手間かかる
     -
     常にバッファ積むので余分にお金かかる
     

     View Slide

239. Fargate いいなあ
     EKS でも使いたいなー
     なるほど！ECSは
     EKSとまた違ったよさがあるんだな
     

     View Slide

240. Containers on AWS まとめ
     - ECR
     -
     プライベートなコンテナリポジトリ
     - EKS or ECS
     -
     どちらも
     Control Plane
     - k8s
     の生態系に乗りたいか、
     AWS
     の他サービスとなめらかに連携したいか
     - Fargate
     -
     よい
     

     View Slide

241. AWS 完全熟知 (￣＾￣) ﾄﾞﾔｯ!
     

     View Slide

242. Part 3
     CI/CD
     

     View Slide

243. 熟知・・・
     あれ・・・
     デプロイまわりはどうしたらええんや
     

     View Slide

244. 熟知できてない！！
     プロダクションに入れるには何かが足りな
     い！！！
     

     View Slide

245. 一旦現状把握
     

     View Slide

246. 既存のインフラ in eureka
     -
     主力サービスは
     EC2
     が多くコンテナでは動いていない
     

     View Slide

247. 既存のインフラ: CodeBuild
     - Docker
     イメージではなく、ビルドの生成物を
     S3
     にアップロード
     

     View Slide

248. 開発者視点のOverview
     - ChatOps
     経由でのデプロイ
     - @nana prepare {env}
     {region]-{service}
     -
     差分確認
     -
     前回
     deploy
     との
     commit
     差分
     (GitHub)
     -
     確認して
     deploy
     ボタンを押す
     -
     デプロイ完了
     - Slack
     通知
     

     View Slide

249. SRE視点の既存のOverview
     -
     インターフェイスは
     ChatOps
     - Slackbot
     で
     CodeBuild
     がキック
     -
     ビルド完了後、
     bot
     が
     CodeDeploy
     を
     API
     経由で呼び出してデプロイ
     BotApp
     RTM
     API Calls
     

     View Slide

250. Why not CodePipeline
     -
     １つのリポジトリで複数のものが内包されており、
     - master
     等のブランチに単純にフックさせるのが難しい
     pairs-repo
     JP
     FE
     JP
     BE
     TW
     BE
     KR
     BE
     TW
     FE
     

     View Slide

251. つぎに未来を考える
     

     View Slide

252. どうしたらいいのか
     -
     できるだけ開発者のインターフェイスを変えない
     - SOX
     の遵守
     

     View Slide

253. せっかくコンテナにするので
     -
     ステージングと本番では同じイメージが動く状態にしたい
     -
     イメージの脆弱性スキャン
     -
     構成変更の手間を減らしたい
     

     View Slide

254. イメージの検証
     -
     ステージングでの検証後本番に出せるようになる
     

     View Slide

255. 構成変更の手間
     EC2
     のゴールデンイメージを作成するのがそれなりに手間
     

     View Slide

256. 構成変更の手間
     EC2
     のゴールデンイメージを作成するのがそれなりに手間
     これがコンテナになると
     

     View Slide

257. VMとコンテナでの構成管理の違い
     - Immutable
     なインフラという思想はそのまま
     -
     構成管理
     = Docker Image
     の変更という世界観になる
     -
     ミドルウェアの細かい変更など、全て
     Docker Image
     の変更で済む
     

     View Slide

258. How to
     Deploy to
     Kubernetes
     

     View Slide

259. 頼りたくないけど、あいつを頼ってみよう
     

     View Slide

260. okok
     Kubernetes ってどうやって、デプロイのフ
     ロー作ればいいっすか？
     

     View Slide

261. コンテナ一般 CI/CD
     

     View Slide

262. Container CI/CD
     https://speakerdeck.com/sakajunquality/starting-google-kubernetes-engine-2019
     コンテナ全般
     テストは省略...
     

     View Slide

263. Container CI/CD
     https://speakerdeck.com/sakajunquality/starting-google-kubernetes-engine-2019
     コンテナ全般
     

     View Slide

264. GitOps
     

     View Slide

265. GitOps - Operations by Pull Request
     https://www.weave.works/blog/gitops-operations-by-pull-request
     

     View Slide

266. GitOps
     アプリケーションのリポジトリと、マニフェストのリポジトリを分離
     マニフェストリポジトリは常にクラスターの状態と整合性がとれている
     Application Config
     

     View Slide

267. “Declarative” が、ポイントなのか！
     terraform もそうだよなー
     

     View Slide

268. GitOps
     それぞれのリポジトリに対して、アプリケーションをビルドする
     CI
     と
     Kubernetes
     に
     apply
     する
     CI
     を設定する
     

     View Slide

269. GitOps on AWS
     CodeBuild
     ２つ設定すれば簡単に作れそう
     場合によっては
     CodePipeline
     も使えそう
     

     View Slide

270. CodePipeline
     

     View Slide

271. CodePipeline + Lambda
     https://aws.amazon.com/blogs/devops/continuous-deployment-to-kubernetes-using-aws-
     codepipeline-aws-codecommit-aws-codebuild-amazon-ecr-and-aws-lambda/
     

     View Slide

272. GitOps on AWS?
     CodePipeline?
     

     View Slide

273. CodePipelineでもできそうだし
     GitOpsも試すのも良さそう
     

     View Slide

274. もう少しいろいろ検討してみよう・・・
     

     View Slide

275. (今回ここを実装するのは間に合わず)
     

     View Slide

276. CI/CD まとめ
     - Kubernetes
     では
     GitOps
     という考えがある
     - CodePipelines
     を使うとシンプルなパイプラインも構築できそう
     -
     あたらしいワークフローを作りつつも、
     -
     既存の開発者のインターフェイスはできるだけ変えずにやりたい
     

     View Slide

277. What’s Next?
     

     View Slide

278. Monitoring
     -
     監視は大事だよね
     - Kubernetes
     そのものの監視
     -
     ノードの監視
     -
     コンテナの監視
     -
     タグとラベルつかう
     -
     リソース使用量
     -
     ヘルスチェック
     - etc ...
     

     View Slide

279. Logging
     -
     ログ、必要だよね
     -
     既存のログと同じように収集して同じように解析したい
     

     View Slide

280. Service Mesh?
     マイクロサービス間の可視化
     

     View Slide

281. Service Mesh?
     マイクロサービス間の可視化
     

     View Slide

282. 気になるRoadmaps
     

     View Slide

283. EKS IAM Roles for Pods
     https://github.com/aws/containers-roadmap/issues/23
     

     View Slide

284. EKS IAM Roles for Pods
     https://github.com/aws/containers-roadmap/issues/23
     ECSにはあるやつ
     GKEでも恩恵うけれる？
     

     View Slide

285. Fargate for EKS
     https://github.com/aws/containers-roadmap/issues/32
     

     View Slide

286. Fargate for EKS
     https://github.com/aws/containers-roadmap/issues/32
     Fargate for EKS !!!
     

     View Slide

287. Managed worker nodes
     https://github.com/aws/containers-roadmap/issues/139
     

     View Slide

288. Managed worker nodes
     https://github.com/aws/containers-roadmap/issues/139
     Is this different from
     “EKS Fargate”?
     

     View Slide

289. EKS Private Link Support
     https://github.com/aws/containers-roadmap/issues/22
     

     View Slide

290. EKS Private Link Support
     https://github.com/aws/containers-roadmap/issues/22
     他のサービスでは進んでるやつ！
     

     View Slide

291. Takeaways
     

     View Slide

292. Takeaways
     - Docker & k8s
     の基礎
     - k8s
     は覚えること多めだけど
     -
     焦らず
     1
     個ずつ確実に理解する
     - AWS
     のコンテナ関連サービス
     - ECR
     - EKS / ECS
     - Fargate
     - CI/CD
     - GitOps
     - CodePipeline
     - What’s Next
     -
     監視
     /
     ロギング などまだまだ考えることある
     -
     今後のロードマップ
     

     View Slide

293. ご清聴ありがとうございました！
     

     View Slide

294. Appendix
     

     View Slide

295. Appendix
     - https://docs.docker.com/
     - https://kubernetes.io/docs/home/
     - https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html
     - https://github.com/weaveworks/eksctl
     - https://www.weave.works/blog/gitops-operations-by-pull-request
     -
     https://www.slideshare.net/AmazonWebServicesJapan/20180214-aws-black-
     belt-online-seminar-amazon-container-services
     

     View Slide