シフトレフト: Docker でイテレーションを高速化

こんにちは、マイケル・アーウィンです。 私はここ Docker のデベロッパー リレーションズ チームのメンバーです。 シフトレフトについてお話しできることを楽しみにしています。 さて、これに飛び込むと、まず、少し時間をかけて、シフトレフトが何を意味するのか、それが何であるか、何が重要でないか、なぜそれが重要なのかなどを実際に定義します。 次に、Dockerがシフトレフトを支援する3つの異なる方法について説明します。 まず、開発環境の移行、次に統合テスト、脆弱性評価、セキュリティ全般についてお話しし、最後にまとめます。 さっそく始めましょう。

 

目次

• 「シフトレフト」の定義 (0:35)
• 開発環境のシフト (4:20)
• デモ:開発環境(9:26)
• 統合テストの移行 (15:05)
• Testcontainersの紹介 (17:43)
• デモ: Testcontainers (21:30)
• 脆弱性評価のシフト (26:32)
• Docker Scoutとは何ですか? (28:20)
• デモ: Docker Scout (29:31)
• 総集編 (35:19)
• さらに詳しく

 

「シフトレフト」の定義 (0:35)

シフトレフトとはどういう意味ですか? それはどこから来たのか、また、それは何であり、何ではないのか、など。まず、ソフトウェア開発ライフサイクル、またはSDLCと呼ばれるものを見てみましょう。 通常、内側のループと外側のループと呼ばれる 2 つのループがあることがわかります。 各ループは、フィードバックを受け取り、次のループに備えるように設計されています。 内側のループは、コードがリポジトリにプッシュされる前に発生するすべてのことに焦点を当てています。 計画、セットアップ、実際のコーディング、構築、テストなど。 ただし、コードがプッシュされると、通常は CI ジョブがトリガーされ、アプリケーションがビルド、テスト、検証され、組織の標準を満たしていることが確認されます。 その後、アプリがデプロイされ、監視されます。明らかに、SDLCにはより多くのニュアンスがあり、詳細があり、これによりSDLCは高いレベルに保たれています。 これらは通常、SDLC に収まるコンポーネントです。 ここで興味深いことの1つは、このプロセスが本当に何年も変わっていないということです。 確かに、ツールは進化しており、これらの各ステップ間のプロセスと引き継ぎの一部は少し進化しています。 しかし、SDLC内に存在する全体的な目標と全体的なステップは、かなり一貫しています。

数年前、ほとんどの人がDevOpsの動きについて聞いたことがあると思いますが、それは多くの方法で同じ内側と外側のループであり、今では無限大記号にマッシュアップされているようなものです。 しかし、実際には、DevOpsの焦点は、チーム間の引き継ぎ、従来の開発のようなもの、従来の運用、内部ループと外部ループ、そしてそれらのプロセスをどのように合理化するかということでした。 問題点はどこにあるのか? 摩擦はどこにありますか? どうすればチームとしてより良く協力できるでしょうか? しかし、ソフトウェアを迅速に提供すると同時に、品質、稼働時間、セキュリティの面で打撃を受けないようにしたいと考えています。 結局のところ、主な目標はソフトウェアを提供し、顧客を満足させることだからです。

さて、シフトレフトについて考えると、また、内側のループ、外側のループ、そしてSDLCに戻ると、シフトレフトの全体的な考え方は、フィードバックがどこから来ているのか、そしてそのフィードバックループをどのように短縮できるかを見ることです。 DevOps に話を戻すと、摩擦点はどこにあるのでしょうか? ワークフローの問題点はどこにあるのか? では、通常は外側のループで実行されるものや、外側のループに依存するものはありますか? そして、それらを左に動かすことができるでしょうか? 内側のループに向かって動かすことができるでしょうか? なぜなら、ここで左に動かすことができれば、フィードバックが速くなるからです。 そして、開発者がフローに費やす時間が増えれば増えるほど。 では、繰り返しになりますが、うまくいかない可能性のあることはどこにあるのでしょうか? 遅いものは何ですか? これらの問題を早期に発見するための追加のコンテキストとツールをどのように提供できますか?

さて、前もって明確にしておきたいことの1つは、シフトレフトとは、単に開発者により多くの作業を与えることを意味するのではないということです。 なぜなら、それは人々が左にシフトするときによく聞くことだからです:「素晴らしい、それは開発者としての私、もっとやらなければならないということです」。 それは私たちがここで取りたいアプローチではありません。 シフトレフトについて話すとき、私たちはあなたがすでにしなければならない責任と物事について考えたいと思います。 そしてまた、それらを少し左に動かして、フローを維持し、フィードバックをより迅速に取得し、より効果的に、より簡単に開発できるようにするにはどうすればよいでしょうか。 そして、それを可能にするために必要なツールは何ですか? そこで、Dockerが支援する3つの異なる非常に具体的な領域、つまりシフトレフトと開発者がより簡単に開発できるようにすることについて説明します。

 

開発環境のシフト (4:20)

まず、開発環境と、Dockerがこれにどのように役立つかについて話しましょう。 さて、多くの人がすでにこのアイデアを持っており、コンテナがこれにどのように役立つかを考えていると思います。 そのため、繰り返しになるものもあれば、初めてのものもあるかもしれません。 まず、サンプル アプリケーションから始めましょう。 私たちのアプリの多くは、さまざまなサービスで構成されています。 この特定のアプリケーションであるカタログサービスは、そのデータをPostgreSQLデータベース、イメージ、およびAWS S3などのブロブストレージに保存し、外部のインベントリサービスからインベントリデータを取得します。 さらに、更新イベントをKafkaに公開して、他のサービスにそれらの変更を通知できるようにし、通知や電子メールなどを何でも送信できるようにします。 さて、問題は、テスト環境で開発環境をどのように設定するかということです。 さて、さまざまなチームや組織と話し合う中で、さまざまな方法が見てきました。

最初の選択肢は、これは十分に複雑になり始めており、システム内には非常に多くの異なるマイクロサービスがあるため、ローカル開発環境をセットアップすることさえしないと言うことです。 変更をテストするには、Dev 環境にデプロイするだけです。 したがって、この場合、開発者はコードベースに変更を加えます。 これらの変更をコードリポジトリにプッシュします。 そこから、CI システムがテストをビルドし、それを開発環境にデプロイします。 そして、そこから、必要なさまざまなサービスすべてに接続することができます。 しかし、繰り返しになりますが、CI 環境の長さによっては、たとえ 5 分であっても、 10 分であっても、コード変更をテストするためだけに長いフィードバック ループになります。 そして、これを行うたびに、開発者はフローを離れることができ、他のリクエストが入ってくるなどします。 では、どうすればそのフィードバックループを短縮できるのでしょうか?

通常、次に表示される反復は、さまざまなサービスをすべて持っていた同じDev環境を使用できるが、今度はアプリケーションをローカルで実行してみましょう。 したがって、この場合、アプリはローカルで実行されており、Dev 環境で実行されているさまざまなサービスに接続しています。 したがって、このオプションを使用すると、開発者である私は、アプリケーションに変更を加えることができます。 これらの変更はローカルにデプロイできます。 私はそれらをテストすることができます。 私はそれが機能し、すべてを検証することができます。 しかし、問題は、開発者が 1 つのアプリケーションで 1 人で作業することがどれほど多いかということです。 通常、他の開発者が同じアプリ、または同じサービスやリソースを活用する近くのアプリケーションに取り組んでいます。 これにより、ネットワークとリソースの競合が非常に複雑になり始めます。 そして、ある開発者がデータベースを核攻撃し、他の開発者が開発を続けることができなくなった場合、再び事態は本当に複雑になります。 また、Dev環境ではこれがオフになっているため、クラウド上のこの開発環境で問題が発生した場合、開発環境の修正や問題の修正などのために別のチームを引き込む必要がある可能性が高くなります。

では、シフトレフトでは、どうすれば外側のループ、つまりCIプロセスを取り除き、それを内側に移動させることができるのでしょうか? Dockerのコンテナを実行する機能を使えば、同じ環境を模倣した開発環境をセットアップできます。 では、リモートクラウドインフラストラクチャをデプロイし、IMポリシーとそのAWS S3 バケットのすべてを管理する代わりに、マシンでMinIOやローカルスタックなどのS3 互換サービスを実行するとどうなるでしょうか。 私のアプリはまだ S3と話していると認識しています。 同じプロトコルとAPIを話していますが、今ではそのローカルコピーにすぎません。 外部のインベントリサービスに頼る代わりに、wire mockのようなツールを使用してそれをモックできるかもしれません。 したがって、私のアプリケーションはまだAPIと通信してこの場合はインベントリデータを取得していますが、すべてモックデータです。 返される応答は、私が期待するのと同じ構造にまだ適合しますが、私のアプリはモックと話しているので、そのダウンストリームの依存関係などをすべて実行する必要はありません。 また、KafkaとPostgreSQLをローカルで実行することもできます。 そして、多くのチームがすでにこの部分も行っています。 しかし、繰り返しになりますが、コンテナについて考え始めると、ここで環境を再現できるだけでなく、環境を強化し始めることができます。 したがって、この場合、Kafkaで何が起こっているのかを確認したい場合は、ビジュアライザーを実行できます。または、私がプラットフォームチームであり、Kafkaを実行している開発者をサポートしたい場合、彼らはそれにあまり詳しくないかもしれません。 もしかしたら、そのKafkaクラスタからテストメッセージを公開または消費するのに役立つツールを作成できるかもしれません。 もしかしたら、PostgreSQLのさまざまなニュアンスにあまり詳しくない人もいるかもしれません。 そして素晴らしい、pgAdminを実行し、データベースビジュアライザーを提供して、何が起こっているのかを見てみましょう。 つまり、この考え方は、コンテナを使用して開発環境を構築するだけでなく、さらに強化する コンテナサポート開発 と呼ばれるものです。 さて、素晴らしいことに、このアプリケーションがコンテナで実行されていない場合でも、これが発生することがあります。 これらすべての他のすべてのサービスをコンテナで実行でき、メインアプリはネイティブに実行できます。 そして実際、今すぐそれを試してみましょう。

 

デモ:開発環境(9:26)

VS codeに切り替えます。 また、VS Code には、先ほど見たのと同じアーキテクチャの概要を示す compose ファイルがあります。 つまり、Postgresデータベース、PGAdmin、AWSを実行するためのローカルスタックがあります。 この場合、アプリが使用するバケット、モックインベントリ、Kafka構成などを作成するツールがあります。さて、これで、Docker compose upを実行することができます。 -dを追加して、バックグラウンドで実行されるようにします。 そして、これは、合格しなければならないヘルスチェックやその他すべてがあるため、スピンアップするのに数秒かかります。 しかし、数秒でデータベースを手に入れ、すべてを稼働させました。 そして、それを待ちます。 ここでヘルスチェックが通過するのを待っているだけです。 さて、これで終わりです。 大丈夫です。 そして今、私がやろうとしていることは、実際にyard devを実行してみましょう。 したがって、このアプリケーションを自分のマシンでネイティブに実行します。 繰り返しになりますが、私はノードを使用しており、ネイティブに実行されていますが、データベースとローカルスタック、コンテナで実行されている他のすべてのものに接続しています。 だから私がやろうとしていることは、このリポジトリにいくつかのヘルパースクリプトがあり、APIに対してクエリを実行してリクエストを行うことができるということです。

したがって、この場合、私はいくつかの製品を作るつもりです。 3つ作ってみましょう。 そして、商品の名前と価格を送信するだけです。 だから、私のデータベースには3つの製品があります、それは素晴らしいです。 今、私ができることは、データベースで何が起こっているかを視覚化する必要がある場合、まあ、ブラウザに行くことができるということです。 そして、ここでPGadminを実行しており、データベースを開くことができます。 そして、あなたが疑問に思っている場合、そのパスワードは実際にはここの作成ファイルで構成されています。 それはそこにあるデフォルトのパスワードだけです。 PGAdminでそれを自動構成する方法はまだわかっていませんが、それは問題ありません。 しかし、ここでもデータベースを開くことができます。 スキーマを開くことができます。 テーブルに移動して、すべてのデータを表示してみましょう。 これらのアイテムの1つに変更を加えて、別の製品と呼びましょう。 変更を保存します。 繰り返しになりますが、データベースと対話していますが、これが事実であることを証明するために、VSコードに戻り、ID 2の製品を取得すると、更新された名前が関連付けられていることがわかります。 また、インベントリサービスからインベントリデータを取得しており、ここでもインベントリー2をリクエストすると、 15の数量が得られ、これがここに反映されます。 しかし、 3、実際には、テストするのが難しいコーナーケースをテストしています。 そのため、3 つをリクエストすると、インベントリ サービスから 500 が返されます。 そして今、私はテストすることができます、私のアプリケーションは、サービスがうまく応答していないこれらの種類のエッジケースまたはエラーケースに応答しますか。 そしてまた、他の方法では難しいかもしれないことを、私は本当に簡単に嘲笑することができます。

ブラウザに戻ると、この場合はkafbatを使用してKafkaクラスターで何が起こっているかを視覚化しています。 また、製品の作成中に公開されたメッセージも確認できます。 そして、彼らが正しい構造を持っていることなどを検証できます。 また、トラブルシューティングやデバッグにも使用します。 また、Kafkaクラスターと対話するために、さまざまなCLIコマンドやすべてを学ぶ必要はありません。 さて、話を戻しますが、これを機能させるためには、プロトコルと、アプリケーションと外部サービスとの間の抽象化に焦点を当てる必要があります。 データベースには、バイナリプロトコルがあります。 自分のマシンまたはマネージド サービスでローカルに実行されている Postgres データベースと通信する場合、同じバイナリ プロトコルを話しています。 すごい。 しかし、APIやKafkaクラスタでも同じことが言えますし、他のサービスでも、それを抽象化してローカルコピーを実行する方法があります。 また、Key Cloakのコピーをローカルで実行して、テストユーザーだけでマシン上でOAuthまたはOIDC認証をローカルに実行し、アプリケーションが持つさまざまなユーザーやペルソナのさまざまなロールをテストできるようにするというチームも見たことがあります。 繰り返しになりますが、これらのプロトコルとサービス間の抽象化に焦点を当て、サービスにしっかりとしたAPIが備わっていることを確認すると、この種の機会がはるかに簡単になります。

この場合、コンテナ化されていないアプリから接続するために、コンテナポートをホストにもマップします。 ですから、私はPostgresを運営していました。 私はそれをホストマシンに公開するだけです。 そして、この場合、CLIを使用して接続し、ローカルホストをユーザーに接続することができます。 しかし、また、終わったら、コンテナを壊すだけです。 私のマシンには何もインストールされておらず、次のプロジェクトに進むこともできますし、明日仕事に戻ってスピンアップし、中断したところから再開することもできます。 それがここのコンテナの美しさです。 そして最後に、開発環境を構築しているとき、他のツールを追加することを検討しているとき、ビジュアライザーやメッセージパブリッシャー、または開発者がトラブルシューティング、デバッグ、より効果的に行うのに役立つ環境の構築に役立つ他のツールなど、開発環境を強化する他のものは何ですか。 これが開発環境です。

 

統合テストの移行 (15:05)

統合テストについて話しましょう。 統合テストは、多くの人が統合テストとは何かについて異なる考えを持っているため、楽しいものです。ここでは、それを定義するために少し時間を費やします。 具体的には、コードをプッシュした外側のループのこの部分を見て、アプリケーションが外部依存関係で動作することを検証したい場所、データベース、多くの点で開発で見たものなど、テストループでそれをどのように行うかを見ています。 繰り返しになりますが、テストを行えば行うほど、これは通常、デプロイ前の最後のステップです。 したがって、ここでのループ内のテストカバレッジが優れているほど、コードをより頻繁にデプロイすることに慣れます。

さて、統合テストには多くの課題が伴います。 さまざまなサービスを管理する必要があります。 そして、これらをCIで実行するときは、すでにどこかで稼働させておくか、スピンアップする必要があります。 ですから、ライフサイクルの管理、またはこれらをサポートおよび維持するためのインフラストラクチャのみの管理を開始する必要があります。 テスト間でこれらの異なる各サービスにリセットするにはどうすればよいですか? テストの実行ごとにデータをリセットする必要があるテストスイートがあることがわかっている場合もあれば、各テストが相互作用する可能性のあるデータに関する異なるルールや期待値を持つなど、このスイート全体を一度に実行できる場合もあります。 そもそも、どうやって書くのでしょうか? それを踏まえて、サービスのライフサイクルを管理する必要がある場合、実際にテストを作成する前に、それらをどのように設定すればよいのでしょうか。 また、すべてのものをクラウドにスピンアップする能力がない場合、またはCI環境が活用している可能性のある場所で、それをローカルでどのように実行しますか?

そして、できれば、私たちが望んでいるのは、理想的なテストピラミッドに向けて取り組むことです。 そのため、下部にユニットテストがあります。 統合テストがあり、統合テストが多ければ多いほど、アプリケーションが他のサービスとうまく連携することがわかってきます。 しかし、多くの場合、これらの異なるサービスを管理する必要があるため、これは難しいことがわかります。 そのため、多くの場合、チームはテストの砂時計で終わり、「はい、統合テストがあまり行われていないのは大変だからです」という感じになります。 ステージング環境や本番環境などにデプロイするだけです。 また、デプロイされたら、エンドツーエンドまたは UI テストをさらに行う予定です。 さて、繰り返しになりますが、デプロイして期待しないように、適切なテスト構造を得るにはどうすればよいかを考えたいと思います。 しかし、コードが公開される前に自信を持つことができます。

 

Testcontainersの紹介 (17:43)

そのために、Testcontainersフレームワークとライブラリについて説明します。 つまり、Testcontainersは、ここで述べているように、テスト依存関係の一時的な軽量インスタンスを提供するためのライブラリのオープンソースコレクションです。 結局のところ、それはプログラマティックコンテナです。 以前は、Docker compose upと言えるComposeがあり、それをYAMLドキュメントで宣言しましたが、Testcontainersを使用して、これは非常にプログラム的なアプローチでした。 そして、はい、ここにはたくさんの数字、ハブプルの数、および組織がそれを使用しているかを確認できます。 そして、いくつかの大きな会社の名前があります。 実際、Netflixは、Testcontainersがエンジニアリング文化をテスト文化にするのにどのように役立ったかについてかなり語っており、それを見るのは本当に魅力的でした。

しかし、繰り返しになりますが、このプログラムによるアプローチにより、これをテスト自体のライフサイクルに組み込むことができます。 さて、この例では、この特定の画像のpostgresコンテナに関連付けられたpostgresという変数名postgresで定義されたコードスニペットがあります。 この場合、このイメージはDocker Hubから来ていますが、これは独自の内部レジストリからの独自のイメージにすることもできます。 これを実行しているコードに、プライベート レジストリからプルできる資格情報がある限り、どこからでもイメージを使用できます。 したがって、これをテストにプラグインすると、テストの実行前にコンテナを開始し、テストを実行してから、完了したらコンテナをクリーンアップできます。 また、テストの範囲に応じて、このスタートアップの分解をすべてのテストで行うか、一連のテストで行うか、または何でも選択できます。これはプログラムインターフェイスの一部であるため、その制御が可能です。

現在では、データベース、メッセージキュー、AI機械学習モデルなど、多くの一般的なユースケースに対応する多くの頼りになるモジュールとすぐに使えるモジュールがあります。 ですから、本当に良いモジュールがたくさんあります。 実際、私はそれらをブラウザでここに引っ張り出します。 そのため、さまざまなモジュールがあり、さまざまなカテゴリを見ることができます。 そして、あなたはこれらのうちの1つを拾ってそれを使うことができます。 また、多くの企業がTestcontainersを使い始めると、独自のモジュールを作り始めるので、実際にはモジュールは単なるラッパーであり、Testcontainersがもたらすプリミティブの上にある別の高レベルの抽象化のようなものです。 例えば、Kafkaを例にとると、Kafkaが1つのコンテナで実行できるものになる前は、Zookeeperを実行する必要がありました。 そして、私はKafkaモジュールを使用します。 そして、はい、それは私がKafkaのワンライナーを持っているように見えますが、舞台裏では、実際には、Zookeeperを起動し、複数のサービスを接続し、ヘルスチェックが合格するのを待って、Kafkaを起動するための抽象化です。 正直なところ、かなりクールな抽象画です。 そのため、多くの企業や組織が、独自のサービスやワークフローなどをサポートするための独自のモジュールを作成し始めるでしょう。

さて、これらのテストを書いていて、ここですぐにデモを行うとき、開発者としてこれらのテストを記述し、ローカル マシンで動作を検証できることがよくあります。 さて、CIを取得するとどうなりますか? また、多くのCI環境では、DockerでDockerを実行できない場合や、Kubernetesポッドで実行していて、対話するためのDocker CLIやDockerエンジンさえない場合など、少し制限されていたり、ロックダウンされていたりすることがあります。 Testcontainers Cloudは、コンテナの実行をクラウドリソースに委任できるようになったこの問題を解決するのに役立ちます。 そして基本的に、必要なときに回転し、不要になったときに分解します。 そして、それは信じられないほど速いです。 そして、それはここですぐにわかります。 繰り返しになりますが、特にCI環境では、非常に貴重なリソースです。

 

デモ: Testcontainers (21:30)

それでは、IntelliJにジャンプします。 そして、このIntelliJプロジェクト、これがSpringbootアプリケーションです。 そして、ここにテストがありますので、そのブレークポイントを削除します。 基本的には、アプリケーションをスピンアップしてAPIをヒットし、データベースに物が保存されていることを検証します。 また、Redisも使用しています。 ですから、繰り返しになりますが、すべてが機能することを確認してください。 この特定のテストケースは、Postgresデータベースをスピンアップし、Redisをスピンアップするという抽象を拡張しています。 さて、私がただ呼び出すクールなことの1つは、これはSpringbootフレームワークの一種の特別な統合であり、Postgresが起動すると、 公開されたポートと表示されます 5432。 さて、これは必ずしも 5432でホストに公開されるわけではありません。 使用するエフェメラルポートを選択するだけです。 しかし、サービス接続アノテーションは基本的に、これはコンテナです、それを見て、Postgresコンテナであることが判明し、実行中のコンテナから構成を抽出して、残りのSpring構成も更新することを示しています。 したがって、この場合、ランダムなポートを選択するだけだとしましょう 50000。 そのため、Postgres がポート 50000で起動すると、JDBC URL は、その公開ポートのコンテナを指すように自動的に再構成されます。 繰り返しになりますが、私はそれについて何もする必要はありません。 ここでのRedisについても同じことが言えます。

それでは、これらのテストを実行してみましょう。 それらすべてを実行しましょう。 そして、これを行っている間、私はここの側面またはダッシュボードでDocker Desktopを引っ張るつもりです、そしてここで物事が始まると、私は今これをTestcontainersクラウドで実行していることがわかります。 だから、最初にそのデモをやります。 オプションを手に入れました。 そのため、コンテナを引っ張ってここで何かを始めていることがわかりますが、実際には私のローカルマシンでは何も実行していないことに気付くでしょう。 そして、それは問題ありません。 これでも、私のテストパスはコンテナを使用しています。 また、この場合は、クラウドで不足しているコンテナに接続するために何もする必要はありませんでした。 さて、キックについては、先に進んで、今すぐローカルで実行するように再構成します。 そしてこの場合、ブレークポイントを設定したいと思います。 ここで戻りましょう。 そして今、私はこの特定のものをデバッグしましょう。 右クリックメニューが画面共有に表示されなかったことは知っていますが、まあ、この特定のテストを実行しています。 ブレークポイントを設定します。 コンテナが起動したことがわかります。 そして、ブレークポイントがヒットするのを待ちましょう。 大丈夫です。 したがって、ブレークポイントがヒットします。

そして、ここでダッシュボードを全画面表示にしてみましょう。 では、データベースを見てみましょう。 そして、私は実行して、テストユーザーとして接続しましょう。 そして、ここにテーブルが表示されます。 デモ エンティティから 星 を選択します。 そこに価値があることがわかります。 そして、テストをします。 ここで引き上げます。 値が何らかの値を持つことを期待していることを確認します。 だから、今からそれを調整していくつもりです。 したがって、デモエンティティの更新設定値は「テストに失敗する別の値」と等しくなります。 そして、もう一度選択すると、更新されていることがわかります。 大丈夫です。 ここでIntelliJに戻りましょう。 そして、ここでクエリを実行するように指示しましょう。 したがって、ここでの結果オブジェクトには、テストに失敗する他の値と他の値があることがわかります。 繰り返しになりますが、ここではデータベースからプルするライブデモです。 さて、明らかに、これはテストに失敗します。 テストが不合格になるなど そして、実際にそうしている間にも、すべてのテストや他のコンテナはすでに死んでしまっています。

また、Testcontainersフレームワークを使用すると、テストが失敗したことがわかります。 ここに出力が表示されます。 繰り返しになりますが、プログラムでコンテナをスピンアップして、「これが私のアプリケーションに必要なものです」とだけ言うことができます。 そしてこの場合、それを私のspringbootコードにプラグインするのは非常に簡単です。 しかし、SDKはさまざまな方法で機能しています。 異なる言語、異なるフレームワークなど。 ここには、本当に、本当にクールな価値がたくさんあります。 そして今、再び、私はこのコードをコミットすることができます。 私はそれを私のコードリポジトリにプッシュすることができます、私のCI / CDシステムはパイプラインでこれを実行するか、TestcontainersCloudを使用することができます。 そして、それはまったく同じように機能します。 そして今、私は自分のコードが本番環境で期待どおりに動作するという自信がはるかに大きくなりました。

 

脆弱性評価のシフト (26:32)

最後にお話ししたいのは、脆弱性評価のシフトと、セキュリティ全般についてです。 SDLCに話を戻すと、開発者からよく聞くことの1つは、コードをプッシュしてビルドやテストを待たなければならず、最終的にはセキュリティ評価が実行されるのを待たなければならないということです。 そして、プロセスのずっと後になってから、おっと、依存関係が古くなっている、またはここで何かを修正する必要があると聞こえます。 では、どうすればそれを少し左に動かして、少し早く物事を解決できるでしょうか?

現在、コンテナは、アプリケーションのパッケージングとセキュリティについての考え方に、異なるアプローチと戦術をもたらしています。 したがって、コンテナを使用して、環境内でアプリケーションを構築し、アプリを実行する必要があるすべての場所にアプリケーションを昇格させます。 ステージング環境に移動してVMを取得し、必要なものをすべてインストールし、本番環境でも同じものをインストールすることはもうありません。 今では、問題が発生したときに、それらすべてのマシンにパッチを適用する必要があります。 いいえ、私はイメージを構築しており、アプリケーションを実行する必要があるすべての場所でそれを宣伝しています。 つまり、アプリケーションに脆弱性がある場合は、新しいコンテナイメージをビルドするだけで済みます。 しかし、それはまた、そのイメージを開発環境でローカルにビルドできれば、コンテナイメージをプッシュオフしてCIシステムがビルドして実行する前に、コンテナイメージに問題があるかどうかを確認できるということも意味します。理論的には、CI/CDシステムがビルドしているものとまったく同じイメージをローカルでビルドし、出力と結果を取得できるはずです。 等。 そして、それこそが Docker Scout が意図していることです。

 

Docker Scoutとは何ですか? (28:20)

Docker Scout は、サービススイートの一部である製品の 1 つであり、一日の終わりに良いイメージを構築しているかどうかを知るのに役立ちます。 ランタイム構成と脆弱性、CDE、オープンソースライセンスの問題などに関する私の組織のポリシーを満たしていますか? そして、問題が見つかったときには、開発者として、どのように修正すればよいかについて、実用的な洞察を得ることができます。 さて、私が見ているさまざまな機能とさまざまなビューに応じて、それを提供するいくつかの異なる方法があり、ここではそれぞれの動作をすぐに見ていきます。

つまり、機能の1つ目は集中型ビューです。 一元化されたWebパネルを開いて、組織全体を見渡すことができ、他のリポジトリやCI/CDシステムとのさまざまな統合を活用して、ソフトウェアサプライチェーン全体の洞察を得ることができます。 開発者として、推奨されるワークフローを取得し、どのように問題を修正しますか? そして、安全な開発の助けを借りて、画像分析を行い、物事がどのように発生しているかを理解することができます。

 

デモ: Docker Scout (29:31)

それでは、ここで実際に試してみましょう。 私がやろうとしていることは、まず scout.docker.com を開き、ここでデモ環境に入ります。この特定のデモ環境では、かなり多くの異なるポリシーが上部に表示され、これらのいくつかは脆弱性に基づいており、一部はそうでないことがわかります。 たとえば、この最初のユーザー (デフォルトの非ルート ユーザー) は、イメージが既定で非ルート ユーザーとして実行されるように構成されているという組織のポリシーを設定したいと考えています。 この場合、イメージは 1 つだけで、監視されており、準拠していません。 つまり、この特定の政策を見てみましょう。 この特定のイメージは準拠していません。 それでは、非ルートユーザーとして実行されるように修正しましょう。 また、コピーレフトのオープンソースライセンスやそこで注意すべき点、脆弱性評価(古いベースイメージを使用しているか、未承認のベースイメージを使用しているか)、サプライチェーンの認証が実際にイメージに添付されているかなど、他にも関連するものがあります。

つまり、これは私がどのようにやっているかについての組織横断的な視点を与えてくれるだけですか? また、新しい脆弱性が発見され、新しいCVEが発表されると、コンテナの優れた点の1つは、ソフトウェア部品表(SBOM)が基本的に、ボックスの中身やコンテナイメージの中身を示すカーゴマニフェストとして機能することです。 そのため、新しい脆弱性が出てきたら、この脆弱性がこのバージョンのこれらのパッケージに影響を与えるかどうかを単純にクロスチェックするだけです。 涼しい。 SBOMにはその脆弱なパッケージが入っていて、これを開けて「いいね」と言えるだけです。 そのCVEや、その影響を受けるイメージを見て、さらに詳しく学び、どのように修正するかなどを学びましょう。スカウトがこれをくれます。

さて、開発者として、ここにあるツールのいくつかを見てみましょう。 ここにプロジェクトがあります。 これはノードプロジェクトであり、この場合はDockerfileがあります。 これは、デモンストレーションのためだけに古いDockerfileです。 ノード 16からビルドします。 パッケージJSONをコピーします。 インストールを行ったり、アプリのコードをコピーしたりします。 それでは、先に進んでDockerビルドを行い、これをScoutデモv1と呼びます。 そして、これは構築されるでしょう。 そして、これを以前に実行したので、そのほとんどがキャッシュされるのはかなり速いです。 そして、Docker Scoutのクイックビューをすぐに実行できます。 だから、ここでヒントをくれるんだ。 そして、スカウトのデモと1をやってみましょう。 ですから、再び、そのSBOMを見て、これにはどのような問題が存在するのかを考えています。 さて、ここでCLIを操作していますが、GUIダッシュボードでもこれをすぐに行うことができます。 しかし、Scoutが認識していることの1つは、コンテナイメージが複雑であるということです。 それらは層でできています。 では、私がここに脆弱性を持っているとき、それは私が受け継いだものから来ているのでしょうか? 私は悪いベースから始めましたか? それとも、私が構築したイメージを通じてそれらの問題を導入しましたか? したがって、この場合、ベースイメージがここでかなりの数の脆弱性を導入していることがわかります。 しかし、ベースイメージをノード 16-アルパインからノード 18アルパインに変更すると、クリティカルが 1 から 0 に下がり、高は 4 から 0に、ミディアムは 9 から 0 に、低イメージも 0 になります。 だから、それはかなり良い状態です。 では、その変更を行いましょう。 大丈夫です。

ここで v2 をビルドしましょう。 そして今、私も同じことができるようになった。 Scoutのクイックビューをやってみましょう v2。 この場合、SBOMが分析されるのを待つ必要があります。 そして、これには数秒かかる場合があります。 前回このデモを行ったとき、18ではなくノード20に行ったと思います。つまり、インデックス作成を行っていることがわかります。 今はそれを手に入れました。 そしてまた、私たちはここでかなり優れていることがわかります。 しかし、ここにはまだいくつかの脆弱性があることもわかります。 ベースイメージからは取得できませんでした。 なるほど、それは素晴らしいですね。 だから、私はここで何か他のことをしました。 そして、CVEを見ることができます。 つまり、Docker ScoutはCVEです。 そして、これは私にかなりの出力を与えるでしょう。 そして、私はExpressを使用していることがわかります。 そして、私は古いバージョンのExpressを使用しています。 また、いくつかの異なる脆弱性があります。 そして、リンクをクリックしてそれについてもっと学ぶことができるとさえ教えてくれます。 CVSSスコアなどをくれます。 しかし、修正バージョンも教えてくれます。 したがって、この場合、 4173 これは修正されますが、他の2つは修正されません。 それでは、ここでバージョン番号が最も大きいものに行きましょう。 だから私は私のパッケージJSONを手に入れました。 expressをその新しいバージョンに変更します。

そして今、私のV3をやってみましょう。 そしてまた、スカウトは私を助けてくれました、そして私が良いイメージを作っているかどうかを理解するのを助けてくれましたか? このデモでは脆弱性に焦点を当てていますが、ダッシュボードで確認したように、他にも活用できるポリシーがあります。 また、CLIがあまり使いこなせない人のために、GUIをアップグレードすることもできます。 そして、私は画像を見ることができます。 そして、先ほど見たV2 を見てみましょう。 ここでも、基本イメージからの脆弱性はないことがわかります。 でも、私なりのイメージで結構紹介してみました。 そして、レイヤーごとに進めたい場合は、それも可能です。 また、これらの脆弱性が含まれていた 4171 表現されたのと同じ情報と、修正バージョンなどを見ることができます。 したがって、繰り返しになりますが、これらすべてはGUIからも利用できます。

 

総集編 (35:19)

さて、ここで締めくくりとして、結局のところ、ソフトウェアをどのように提供するかについてです。 どうすれば効果的に提供できるのか? どうすれば効率的に配信できるのか? どうすれば迅速かつ安全に配送できるのでしょうか? もちろん、流行語はたくさんあります。 ですから、シフトレフトという考え方は、「開発者の皆さん、もっとやるべきことは何かしら」と言うためのものではありません。 それは、ねえ、あなたがすでに世話をしなければならないこと、そしてあなたが考えるべきことは何ですか? そして、それを左に動かして、開発している場所やすでに時間を費やしている場所に近づけるにはどうすればよいでしょうか。 そうすれば、フロー状態を保つことができますが、それは通常、自分自身のことを言っているのですが、それが私が最も幸せなところです。 では、どうすればいいのでしょうか?

今日は、特に開発環境、統合テスト、セキュリティツールの3つの具体的な機会について話しました。 しかし、繰り返しになりますが、コンテナについて考え始めると、このプロセスを簡素化するのに役立つさまざまな方法があります。なぜなら、一度構築すれば、どこでも実行でき、コンテナを使用して開発できるためです。 本当に良い機会があります。

それでは、ありがとうございました。 ご視聴いただきありがとうございます。 これを見ていただきありがとうございます。 何かを学んだことを願っています。 ご不明な点がございましたら、お気軽にお問い合わせください。 繰り返しになりますが、私の名前はマイケル・アーウィンです。 私はここDockerのDevRelチームのメンバーです。 そして、皆さんと一緒にここにいられることを嬉しく思います。 皆様、ありがとうございました。

 

さらに詳しく

• ドッカーは初めてですか? 始めましょう。
• 注目のガイドでDocker製品を深く掘り下げます。
• Docker Newsletter を購読してください。
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。