ドッキングコンテナの構築と導入時間の最適化プロセス

入社初期は社内CI/CDパイプラインでも7~8分で書類を作成.社内のパイプラインはメインブランチにPRを残しておくと自動的にステージ環境に配置されるので、7~8分はかなりかかると思います.ちょうどZenhubホットスポットにもファイル構築時間最適化タスクがあり、解決したいと思っています.

ドックファイル分析

私たちが定義したドッキングステーションファイルは2つあります.1つはバックグラウンドサーバで、1つはマシンランニングマシンです.バックエンドサーバは、python venvとpipenvで依存性を設定するファイルを表示することもできます.また,マシンラーニングキットのドッキングファイルを表示することで,マシンラーニングデータ処理に関連する様々な依存性を決定できる.
では、どのようにして構築時間を最適化しますか?dockerファイルの構築と導入の時間を最適化する3つの方法を試みた.

Hadolintのドッキングイメージを使ってダイエット

ベストプラクティスは、ドッキングイメージを構築するために正式な書類に存在します.公式ファイルのbestfiltureに従うのもいいですが、私のファイルはbestfiltureに従って静的分析ができることを望んでいます(Pylinutのように...).彼について調べてみるとHadolintがあった.Hadolint DockerfileをASTでグループ化した後、ベストプラクティスを遵守するかどうかを分析した.
hadolintにより、次の画像が改善されました.

Run commandを組み合わせることで

層を減らす

pip install-no-cache-dirオプションを追加すると、イメージ容量が

減少します.

apt-getインストールを使用する依存項目について、apt-list

を削除します.

-no-install-推奨*推奨パッケージまたは推奨パッケージをインストールしないことで、イメージ層の容量を削減します.

このように構築すると,レイヤ数が減少し,Docker画像ファイルの容量がやや減少する.構築と導入の時間は短縮されましたが、希望するほどではありません.

はマルチステーションバージョンを導入しました.=>適用失敗

ドッキング・ファイルでは、2つのコンストラクション・イメージをコンパイル・イメージとコンストラクション・イメージに分割し、コンパイル・イメージの結果をベース・コンストラクション・イメージに構築するモードをマルチレベル・コンストラクションと呼びます.イメージをコンパイルする過程で、実際の運用に不利なデータを削除し、イメージ容量を減らすことができるという.
この部分は進行中にbuild-imageがvenvの認識を継続できない場合がある.Pythonでマルチステージ構築を導入するのは想像していたほど容易ではない.私は根本的な問題を提起した.今ではネットワークも速いですが、大きなファイルの容量を減らすことが重要ですか?問題は構築速度が遅いのではないでしょうか.という考えが生まれた.
実際,CIパイプラインから見ると,ドッキングステーションファイルを構築する速度自体が非常に遅く,GCRにプッシュする時間が比較的速い.そこで,構築速度を改善する方法を見つけた.

Docker Buildキャッシュ

を使用
ドッキング速度を向上させるために、検索中にドッキングキャッシュの概念を理解しました.ドッキングイメージでは、既存のイメージに追加ファイルが必要な場合に再ダウンロードするのではなく、ファイルを追加するために蓄積された概念です.
ドッキングファイルを最初に構築するときにレイヤがスタックされた場合、レイヤはキャッシュされます.
キャッシュされたレイヤを使用できるようにするには、ドッキングファイルを構成することが重要です.
既存のドッキングファイルを表示します.

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

WORKDIR /app

COPY . /app

# Install Python packages
RUN pip install --upgrade pip && pip install pipenv
RUN pipenv sync

Pythonプロジェクトのすべてのソースコードを一度にコピーします.コピー後pipenvでパッケージをインストールします.
しかし、Pythonプロジェクトのソースコードは開発者が作業するときに変化するため、1つのレイヤに構築キャッシュを書き込むことができません.
そこで、以下のように改善されました.

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

COPY ./Pipfile.lock /
WORKDIR /

# Install Python packages
RUN pip install --no-cache-dir --upgrade pip && pip install --no-cache-dir pipenv && pipenv sync

WORKDIR /app
COPY . /app

CMD python manage.py collectstatic --no-input && gunicorn -b :$PORT base.wsgi --workers=5 --timeout=90

Pipfile.まずlockファイルをコピーし、pip installを実行します.Pipfile、パッケージ依存ファイル.lockファイルは開発中によく変化する部分ではありません.従って層を分離した.これにより、キャッシュの構築を有効にし、インストール依存性を解消できます.
ローカルコンストラクションでは、最初のコンストラクションに時間がかかったとしても、ソースコードを少し変更して再構築すると、イメージを構築する時間が大幅に減少します.
ローカルコンピュータではもちろんコンストラクションキャッシュを使用できますが、社内のCI/CDシステムでも使用できます.CI/CDパイプラインはこのサプライヤーが提供する機械によって構築されるからです.
Circle CIを使用しています.https://circleci.com/docs/2.0/docker-layer-caching/ドキュメントには、次の図に示すようにdocker layer cachingオプションがtrueの場合、構築時にレイヤキャッシュを使用できます.

version: 2
jobs:
  build:
    docker:
      # DLC does nothing here, its caching depends on commonality of the image layers.
      - image: circleci/node:14.17.3-buster-browsers
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      # DLC will explicitly cache layers here and try to avoid rebuilding.
      - run: docker build .

実際のアプリケーションでは、Dockerファイルの構築と導入に7~8分かかる時間が1~2分減りました!

このような時間で十分だと思います.他にも解決しなければならない問題がたくさんあるので、この問題は上記の2つの方法で解決します.
しかし、残念ながらMulti-stageバージョンは導入されていません.Technical deptとして保存し、特徴があまり忙しくないときに確認する必要があります.