👨🏿‍✈️ ☺️ 🤜 Pythonプロジェクトでの作業の自動化 ❄️ ◻️ 👩‍👧‍👦

本日、Makefileを使用してPythonプロジェクト用にすばやくアセンブルされ簡単にデバッグできるDockerイメージのビルドを自動化する、IBMDevOpsエンジニアによる記事の翻訳を共有します。このプロジェクトは、Dockerでのデバッグを容易にするだけでなく、プロジェクトコードの品質も管理します。いつものように、詳細はカットの下にあります。

データサイエンスまたはAIを使用してWebアプリケーションで作業している場合でも、すべてのプロジェクトは、適切に調整されたCI / CD、開発中に同時にデバッグされ、実稼働環境用に最適化されたDockerイメージ、または品質保証ツールの恩恵を受けることができます。CodeClimateやSonarCloudなどのコード。これらすべてがこの記事でカバーされ、Pythonプロジェクトにどのように追加されるかが示されています。

開発用のデバッグ可能なコンテナ

コンテナのデバッグが難しい場合や、イメージの構築に時間がかかるため、Dockerを 嫌う人もいます。それでは、開発に理想的なイメージを構築することから始めましょう-構築が速く、デバッグが簡単です。イメージを簡単にデバッグするには、デバッグが必要になる可能性のあるすべてのツールを含むベースイメージが必要です。これらは、bash、vim、netcat、wget、cat、find、grepなどです。Python

イメージ：3.8.1-バスターこのタスクの完璧な候補のようです。箱から出してすぐに使える多くのツールが含まれており、不足しているツールを簡単にインストールできます。画像は大きいですが、ここでは関係ありません。開発でのみ使用されます。お気づきかもしれませんが、画像は非常に具体的です。PythonとDebianのバージョンをロックすることは意図的なものです。つまり、互換性のない可能性のある新しいバージョンのPythonまたはDebianによって引き起こされる破損のリスクを最小限に抑える必要があります。アンAlpine-ベースの画像は、代替として可能であるが、それはいくつかの問題を引き起こす可能性があります：それは使用しています内側MUSL libの代わりにはglibcをPythonが依存している。アルパインを選択する場合は、このことに注意してください。速度に関しては、マルチステージビルドを使用して、できるだけ多くのレイヤーをキャッシュします。そのため、gccなどの依存関係とツール、およびアプリケーションに必要なすべての依存関係が、requirements.txtから毎回ロードされるわけではありません。さらに高速化するために、前述のpython：3.8.1-busterからカスタムベースイメージが作成されますrunner。これらのツールをダウンロードして最終イメージにインストールするために必要な手順をキャッシュできないため、必要なものがすべて揃っています。しかし、話をやめて、Dockerfileを見てみましょう。

# dev.Dockerfile
FROM python:3.8.1-buster AS builder
RUN apt-get update && apt-get install -y --no-install-recommends --yes python3-venv gcc libpython3-dev && \
    python3 -m venv /venv && \
    /venv/bin/pip install --upgrade pip

FROM builder AS builder-venv

COPY requirements.txt /requirements.txt
RUN /venv/bin/pip install -r /requirements.txt

FROM builder-venv AS tester

COPY . /app
WORKDIR /app
RUN /venv/bin/pytest

FROM martinheinz/python-3.8.1-buster-tools:latest AS runner
COPY --from=tester /venv /venv
COPY --from=tester /app /app

WORKDIR /app

ENTRYPOINT ["/venv/bin/python3", "-m", "blueprint"]
USER 1001

LABEL name={NAME}
LABEL version={VERSION}

上記では、最終的なrunner画像を作成する前に、コードが3つの中間画像を通過することがわかります。 1つ目はビルダーです。 gccやPython仮想環境など、アプリケーションの構築に必要なすべてのライブラリをダウンロードします。インストール後、実際の仮想環境が作成され、次の画像で使用されます。次はbuilder-vvです。これは、依存関係のリスト（requirements.txt）をイメージにコピーしてから、それらをインストールします。この中間イメージはキャッシュに必要です。requirements.txtが変更された場合にのみライブラリをインストールします。それ以外の場合は、キャッシュを使用します。最終的な画像を作成する前に、アプリケーションをテストしてみましょう。

最終的なイメージを作成する前に、まずアプリケーションのテストを実行しましょう。ソースコードをコピーして、テストを実行します。テストに合格したら、ランナー画像に移動します。これは、通常のDebianイメージにはないいくつかの追加ツールvimとnetcatを備えたカスタムイメージを使用します。この画像は、上にあるドッカーハブ、あなたはまた、非常にシンプルなDockerfileで見ることができbase.Dockerfile。したがって、この最終イメージで行うこと：最初に、テスターイメージからインストールしたすべての依存関係が保存されている仮想環境をコピーします。、次にテストしたアプリケーションをコピーします。すべてのソースがイメージに含まれているので、アプリケーションが配置されているディレクトリに移動し、ENTRYPOINTをインストールして、イメージの起動時にアプリケーションが起動されるようにします。セキュリティ上の理由から、USERは1001に設定されています。ベストプラクティスでは、コンテナをrootとして実行しないことをお勧めします。最後の2行は、画像ラベルを設定します。それらは、ターゲットを介して構築するときに置き換えられmakeます。これについては、少し後で説明します。

実稼働環境向けに最適化されたコンテナ

プロダクショングレードの外観に関しては、小さく、安全で、高速であることを確認する必要があります。この意味での私の個人的なお気に入りは、DistrolessプロジェクトのPythonイメージです。しかし、「Distroless」とは何ですか？このように言いましょう。理想的な世界では、誰もがFROMスクラッチをベースとして使用して独自の画像（つまり、空の画像）を作成します。しかし、バイナリなどを静的にリンクする必要があるため、ほとんどの人が望んでいることではありません。そこでDistrolessが登場します。それは誰にとってもFROMスクラッチです。そして今、私は本当に「Distroless」が何であるかをあなたに話します。これはGoogleによって作成されたセットですアプリケーションに必要な絶対最小値を含む画像。これは、イメージを膨らませてセキュリティスキャナー（CVEなど）の信号ノイズを生成するラッパー、パッケージマネージャー、またはその他のツールがないことを意味し、コンプライアンスの確立を困難にします。何を扱っているかがわかったので、本番のDockerfileを見てみましょう。実際、コードをあまり変更する必要はなく、2行だけ変更する必要があります。


# prod.Dockerfile
#  1. Line - Change builder image
FROM debian:buster-slim AS builder
#  ...
#  17. Line - Switch to Distroless image
FROM gcr.io/distroless/python3-debian10 AS runner
#  ... Rest of the Dockefile

変更する必要があるのは、アプリをビルドして実行するためのベースイメージだけでした。しかし、その違いはかなり大きいです。開発イメージの重量は1.03 GBで、これはわずか103 MBでした。これは、大きな違いです。そして、私はすでにあなたの言うことを聞くことができます：「アルピナはさらに軽くすることができます！」 ..。はい、そうですが、サイズはそれほど重要ではありません。ロード/アンロード時に画像のサイズに気付くだけで、それほど頻繁には発生しません。画像が機能する場合、サイズは関係ありません。どのような大きさよりも重要なのはセキュリティであり、この点でDistrolessは間違いなくアルパインに優れている：アルパインは攻撃面を高めるために多くの追加のパッケージを持っています。Distrolessについて話すときに言及する価値のある最後のことは、画像のデバッグです。それを考慮してDistrolessにはシェルが含まれておらず（「sh」も含まれていません）、デバッグと調査は非常に困難になります。このために、すべてのDistrolessイメージの「デバッグ」バージョンがあります。そうすれば、問題が発生したときに、タグdebugを使用して作業イメージを作成し、通常のイメージと一緒にデプロイし、デバッグイメージで必要な処理を実行して、たとえばストリームダンプを実行できます。次のように、python3イメージのデバッグバージョンを使用することができます。

docker run --entrypoint=sh -ti gcr.io/distroless/python3-debian10:debug

すべてのための1つのチーム

すべてのDockerfileの準備ができたら、Makefileを使用してこの悪夢全体を自動化できます。最初に実行したいのは、Dockerを使用してアプリケーションをビルドすることです。したがって、開発イメージを構築するために、make build-dev次のコードを実行するものを記述します。


# The binary to build (just the basename).
MODULE := blueprint

# Where to push the docker image.
REGISTRY ?= docker.pkg.github.com/martinheinz/python-project-blueprint

IMAGE := $(REGISTRY)/$(MODULE)

# This version-strategy uses git tags to set the version string
TAG := $(shell git describe --tags --always --dirty)

build-dev:
 @echo "\n${BLUE}Building Development image with labels:\n"
 @echo "name: $(MODULE)"
 @echo "version: $(TAG)${NC}\n"
 @sed                                 \
     -e 's|{NAME}|$(MODULE)|g'        \
     -e 's|{VERSION}|$(TAG)|g'        \
     dev.Dockerfile | docker build -t $(IMAGE):$(TAG) -f- .

このターゲットは、最初に下部のラベルをdev.Dockerfile画像の名前と起動によって作成されたタグに置き換えることによって画像を作成しgit describe、次に起動しdocker buildます。次に、以下を使用して実稼働環境用にビルドしますmake build-prod VERSION=1.0.0。


build-prod:
 @echo "\n${BLUE}Building Production image with labels:\n"
 @echo "name: $(MODULE)"
 @echo "version: $(VERSION)${NC}\n"
 @sed                                     \
     -e 's|{NAME}|$(MODULE)|g'            \
     -e 's|{VERSION}|$(VERSION)|g'        \
     prod.Dockerfile | docker build -t $(IMAGE):$(VERSION) -f- .

このターゲットは前のターゲットと非常に似ていますが、バージョンとしてgitタグを使用する代わりに、引数として渡されたバージョンが使用されます。上記の例では、1.0.0です。すべてがで実行されている場合ドッカー、いくつかの時点で、あなたはまた、デバッグすべてに必要ドッカー。これには目標があります。


# Example: make shell CMD="-c 'date > datefile'"
shell: build-dev
 @echo "\n${BLUE}Launching a shell in the containerized build environment...${NC}\n"
  @docker run                                                     \
   -ti                                                     \
   --rm                                                    \
   --entrypoint /bin/bash                                  \
   -u $$(id -u):$$(id -g)                                  \
   $(IMAGE):$(TAG)             \
   $(CMD)

上記のコードでは、エントリポイントがbashによってオーバーライドされ、containerコマンドがCMDの引数によってオーバーライドされていることがわかります。したがって、コンテナに移動して移動するか、上記の例のように何らかのコマンドを実行することができます。プログラミングとDockerレジストリへのイメージのプッシュが完了したら、を使用できますmake push VERSION=0.0.2。この目標が何をするか見てみましょう：


REGISTRY ?= docker.pkg.github.com/martinheinz/python-project-blueprint

push: build-prod
 @echo "\n${BLUE}Pushing image to GitHub Docker Registry...${NC}\n"
 @docker push $(IMAGE):$(VERSION)

最初に前述のターゲットを起動し、build-prod次に単純に起動しdocker pushます。これは、Dockerレジストリにログインしていることを前提としているため、を実行する前にこのターゲットを実行する必要がありますdocker login。最終的な目標は、Dockerアーティファクトをクリーンアップすることです。これは、Dockerイメージビルドファイル内で置き換えられたnameタグを使用して、削除する必要のあるアーティファクトをフィルタリングおよび検索します。


docker-clean:
 @docker system prune -f --filter "label=name=$(MODULE)"

すべてのMakefileコードはリポジトリにあります。

GitHubアクションを含むCI / CD

このプロジェクトでは、make、Github Actions、およびGithubパッケージレジストリを使用してパイプライン（タスク）を構築し、イメージを保存してCI / CDを構成します。しかし、それは何ですか？

GitHubアクションは、開発ワークフローの自動化に役立つタスク/パイプラインです。それらを使用して個別のタスクを作成し、それらを組み合わせてカスタムワークフローにすることができます。カスタムワークフローは、たとえば、リポジトリにデータを送信するたびに、またはリリースを作成するときに実行されます。
Github Package Registryは、 GitHubと完全に統合されたパッケージホスティングサービスです。Ruby gemやnpmパッケージなど、さまざまなタイプのパッケージを保存できます。プロジェクトはこれを使用してDockerイメージを保存します。Githubパッケージレジストリの詳細については、こちらをご覧ください。

GitHubアクション を使用するには、選択したトリガーに基づいてプロジェクトにワークフローを作成します（トリガーの例はリポジトリへの送信です）。これらのワークフローは、ディレクトリ内のYAMLファイルです.github/workflows。


.github
└── workflows
    ├── build-test.yml
    └── push.yml

build-test.ymlファイルには、コードがリポジトリに送信されるたびに実行される2つのジョブが含まれています。これらのジョブを以下に示します。


jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Run Makefile build for Development
      run: make build-dev

ビルドと呼ばれる最初のタスクは、ターゲットを実行してアプリケーションをビルドできることを確認しますmake build-dev。ただし、開始する前に、checkoutGitHubに公開されたリポジトリを実行してリポジトリをチェックします。


jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-python@v1
      with:
        python-version: '3.8'
    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run Makefile test
      run: make test
    - name: Install Linters
      run: |
        pip install pylint
        pip install flake8
        pip install bandit
    - name: Run Linters
      run: make lint

2番目のタスクはもう少し難しいです。アプリケーションの隣でテストを実行し、3つのコード品質管理リンター（コード品質コントローラー）を実行します。前のタスクと同様に、アクションを使用してソースコードを取得しますcheckout@v1。その後setup-python@v1、python環境をセットアップする、と呼ばれる別の公開されたアクションが起動されます（詳細はこちら）。 Python環境ができたので、requirements.txtpipを使用してインストールするアプリケーションの依存関係が必要です。この時点make testで、ターゲットの実行を開始しましょう。ターゲットはPytestテストスイートを実行します。キットのテストに合格した場合は、前述のリンター（pylint、flake8、bandit）のインストールに進みます。最後に、ターゲットを起動しますmake lint次に、これらの各リンターを起動します。ビルド/テストジョブがすべてですが、コードを送信するのはどうですか？彼女について話しましょう：


on:
  push:
    tags:
    - '*'

jobs:
  push:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Set env
      run: echo ::set-env name=RELEASE_VERSION::$(echo ${GITHUB_REF:10})
    - name: Log into Registry
      run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login docker.pkg.github.com -u ${{ github.actor }} --password-stdin
    - name: Push to GitHub Package Registry
      run: make push VERSION=${{ env.RELEASE_VERSION }}

最初の4行は、ジョブの開始時間を定義します。このタスクは、タグがリポジトリに移動されたときにのみトリガーされる必要があることを示します（*は名前のパターンを示し、ここではすべてタグです）。これは、データをリポジトリにプッシュするたびにDockerイメージをGitHubパッケージレジストリにプッシュしないようにするためですが、アプリケーションの新しいバージョンを示すタグがアップロードされた場合にのみ行われます。ここで、このタスクの本体について説明します。まず、ソースコードを確認し、RELEASE_VERSION環境変数の値をgitアップロードタグと同じに設定します。これは、組み込みのGitHubアクション関数:: setenvを使用して実行されます（詳細はこちら）。次に、タスクは、リポジトリに格納されているシークレットREGISTRY_TOKENと、ワークフローを開始したユーザー（github.actor）のログインを使用してDockerレジストリに入ります。最後に、最後の行でプッシュターゲットが実行されます。プッシュターゲットは、本番イメージをビルドし、以前に投稿されたgitタグをイメージタグとしてレジストリにプッシュします。リポジトリファイル内のすべてのコードを確認してください。

CodeClimateによるコード品質チェック

最後になりましたが、CodeClimateとSonarCloudを使用してコード品質チェックを追加しましょう。これらは、上記のテストタスクと連携して機能します。コードを数行追加します。


# test, lint...
- name: Send report to CodeClimate
  run: |
    export GIT_BRANCH="${GITHUB_REF/refs\/heads\//}"
    curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter
    chmod +x ./cc-test-reporter
    ./cc-test-reporter format-coverage -t coverage.py coverage.xml
    ./cc-test-reporter upload-coverage -r "${{ secrets.CC_TEST_REPORTER_ID }}"

- name: SonarCloud scanner
  uses: sonarsource/sonarcloud-github-action@master
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

始まるCodeClimate：変数のエクスポートGIT_BRANCH環境変数を使用して取得しますGITHUB_REF。次に、CodeClimateテストレポートツールをダウンロードして実行可能にします。次に、それを使用してテストスイートカバレッジレポートをフォーマットします。最後の行では、リポジトリのシークレットに保存されているテストレポート用のツールのIDを使用してCodeClimateに送信します。SonarCloud、あなたが作成する必要がありますsonar-project.properties。このファイルの値は、右下隅のSonarCloudダッシュボードにあり、このファイルは次のようになります。


sonar.organization=martinheinz-github
sonar.projectKey=MartinHeinz_python-project-blueprint

sonar.sources=blueprint

また、私たちのために仕事をしているものを簡単に使用することも可能sonarcloud-github-actionです。GitHubの、デフォルトのリポジトリ内の1つのために、とのために：私たちはしなければならないすべては、2つのトークンを提供SonarCloud、我々はから得た1 SonarCloudのウェブサイトを。注：言及されているすべてのトークンとシークレットを取得してインストールする手順は、リポジトリのREADMEに記載されています。

結論

それで全部です！ツール、構成、およびコードを使用して、次のPythonプロジェクトのあらゆる側面をカスタマイズおよび自動化する準備が整いました。この記事に示されている、または説明されているトピックに関する詳細情報が必要な場合は、リポジトリ内のドキュメントとコードを確認してください。提案や問題がある場合は、リポジトリにリクエストを送信するか、この小さなプロジェクトにスターを付けてください。お気に入り。

また、HABRプロモーションコードを使用すると、バナーに示されている割引にさらに10％を追加できます。

その他のコース

Pythonプロジェクトでの作業の自動化

開発用のデバッグ可能なコンテナ

実稼働環境向けに最適化されたコンテナ

すべてのための1つのチーム

GitHubアクションを含むCI / CD

CodeClimateによるコード品質チェック

結論

おすすめ記事

More articles: