Introduction: Docker Support In Visual Studio IDE

In the 6.0 Visual COBOL/Enterprise Developer products, we have added additional tooling for working with Docker Images and Containers in the IDEs when using native COBOL projects. We understand that increasingly customers are looking to containerisation as a means to modernise their codebase. With this in mind, we want to help streamline the developer experience. In this post, we will cover what a developer can expect from the new support when working with native COBOL projects. This assumes some basic understanding of containerisation concepts. The Eclipse IDE product has also added containerisation support, but will not be covered in this post.

Enabling Visual Studio container support

Before enabling the container support, the developer should ensure the corresponding Micro Focus base images have been built and are present on the system. There is a base image that will be used to build the developer's source code and another for running the built artifacts.

• Visual COBOL Build Tools / COBOL Server
• Enterprise Developer Build Tools / Enterprise Server

Once the base images are present, we can now enable the support in the IDE.

• Right click on the project node in Solution Explorer
• Click Add... > COBOL Docker Support

This will add a Dockerfile into the project and also provide a new debug launch profile called Project (Docker). Behind the scenes it also updates your project file to indicate the support is enabled.

Understanding the default Dockerfile

By default, when container support is added to a project, a Dockerfile is added. The Dockerfile is structured to support a quick develop and test cycle. When updating this DockerFile, the layer structure should be maintained in order to retain IDE support. The structure is as follows:

• base layer
  • Defines the base structure of the image.
  • This layer should contain the environment and all dependencies required by the application
  • When debugging, only this layer gets built as part of the image build process. The outputs of the container-enabled project are instead built on the host machine. It is then then volume mounted when the container starts. This means that we can avoid the overhead of creating a new Image and starting up a new container every time an edit in the project is made. Where possible, the IDE will reuse an existing running container.
• build layer
  • Defines how the project should be built when doing a build of the image
  • By default, it uses msbuild to build the project file.
  • This layer is not built when debugging.
• final layer
  • Copies the built artifacts from the build layer into a layer that derives from the production images (either COBOL Server or Enterprise Server).
  • Sets up the default entry point that should be run when the container is started. By default, this launches the build output of the COBOL project.
  • This layer is not built when debugging.

Building a Release Image

To build the Image for production use, it is possible to do it directly within the IDE or on the command line. Within the IDE, simply right click on the Dockerfile and click Build Image. This executes a docker build on the Dockerfile. This always does a full build of the image, whereas builds that are automatically triggered via debugging only include the base layer.

Launching and Debugging a Container

Docker Debug Profile

To support debugging COBOL code running inside a containerised environment, there are new debug launch profiles. These run in the same way as their non-Docker specific counterparts and provides Docker specific handling. The developer can configure these launch options in the Debug project properties page of their container enabled project. Once the developer has selected one of these profiles, it's a simple case of clicking the Start Debugging command. The IDE will build the image, start up a new container and debug the application.

Behind the scenes

Since debugging containers is a little different from debugging an application on your local machine, it's useful to have an outline of what happens when the IDE does a debug launch. The general steps are as follows:

1. Build project locally
2. Build image from Dockerfile (but only base layer)
3. Start container from new image and volume mount the output directory to a location in the container. By default, this is C:\app
4. Start the remote debugger inside the container
5. Attach IDE to remote debugger
6. Handle application launch (usually this means launching the project build artifact)

These steps are only for a first-time launch. Subsequent launches will reuse the existing container where possible. If there are changes that require a rebuild of the container, then this will be automatically handled by the IDE (e.g. if the Dockerfile was updated). This means that any edits made to the sources can be quickly rebuilt locally and tested in the containerised environment. Since the output directory is volume mounted inside the container, there is no need to rebuild the image and relaunch the container.

Advanced

If this mode of working is not suitable, it is possible to force the IDE to do a full build of the Dockerfile, rather than just the base layer. When the project configuration is set to Release, a full build of the Dockerfile will always be triggered. Coupled with the use of the Executable (Docker) debug launch profile, it is possible to handle more complex debug scenarios. To enable debugging when building for a Release configuration, the Compile for debugging setting must be enabled in the COBOL properties for the project. The developer should be careful to avoid committing this change to version control, since typically debugger artifacts are unwanted for release builds. Additionally, builds and debug start up will take longer, since a new image must be built and a container started for each debug session.

Afterword

Hopefully this post explains how the new Docker support in the IDE for 6.0 works. In my next post I will cover some of the specifics for containerising an Enterprise Server project when using the Enterprise Developer product. Be sure to check out the documentation for additional info about the support.

Don't forget to join the Visual COBOL Launch Webinar on June 24 for more: