CI/CD での Docker の使用

写し

こんにちは、Docker と CI/CD の使用に関するこの技術トーク セッションへようこそ。 DockerとCI/CDについて簡単に紹介すると、Dockerは、一貫した環境でアプリケーションを開発、出荷、実行するためのプラットフォームです。 つまり、ラップトップ、サーバー、クラウドなど、あらゆる場所でプロジェクトを実行できます。 CI/CD は、継続的インテグレーションと継続的デリバリーとデプロイです。 これは、すべてを自動化するための一連のプラクティスです。 たとえば、コードを更新し、コミットしてプッシュすると、ビルドとテストはデプロイでも自動的に行われます。

目次

• CI/CDでDockerを使用する理由 (0:41) (0:21)
• 開発ワークフロー&CI/CD (1:08)
• パイプラインの改善 (3:55)
• Docker ComposeによるDXの改善 (7:14)
• 成果物を効率化する (8:32)
• CI/CD からのイメージの構築 (10:52)
• CIを支援する (11:12)
• さらに詳しく

CI/CDでDockerを使用する理由 (0:41)

私は、プロジェクトはどこでも実行できると言いました。 それを停止し、不具合で再起動し、それを1日に100回行うことができます。 したがって、CI/CDシステムでも同じことができます。 さらに、CI/CD パイプラインの各ステップで実行中の環境を簡単に再現できる保証を追加します。 また、自動化により、テスト、再試行、再テスト、再テスト、再テスト、および再テストのリタイアを簡単に行うことができます。 しかし、その前に、開発ワークフローを見てみましょう。

開発ワークフロー&CI/CD (1:08)

これは、開発ワークフローの一例です。 私はそれを機能フローと呼び、他の人はそれをGitLabフローと呼んでいます。 GitLab、GitLab、Bitbucketなどで動作します。 メインブランチはプロダクションブランチです。 開発者は、機能や修正を行うときに、メイン ブランチから機能ブランチを作成します。 プルリクエストのすべてのコミットと更新を追加するか、GitHubを使用している場合はリクエストをマージします。 CIは、高品質の組み込みセキュリティチップのバッチでトリガーされます。 そして最後に、メインブランチにマウントすると、CIが再度トリガーされます。たとえば、アプリケーションをパッケージ化してデプロイします。 コミットすると、CI パイプラインはすべてのステップで環境をブートストラップする必要があります。 マージする場合、CI は運用前環境と運用環境をブートストラップする必要があります。 そして、これらすべての環境での違いを避ける必要があります。 また、多くの場合、CI/CD プラットフォームやソース システムによっては、複雑で非常に長くなります。 すべてを同期させるのは大変なことです。 フィードバックループは非常に難しく、非常に複雑で、開発者のエクスペリエンスはひどいものになる可能性があります。

これは、GitLab CIの簡単なリマインダーです。 GitLab CIは、GitLabのCI/CD機能の名前で、JenkinsやGitHub Actionのようなものです。 GitLabランナーは、ワークフローを実行するサーバーです。 ランナーは、ローカル、サーバー、Kubernetes など、どこにでもインストールできます。 操作はとても簡単です。 開発者は、変更をコミットしてGitLabインスタンスにプッシュします。 ランナーは GitLab インスタンスをポーリングしています。 ランナーは、何かやるべきことを検出すると、プロジェクトを Git クローンします。 次に、ランナーは.gitlab-ci.ymlファイルに記述されているコマンドを実行します。このファイルはリポジトリにあります。 そして、ランナーはフィードバックをGitLabインスタンスに送信します。

パイプラインのすべてのジョブは、エグゼキューターによって実行されます。 これは、ランナーにインストールされているgolangプログラムです。 エグゼキューターは、ベアメタルプラットフォーム、VM、およびコンテナ上でジョブのコマンドを実行できます。 このリストには、同じステージに属する 2 つのジョブがあります。 これら 2 つのジョブの両方について、Ubuntu イメージを使用し、すべてのコマンドを Ubuntu コンテナーで実行することをエグゼキューターに伝えています。 そして、必要なものをインストールできます。

では、覚えておくべき重要なことは何ですか? パイプライン ジョブはコンテナで実行できます。 各ジョブでは、異なるイメージを使用できます。 そして、すべてのジョブにすべての依存関係を備えた、すぐに使用できる環境を簡単に提供できます。 そしてもちろん、テストを容易にします。

パイプラインの改善 (3:55)

それでは、DockerがCIの改善にどのように役立つかを見てみましょう。 お仕事に必要な画像をお選びいただけます。 また、すべてのジョブのオペレーティングシステムを完全に制御できます。 最新のタグを使用するのは良くないことを忘れないでください。 この例では、基本イメージから開始します。 たとえば、Ubuntuです。 しかし、時には、必要なすべてのツールを画像に提供してみるのも面白いかもしれません。 この例では、goとnode jsがすでにインストールされている個人用イメージの1つを使用しています。 その後、これらのツールをインストールする必要はありません。 これらはすでにイメージにインストールされています。 そして、パイプラインを合理化し、スムーズにし、加速します。 また、全員が同じツールを使用していることが保証されます。 同じバージョンで、同じ動作をします。 すべてのツールがプリインストールされたすぐに使用できるイメージを使用して、パイプラインを高速化します。

私の例では、ツールイメージを使用する前は、所要時間は約 2 分 30 秒でした。 さて、私のツールのイメージで、私はちょうど1分に移りました。 しかし、画像を作成しているときは、私よりも賢くなることができます。 また、すべてを実行できる巨大な汎用イメージは使用しないでください。 すべてのジョブに関連するベースの画像を選択し、小さい画像を選択します。 この例では、すべてのジョブに対して、特定のコンテキスト専用の画像を選択しました。 これらのイメージには、必要なバイナリと依存関係のみが埋め込まれていることを私は知っています。 したがって、これらの画像は最適化され、より軽量になります。 したがって、パイプラインを加速します。 また、ジョブや画像を他のパイプラインに再利用しやすくなります。 今回は、適当な画像で、 40 秒に移りました。 ジョブを頻繁に実行すると、違いが生じます。

あなたはもっとうまくやることができます。 小さいgolang画像を選択すると、画像のプールが速くなります。 というわけで、今回は 30 秒に移りました。 また、より小さな画像で攻撃対象領域を縮小することで、画像のセキュリティを向上させました。 したがって、これらのベストプラクティスを念頭に置き、その経験で独自のベストプラクティスを作成してください。 小さなイメージを使用またはビルドします。 これにより、ロード時間が短縮されます。 Image Deep Diveの技術トークプレゼンテーションのトピックです。マルチステージ ビルド手法を使用すると、より小さなイメージが生成され、デプロイが容易になります。 イメージをバージョン管理し、バージョン管理されたイメージを使用して一貫性を維持し、予期しない事態を避けることを忘れないでください。

CI/CD で Docker を使用すると、いくつかのメリットが得られます。 移植性、新しい環境でCIを移動する必要がある場合、またはCIシステムを変更する必要がある場合でも、痛みは少なくなります。 孤立すると、副作用を回避できます。 効率、あなたはより少ないエネルギーで同じタスクを実行します。 スケーラビリティ、チェーンにコンポーネントを追加する必要がある場合、それはより簡単で管理しやすくなります。 そしてもちろん、セキュリティも。

Docker ComposeによるDXの改善 (7:14)

そして、これをさらに支援するために、優れたDocker機能であるDockerComposeがあります。 たとえば、私はComposeプロジェクトに取り組んでおり、アプリケーションサーバーとしてNodeJSを使用し、データベースとしてPOSTGRESQLを使用しています。 Docker Composeを使用すると、オンデマンドでブートストラップを行うため、この種のプロジェクトは非常に簡単です。 必要なのは、1 つのシンプルな Compose ファイルだけです。 また、GitLab CIやその他のCI/CDシステムとの併用も非常に簡単です。 ジョブの Docker ツールで Docker イメージを使用できます。 もちろん、互換性の問題を回避するために、画像の特定のバージョンをピン留めします。 ジョブ スクリプトで Docker を使用するには、Docker DND サービス Docker を Docker に含める必要があります。 そして今、あなたはパイプラインの複雑な配管を忘れることができます。 このソリューションは、複数のコンテナの管理とそれらの相互作用をGitLab CIパイプラインに効率化します。 この例では、アプリケーションの単体テストを実行します。 また、適切なアーティファクトを生成した場合は、ランナーの出力やGitLabのテストレポートを使用してテスト結果を追跡できます。

成果物を効率化する (8:32)

では、いくつかのベストプラクティスについてお話ししましょう。 まず、シークレットをイメージに含めないで、シークレットをボリュームとしてマウントし、環境変数を使用するか、ボールトを使用します。 Docker および組織からの信頼できるコンテンツのみを使用してください。 たとえば、Dockerには3種類の信頼できるコンテンツがあります。 Dockerの公式イメージ、発行者の確認、およびスポンサー付きのオープンソースプロジェクト。 画像を使用するときは、最新のタグを使用しないでください。 危険すぎます。

Docker イメージをスリムで効率的に保ちます。 アプリケーションに絶対に必要なもののみを含め、画像レイヤーを賢く整理して再利用できるようにします。 これにより、画像サイズが縮小されるだけでなく、ビルダーが高速になります。 さらに、マルチステージビルドを採用しているため、すべてを合理化およびシンプルに保つための優れたツールです。

それでは、マルチステージビルドについてもう少しお話ししましょう。 これはDockerの2番目に好きな機能で、1つ目はComposeです。 マルチステージ ビルドの使用は、パイプラインを Dockerfile に定義するのと似ています。 このスライドの Dockerfile は 2 つのステップに分かれています。 最初のステップでは、公式のgolangイメージを使用してgolangアプリケーションを構築します。 このイメージのサイズは約 800 MB です。 次に、アプリケーションがビルドされたら、最小限のスクラッチイメージを使用して、最初のステージのバイナリを最終イメージにコピーします。 最終的に、画像のサイズはわずか約 20 MB です。 もちろん、サイズはアプリケーションや複雑さによって変わる可能性があります。 これにより、メリットが得られます。 画像サイズを縮小しました。 そのため、ロード時間とストレージ効率が向上します。 再構築が速くなります。 また、イメージが小さいほど攻撃対象領域が最小限に抑えられるため、セキュリティが向上します。 また、CI/CDではセキュリティが重要なポイントです。 イメージに脆弱性がないことを確認する必要があります。

CI/CD からのイメージの構築 (10:52)

CI/CDからのDockerイメージのビルドと公開に関しては、仕事は非常に簡単です。 GitLabは、GitLab CIからDockerイメージをビルドするさまざまな方法を説明する優れたドキュメントを提供しているため、この部分には時間を費やしません。

CIを支援する (11:12)

CI についてさらに少し説明します。 では、キャッシュ管理についてです。 ビルドキットは、結果をキャッシュすることでビルドを高速化します。 ビルド キットは、Docker イメージの既定のビルド エンジンです。 これにより、前の作業が保存されるため、繰り返しが回避されます。 その後、後で使用するためにキャッシュを外部に保存できます。 これは、ビルドが毎回ゼロから開始されるが、高速性を維持する必要があるCI/CD環境で特に便利です。

ここでは、キャッシュの例をいくつかご紹介します。 そのため、イメージをビルドしてプッシュし、キャッシュをレジストリに格納できます。 そのため、ビルドの一部をレジストリに保存し、次のビルドでこの部分を再利用できます。 2 番目の例は、オブジェクト ストレージ、たとえば S3 バケット (Docker ビルドでの使用) です。

以上で、ご清聴ありがとうございました

さらに詳しく

• Docker Buildと Docker Compose のドキュメントを確認してください。 
• ドッカーは初めてですか? 始めましょう。
• 無料のラーニングパスでDocker製品を深く掘り下げます。
• Docker Newsletter を購読してください。
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。