開発作業に役立つ Docker を実装する場合は、開発プロセスのさまざまな部分を遂行するために、さまざまなイメージを作成して実行する必要があります。さまざまなイメージを用意することで、常に作業に適したツールを使用し、実行するタスクに合わせて最適化されたイメージを使用できるようになります。
たとえば、COBOL アプリケーションをビルドする場合は、そのためのサポートを提供するイメージを使用する必要がありますが、アプリケーションを実行するだけの場合は、使用するイメージにビルド機能が含まれている必要はありません。
目的に応じたイメージを使用すること、また他のイメージに基づいてイメージを作成することは、Docker コミュニティ全体で広く利用されている手法です。
たとえば、Windows では、Enterprise Developer は 2 つのベース イメージとして提供されます。2 つのうちの小さいイメージは、.NET 開発用のビルド ツールは備えていないものの、ネイティブ COBOL 開発用の関連機能をすべて含む microsoft/dotnet-framework イメージに基づいています。もう 1 つの大きなイメージは、microsoft/dotnet-framework-build イメージ (SDK) によって提供される追加のビルド ツールを備えています。このイメージには、NuGet、.NET Framework プロファイル、および File Tracker が含まれています。
ビルド ツールを含むすべてのイメージは、リポジトリ名に -build というサフィックスが付いているため、ビルドおよびテストに最適なイメージであることが一目でわかります。
このバージョンのイメージは、リポジトリ名に _login というサフィックスが付いており、すぐに使える COBOL 開発環境設定を含む対話型 Docker セッションの作成に使用できます。詳細については、Docker マニュアルの docker run -ti コマンドに関する説明を参照してください。
Micro Focus では、Enterprise Developer に付属する Docker デモンストレーションで同様の命名方式およびイメージ階層化方式を使用しており、同じ規則を採用することを推奨しています。
Enterprise Developer for Eclipse ユーザーの場合：
Enterprise Developer 用として microsoft/dotnet-framework に基づくベース イメージと microsoft/dotnet-framework-build に基づくベース イメージをそれぞれ作成し、作業対象がネイティブ COBOL アプリケーションであるかマネージ COBOL アプリケーションであるかに応じて、2 つのベース イメージを使い分けることができます。
マネージ COBOL 機能を利用する必要があるかどうかにかかわらず、-build バージョンのベース イメージを使用することもできますが、その場合、ネイティブ COBOL アプリケーションを扱ううえで不要なファイルが含まれることになります。
ビット体系はイメージのタグで示されます。たとえば、汎用ベース イメージ microfocus/edbuildtools:win_4.0 では、そのプラットフォーム固有のイメージは microfocus/edbuildtools:win_4.0_x86 と microfocus/edbuildtools:win_4.0_x64 という名前になります。
Enterprise Developer UNIX コンポーネント ユーザーの場合：
前述のとおり、対話型ログイン イメージのリポジトリ名には、通常、_login というサフィックスが付いているため、たとえば、microfocus/entdevhub:sles12sp3_4.0_x64 というイメージを作成する場合、このイメージに基づく対話型ログイン イメージは、microfocus/entdevhub:sles12sp3_4.0_x64_login という名前になります。