脱 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
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 の紹介 目次
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.実行コードの定義 ビルド定義 差分の積み重ねでビルド コンテナイメージ 成果物
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の管理。大丈夫?
5. Confidential │ ©2021 VMware, Inc. 5 Dockerfileの中身がプロダクションレディではない -> Dockerfileのように自分たちで細かなステップごとのビルド定義をしない -> ソースコードに応じたベストプラクティスに沿った自動ビルドを実施 大量にあるDockerfileが陳腐化(古く)する -> 共通したビルド定義のみ更新すれば、全イメージを新定義でビルドしなおせる 人に頼らないベストプラクティスを採用した自動ビルドの採用 Dockerfileの問題の解決方法
6. 6 Confidential │ ©2021 VMware, Inc. Cloud Native Buildpacks (CNB)
7. Confidential │ ©2021 VMware, Inc. 7 Dockerfileで実現していたビルド手順の定義を自動で作成/ビルド Dockerfileにない強み • 細かなビルド手順を書く必要がなくなる • ベストプラクティスに沿ったビルドが実施される • ビルドキャッシュ(前回のビルドから変更がない箇所の再利用)が優秀 ソースコードを書くだけでコンテナイメージのビルドができる 概要 Cloud Native Buildpacks Buildpacks • ソースコード判定 • ビルド手法の定義 ソースコード記述 コンテナイメージの完成 Dockerfile相当を 自動生成する仕組み $ pack build sample-app ビルドコマンド発行 Buildpacksを使って イメージをビルド ビルド用イメージのPull イメージレジストリ
8. Confidential │ ©2021 VMware, Inc. 8 内容 • 解説しながらCNBでJavaアプリのイメージビルド、及び実行 • .Netアプリののビルドと実行(早送り) • Pythonアプリののビルドと実行(早送り) • Node.jsアプリののビルドと実行(早送り) • Rubyアプリののビルドと実行(早送り) • PHPアプリののビルドと実行(早送り) Demo
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
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)
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内の定義 最適なビルドパックの選択 (言語の判定) ビルドするレイヤーの判定 (キャッシュが効くか判定) 必要なレイヤーのビルド (更新のみビルド) レイヤーを束ねてイメージ化 (リモートレイヤーの置き換え)
12. Confidential │ ©2021 VMware, Inc. 12 ソースコードをビルドパックのサポート言語の判定定義に従って順にチェック 判定にヒットした言語として後工程でビルドをする (判定にヒットするようにプログラムを書く必要がある) ソースコードの種類(言語)の判定 Step1. Detection
13. Confidential │ ©2021 VMware, Inc. 13 Buildを効率化するための前処理 Step2. Analysis 前回のビルド結果(メタ情報)を参照 レイヤーごとに新規ビルド/再利用の判定
14. Confidential │ ©2021 VMware, Inc. 14 Analysisの結果とソースコードを見比べて必要な箇所のみビルド Step3. Build Dockerfileの積み上げ式ビルドとは異なる ビルドパックを使って機能ごとにビルド
15. Confidential │ ©2021 VMware, Inc. 15 コンテナイメージの作成 Step4. Export 新規ビルド/既存のレイヤーよりイメージ作成 次回ビルドのためのレイヤーとメタ情報登録
16. Confidential │ ©2021 VMware, Inc. 16 1. Dockerのインストール 2. packコマンド(バイナリ)のインストール • Windows • MacOSX • Linux 以上!! パッケージソフトやバイナリによるpackコマンドのインストール CNBの導入手順 https://buildpacks.io/docs/tools/pack/
17. 17 Confidential │ ©2021 VMware, Inc. kpack
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
19. Confidential │ ©2021 VMware, Inc. 19 内容 • 解説しながらkpackでGoアプリのイメージビルド、及び実行 Demo
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
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リソース作成時/更新時に定義されたビルドタスクを実施
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を定義 ビルドの詳細 実行に必要な情報や権限
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
24. 24 Confidential │ ©2021 VMware, Inc. 自動ビルドのCI構築例
25. Confidential │ ©2021 VMware, Inc. 25 CIパイプラインでのスクリプト作業が多い。パイプラインの更新がスクリプトの調整(手間) CNBを使う例 Git ブランチ Continuous Integration アプリケーション ソースコード Linuxホスト コンテナレジストリ CNB Git Pull Build Docker Push shell shell shell kick
26. Confidential │ ©2021 VMware, Inc. 26 CIパイプラインが単純。パイプラインの更新はkpackへのYAMLの適用 kpackを使う例 Git ブランチ Continuous Integration アプリケーション ソースコード Kubernetes コンテナレジストリ kpack Build ImageのYAMLを更新して適用 kick
27. Confidential │ ©2021 VMware, Inc. 27 サポート付きで「kpack + α」を実現したい場合に導入をご検討ください 宣伝: VMware Tanzu Build Service Tanzu Build Service が新たなコミットを検知 kpack 初回のコンテナビルドと同じステップを経て、新たなコンテナイメージを自動で作成 Git Pushがトリガー(kpackのようにYAML更新不要)
28. Confidential │ ©2021 VMware, Inc. Thank You Please email any questions to PowerPoint@vmware.com