When implementing containers 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. Similarly, in a production environment you would use an image that contains Enterprise Server rather than Enterprise Developer.
Working with different images for different purposes and basing images on other images are techniques used widely across the container-using 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.
This version of the image has the suffix _login in the repository name and can then be used for creating an interactive container session that has the COBOL development environment setup ready for use. See the description of the docker run -ti command in the Docker documentation or the podman run -ti command in the podman documentation for more information.
Micro Focus uses similar naming and image layering schemes in the container 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:
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 JVM COBOL applications.
You could decide to use the -build version of the base image regardless of whether you need to use the JVM COBOL features, but doing so would result in the inclusion of unnecessary files when working with native COBOL applications.
The bitisim is indicated in the images' tags. For example, the generic base image microfocus/edbuildtools:win_7.0 could have platform-specific images named microfocus/edbuildtools:win_7.0_x86 and microfocus/edbuildtools:win_7.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:sles12sp4_7.0_x64 the interactive login image based on this image would be called microfocus/entdevhub:sles12sp4_7.0_x64_login.