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

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

yuichi
March 15, 2021

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

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

yuichi

March 15, 2021
Tweet

More Decks by yuichi

Other Decks in Programming

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 [email protected]:~/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 ([email protected]) ===
    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
    [email protected]:~# 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)
    ビルド成果物(アプリ)
    [email protected]:~# 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 [email protected]:~# kubectl apply -f image-go.yaml
    image.kpack.io/go-image created
    [email protected]:~# 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
    [email protected]:~# 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 [email protected]

    View Slide