Create Different Images for Different Development Tasks

When implementing Docker to help you with your development work you need to create and run different images to carry out different parts of the development process. By having a number of different images you can be sure that you always use the right tools for the job, and that the images you use are optimized to carry out their particular tasks.

For example, if you are building a COBOL application you need to use an image that provides the support to enable you to do that, but if you only want to execute an application the image you use does not need to include the build functionality.

Working with different images for different purposes and basing images on other images are techniques used widely across the Docker community.

For instance, on Windows, Enterprise Developer is provided as two base images. The smallest of the two is based on the microsoft/dotnet-framework image which does not have any build tools for .NET development but does include all relevant functionality for native COBOL development. The second, larger, image includes the extra build tools provided by the microsoft/dotnet-framework-build image (SDK). This image includes NuGet, .NET Framework profiles and File Tracker.

The images that include build tools all have the suffix -build in the repository name, which enables you to identify them as images ideally suited for building and testing.

Note: If you are using Enterprise Developer UNIX Components, the Enterprise Developer base image, for instance, is extended with an extra image that has the environment setup for interactive login use.

This version of the image has the suffix _login in the repository name and can then be used for creating an interactive Docker session that has the COBOL development environment setup ready for use. See the description of the docker run -ti command in the Docker documentation for more information.

Micro Focus uses similar naming and image layering schemes in the Docker demonstrations that are supplied with Enterprise Developer and recommends that you adopt the same sort of conventions.

For users of Enterprise Developer for Eclipse:

For example:

As described above, Microsoft provide microsoft/dotnet-framework and microsoft/dotnet-framework-build images and you can base your Enterprise Developer image on either of these images.
By creating one base image for Enterprise Developer based on microsoft/dotnet-framework and another based on microsoft/dotnet-framework-build you can then switch between using them depending on whether you are working with native or managed COBOL applications.

You could decide to use the -build version of the base image regardless of whether you need to use the managed COBOL features, but doing so would result in the inclusion of unnecessary files when working with native COBOL applications.
When creating the base images for Enterprise Developer you need to create a version that is specific to the bitism of the platform that it will be used on. To achieve this, the Docker demonstrations do the following:
1. Create a generic base image. This is not specific to a particular bitism and will only be used to create other images that are platform-specific.
2. Create images that based on the generic base image but are specific to 32-bit and 64-bit platforms.
  The bitisim is indicated in the images' tags. For example, the generic base image microfocus/edbuildtools:win_4.0 could have platform-specific images named microfocus/edbuildtools:win_4.0_x86 and microfocus/edbuildtools:win_4.0_x64.

For users of Enterprise Developer UNIX Components:

For example, as described above, interactive login images typically have a suffix of _login in the repository name, so when creating an image called microfocus/entdevhub:sles12sp3_4.0_x64 the interactive login image based on this image would be called microfocus/entdevhub:sles12sp3_4.0_x64_login.