Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Daichi Harada

February 23, 2019
Tweet

More Decks by Daichi Harada

Other Decks in Technology

Transcript

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

    View full-size slide

  2. はじめに

    View full-size slide

  3. Docker やろうぜ
    お、おす

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. Daichi Haradaのクジラ漁

    View full-size slide

  7. Daichi Haradaのクジラ漁

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. Part 1
    Docker and Kubernetes

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. Build Ship Run

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. こんな感じのコードですね
    // 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 full-size slide

  23. 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 full-size slide

  24. “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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. Dockerfile が必要らしい

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. マルチステージビルドを使うとよいよ
    // 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 full-size slide

  40. イメージのサイズを比べてみよう
    $ 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. マルチステージビルドとは・・・
    -
    アプリケーションをビルドするコンテナ
    /
    実行するコンテナ を分離する
    -
    実行するコンテナにはビルドに使うパッケージは入ってなくて
    OK
    - Docker Image
    のサイズを小さくできる
    - Go

    Java
    などビルドしたらバイナリや
    jar
    が出力されるものにはピッタリ

    View full-size slide

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

    View full-size slide

  48. Docker Hubとは・・・
    - Docker
    社が運営する
    Docker
    レジス
    トリ
    - FROM golang:1.11

    FROM alpine
    など書いて
    Pull
    される
    Image

    Docker Hub
    にホストされている
    https://hub.docker.com/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  53. $ 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  56. VM vs Container

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  59. Build Ship Run

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  62. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  67. Docker 完全熟知 ( ̄^ ̄) ドヤッ !

    View full-size slide

  68. Kubernetes
    Google’s Borg

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  72. こんな絵本が・・・

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  75. 本題の Kubernetes

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  79. Small Ikesu
    Large Ikesu
    Medium Ikesu

    View full-size slide

  80. ...ってことだ!多分

    View full-size slide

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

    View full-size slide

  82. 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 full-size slide

  83. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  86. ワーカーノードがいけす!
    Ikesu Node

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  91. ラベルと同時に、名前空間でも管理してい

    e.g.
    - production
    - web
    - datch-area
    Namespaces

    View full-size slide

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

    View full-size slide

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

    ReplicaSet

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  96. -
    データの永続化する際に仕様
    - EC2

    EBS
    をアタッチするノリ
    Volumes

    View full-size slide

  97. ワケワカラン

    View full-size slide

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

    View full-size slide

  99. カエリタイ

    View full-size slide

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

    View full-size slide

  101. これね
    // 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  108. // 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 full-size slide

  109. // 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 full-size slide

  110. // 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 full-size slide

  111. // 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  115. 次に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 full-size slide

  116. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  119. // 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  124. おー
    いんたーねっつに公開された!!!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  127. container == pod?

    View full-size slide

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

    View full-size slide

  129. ところで何で急に教育熱心になったんで
    すか?
    恩田さん(上司)に怒られました?

    View full-size slide

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

    View full-size slide

  131. (冷静に、こんなに技術先行なのは、
    引き継ぎってことか・・・)

    View full-size slide

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

    View full-size slide

  133. さらばじゃ

    View full-size slide

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

    View full-size slide

  135. Part 2
    Containers on AWS

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  139. AWS Container
    Services

    View full-size slide

  140. 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 full-size slide

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

    View full-size slide

  142. ECR
    - ECR = Elastic Container Registry
    - IAM Policy / Role

    ECR
    リソースの利用を細かく制御可能

    View full-size slide

  143. ECR == AWSのDocker Registry

    View full-size slide

  144. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  154. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  157. Kubernetes 、やりたい

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  163. 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 full-size slide

  164. ぽちっとな
    $ eksctl create cluster

    View full-size slide

  165. でかいインスタンスたててもたーーーー
    ※デフォルトだとオレゴンにて
    m5.large

    2
    台立つ

    View full-size slide

  166. けしけし

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  169. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  181. 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 full-size slide

  182. よし、つぎは
    EKS へデプロイしたい!

    View full-size slide

  183. まずはdeployment.yamlを書く

    View full-size slide

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

    View full-size slide

  185. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  188. えいや
    service.yaml

    View full-size slide

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

    View full-size slide

  190. 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 full-size slide

  191. 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 full-size slide

  192. コンソールで確認すると
    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 full-size slide

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

    View full-size slide

  194. (Classic LoadBalancerだけど)
    動いてる〜!

    View full-size slide

  195. やったね

    View full-size slide

  196. でも、あれれ、、、

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  200. (うるさいなあ)

    View full-size slide

  201. ALBも試しておくか

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  205. これを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 full-size slide

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

    View full-size slide

  207. しばらく待って...
    ALBでも動いた!

    View full-size slide

  208. 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 full-size slide

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

    View full-size slide

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

    Ingress
    でやる
    - annotation

    AWS
    固有の設定を書く

    View full-size slide

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

    View full-size slide

  212. Cluster Management

    View full-size slide

  213. Terraformで、コード管理や!

    View full-size slide

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

    View full-size slide

  215. 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 full-size slide

  216. 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 full-size slide

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

    View full-size slide

  218. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  226. ECSの良さ
    - AWS
    のサービスとの密な連携
    - CodeDeploy

    Blue/Green
    してくれる
    - Task (

    k8s
    でいう
    Pod)
    ごとに異なる
    IAM Role
    を付与できる
    - Fargate
    を使えるのがでかい
    - EC2
    の面倒を見なくてすむ
    -
    スケールするとき
    Service
    のスケールだけ考えれば良い
    - EC2
    の場合
    - Service
    のスケール時に
    EC2
    もスケールさせるので手間かかる
    -
    常にバッファ積むので余分にお金かかる

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  229. AWS 完全熟知 ( ̄^ ̄) ドヤッ!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  232. 一旦現状把握

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  236. SRE視点の既存のOverview
    -
    インターフェイスは
    ChatOps
    - Slackbot

    CodeBuild
    がキック
    -
    ビルド完了後、
    bot

    CodeDeploy

    API
    経由で呼び出してデプロイ
    BotApp
    RTM
    API Calls

    View full-size slide

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

    View full-size slide

  238. つぎに未来を考える

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  245. How to
    Deploy to
    Kubernetes

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  248. コンテナ一般 CI/CD

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    Kubernetes

    apply
    する
    CI
    を設定する

    View full-size slide

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

    View full-size slide

  256. CodePipeline

    View full-size slide

  257. 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 full-size slide

  258. GitOps on AWS?
    CodePipeline?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  263. What’s Next?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  268. 気になるRoadmaps

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  278. ご清聴ありがとうございました!

    View full-size slide

  279. 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 full-size slide