Dockerがエンタープライズソフトウェア開発を後押しする4つの方法

このゲスト投稿では、Adnovumの地域CTOであるDavid Balakirevが、Dockerに基づくコンテナテクノロジーの利点をどのように示しているかについて説明します。 Adnovumは、コンサルティングと設計から実装と運用までのビジネスプロセスの迅速かつ安全なデジタル化を包括的にサポートするスイスのソフトウェア会社です。

—

1.コンテナは標準化された開発を提供します

ソリューションプロバイダーがターゲット環境の複雑さではなく、価値の提供に焦点を当てると、誰もが勝ちます。 これはコンテナが輝くところです。

コンテナテクノロジー製品(Dockerなど)の大規模な採用と、標準のコンテナランタイムプラットフォーム(Kubernetesなど)の継続的な普及により、開発者は考慮すべき互換性の側面が少なくなっています。 ターゲット環境に精通していることは依然として重要ですが、開発中に同じプラットフォームで作業できる限り、特定のオペレーティングシステム、インストールされているユーティリティ、およびサービスはそれほど問題になりません。 これが、新しいコンテナランタイムオプションの数が増えている理由の1つであると考えています。

オンプレミス環境を対象とするワークロードの場合、必要なオーケストレーションのレベルに基づいてランタイム プラットフォームを選択できます。 一部のチームは、Docker-Composeを介して少数のサービスを実行することを決定しますが、これは開発およびテスト環境では一般的であり、生産的なインストールでは前代未聞ではありません。 本格的なコンテナオーケストレータを保証するユースケースでは、Kubernetes(およびOpenShiftなどの派生物)が依然として支配的です。

クラウド向けに開発している人は、多数のオプションから選択できます。 Kubernetesはすべての主要なクラウドプラットフォームに存在しますが、セミマネージドサービスからフルマネージドサービスまで、モノリシックワークロードを持つユーザー向けに、これらのシンプルなWebアプリケーション(Azure App ServicesやGoogle Cloud PlatformのApp Engineなど)を公開するためのオプションもあります。

サーバーレスに挑戦する場合、デプロイユニットは通常、コンテナイメージまたはソースコードのいずれかであり、プラットフォームがコンテナに変わります。

これらすべてのオプションを使用して、お客様がコンテナテクノロジーをどのように採用したかを追跡することは興味深いことです。 中小企業のIT戦略は、私たちのようなソリューションプロバイダーを利用することに迅速に反応しているように見えました。

しかし、大企業も追いついてきています。 私たちは、企業のお客様がコンテナやその他のクラウドネイティブテクノロジーを使用してソフトウェアを構築および出荷することの利点を認識する傾向を歓迎します。

全体として、コンテナとしての輸送ソリューションが標準になりつつあると言えます。 AdnovumではDockerを使用しており、開発者にとって具体的なメリットが見られました。 これらの利点をもっと見てみましょう。

2.露出が制限されているということは、セキュリティが強化されていることを意味します

(従来のOSパッケージとは対照的に)コンテナプラットフォームをターゲットにすると、セキュリティにも影響が及びます。 たとえば、完全に管理された Kubernetes プラットフォームが与えられたとします。 つまり、クライアントのITチームは、安全な方法でクラスターを構成および運用する責任があります。 このような場合、開発者は私たちが提供するアプリケーションに注意を向けることができます。 コンテナテクノロジーのおかげで、さまざまな攻撃や脆弱性にさらされることをさらに制限できます。

これは、アプリケーションに厳密に必要なものだけをパッケージ化することで、攻撃対象領域を減らすことができるというコンテナーの基本的な考え方と結びついています。 これは、イメージを 最初から 構築するか、成果物を囲む安全な基本イメージを選択することで実現できます。 Docker Hub でセキュリティで保護されたベース イメージを選択する場合は、検証済みのパーティによって生成されたコンテナー イメージをフィルター処理することをお勧めします。

また、完全なパッケージ化プロセスが開発ツールによって処理される場合もあります。 私たちは多くのWebアプリケーションプロジェクトでSpring Bootを使用しています。 Spring Boot にはビルド パックが組み込まれており、効率的かつ信頼性の高い方法で Web アプリケーションから Docker OCI イメージをビルドできます。 これにより、開発者は基本イメージを探す必要がなくなり、さまざまな最適化を行う必要性が軽減されます (ただし、完全に排除されるわけではありません)。

Docker Desktop を使用している開発者は、ローカルセキュリティスキャンを試して、コードやアーティファクトリポジトリに入る前に脆弱性を見つけることもできます https://docs.docker.com/engine/scan/

3. コンテナは多様な開発者環境をサポート

AdnovumはWebおよびモバイルアプリケーションの開発を専門としていますが、これらの境界内では幅広いテクノロジーを利用しています。 このような異種環境をサポートするのは難しい場合があります。

Linuxで動作するスプリングブート開発者と、MacでAngularフロントエンドを開発する別の開発者がいると想像してください。 どちらも、マシン上でプロジェクトを開発するために一連のツールと依存関係に依存しています。

• ローカル・データベース・インスタンス
• 第三者サービスのテストダブル(モックなど)
• ブラウザ — 場合によっては複数のバージョン
• ランタイムやビルドツールなどの開発者ツール

私たちの経験では、これらのツールがネイティブにインストールされている場合、複数のオペレーティングシステムでこれらのツールをサポートするのは難しい場合があります。 代わりに、これらのできるだけ多くをコンテナにプッシュしようとします。 これにより、開発者エクスペリエンスを調整し、プラットフォーム間でメンテナンスコストを削減できます。

WindowsまたはMacで作業している開発者は、コンテナを実行できるだけでなく、いくつかの追加機能をもたらすDocker Desktopを使用できます( Docker DesktopはLinuxでも利用できますが、Docker-engineを直接使用することもできます)。 たとえば、 docker-compose をすぐに使用できるため、さまざまなオペレーティングシステムにインストールできることを心配する必要はありません。 このような多くのツールでこれを行うと、サポートチームの認知的およびコストを大幅に削減できます。

この方法で依存関係をアウトソーシングすることは、開発者が一度に複数のプロジェクトで作業する必要がある場合にも役立ちます。 結局のところ、データベース、ブラウザ、およびツールの複数のバージョンをインストールすることを楽しんでいる人は誰もいません。

通常、この手法は最近のプロジェクトに適用できますが、Dockerが大量に採用される前のテクノロジーを備えた古いプロジェクトの場合、まだ宿題があります。

4.コンテナは再現性を高めます

プロのソフトウェアメーカーとして、私たちはクライアントに優れたソリューションを提供するだけでなく、懸念事項(機能またはセキュリティ)がある場合、アーティファクト(通常はWebアプリケーションのコンテナイメージ)を生成した正確なコード変更に問題を追跡できるようにしたいと考えています。 最終的には、上記のアーティファクトの修正バージョンを再構築する必要が生じる可能性がありますが、これは困難な場合があります。 これは、ビルド環境も時間とともに進化し、提供するものの互換性ウィンドウが絶えず変化するためです。

私たちの経験では、 自動化 (特にコードとしてのインフラストラクチャ)は、信頼性が高くスケーラブルなビルドインフラストラクチャを開発者に提供するための鍵です。 ソフトウェアまたはハードウェアの障害が発生した場合に環境を迅速に再作成したり、調査のために古い構成パラメーターに従ってインフラストラクチャコンポーネントをプロビジョニングしたりできるようにしたいと考えています。 私たちの戦略は、AnsibleやTerraformなどのツールを使用してすべてのインフラストラクチャを管理することであり、エンジニアは手動でサービスを管理することを避けることを強くお勧めします。 これは、データセンターとクラウド環境にも当てはまります。

可能な限り、サービスを従来のパッケージとしてインストールするのではなく、コンテナーとして実行することをお勧めします。 NGINX や PostgreSQL などのトレンドのインフラストラクチャサービスの多くは、 Docker Hubにあります。

ハーメチック ビルド をプッシュしようとするのは、独自の依存関係をブートストラップできるため、特定の CI/CD プラットフォームが提供するビルド コンテキストにインストールされているものへの依存度が大幅に低下するためです。従来、マシンにインストールされているブラウザーに依存する自動 UI テストのサポートには課題がありました。 私たちのプロジェクトの数が増えるにつれて、ブラウザのバージョンに対する彼らの期待は分かれました。 これは、自動化に専念してもサポートがすぐに困難になりました。 その後、Node.jsやJava JDKなどのツールでも同様の課題に直面し、需要に追いつくことはほとんど不可能でした。

最終的に、自動ビルドにブートストラップとコンテナを採用し、プロジェクトに必要なChromeまたはJavaのバージョンをチームが定義できるようにすることにしました。 CI/CD パイプラインでは、必要なバージョンの依存関係がまだキャッシュされていない場合は、ビルド前にダウンロードされます。

不変性 とは、依存関係と製品の構築後に変更されないことを意味します。 残念ながら、これはDockerタグの仕組みではありません。 実際、Dockerタグは設計上変更可能であり、 SemVerに慣れている場合、最初は混乱する可能性があります。

あなたのDockerfileが次のように始まるとしましょう:

アクメから:1.2.3

独自のイメージを(再)ビルドするときはいつでも、同じ基本イメージが使用されると仮定するのは論理的です。 実際には、誰かが同じラベルで新しい画像を公開することを決定した場合に備えて、ラベルは異なる画像を指す可能性があります。 彼らはいくつかの理由でこれを行うかもしれません:時には必要に迫られて、しかしそれはまた悪意のある理由である可能性があります。

以前とまったく同じ画像を使用することを確認したい場合は、 ダイジェストを介して画像の参照を開始できます。 これは、使いやすさとセキュリティのトレードオフです。 ダイジェストを使用すると、真に再現可能なビルドに近づきますが、基本イメージの作成者が同じタグで新しいイメージ バージョンを発行した場合、ビルドは最新バージョンを使用しなくなります。 どちらの側に傾いている場合でも、信頼できるソースからの基本イメージを使用し、パイプラインに脆弱性スキャンを導入する必要があります。

不変性(そのすべての課題)、自動化、および気密ビルドを組み合わせることで、古いバージョンのコードを再構築できるようになります。 バグを再現するため、または修正されたアーティファクトを出荷する前に脆弱性に対処するために、これを行う必要がある場合があります。

再現性への道のりにはまだ改善の機会がありますが、途中でコンテナを採用することは 、 私たちが再び下す決定でした。

結論

コンテナ、特にDockerは、小規模なショップから企業まで、すべての開発者グループにとって大きな後押しになる可能性があります。 ほとんどのトピックと同様に、ベストプラクティスを知ることは、経験と学習のための適切なソースを使用することによってもたらされます。

Dockerの幅広い機能を最大限に活用するには、 必ずドキュメントを参照してください。

Adnovumが企業や組織のデジタルの可能性に到達するのをどのように支援しているかについての詳細は、当社の Webサイトにアクセスしてください。