オンデマンドトレーニング

Docker の紹介と概要

 

写し

こんにちは、私の名前はマイケル・アーウィンで、ここDockerのデベロッパーリレーションズチームのメンバーです。 このセッションでは、Dockerの紹介と概要について説明します。 Dockerについてのさまざまなこと、Dockerがコンテナを使用した開発者のエクスペリエンスの効率化にどのように役立つか、また、本番環境とコンテナ化された環境向けにアプリケーションを準備する方法についてお話しします。 さて、先に進んで、多くの異なることについて話すことになるという警告を前もって述べておきます。 そして、多くのデモや例、そして私たちのさまざまな製品やサービスがすべて組み合わさっているのを見ることができます。 それはたくさんあるでしょう。 あまり深く掘り下げるつもりはありません。 ですから、これは非常に幅の広い会話と深い会話になるでしょう。 ですから、実際にどのように実装し、実行に移すかを学ぶためには、他のセッションもチェックする必要があります。

しかし、それでは、今日は何を話そうか? まず、コンテナ 101を行います。 Dockerが行うすべてのことは、コンテナに焦点を当てています。 ですから、私たち全員が同じページにいることを確認しましょう。 まず、そのことから始めましょう。 次に、Dockerを使用するさまざまな方法に飛び込みます。 ここでは、2つの導入トラック、特にコンテナサポート開発についてお話しします - 基本的には、アプリケーションの開発、アプリケーションのテスト、チーム全体で一貫した環境の提供などにコンテナをどのように使用できるかということです。- 次に、コンテナ化された環境での本番環境用にアプリケーションをどのように準備できますか? では、アプリケーションをコンテナ化するにはどうすればよいでしょうか。 効率的に構築するにはどうすればよいですか? その画像などをどのように保護しますか? そこで、その過程でさまざまなツールやサービスについてお話しします。

 

目次

 

コンテナ 101 (1:34)

それでは、コンテナ 101に飛び込みましょう。 そして、私たちが答える最初の質問は、コンテナとは何ですか? これに答える最善の方法は、実際に例えを使うことです。 ですから、私たちは皆、スマートフォンを持っています、または私たちのほとんどがとにかく持っています。 私たちのスマートフォンには、さまざまなアプリケーションがインストールされています。 この場合、緑、青、黄色、青緑色の4つの異なるアプリがあります。 そして、考えていただきたいのは、これらのアプリの1つを実際にインストールする方法、つまり電話の設定、適切な依存関係と設定など、すべてについて心配しなければならなかったのはいつだったかということです。 まあ、答えはおそらく決してありません。 そんな心配は一度もありませんでした。 なぜなら、私たちは何をしているのか? アプリストアを開き、インストールボタンをクリックすると、ダウンロードされ、インストールされ、数秒以内に携帯電話にアプリが表示されます。 そして、そこから、ここで赤いアプリケーションをクリックすると、そのアプリが私の電話で実行されます。 そしてまた、携帯電話の他のアプリについて心配する必要はありません。 青いアプリを起動したときに、赤いアプリにどのように影響するかを心配する必要はありません。 これらはすべて、これらの分離された環境を実行しています。 まあ、コンテナは同じものとよく似ています。 確かに、それらは少し異なる方法で実装されていますが、すべてのコンテナ化されたプロセスが分離された環境で実行でき、他のコンテナから完全に独立しているだけでなく、ホストからも独立している同様の分離セットを提供します。

では、ここで例を見てみましょう。 PostgreSQLを実行したいと想像してみてください。 コンテナ化された環境では、Docker Hubにアクセスして、「PostgreSQLを探す」と言うことができます。 実際、Docker Hubとここでブラウザに切り替えると、PostgreSQLイメージが表示され、存在するすべての異なるバージョンなど、このイメージに関する多くの詳細を確認できます。 最新の 17が使えます。1、 または、古いバージョンが必要な場合は、 12を実行できます。21。 タグタブに移動して、他の多くのタグを表示することもできます。 Postgresを実行する方法に関する追加のドキュメントがありますが、これにより私ができることは、ここでターミナルにジャンプして「dockerrun」コマンドを実行することです。 そして、これは、スマートフォンの例えで話していたアプリのインストールと実行と非常によく似ています。 しかし、これが何をしようとしているかというと、コンテナを実行し、環境変数を指定し(ここではポートマッピングについてすぐに説明します)、この特定のバージョンのイメージ 17でPostgresイメージを実行したいとします。1。

そして、Enterキーを押すと、Postgresが起動します。 すでにイメージをダウンロードしました。 そうしないと、ダウンロードが最初に行われるのが表示されます。 しかし、すべてのログ出力が出力されたので、Postgresは実行されています。 さて、覚えている方もいらっしゃると思いますが、これらの各コンテナは分離された環境で実行されていると述べました。 したがって、このポートマッピングが行っていることは、基本的にネットワーク分離に穴を突くようなものです。 そうすれば、ローカルマシンからアクセスできます。 そうしないと、データベースにアクセスできません。 つまり、これが言っているのは、ホストのポート 5432 をコンテナのポート 5432 に接続することです。 それで、これで私ができることは、ここで別のタブを開くことができるということです。 そして、ネイティブにインストールされたPSQLコマンドラインツールを使用して、ローカルホストに接続したいとだけ言います。 設定したパスワード(dev)を使用します。 そして今、私はデータベースに接続しています。 繰り返しになりますが、何もインストールする必要はありませんでした。 何も設定する必要はありませんでした。 そして、それはうまくいきます。 私は動き回ることができます。 もちろん、ここにはテーブルはありません。 空のデータベースです。 しかし、完了したら、Ctrl-Cを押すだけでデータベースが完成します。 止まった。 コンテナはもう実行されていません。 そして、画像を削除したいと思ったら、基本的にすべてが含まれていたパッケージはなくなってしまいます。 私のマシンには何もインストールされていません。 繰り返しになりますが、スマートフォンのアプリのように、これらのポータブルで分離されたプロセスを持てるという考え方です。 しかし、大きな違いの 1 つは、これらのコンテナを複数接続して開発環境を作成できることです。 そして、それはここですぐにわかります。

さて、ここでのスライドに戻ると、これについて適切な定義をするために、一日の終わりのコンテナは、スマートフォンのアプリと同じように、マシン上の孤立したプロセスにすぎません。 完全な仮想マシンではありません。 つまり、カーネルやハイパーバイザーなどは関係ありません。これは、マシン上で分離されたプロセスにすぎません。 イメージは、コンテナ化された環境を実行するために必要なすべてを提供するインストールパッケージと考えてください。 したがって、すべてのバイナリ、すべてのファイル、すべての構成依存関係などを提供します。 したがって、Pythonアプリがある場合、Pythonランタイムがあり、そこから続きます。

 

画像の検索 (6:22)

では、もう少し掘り下げると、これらの画像はどこにあるのでしょうか? さて、Docker Hubから来たPostgresの一例を見ました。 また、Docker Hubは世界最大のマーケットプレイスです。 それは私たちが運営し、提供するサービスです。 そして、利用可能なさまざまな画像がたくさんあります。 実際、Docker Hubのブラウザに戻ると、ここにある多くの画像を調べることができます。 また、Dockerの公式イメージのセットを見ると、ここにはさまざまな種類のイメージがあることがわかります。 実行したばかりのPostgresコンテナとよく似ています。 これらのいくつかは、RedisやPostgres、ここでもnginxなど、すぐに実行できるソフトウェアを提供するイメージです。 しかし、これらの他のいくつかは、単にそれを実行するとはどういう意味ですか? 例えば、Pythonのように。 Pythonイメージは、拡張して独自のアプリケーションを構築するための優れた基盤を提供します。 繰り返しになりますが、Pythonを実行するだけでなく、Pythonランタイム、pip、およびPython環境に期待されるその他のツールを備えたPythonイメージが必要です。 そして、それを自分のイメージのベースとして使い、そこから拡張することができます。 そしてまた、ここにはたくさんの画像があります。 Dockerの公式イメージがあります。 これらは、私たちが作成し、維持し、保護するイメージであり、多くの組織が活用するための優れた基盤を提供します。

 

建物イメージ (7:40)

独自のイメージを構築する準備ができたら、イメージの構築とそれに関するベストプラクティスに焦点を当てた別のセッションがあります。 ただし、通常は Dockerfile を使用します。 また、Dockerfile は、そのイメージのビルド方法に関する一連の命令を提供します。 この例では、Pythonから開始し、いくつかのファイルをコピーし、それらの依存関係をインストールするためのいくつかのコマンドを実行します。 また、実行に必要なすべてのもの (この場合は Python アプリケーション) を含むインストール パッケージを作成します。 CLIを使用してビルドできます。 私はDockerビルドを行います。 その画像に名前を付けることができます。 この場合は、moby/my-app です。 そして、それをレジストリにプッシュできます。 また、このレジストリはDocker Hub、AWS ECR、内部のJFrog Artifactoryなどです。 さまざまなレジストリがあります。 そして、そこにはたくさんのチャンスがあります。

 

Dockerの使い方 (8:40)

繰り返しになりますが、コンテナ、分離されたプロセス、イメージには、アプリケーションを実行するために必要なすべてのものが含まれています。 Dockerはこれにどのように適合しますか? Dockerが提供するさまざまなサービスとツールは何ですか? さて、最初に言及するのは、ほとんどの人がすでによく知っているものです。

  • Docker デスクトップ: 開発者としての私にとっての単一のワンインストールソリューション。 私はそれを自分のマシンにインストールします、それは私がコンテナですべてを開発、テスト、構築するために必要なすべてのツールを私に与えます。 そして、その例をもう少し後で見ていきます。 
  • Docker ハブ: 画像を見つけたり、画像を共有したり、そこで画像リポジトリを作成したりできるマーケットプレイスです。 
  • Docker Scout: 私たちが提供する製品は、基本的に次の質問に答えます:私はイメージを構築しましたが、良いイメージを構築したかどうかはどうすればわかりますか? その画像は、組織のコンプライアンス ポリシーを満たしていましたか? ですから、Scoutを使えば、さまざまなポリシーに照らして自分のイメージを分析することができます。 ここでは、その例を少しだけ見ていきます。 そして、問題が発生した場合は、Scoutがそれらを修正する方法について推奨事項を提供できます。 そのため、開発者として、テストを行い、イメージをビルドし、イメージをテストし、分析し、コードをプッシュしてCI/CDプロセスが進むずっと前に、それらが準拠していることを確認できます。 そこでも、フィードバックループを短くしようとしています。 
  • Docker ビルド クラウド: イメージをより迅速に作成するのに役立ちます。 そのため、クラウドのマネージド ビルダーを使用すると、より迅速にビルドし、以前のビルドのキャッシュを活用できます。 そして、その例を後でいくつか見ていきます。 
  • Testcontainersクラウド: コンテナの実行をクラウドベースの環境に委任するのに役立ち、特にCI環境での統合テストを実行するのに非常に役立ちます。 そしてまた、その例をすぐに見ていきます。 

 

Dockerデスクトップ (10:20)

Docker Desktopについてもう少し詳しく説明すると、多くの混乱があるため、Docker Desktopは右上のGUI以上のものであることを明確にしたいと思います。 これは、私のローカル マシンでコンテナーを操作するために必要なすべてを提供します。 イメージの構築、コンテナの実行、Kubernetesクラスタのスピンアップ、Helmチャートのテスト、クロスプラットフォームのサポート、他のすべての製品やサービスとの統合も可能です。 CLIのGUIを提供しますが、最も重要なことは、特にエンタープライズスペースの人々にとって、エンタープライズ制御を提供して、企業が開発環境を安全でセキュアに保つことができるようにすることです。 これには、ユーザーが取得できるレジストリに関する設定や制御、および開発者ワークステーションを安全に保つためのその他の設定を含めることができます。

さて、実際にコンテナを採用して使用すると、ここからが楽しみの始まりで、多くのデモには、2つの異なるトラックがあります。 1つ目は、コンテナサポート開発と呼ばれるものです。 これは基本的に、開発とテストでコンテナを使用する方法であり、基本的にはコードをプッシュしてCIパイプラインを開始する前のすべてです。 開発環境の設定方法を教えてください。 チームの一貫性を保つために、どうすればよいでしょうか? コンテナでテストするにはどうすればいいですか? 等。 これにより一貫性が保たれ、リモート環境のために自分自身を切り離すことができ、ここではその例をすぐに見ていきます。 私が指摘することの 1 つは、開発のメイン アプリが実際にコンテナー化されているかどうかに関係なく、ローカル開発でコンテナーを使用できるということです。 そして、ここでもその例をいくつか見ていきます。

もう1つのトラックは、実際にアプリケーションをコンテナでどのようにビルドし、本番環境にどのように準備するかということです。 どうやって作ればいいの? ベストプラクティスに従うにはどうすればよいですか? セキュリティを確保するにはどうすればよいですか? そして、これには通常、CIチーム、プラットフォームチーム、SREなど、より多くのチームが関与することになります。なぜなら、それは私たちが実際にアプリケーションをデプロイする方法を変えるからです。

 

コンテナサポート開発 (12:30)

まずは、コンテナ支援開発から始めましょう。 ローカル開発でコンテナを使用するにはどうすればよいですか? 先ほど、Postgresコンテナを実行したことを見ましたが、そのストーリーを少し詳しく説明しましょう。 私がカタログサービスであるアプリケーションを持っており、このアプリケーションがAPIを提示するだけだと想像してください。 このアプリケーションは、前に見たのと同じように、そのデータをPostgresデータベースに保存します。 私はそれをコンテナで実行できます。 しかし、私のアプリケーションは、カタログが画像を保存する必要があるため、それらの画像をAWS S3に保存するとしましょう。 私のアプリケーションでは、インベントリ サービスなどの外部データ サービスも利用しています。 カタログを検索すると、特定の場所に特定のアイテムがいくつ存在するかを知ることができます。 カタログ内で変更が発生すると、アプリケーションは更新をKafkaクラスタに公開し、他のダウンストリームサービスがそれらのイベントに応答したり、通知を送信したりできるようになります。

ですから、これについて考えると、ここには多くの動く部分があります。 そこで問題となるのは、これを使って開発環境をどのように設定するかということです。 さて、よく見かけることの1つは、ローカル開発環境でAPIをスピンアップするだけでなく、デプロイされたサービス、おそらく開発用の共有AWSアカウントに接続すると言う人がいることです。 私のアプリには S3が必要であり、外部インベントリ サービスが必要です。 アプリが他の場所で実行されているサービスに接続できるようにさせてください。 そして、ほとんどの場合、これはかなりうまくいきます。 しかし、その 1 人の開発者が開発者のチームに属していることに気付くと、今度は同じリソースをめぐって争う他の多くの開発者がいます。 また、S3 バケットのIAMポリシーがめちゃくちゃになり、誰もバケットからオブジェクトをプッシュまたはプルできなくなったり、誰かが誤ってPostgresデータベースからテーブルを削除したりした場合にどうなるでしょうか。 繰り返しになりますが、人々がお互いのつま先を踏みつけ合う機会がたくさんあり、許可が台無しになる可能性があります。 そして、開発中の一日の終わりには、私はそのようなことのほとんどを気にしません。

開発環境を簡略化できますか? まあ、明らかに答えはイエスです - だからこそ、私たちはこれについて話しているのです。 では、別の方法として、開発者のワークステーションで、開発環境のAWSアカウントに実際に接続する代わりに、S3互換のサービスをローカルで実行した場合はどうでしょうか。 結局のところ、私のコードはAPIと通信しているだけです。 それが実際に背後にS3 であるかどうかはあまり気にしません。 では、そのS3 をS3 API互換サービスに交換し、それをローカルで実行した場合はどうなるでしょうか。 さて、もしそうするなら、なぜ私のインベントリサービスでもそれができないのでしょうか? 結局のところ、インベントリ サービスは単なる API です。 では、もし私がこれらすべてを嘲笑したらどうなるでしょうか? そして、それはどのような機会を開くのでしょうか? それについては、すぐに説明します。 Kafkaをローカルで実行することもできます。 Postgresをローカルで実行できます。 ですから、これだけでも、リモート開発環境だったものが今ではローカルになっているという自分の開発を、すでに模擬し始めています。 しかし、これに機能を追加することもできます。 私の開発者全員がKafkaがあまり得意ではなく、さまざまなCLI/コマンドライン引数などをすべて理解していない場合はどうなりますか? まあ、Kafkaクラスタと対話してメッセージの公開をテストしたり、メッセージが正しく生成されていることを検証できる別のサービスを立ち上げることができればいいと思いませんか? あるいは、データベースで何が起こっているかを視覚化するためのオープンソースツール、おそらくpgAdminをスピンアップさせてください。 そして再び、他の方法では実現が難しかった機能で開発環境を強化し始めることができます。

 

デモ (16:18)

これを見てみましょう。 大丈夫です。 ここからVSCodeに切り替えます。 そして、ここVSCodeでは、このComposeファイルから始めます。 さて、私はまだComposeについて話していないことを知っています、そしてそれについては別のセッションでもっと話します。 ただし、Composeは、以前にPostgresに対して行ったdocker runコマンドに戻ると、環境変数とポートを指定してからイメージを指定した場合のdocker runコマンドのように考えてください。 まあ、ここでもほぼ同じことをしていますが、形式が違うだけです。 これが画像、これがポート、いくつかの環境変数、他のいくつかのファイルボリュームがあり、これについては後で説明します。 しかし、繰り返しになりますが、ここに一つのコンテナがあり、ここに別のコンテナがあり、別のコンテナがあるというアウトラインを描かせてくれます。 そのため、ここでは環境を設定するために多くのコンテナが定義されています。 そして、これにより私ができることは、 'docker compose up'を実行することができるということです。 基本的にこれをバックグラウンドで実行するために '-d'を追加しています。 そして、これによりコンテナがスピンアップします。 ここでも、これらのコンテナの一部がデータベースを提供しています。 私はLocalStackというオープンソースのツールを使ってAWSを実行しています。 これにより、基本的に S3 互換の API をローカルに持つことができます。 そのAWSアカウントをバケットで設定します。 Kafkaの設定などです。 そして今、数秒以内にアプリの依存関係が稼働しています。

このデモでは、実際にアプリを自分のマシンでネイティブに実行します。 「yarn dev」はNodeアプリであるため、実行します。 そして、何が起こるかというと、データベースはホスト上で公開されているため、アプリはその公開ポートを介してそのデータベースに接続するだけです。 ここで別のタブを開き、製品を作成できるヘルパースクリプトに移動します。 したがって、この場合、3つの製品を作成しました。 さて、このアプリケーションによって公開されているAPIと対話しただけです。 さて、スタックの一部である他のいくつかのサービスがあることを述べました。 ブラウザに戻ると、localhost:5050 (これはここで選択したポートだけです)で、pgAdminが実行されていることがわかります。 pgAdminは、Postgresデータベースを視覚化するのに役立つオープンソースツールであり、サーバーを開くことができ、このパスワードは作成ファイルで構成されます。 そして、ここから、すべてのスキーマとテーブルをナビゲートし続けることができます。 そのテーブルのすべてのデータを表示してみましょう。 さっき作った3つのアイテムが見えます。 これらのうちの1つを変更しましょう。 「別の製品」に変更してから、トランザクションをコミットするだけです。 そして今、VS Codeに戻ると、「ねえ、製品 2をください」と言うことができ、ここでも名前が変更されていることがわかります。 さて、繰り返しになりますが、そのデータベース ビジュアライザーでは、「どのように設定すればよいか」を理解するのに時間を費やす必要はありませんでした。 インストール方法は? How to Configure It?」というメッセージが表示されるようになりました。 これは、そのツールの作成者がコンテナイメージを公開し、今ではそれを実行することができるオープンソースのツールです。 とても簡単です。

これで、ここにインベントリデータがあることも確認できます。 それはどこから来ているのですか? 繰り返しになりますが、私はWireMockというツールを使用したインベントリモックを実行しており、このツールを使用すると、いくつかのファイルマッピングを入力できます。 そのため、私の API が在庫サービスに対して製品番号のリクエストを再度行うとき 2 (これは好きなように構成できます) その検索のために、この JSON 本文で 200 ステータスを返します。 そして、それがマージされることがわかります。 さて、モックを使用する大きな利点の1つは、他のエラー状態をテストし始めることができることです。 たとえば、この別のエンドポイントに移動すると、実際にはインベントリサービスから、発生したエラーを示すメッセージを含むJSON本文の 500 が送信されることになります。 そして、私のコードがその 500 エラーケースを処理していることを検証できます-それは爆発しません。 エラーメッセージを返しますが、必要な残りの関連詳細を提供します。 ですから、再び、実際のサービスと話していると難しい他の条件をすべてテストし始めることができます。 繰り返しになりますが、コンテナを使用すると、これらのさまざまなサービスを簡単にスピンアップできます。 さて、ここでモックしたい、ここにデータベースビジュアライザーが欲しい、など。

実は、もう一つちょっとしたデモがあります。 localhost:8080に行くと、kafbat という別のオープンソースツールがあります。 Kafka クラスターで何が起こっているかを視覚化できます。 そして、その製品が作成されたときに公開されたメッセージを見ることができました。 また、メッセージが公開されたことや、適切なスキーマを持っていることなどを検証できます。 繰り返しになりますが、コンテナを使用すると、アプリケーションスタックについて考え始めることができます。 VS Codeに戻ると、スマートフォンアプリの代わりに、ほとんどレゴブロックの束から始めるかもしれません。 また、さまざまなサービスや、生産性を向上させたり、トラブルシューティングやデバッグを容易にしたりするための開発環境を作るために接続できるさまざまなコンポーネントは何ですか。

そこで、いくつかのヒントを挙げると、これは私がサービス間のプロトコルと抽象化に焦点を当てているため、うまくいきます。 データベースをローカルで実行できるのは、マネージドデータベースサービスがクラウド環境で提供するものと同じバイナリプロトコルだからです。 しかし、私のAPIもそうです。 APIはよく理解され、十分に文書化されている必要があります。そして、それらをローカルでモックアウトすることができます。 この場合、コンテナポートをホストにマップし、アプリケーションに接続できるようにします。 私のアプリはネイティブに実行されていますが、実際にはコンテナでも実行できます。 たとえば、ここには別のComposeファイルがあります。 この場合、アプリ自体はコンテナ内で実行され、基本的にはNode環境を構築しています。 したがって、 'yarn dev'が私のホストのCLIで直接実行されるのではなく、基本的にコンテナ化された環境内で実行されています。 その場合、このリポジトリをクローンでき、この特定のComposeファイルを使用すると、すべてがコンテナで実行されることになります。 DockerDesktop以外にマシンに何もインストールする必要はありません。 繰り返しになりますが、それはそこで多くの良い機会を開きます。

また、開発環境について考えるときは、その開発環境に提供できる追加のツールや機能について考えてみてください。これにより、データベースや Kafka クラスターなど、使用しているものすべてでトラブルシューティングやデバッグを容易にし、有用性を高めることができます。

統合テストの課題 (23:05)

ですから、問題は、開発の枠を超えて、テストを開始する準備ができたときです。 それからどうしますか? 統合テストは困難です。 そして、その多くは、サービスのライフサイクルを管理しなければならないためです。 どのように開始しますか? どうすれば彼らを止めることができるのでしょうか? テストなどを行うためには、実行中のデータベースが必要です。 また、テストラン1がテストラン2の影響を受けることがわかっているような、長時間稼働するインフラストラクチャにとどまらないようにするにはどうすればよいでしょうか。 またしても、めちゃくちゃです。 そして伝統的に、私たちは多くのユニットテストがあり、その上にいくつかの統合テストがあり、さらに少ないエンドツーエンドのテストがあるテストピラミッドに従うようにしています。 しかし、統合テストは難しいため、多くの場合、人々はテストの砂時計に行き着き、その部分は難しいと言います。 ですから、スタック内で上位に押し上げ、QAテストやエンドツーエンドのテストなどを行うだけです。 しかし、エンドツーエンドのテストは非常に時間がかかります。 また、非常にもろいです。 正しく行うのは難しいです。 では、問題は、コンテナの力をどのように活用して統合テストに役立てることができるかということです。 そこで、Testcontainersフレームワークの出番です。

 

Testcontainersの紹介 (24:15)

さて、先に進んで前もって明確にしますが、Testcontainersは別のタイプのコンテナではありません。 この孤立した環境という考え方は変わりませんが、コンテナの力をテストの世界に持ち込んでいます。 したがって、Testcontainersが提供するのは、コンテナをプログラムで管理できるようにするライブラリのオープンソースコレクションです。 ここでの例として、Javaスニペットがあり、「Postgresコンテナが必要です。 これが私が使用したい特定の画像で、それをこの変数に代入します。 しかし、これはプログラムによるアプローチであるため、これをテストのスタートアップ スクリプトに入れると、スタートアップ スクリプトで必要なすべてのさまざまなサービスを開始できます。 テストを実行し、再び実際のサービスと通信し、完了したら、Testcontainersフレームワークがすべてをクリーンアップするのに役立ちます。 つまり、すべてのコンテナ、すべてのボリュームネットワーク、その他すべてのものが確実に削除されるのです。 そしてもう1つの利点は、プログラムによるアプローチであるため、その周りに独自の抽象化レイヤーを作成し始めることができることです。 だから、あなたはおそらく言いたいのでしょう、私はこの特定のデータスナップショットを持つpostgresコンテナが欲しいです。 繰り返しになりますが、あなたはそれを始めることができます。

Testcontainersには、すぐに使えるモジュールがたくさんあります。 ですから、本当に複雑なものを作るのは本当に簡単です。 そして、今日ではそれらの幅広いライブラリがあり、それも常に成長しています。

 

デモ: Testcontainers (25:40)

だから、これも少しだけお見せします。 ほんの少し前に見ていたのと同じプロジェクトに戻ります。 そして、テストディレクトリを開くと、ここに統合テストがあり、すべてのテストが実行される前に、Postgresコンテナを作成してブートストラップし、Kafkaコンテナを作成してブートストラップします。 このPostgresコンテナを見ると、これもNode SDKを使用しています。 Postgresコンテナを作成します。 スキーマを設定するデータベース初期化スクリプトをバインドマウントして開始します。 この約束が解決されたら、詳細を抽出していくつかの環境変数を設定し、コードベースが取得して活用できます。 そこで、ホストポートとデータベースのユーザー名とパスワードを抽出します。 ここで良い点は、Testcontainersフレームワークがデフォルトでポートをエフェメラルポートに公開することです。 したがって、ホストでポート 5432 を公開すると言っていますが、それは 55017 である可能性があります。 そのため、多くのテストを並行して実行することもできます。 そして、Kafkaコンテナを起動するKafkaクラスタについても同様のものがあります。 そして、戻る前に、実際に先に進んで、コードを実行するために必要なトピックを作成します。 そして、そこから、これらのテストの1つを見て、たとえば、消費者を作成します。 しかし、実際に製品を作るときは、自分が欲しいメッセージが実際に公開されているかどうかを検証します。 そしてまた、これはすべてが機能していることを検証することになります。 先に進んでこれを実行しましょう。

さて、これをCLIから実行し、その間に実際にその横にあるDocker Desktop GUIを引き出して、コンテナの起動を確認できるようにします。 実際、私は先に進んで、ここでこのスタックを折りたたむと、もう少し簡単に見ることができます。 そこでテストを開始すると、ここのログ出力でコンテナが開始されていることがわかり、Docker Desktopダッシュボードにも表示されていることがわかります。 そうそう、ここにはたくさんのログ出力があります。 現在、デバッグログを有効にしています。 そしてまた、コンテナを回転させています。 テストを実行しています。 そして、完了すると、それらのコンテナが削除されたことがわかります。 この最後のTestcontainerコンテナは、物事をクリーンアップするために使用され、それも自動的に消えることがわかります。

繰り返しになりますが、Testcontainersフレームワークを使用すると、テスト環境でコンテナの力を活用できます。 また、ブラウザに飛び込むと、さまざまな言語でサポートされています。 さて、明らかに、Testcontainer コードの書き方は言語によって少し異なります。 そして、その特定の言語のイディオムも保とうとします。 それで、ここで最後に述べることは、多くのチームは、Dockerまたは特権モードでDockerを実行できないKubernetesポッドを使用している可能性があるため、CI環境でコンテナを起動できない可能性があるということです。

そこで、Testcontainers Cloudの出番であり、Testcontainers Cloudを使用すると、基本的にこれらのコンテナの実行をクラウドベースのリソースに委任できます。 そのため、Docker で Docker を使用する必要がなくなり、パイプラインの安全性が向上します。 実際、以前に行ったのと同じテストを実行でき、トグルを反転してTestcontainers Cloudを使用するだけです。 そして今、私は同じテストを実行します。 そして、今回は実際にクラウドベースの環境を使用することがわかります。 そのため、ここではいくつかのプルが進行しているのがわかりますが、ダッシュボードでもアクションは行われていません。 繰り返しになりますが、Testcontainers Cloudを使用すると、それらの実行をクラウドベースのサービスに委任できるため、CI環境や、AI機械学習ワークロードなどのGPUが必要な場合に特に役立ちます。

 

アプリのコンテナ化 (29:57)

それでは、アプリケーションをコンテナ化する方法について話しましょう。 さて、開発とテストについて話しました。 では、実際にアプリケーションをバンドルしてビルドし、デプロイする準備をするにはどうすればよいでしょうか、また、Docker はそれをどのように行うのに役立っているのでしょうか。 まず最初に触れたいのは、多くのチームがこの旅を始めるとき、最初はすべてのベストプラクティスに従わなければならないと感じているということです。 そして、分析麻痺に陥るのは本当に簡単です。 私は、小さな小さな一歩を踏み出しても大丈夫だということを、前もってはっきりさせておきたいのです。 ですから、私が多くのチームに最初に行うように勧めているのは、アプリをコンテナに入れることです。 さて、それはきれいである必要はありません。 最も最適化する必要はありません。 世界最小の画像である必要はありません。 何かを機能させるだけです。 したがって、最初の目標は、アプリをコンテナに入れることです。

その後、どのように自動化しますか? そのため、コードをプッシュするたびに、コードのビルドを開始できます。 そして、それがCIパイプラインに統合されます。 また、その画像の構築を自動化することで、時間の経過とともに変化が見えてくるようになります。 その後、そこから最適化に焦点を当てます。 画像を小さく、速く、スリムにするにはどうすればいいのか、などなど。 そして、キャッシュを活用するなど、さまざまなことを行っています。 また、セッション全体は、ベストプラクティスの構築などに焦点を当てています。 そして、これらすべてを横断し、これを前もって述べておくべきですが、組織のコンプライアンスのニーズとポリシーを満たしていることを確認したいと考えています。 そうすれば、最初のビルドであっても、多くの脆弱性などに身をさらしたくありません。 では、これらのさまざまなステップのそれぞれで私たちを助けるツールは何ですか?

 

Docker Init(31:41)

Docker Init は、コンテナ化の取り組みをブートストラップするために設計されたツールです。 7つの異なる言語をサポートしており、その特定のプロジェクトがどの言語であるかを検出でき、開始に役立つDockerfileと作成ファイルを提供します。 さて、先に進んで、それは完璧ではないかもしれませんが、少なくともあなたに良い一歩を踏み出し、あなたの旅を始めるきっかけを与えるでしょう。 そしてもちろん、それはローカルファイルシステム内のファイルだけなので、そこから変更を加えたり、ベースイメージを別のイメージに交換したりすることができます。これがDockerのベストプラクティスです。 うまくいけば、組織レベル、チームレベル、そして個人レベルで考えるための新しい領域がたくさんあると思います。 確かに、世の中には常により多くのベストプラクティスがあります。 このプレゼンテーションを楽しんでいただければ幸いです。 ありがとうございます。

 

GitHub アクション (32:18)

CI環境で開始する準備ができたら、それを支援する多くのツールを用意しています。 イメージのビルドとプッシュ、Docker Build Cloudとの統合に役立つ公式のGitHub Actionsがたくさんありますが、これについては後ほど詳しく説明しますが、Docker Scoutもそうです。 Testcontainers Cloudについては、先ほどお話ししました。 そのため、Testcontainers Cloudを使用して再度テストを実行したい場合は、その多くをサポートするための公式のアクションもあります。 また、GitLab CI環境でも、実際にこれらのGitHub Actionsを使用している人も見かけ始めており、GitLab CIでもGitHub Actionsの一部を活用できるようになりました。 そして、そこから、私が言及したいことの1つである、いくつかの簡単なヒントとベストプラクティスです。

 

クイックヒント/ベストプラクティス (32:59)

さて、ここで掘り下げることができることはもっとたくさんありますが、少し食欲をそそるだけです。 まず、この旅を始めると、プライベートNPMレジストリから依存関係を取得する必要があるのか、SSH資格情報から依存関係を取得する必要があるのか、資格情報が必要だ、などと言うのが一般的です。 しかし、私があなたにアドバイスしたいのは、画像に秘密を含めないことです。 ビルド シークレットを使用してビルド時にシークレットを提供する方法があります。 ただ、イメージに焼き付けないでください。 画像のレイヤー化と、それが実際にどのように構成されているかについてはまだ話していないことは承知しています。 シークレットを 1 つのレイヤーに配置し、次のレイヤーで「そのファイルを削除するよ」と言うとしたら、そのファイルを削除することになります。 結局のところ、実際にはまだ資格情報を発送しています。 ですから、その点には十分注意してください。 画像にシークレットを含めないでください。

信頼できるベース イメージから開始します (それが Microsoft が提供するものであろうと、組織が提供するものであろうと、適切な信頼ベースから開始します)。

マルチステージ ビルドを使用すると、ビルド時の依存関係とランタイムの依存関係を分離し、本番環境用のはるかに小さく、無駄のない、より安全なイメージを作成するのに役立ちます。 そしてまた、今後のセッションでこれについてさらに深く掘り下げることができます。

また、可能な限り画像サイズを小さくする必要があります。 画像が小さいほど、押したり引いたりするのが速くなり、占めるストレージスペースも少なくなります。 そして、それを支援する1つの方法は、キャッシュの使用を促進するために、レイヤーまたは基本的にDockerfileの命令を構造化することです。

さて、これらの各アイテムは、おそらく 5 分または 10 分のセクションとデモ、そしてそれに付随するすべてに値するでしょう。 これについては、今後詳しく説明します。 しかし、ここでも考慮すべき点がいくつかあります。 これの多くを助けるためのツールのいくつか。

先に述べたように、ビルドを支援するツールがあり、それがDocker Build Cloudです。 Build Cloud の考え方は、ビルドを実行するたびにローカル マシンのビルダーを使用するのではなく、基本的にクラウドで実行されているビルダーを活用できるということです。 したがって、5 人のチームがある場合、クラウド ビルダーを使用していると仮定すると、1 人のビルドによって、チームの他の全員が活用できるキャッシュが設定されます。 これは、仕事をするたびに白紙の状態から始めるCI環境で特に役立ちます。 では、毎回白紙の状態から始める場合、以前のビルドのキャッシュをどのように活用できますか? クラウドビルダーでは、そのクラウドビルダーが常に実行されているため、これらのキャッシュを持つのに役立ちます。

そして、コンプライアンスを支援する2つ目のツールはDocker Scoutです。 Docker Scoutは、組織のポリシーを設定する機能だけでなく、ローカルの開発環境でそれらのポリシーを分析できるようにするための機能も提供します。 それでは、ここで少しお見せしましょう。

 

デモ (35:58)

VSCodeに戻ります。 そして、ここでDockerfileを開きます。 ここで多くの時間を費やすつもりはありませんが、少しだけ見せるために、ビルドを行います。 そして、このデモアプリを呼び出し、V1というタグを付けます。 そして最後の点は、これがその場所であるということです。 さて、このビルドは、先ほどビルドしたばかりなので、ほぼ瞬時に行われます。 そのため、ここにはキャッシュされた出力が多数表示されます。 しかし、これにより私ができることは、Docker Scoutのクイックビューを実行してから、これについてさらに詳細を取得できることです。 ですから、Scoutがやろうとしていることは、基本的に私の画像を分析し、SBOM(ソフトウェア部品表)を見て、箱に何が入っているかを見ることです。 どのような依存関係がありますか? どのOSパッケージですか? 他にどのようなアプリケーションの依存関係がありますか? それらのいずれかに問題はありますか? それらにはどのようなオープンソースライセンスが添付されていますか? また、アプリケーション自体はどのように構成されていますか? コンテナはデフォルトで非ルートユーザーとして実行するように構成されていますか? ここには、他にも多くのポリシーが関係している可能性があります。 しかし、Scoutの大きな利点の1つは、私のイメージ階層を認識することです。 したがって、この場合、node：20 からビルドしたことを認識でき、このレポートを生成するときに、問題を継承したのか、それとも実際に自分で問題を導入したのかを通知できますか?

ここは実に良いタイミングです。 そして、ここで私の画像に問題があることがわかります。 さて、現在、脆弱性は高 7 、脆弱性 8 中、 108 低です。 さて、かなりあります。 そして、それは私によく教えてくれます、ノード:20イメージ、私が活用している基本イメージは、高、中、4、107低3持ってきました。私は多くの問題を受け継いでいます。 そのため、ベースイメージを変更すると、ベースイメージを変更するだけで発生する変更を基本的に教えてくれます。 また、発見されたCVEについての追加の詳細も取得できます。 実際、私は先に進んで、それを本当に速く実行します。 そして、これにより、発見された特定の脆弱性について詳しく説明します。 ここでは、それらに関連付けられている修正バージョンと、それらをもう少し詳しく理解するためのリンクを示します。 その一方で、GUIでも同じものを見ることができ、分析を行い、この特定の画像で何が起こっているかを確認できることを示すこともできます。 これは、私が録音を行っているため、マシンが現在他の多くの処理も行っているため、通常よりも少し長くなると思いますが、これにより、CLIで見ている多くのことに対してGUIベースのアプローチが可能になります。 そのため、脆弱性をクリックして、その修正済みバージョンを確認できます。 画像を修正し、画像をより準拠させる方法についての推奨事項が表示されます。

さて、これはここですぐに終わるはずです。 そして、私ができることの 1 つは、この特定のビルドでは行わなかったことですが、実際に SBOM をビルドしてイメージにアタッチできることです。 したがって、これが少し遅くなる理由は、そのオプションを含めなかったためです。 したがって、基本的にはここで分析を行うたびにSBOMを生成する必要がありますが、ビルド時に一度生成することもできます。 しかし、繰り返しになりますが、基本的には私のイメージの祖先をすべて見ることができ、エクスプレスの 4に問題があることがわかります。17 、それには3つの異なるCVEが関連付けられていることがわかります。 この特定のものは私にそれについての詳細を与え、大丈夫、私が少なくとも行く必要がある固定バージョンを教えてくれます 4。20。 これは 4と言っています。19。2 そして、この最後のものは 4と言います。17。3。 したがって、その知識があれば、コードベースに戻ることができます。 パッケージのJSONを変更して、Expressを 4に更新する必要があるとだけ言うことができます。20。0。 すべてのテストを再構築して再分析し、実行したり、すべてが引き続き機能していることを確認したりできます。 ですから、Scoutは、展開する前にすべてを追跡するのに役立ちます。

さて、Build Cloudについて話しましたが、このコードをプッシュすると、実際には2つの異なるワークフローがトリガーされ、コミットごとにこれら2つの異なるワークフローがあることがわかります。 プレーンな GitHub アクションだけで構築されたものと、Docker Build Cloud を使用しているもの。 また、Docker Build Cloud を使用したビルドが 30秒の時間枠でホバリングしている時間には違いがあることがわかります。 この最後のものは依存関係を変更したため、少し時間がかかりましたが、Docker Build Cloudを使用しない場合は、約2分かかりました。 そのため、かなり時間がかかり、これはビルドを実行しているだけのワークフローです。 繰り返しになりますが、Testcontainers Cloudでも同じことが言えますが、コンテナの起動、コンテナの実行などです。

 

概要 (41:16)

繰り返しになりますが、これらすべての異なるサービスが、私の開発プラクティスを合理化するのに役立っています。 Docker Desktop、Docker Hub、Docker Scout、Docker Build Cloud、Testcontainers CloudなどのDockerサービススイートは、コンテナを使用した開発、コンテナを使用したテスト、ビルドと保護、そして最終的にはコンテナを使用したデプロイも支援するように設計されています。 そして、これらすべてがDockerサービススイートです。 繰り返しになりますが、この旅に皆さんをお迎えできることを嬉しく思いますので、今後のセッションにご注目ください。また、これらのことを実際に行う方法をより深く掘り下げ、実践して学ぶことができる場所もご覧ください。 それでは、よろしくお願いいたします。 これがあなたにとって有益であることを願っています、そして私たちはあなたの旅をサポートするのを楽しみにしています。

 

さらに詳しく

Dockerにクジラが来てください! この入門セッションでは、「コンテナとは何か」という基本から始めます。 そこから、ローカル開発におけるコンテナの力と、Docker の一連のサービスがどのようにすべてをまとめるかを学び、見ることができます。 一貫性のある開発環境、簡単な統合テスト、イメージのセキュリティ保護とビルドの迅速化に役立つツールが表示されます。

このセッションは、Dockerが提供するすべてのものの広範な概要を提供することを目的としており、技術的なハウツーには触れていないことに注意してください。 Docker を初めて使用するユーザーでも、経験豊富なユーザーでも、誰にとっても新しいものがあります。

登壇者

マイケル・アーウィン

シニアマネージャー、デベロッパーリレーションズ
港湾労働者