Create Different Images for Different Development Tasks

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 COBOL Server rather than Visual COBOL.

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, Visual COBOL 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.

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

For example:

• As described above, Microsoft provide microsoft/dotnet-framework and microsoft/dotnet-framework-build images and you can base your Visual COBOL image on either of these images.

  By creating one base image for Visual COBOL 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.

• When creating the base images for Visual COBOL 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 container 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/vcbuildtools:win_10.0 could have platform-specific images named microfocus/vcbuildtools:win_10.0_x86 and microfocus/vcbuildtools:win_10.0_x64.