最初の Docker GitHub アクションがここにあります!

本日、Dockerが最初のGithubアクションをリリースしたことをお知らせできることを嬉しく思います。 私たちはGitHubと協力して、開発者がDockerで GitHub アクションを使用してCI / CDワークフローをどのように設定しているかを調査してきました。 見回すとわかる標準的なフローは、イメージの構築、タグ付け、Hub へのログイン、イメージのプッシュなど、期待どおりのものです。 これは、Docker のビルド/プッシュ アクションでサポートすることを目的としたワークフローです。

CI/CD ワークフローの簡素化

Docker では従来、CI/CD ワークフローの多くは Jenkins を通じて処理され、さまざまな製品を使用してセットアップと保守を行ってきました。 いくつかの点では、これは、さまざまな異なるホストや構成でDockerデスクトップをテストする場合のように、最良のソリューションです。 他の人にとっては、それは少しやり過ぎです。 多くの人と同様に、私たちDockerでも、Docker自体の使用方法を含め、 GitHubアクションを活用してワークフローを簡素化する方法を検討してきました。

GitHub Actions は、すでに多くのワークフローで Docker を活用しています。 クラウドランナーにDockerをプレインストールして構成することから、コンテナ化されたアクションをファーストクラスでサポートすることまで、開発者はローカルで使用するのと同じDockerワークフローを簡単に使用してリポジトリのCI/CDを構成できます。 マルチステージビルドと組み合わせることで、強力な環境を使用できます。 

ドッカーアクション

Githubアクションを開始したとき、メインビルド、タグ、プッシュフローを処理する組み込みアクションがなかったため、まだローカルで実行できないyamlファイルになり、bashコマンドでいっぱいになりました。 実際、GitHub内から「Docker公開」ワークフローテンプレートを選択した場合、それはまさにあなたが与えられるものです。 確かに実行可能ですが、事前に構築されたアクションを使用するだけのスクリプトほど読みやすく、保守するのは簡単ではありません。 これが、コミュニティがまさにそれを行うための多くのアクションをすでに公開している理由である可能性があります。 GitHub Marketplace にアクセスして、Docker アクションを検索するだけです。

標準のビルド/タグ/プッシュ以外にもよく見られるのは、ビルド元のブランチに基づくイメージの自動タグ付けのサポート、プライベートレジストリへのログイン、Dockerfile パスなどの標準 CLI 引数の設定です。

これらのいくつかを検討した結果、これらのアイデアから 独自のアクションを構築し 、公式のDockerがGitHub Actionsをサポートしているため、コミュニティに公開することにしました。 これらの最初の もの、docker / build-push-actionは、上記の内容の多くをサポートし、次のようなベストプラクティスと見なされるものを使用してイメージをビルドおよびプッシュしようとします。

• git 参照 (ブランチ、タグ、および PR) に基づくタグ付け。
• git SHA でタグ付けして、より複雑な CI/CD フローの後の段階でイメージを簡単に取得できるようにします。たとえば、大規模なセルフホステッド クラスターでエンドツーエンドのテストを実行する必要がある場合などです。
• GitHub Actions 環境から取得したデータを使用して、 Open Container Initiative ラベルでイメージに ラベルを付ける 。
• ビルド時の 引数 と複数ステージ のターゲットのサポート。
• GitHub Actions によって提供されるデータと独自のスクリプトに応じて、イメージをビルドするタイミングと実際にプッシュするタイミングを設定できるプッシュフィルター。私たちが自分で使用する ものの例 を参照してください。

シングルアクションアプローチ

しかし、なぜ多くの小さなアクションではなく、1つの大きなアクションなのでしょうか。 GitHubとの議論で浮かび上がったことの1つは、ユーザーが多くの小さなアクションを作成し、入力と出力を使用してそれらを連鎖させることをどのように想定していたかということですが、現実は逆のようです。 私たちが見てきたことから、ユーザーは大きなアクションを作成し、構成の詳細の入力を使用してフローを内部的に処理しています。

独自のアクションを開発している間、ワークフロースクリプトをローカルで実行する方法が現在ないため、その方法でテストする方が簡単であるため、同じ方法で進んでいることに気づきました。

またこれ:

‐ name: build
  id: build
  uses: docker/build-action@v1
  with:
    repository: myorg/myrepo
    tags: v1
‐ name: login
  uses: docker/login-action@v1
  with:
    registry: myregistry
    username: ${{ DOCKER_USERNAME }}
    password: ${{ DOCKER_PASSWORD }}
‐ name: push
  uses: docker/push-action@v1
  with:
    registry: myregistry
    tags: ${{ outputs.build.tags }}

書くのはもう少し手間がかかります:

‐ name: build-push
  uses: docker/build-push-action@v1
  with:
    username: ${{ DOCKER_USERNAME }}
    password: ${{ DOCKER_PASSWORD }}
    registry: myregistry
    repository: myorg/myrepo
    tags: v1

シングルアクションアプローチを採用した最後の理由は、個別のステップがどのようにリンクされ、いつスキップする必要があるかというロジックが、純粋にいくつかの入力に基づいてバックエンドで簡単に処理できるためです。 ユーザー名とパスワードが設定されていますか? 次に、ログインを行います。 プッシュする必要がありますか? 次に、イメージをビルドしたタグでプッシュします。 レジストリが設定されていますか? 次に、そのレジストリにログインし、そのレジストリでイメージにタグを付けて、デフォルトで Docker Hub を使用するのではなく、そのレジストリにプッシュします。

フィードバックは大歓迎です!

これらはすべて、アクションを裏付ける イメージ によって処理されます。 バックエンドは、Docker CLIにシェルアウトする単純なgoプログラムであり、そのコードは ここ にあり、アクション自体を使用してビルドおよびプッシュされます。 いつものように、 フィードバックと貢献はいつでも大歓迎です。

Docker Githubアクションを試してみたい場合は、 こちら で見つけるか、Githubアクションを使用したことがない場合は、Githubを開始するためのガイドを見つけることができます 詳細を見る. Dockerから間もなく提供されるその他のニュースについては、公開ロードマップをご覧ください。