Different Ways of Building a Native COBOL Application in a Container

Note: This topic only applies to using native COBOL applications in containers. To use JVM COBOL applications in containers you need to use the functionality described in Debugging and Running JVM COBOL Applications in Containers.

When working with native COBOL applications in containers one of the decisions you need to make is which method to use for building the application when debugging or running it. This topic describes the options available and offers guidance on when each option might be most suitable for you.

When debugging and running a native COBOL application you can choose between three different methods of building and executing the application with regard to containers. To specify the method you want to use you use options on the Containers tab of the Debug Configurations and Run Configurations dialog boxes.

The different methods, the relevant options on the Containers tab, and the effects of using each are as follows:

  • Build without containers

    Specifies that the project is to be debugged or run without using any containers. Instead, the project's Dockerfile is ignored and the project is debugged or run as normal.

    Select Run on machine where the project is located (default) on the Containers tab to specify this method.

  • Build on host

    The standard Dockerfile that Enterprise Developer creates uses multi-stage builds - the "base" stage creates an image that contains all the software that is required to run the final application but does not contain the application files themselves, the "build-env" stage builds the application, and the final stage creates the image that will be run, using the "base" image as its starting point and copying other files from either the context or the "build-env" stage to create the final image.

    Using the "build on host" method results in the project being built using only the "base" stage of the Dockerfile, which means that the project is built not with the development environment in the container, but with the development environment on the host. Once the build has taken place on the host, the folder containing the build output is volume mounted to the /App folder in the container file system of the "base" stage.

    Select Use base stage from Dockerfile on the Containers tab to specify this approach.

  • Build in container

    Using the "build in container" method results in the project being built using the whole Dockerfile. This means that the project source files are copied into the container, they are then built by the development environment in the container, and the build output is then run using the deployment environment in the container.

    Select Use project Dockerfile on the Containers tab to specify this method.

Note:

When using the "build on host" or "build in container" method, Enterprise Developer creates a container for the debug or run operation then removes the container once the project finishes its execution. Each method also creates an image which is kept and used for subsequent builds.

Choosing between the different methods

If you are going to be using containers you need to choose between the "build on host" and "build in container" methods. You would only use the "build without containers" method if you wanted to use the regular, non-containerized method of debugging and running.

Choosing between the "build on host" and "build in container" methods essentially depends on which is more important: speed of the build process or consistency of the build and debug environment.

  • "build on host" can be significantly faster than "build in container" because building a project on your host computer is typically faster than building it in a container
  • "build in container" will always use the same build, debug and deployment environment; that is, the environment included in the container. Using "build on host" uses whatever environment is defined on the host, which can change over time or from host to host

As a result of these differences, one approach that you might want to adopt is to use "build on host" when your project is in the relatively early stages of development and might need many edit/build/debug iterations, but switch to using "build in container" as your project matures and stabilizes and you are less concerned with build speed and more concerned with ensuring that your project is built using a build environment exactly as used to build the deployed container.