PythonにとってのよりよいDockerfileを考える

by RevComm_inc

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Copyright © 2022 RevComm Inc. はじめに 4 この資料の想定読者 ● コンテナ技術に入門済みの人 ● Dockerﬁle を書いたことがある人 ● Web アプリケーション開発者（インタプリタ言語）この資料で話さないこと ● コンテナとは何か？コンテナ技術の仕組み ● ML/DL、バッチ処理用途のワークロード ● コンパイル言語向けのこと（Java, Go, Rust） ○ …Dockerﬁle の戦略が異なってくる (alpine とか distroless とか)

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © 2022 RevComm Inc. “よい Dockerﬁle” とは 7 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン (VM) と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ● 可搬性 / セキュリティ

Slide 8

Slide 8 text

Copyright © 2022 RevComm Inc. “よい Dockerﬁle” とは 8 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 9

Slide 9 text

Copyright © 2022 RevComm Inc. “よい Dockerﬁle” とは 9 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない ⇒Python アプリケーションを想定した実例とともに深堀り

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © 2022 RevComm Inc. (再掲) “よい Dockerﬁle” とは 12 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © 2022 RevComm Inc. ● 先頭で COPY ./ ./ をしない ○ docker build で毎回（≒ソースコードを書き換える度）初めからになってしまう（= キャッシュを活用できない） ○ ビルド過程で必要となる requirements.txt などを先に配置する ○ パッケージマネージャを使用する場合開発利便性 - ビルド時キャッシュを活用する(1/2) 16 ● Pipenv ※以降、Pipenv を使用する前提のサンプルとする ● Poetry

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © 2022 RevComm Inc. “よい Dockerﬁle” とは 19 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © 2022 RevComm Inc. (再掲) “よい Dockerﬁle” とは 21 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 22

Slide 22 text

Copyright © 2022 RevComm Inc. ● 同じ命令は可能な限りまとめるレイヤの数を最小にする > RUN 、 COPY 、 ADD 命令のみレイヤを作成します。他の命令では、一時的な中間イメージ（temporary intermediate images）を作成し、構築時の容量は増えません。 1. RUN 可搬性 / セキュリティ (1/2) - レイヤの数は最小に 22 2. COPY 3. ADD ※COPY が推奨される

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright © 2022 RevComm Inc. (再掲) “よい Dockerﬁle” とは 24 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright © 2022 RevComm Inc. ● ベースイメージ ○ “buster” イメージを使っていませんか？（python:3.x-buster、python:3.x-slim-buster） ○ No！最新は “bullseye” です（= Debian 11.0） ※2022年11月時点 ○ ベースイメージには debian バージョンを指定しなくても良いかも（alias があるので） ■ python:3.10.8 = python:3.10.8-bullseye ■ python:3.10.8-slim = python:3.10.8-slim-bullseye ● パッケージ ○ Docker 公式ドキュメントで「Dockerﬁle の中で apt-get upgrade しないように」と書かれていたのは昔の話 ○ OWASP が提唱して、Docker コミュニティも修正済み ○ Not installing security updates is bad advice by itamarst · Pull Request #614 · OWASP/CheatSheetSeries ○ Stop telling people not to install security updates by itamarst · Pull Request #12571 · docker/docs ○ パッケージは必ず最新化しましょう！ ○ 定期的にイメージを更新しましょう！ベースイメージとパッケージを最新化する 26

Slide 27

Slide 27 text

Copyright © 2022 RevComm Inc. (再掲) “よい Dockerﬁle” とは 27 コンテナイメージにとって重要な性質（抜粋）参考: Dockerﬁle のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント ● ※“コンテナ” 自体の理解 ○ 仮想マシン（VM）と同じ使い方をしない ○ (原則) 1コンテナ1プロセス ● 開発利便性 ○ ビルド時キャッシュを活用する ● 可搬性 / セキュリティ ○ .dockerignore で除外 ○ レイヤの数は最小に ○ ベースイメージとパッケージを最新化する ○ 不要なパッケージをインストールしない

Slide 28

Slide 28 text

Copyright © 2022 RevComm Inc. ● デフォルトのベースイメージには無駄なパッケージが（非常に）多い ⇒slim イメージを使いましょう ● slim イメージには gcc などビルドツール群が含まれないため、Python ライブラリをビルドできない場合がある ⇒マルチステージビルドを使う ○ slim イメージに gcc をインストールするのは可搬性 / セキュリティ (2/2) - 不要なパッケージをインストールしない 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Copyright © 2022 RevComm Inc. ここまでの整理 ● slim イメージを使用する ○ Python ライブラリの準備を “not slim イメージ” で行う (マルチステージビルド) ● 課題 ○ パッケージマネージャー (Pipenv / Poetry) をアプリケーションに含めたくない ○ dev-packages （テスト用ツールなど）を本番用イメージから分離した ■ CI では dev-packages を使いたい可搬性 / セキュリティ (2/2) - 不要なパッケージをインストールしない 30 アプリケーション自体に Pipenv は要らない（普通は）

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © 2022 RevComm Inc. ● 結論可搬性 / セキュリティ (2/2) - 不要なパッケージをインストールしない 34 1. ステージ: export ○ requirements.txt 形式のライブラリ一覧を生成する ○ ⇒後続ステージにて Pipenv 不要となる 2. ステージ: builder / dev-builder ○ requirements.txt を元にライブラリを準備する ○ COPY --from=[stage name] … でステージ間でファイルを受け取る ○ prod 用、dev 用の2通りを用意

Slide 35

Slide 35 text

Copyright © 2022 RevComm Inc. ● 結論可搬性 / セキュリティ (2/2) - 不要なパッケージをインストールしない 35 1. ステージ: export ○ requirements.txt 形式のライブラリ一覧を生成する ○ ⇒後続ステージにて Pipenv 不要となる 2. ステージ: builder / dev-builder ○ requirements.txt を元にライブラリを準備する ○ COPY --from=[stage name] … でステージ間でファイルを受け取る ○ prod 用、dev 用の2通りを用意 3. ステージ: base ○ 最終的なアプリケーション用の環境をセットアップ ○ 必要なパッケージをインストール ○ ※一般ユーザーを作成、スイッチなど（割愛） libpq5: PostgreSQL 接続に必要 libxml2: uWSGI 実行に必要

Slide 36

Slide 36 text

Copyright © 2022 RevComm Inc. ● 結論可搬性 / セキュリティ (2/2) - 不要なパッケージをインストールしない 36 1. ステージ: export ○ requirements.txt 形式のライブラリ一覧を生成する ○ ⇒後続ステージにて Pipenv 不要となる 2. ステージ: builder / dev-builder ○ requirements.txt を元にライブラリを準備する ○ COPY --from=[stage name] … でステージ間でファイルを受け取る ○ prod 用、dev 用の2通りを用意 3. ステージ: base ○ 最終的なアプリケーション用の環境をセットアップ ○ 必要なパッケージをインストール ○ ※一般ユーザーを作成、スイッチなど（割愛） 4. ステージ: dev / prod ○ Python ライブラリをインストール ○ ソースコードを配置 ○ ※dev / prod で CMD を分ける、など適宜 ○ docker build --target [stage-name] .... でビルド対象ステージを指定する

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Copyright © 2022 RevComm Inc. ● 開発利便性と軽量性/セキュリティは両立できる（相反する性質ではない） ● なるべく slim イメージを使用しましょう ● マルチステージビルドを活用することで「アプリケーションに必要十分な環境」が作りやすくなる ○ 開発 / 本番用イメージを同一 Dockerfile で管理できる（DRY 原則を保てる） ※必要に応じて Dockerfile を分離して可読性を維持する（要はバランス）リンク ● サンプルコード: GitHub revcomm/public-slide-docker-multistage-build-for-python ○ dev コンテナ: ユニットテスト実行 ○ prod コンテナ:アプリケーション起動、動作確認 ● 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ ● 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog まとめ 42

Slide 43

Slide 43 text