脱 Dockerfile! Cloud Native Buildpacksとkpackを 使った簡単で安全なイメージビルド

コンテナイメージをDockerfileを使わずにビルドする Cloud Native Buildpacks と kpack の紹介。

Transcript

1. Confidential │ ©2021 VMware, Inc.
   脱 Dockerfile!
   Cloud Native Buildpacksとkpackを
   使った簡単で安全なイメージビルド
   Yuichi Ito
   Sr Platform Architect / Modern Application Platform BU
   Feb 2021
   

   View Slide

2. Confidential │ ©2021 VMware, Inc. 2
   l Dockerfileのおさらいと問題点
   l Cloud Native Buildpack
   l 概要
   l デモ
   l ビルドの流れと内部の仕組み
   l 導入方法
   l kpack
   l 概要
   l デモ
   l ビルドの流れと内部の仕組み
   l 導入方法
   l CIパイプラインの構築例
   l 製品版である VMware Tanzu Build Service の紹介
   目次
   

   View Slide

3. Confidential │ ©2021 VMware, Inc. 3
   コンテナイメージをビルドするための定義ファイル
   Infrastracture as a Code によくあるYAMLなどの「構成定義ファイル」というよりも、ビルド
   するための手順書(コマンドを羅列したBashスクリプト)に近い
   分かりやすく、導入が簡単
   Dockerfileのおさらい
   Dockerfile
   1. ベースイメージ
   2. OSパッケージインストール
   3. ソースコード取り込み
   4. ライブラリインストール
   5. コードのビルド
   6. 実行コードの定義
   Docker 基盤
   1. ベースイメージ
   2. OSパッケージインストール
   3.ソースコード取り込み
   4.ライブラリインストール
   5.コードのビルド
   6.実行コードの定義
   ビルド定義
   差分の積み重ねでビルド
   コンテナイメージ
   成果物
   

   View Slide

4. Confidential │ ©2021 VMware, Inc. 4
   よくあるDockerfileの使われかた
   • ググって見つけたDockerfileをベースに修正
   • アプリを載せて動くことは確認できた
   • 微調整しながら本番用イメージ構築用に近づける
   「動く」 ≠ 「プロダクションレディ」
   Javaアプリで挙げられるDockerfileの問題例
   • ビルド作業のガバナンスがない(危険なビルドを実施可能)
   • ベースイメージ: LinuxやJava的な脆弱性はないか
   • JVMパラメーター: Javaの設定(ヒープなど)は問題ないか
   • ライブラリ: 問題の報告されているライブラリを使っていないか
   • 数十、数百ある Dockerfile をメンテナンスし続けられるか
   その手順で作成したイメージは「ただ動くだけ」ではないか?
   Dockerfileの問題点
   Dockerfile
   1. ベースイメージ
   2. OSパッケージインストール
   3. ソースコード取り込み
   4. ライブラリインストール
   5. コードのビルド
   6. 実行コードの定義
   50人で500Dockerfileの管理。大丈夫?
   

   View Slide

5. Confidential │ ©2021 VMware, Inc. 5
   Dockerfileの中身がプロダクションレディではない
   -> Dockerfileのように自分たちで細かなステップごとのビルド定義をしない
   -> ソースコードに応じたベストプラクティスに沿った自動ビルドを実施
   大量にあるDockerfileが陳腐化(古く)する
   -> 共通したビルド定義のみ更新すれば、全イメージを新定義でビルドしなおせる
   人に頼らないベストプラクティスを採用した自動ビルドの採用
   Dockerfileの問題の解決方法
   

   View Slide

6. 6
   Confidential │ ©2021 VMware, Inc.
   Cloud Native Buildpacks (CNB)
   

   View Slide

7. Confidential │ ©2021 VMware, Inc. 7
   Dockerfileで実現していたビルド手順の定義を自動で作成/ビルド
   Dockerfileにない強み
   • 細かなビルド手順を書く必要がなくなる
   • ベストプラクティスに沿ったビルドが実施される
   • ビルドキャッシュ(前回のビルドから変更がない箇所の再利用)が優秀
   ソースコードを書くだけでコンテナイメージのビルドができる
   概要
   Cloud Native Buildpacks
   Buildpacks
   • ソースコード判定
   • ビルド手法の定義
   ソースコード記述 コンテナイメージの完成
   Dockerfile相当を
   自動生成する仕組み
   $ pack build sample-app
   ビルドコマンド発行
   Buildpacksを使って
   イメージをビルド
   ビルド用イメージのPull
   イメージレジストリ
   

   View Slide

8. Confidential │ ©2021 VMware, Inc. 8
   内容
   • 解説しながらCNBでJavaアプリのイメージビルド、及び実行
   • .Netアプリののビルドと実行(早送り)
   • Pythonアプリののビルドと実行(早送り)
   • Node.jsアプリののビルドと実行(早送り)
   • Rubyアプリののビルドと実行(早送り)
   • PHPアプリののビルドと実行(早送り)
   Demo
   

   View Slide

9. Confidential │ ©2021 VMware, Inc. 9
   Demo root@ubuntu:~/Cloud-Native-Buildpacks/gcr.io-buildpacks-builder/java# pack build java-app --builder gcr.io/buildpacks/builder:v1
   v1: Pulling from buildpacks/builder
   Digest: sha256:bc3918285977bcb8ba7ef0a187497d0d8f84a10bc32f7ae85adaffe3fb206ce9
   Status: Image is up to date for gcr.io/buildpacks/builder:v1
   v1: Pulling from buildpacks/gcp/run
   Digest: sha256:7a00ffa71a5ac563346cf3f7d2bb5430d1518f4ff65662233fac48bec65dc813
   Status: Image is up to date for gcr.io/buildpacks/gcp/run:v1
   ===> DETECTING
   4 of 5 buildpacks participating
   google.java.runtime 0.9.1
   google.java.maven 0.9.0
   google.java.entrypoint 0.9.0
   google.utils.label 0.0.1
   ===> ANALYZING
   Restoring metadata for "google.java.runtime:java" from app image
   Restoring metadata for "google.java.maven:m2" from cache
   ===> RESTORING
   Restoring data for "google.java.runtime:java" from cache
   Restoring data for "google.java.maven:m2" from cache
   ===> BUILDING
   === Java - Runtime (google.java.runtime@0.9.1) ===
   Using latest Java 11 runtime version.
   ...
   *** Images (3320cf9e22a7):
   java-app
   Reusing cache layer 'google.java.runtime:java'
   Reusing cache layer 'google.java.maven:m2'
   Successfully built image java-app
   

   View Slide

10. Confidential │ ©2021 VMware, Inc. 10
    Buildpack: コードをビルドするためのスクリプトのまとまり
    Stack: ビルドしたコードを動かすベースイメージ(OS)
    CNBによるビルド作業
    Buildpack
    root@ubuntu:~# pack builder suggest
    Suggested builders:
    Google: gcr.io/buildpacks/builder:v1 Ubuntu 18 base image with buildpacks for .NET, Go, Java, Node.js, and Python
    Heroku: heroku/buildpacks:18 heroku-18 base image with buildpacks for Ruby, Java, Node.js, Python, Golang, & PHP
    Heroku: heroku/buildpacks:20 heroku-20 base image with buildpacks for Ruby, Java, Node.js, Python, Golang, & PHP
    Paketo Buildpacks: paketobuildpacks/builder:base Ubuntu bionic base image with buildpacks for Java, .NET Core, NodeJS, Go, Ruby, NGINX and Procfile
    Paketo Buildpacks: paketobuildpacks/builder:full Ubuntu bionic base image with buildpacks for Java, .NET Core, NodeJS, Go, PHP, Ruby, Apache HTTPD, NGINX and Procfile
    Paketo Buildpacks: paketobuildpacks/builder:tiny Tiny base image (bionic build image, distroless-like run image) with buildpacks for Java Native Image and Go
    ビルドパックを選択
    Stack(ベースOS)
    ビルド成果物(アプリ)
    root@ubuntu:~# pack stack suggest
    Stacks maintained by the community:
    Stack ID: heroku-18
    Description: The official Heroku stack based on Ubuntu 18.04
    Maintainer: Heroku
    Build Image: heroku/pack:18-build
    Run Image: heroku/pack:18
    Stack ID: io.buildpacks.stacks.bionic
    Description: A minimal Paketo stack based on Ubuntu 18.04
    Maintainer: Paketo Project
    Build Image: paketobuildpacks/build:base-cnb
    Run Image: paketobuildpacks/run:base-cnb
    ...
    ビルドパックの定義で
    どのスタックを使うか指定
    (ユーザーは気にしないでOK)
    

    View Slide

11. Confidential │ ©2021 VMware, Inc. 11
    詳細はBuildpackの開発者向けドキュメントにある(利用者は内部を気にしないでOK)
    • Buildpack Author’s Guide: https://buildpacks.io/docs/buildpack-author-guide/
    • Buildpack Interface Specification: https://github.com/buildpacks/spec/blob/main/buildpack.md
    おおまかな処理の流れ
    CNB内部のビルドの流れ
    Detection Analysis Build Export
    Buildpack内の定義 Buildpack内の定義
    最適なビルドパックの選択
    (言語の判定)
    ビルドするレイヤーの判定
    (キャッシュが効くか判定)
    必要なレイヤーのビルド
    (更新のみビルド)
    レイヤーを束ねてイメージ化
    (リモートレイヤーの置き換え)
    

    View Slide

12. Confidential │ ©2021 VMware, Inc. 12
    ソースコードをビルドパックのサポート言語の判定定義に従って順にチェック
    判定にヒットした言語として後工程でビルドをする
    (判定にヒットするようにプログラムを書く必要がある)
    ソースコードの種類(言語)の判定
    Step1. Detection
    

    View Slide

13. Confidential │ ©2021 VMware, Inc. 13
    Buildを効率化するための前処理
    Step2. Analysis
    前回のビルド結果(メタ情報)を参照
    レイヤーごとに新規ビルド/再利用の判定
    

    View Slide

14. Confidential │ ©2021 VMware, Inc. 14
    Analysisの結果とソースコードを見比べて必要な箇所のみビルド
    Step3. Build
    Dockerfileの積み上げ式ビルドとは異なる
    ビルドパックを使って機能ごとにビルド
    

    View Slide

15. Confidential │ ©2021 VMware, Inc. 15
    コンテナイメージの作成
    Step4. Export
    新規ビルド/既存のレイヤーよりイメージ作成
    次回ビルドのためのレイヤーとメタ情報登録
    

    View Slide

16. Confidential │ ©2021 VMware, Inc. 16
    1. Dockerのインストール
    2. packコマンド(バイナリ)のインストール
    • Windows
    • MacOSX
    • Linux
    以上!!
    パッケージソフトやバイナリによるpackコマンドのインストール
    CNBの導入手順
    https://buildpacks.io/docs/tools/pack/
    

    View Slide

17. 17
    Confidential │ ©2021 VMware, Inc.
    kpack
    

    View Slide

18. Confidential │ ©2021 VMware, Inc. 18
    CNBをKubernetes上で自動で動かす仕組み
    1. イメージリソースの作成/更新 (ビルド作業のKick)
    2. 自動: GitリポジトリからのコードのPull
    3. 自動: CNBによるビルド
    4. 自動: イメージリポジトリへのイメージのPush
    CNBにない強み
    • ビルド設定の作成/更新をYAMLで実現(ガバナンス)
    • ベースOSを変更しやすくアプリ層の再ビルドも不要
    • CIを自動化させやすい
    Kubernetesを使ってCNBによるビルドをさらに自動化
    概要
    Kubernetes Cluster
    kpack
    • Builder: Image Repository
    • Source: Git Repository
    • Dest: Image Repository
    コードのPull
    イメージのビルド
    成果物イメージのPush
    ビルド用イメージ(CNB)のPull
    イメージレジストリ
    イメージレジストリ
    Git
    

    View Slide

19. Confidential │ ©2021 VMware, Inc. 19
    内容
    • 解説しながらkpackでGoアプリのイメージビルド、及び実行
    Demo
    

    View Slide

20. Confidential │ ©2021 VMware, Inc. 20
    Demo root@ubuntu:~# kubectl apply -f image-go.yaml
    image.kpack.io/go-image created
    root@ubuntu:~# logs -image go-image
    ===> PREPARE
    Build reason(s): CONFIG
    CONFIG:
    resources: {}
    - source: {}
    + source:
    + git:
    + revision: 17cf01b61f9c055b7ac22142fa458f1edfe2a4e9
    + url: https://github.com/yuichi110/kpack-demo-go
    Loading secret for "https://index.docker.io/v1/" from secret "tutorial-registry-credentials" at location "/var/build-secrets/tutorial-registry-credentials"
    Cloning "https://github.com/yuichi110/kpack-demo-go" @ "17cf01b61f9c055b7ac22142fa458f1edfe2a4e9"...
    Successfully cloned "https://github.com/yuichi110/kpack-demo-go" @ "17cf01b61f9c055b7ac22142fa458f1edfe2a4e9" in path "/workspace"
    ===> DETECT
    3 of 4 buildpacks participating
    paketo-buildpacks/go-dist 0.2.8
    .....
    Adding label 'io.buildpacks.project.metadata'
    Setting default process type 'web'
    *** Images (sha256:275881669bbb1559d0bac30cad2ef0ef3b5d20b6d4f994dfb2e929089d6545e7):
    iyuichivm/kpack-go-app
    index.docker.io/iyuichivm/kpack-go-app:b1.20210218.021245
    Adding cache layer 'paketo-buildpacks/go-dist:go'
    Adding cache layer 'paketo-buildpacks/go-mod-vendor:mod-cache'
    Adding cache layer 'paketo-buildpacks/go-build:gocache'
    ===> COMPLETION
    Build successful
    root@ubuntu:~# cat image-go.yaml
    apiVersion: kpack.io/v1alpha1
    kind: Image
    metadata:
    name: go-image
    namespace: default
    spec:
    tag: iyuichivm/kpack-go-app
    serviceAccount: tutorial-service-account
    builder:
    name: my-builder
    kind: Builder
    source:
    git:
    url: https://github.com/yuichi110/kpack-demo-go
    revision: 17cf01b61f9c055b7ac22142fa458f1edfe2a4e9
    

    View Slide

21. Confidential │ ©2021 VMware, Inc. 21
    1. kpackを動かす管理系ワークロードをYAMLで展開
    2. リソース定義に従い上記ワークロードが必要時にビルド用Podを勝手に作成して作業を実施
    コード取得 -> CNBによるビルド -> イメージの登録
    kpackがビルドを実施する流れ
    Kubernetes Cluster
    kpack 管理系
    ビルド用の一時的なPod
    Git
    Pull
    CNB
    Build
    Image
    Push
    kpack
    Image Resource
    (アプリのビルド定義)
    リソース監視
    Imageリソース作成時/更新時に定義されたビルドタスクを実施
    

    View Slide

22. Confidential │ ©2021 VMware, Inc. 22
    1. kpackを動かす管理系ワークロードをYAMLで展開
    2. リソース定義に従い上記ワークロードが必要時にビルド用Podを勝手に作成して作業を実施
    CNBやリポジトリを使うためのリソース定義。及びビルド作業の定義
    kpackのK8sリソース
    Kubernetes Cluster
    kpack 管理系
    Secret定義
    Service-Account定義
    Stack定義
    Store定義
    Builder定義
    (CNB)
    Image定義
    (アプリ)
    1. Imageのリソースを作成する
    2. 自動: kpackがGitからコードを取得
    3. 自動: kpackがCNB PodでBuild
    4. 自動: kpackがイメージをPush
    ビルドの流れ
    K8sリソース
    YAMLで展開
    ビルドパックのリポジトリ指定 スタックのリポジトリ指定
    StoreとStackからBuilderを定義 ビルドの詳細
    実行に必要な情報や権限
    

    View Slide

23. Confidential │ ©2021 VMware, Inc. 23
    1. プライベートレジストリの構築(Push/Pull速度的におすすめ。DockerHubなどでもOK)
    2. Kubernetesクラスタの作成
    3. kpack管理系のデプロイのためのYAML(Downloadする)を適用
    4. リソースSecret作成
    5. リソースStackとStoreを作成
    6. リソースBuilderの作成
    インストール用YAMLの実施とビルドに必要なK8sリソースの定義
    kpackの導入手順
    ビルドの詳細を指定する
    イメージリソースと異なり
    使いまわしが可能
    https://github.com/pivotal/kpack/blob/master/docs/install.md
    

    View Slide

24. 24
    Confidential │ ©2021 VMware, Inc.
    自動ビルドのCI構築例
    

    View Slide

25. Confidential │ ©2021 VMware, Inc. 25
    CIパイプラインでのスクリプト作業が多い。パイプラインの更新がスクリプトの調整(手間)
    CNBを使う例
    Git ブランチ
    Continuous Integration
    アプリケーション
    ソースコード
    Linuxホスト コンテナレジストリ
    CNB
    Git Pull
    Build
    Docker Push
    shell shell shell
    kick
    

    View Slide

26. Confidential │ ©2021 VMware, Inc. 26
    CIパイプラインが単純。パイプラインの更新はkpackへのYAMLの適用
    kpackを使う例
    Git ブランチ
    Continuous Integration
    アプリケーション
    ソースコード
    Kubernetes コンテナレジストリ
    kpack
    Build
    ImageのYAMLを更新して適用
    kick
    

    View Slide

27. Confidential │ ©2021 VMware, Inc. 27
    サポート付きで「kpack + α」を実現したい場合に導入をご検討ください
    宣伝: VMware Tanzu Build Service
    Tanzu Build Service が新たなコミットを検知
    kpack
    初回のコンテナビルドと同じステップを経て、新たなコンテナイメージを自動で作成
    Git Pushがトリガー(kpackのようにYAML更新不要)
    

    View Slide

28. Confidential │ ©2021 VMware, Inc.
    Thank You
    Please email any questions to PowerPoint@vmware.com
    

    View Slide