DEV Community

tonipetov for Software AG Tech Community

Posted on • Originally published at techcommunity.softwareag.com on

Moving to Containers with Command Central Builder for Docker

How Command Central "infrastructure as code" capabilities help you with your container and cloud journey

Learn how you can build custom Docker images for Software AG Digital Business Platform products using the Command Central Builder for Docker and a library of default templates from GitHub®.

Issue 4, 2018 Download PDF

Containers, cloud and Command Central

Command Central is a DevOps tool for automated provisioning, migration, configuration, administration, asset deployment and monitoring of the Software AG Digital Business Platform. Traditionally, it is used for on-premises deployments of physical hardware and virtual machines, but it does not stop there. The fundamental capabilities of Command Central template-based provisioning and "infrastructure as code" are applicable to the world of containers and immutable infrastructure. Command Central Builder for Docker natively integrates into the standard Dockerfile-based build process and helps you to adopt containers technology for your applications running on top of Software AG products.

How the build process works

To build a Docker image using the Docker builder you will need:

  1. Dockerfile
  2. Command Central composite template.yaml file
  3. Docker engine for Linux®, Mac® or Windows® 10
  4. Access to Software AG product, fix and license repositories on Empower SDC or hosted on Command Central server in your network

Dockerfile

The builder Dockerfile is a standard Docker build file that includes four key instructions that control the build process. Let’s review all of them individually.

FROM softwareag/commandcentral-builder:10.3 as builder RUN $CC\_HOME/provision.sh myTemplate && $CC\_HOME/cleanup.sh FROM centos:7 as base COPY –from=builder /opt/softwareag /opt/softwareag EXPOSE 1234 ENTRYPOINT /opt/softwareag/some/bin/runme.sh<font face="Arial, Open Sans, PT Sans, Lato"><span style="white-space: normal;">
</span></font>

The first instruction (FROM … as builder) brings in the Docker builder tooling that comes as a Docker image itself. The image is custom-built to include configuration for product, fix and license key repositories that are used by the provisioning operations during the build process.

The second instruction (RUN provision.sh) runs template-based provisioning operations declared in the template.yaml file, which can be provided next to the Dockerfile or prepackaged on the Command Central Builder for Docker image. When the RUN instruction completes, the new Docker image layer has / opt/softwareag directory populated with installed products, fixes and a configured instance of the product runtime, just like during traditional provisioning against a remote VM managed by Command Central server. The cleanup.sh script deletes files that are not needed for the container run-time, for example, Update Manager and its metadata, resulting in smaller image sizes. This instruction is the most important step in the build process.

The third instruction (FROM … as base) controls the base layer for the target image. Typically it is a standardized base OS image or an image with the Java® runtime on it. Using the same base layer across multiple images improves the download performance and optimizes the storage.

The fourth instruction (COPY –from=builder) copies the /opt/ softweareag installation folder from the builder stage into the final image. The instruction can be a single COPY command or a list of COPY’s of individual subfolders and files to achieve even smaller, highly optimized image size.

The Dockerfile can include other instructions like EXPOSE’ing runtime ports, defining an ENTRYPOINT script or any other valid instructions supported by the Docker Engine.

Template.yaml

The template.yaml file used by the Command Central Builder for Docker normally includes instructions for product and fix installation, runtime instance creation and its configuration. Below is a generalized example of the template.yaml file with inline comments.

alias: myTemplate  templates:   myContainer:      fixes: ALL             # install all fixes      products:           myProduct:          # install myProduct            myInstance:      # create myInstance of myProduct               my.port: 1234                   # port configuration               configuration:                 configurationType:                    configurationInstance:                     property1: value1         # configuration property1                     property2: value2         # configuration property2 layers:    runtimes:       productRepo: ${repo.product}            # product repository       fixRepo:     ${repo.fix}                # fix repository       templates:   myContainer  provision:    default:       runtime: ${nodes}

Key points:

  1. The template should define only a single runtime instance. Different product runtimes should run as different Docker containers and thus should be built as separate Docker images
  2. Baking as much configuration as possible into the Docker image allows to achieve (almost) immutable infrastructure, which brings a lot of benefits for running containerized applications. Mutable configuration aspects can be addressed by leveraging product specific capabilities like dynamic re-configuration using environment variables.
  3. The templates used for building Docker images are the same templates that can be used for traditional provisioning. This allows developing and testing templates iteratively outside of the Docker build process and then use them for both traditional and containerized deployments.

Build Process

The builder process is as simple as running docker build command in the folder that contains the Dockerfile:

docker build -t myimage .

Building Docker images using default templates

The default library of Command Central templates and Docker build files is available at https://github.com/SoftwareAG/sagdevops-templates and the user guide is available at https://github.com/SoftwareAG/sagdevops-templates/wiki/Building-default-Docker-images

As a quick start, copy licenses.zip file with 10.x release Software AG license keys for Linux into sagdevops-templates/ licenses folder and build your custom Command Central Builder for Docker image with your Empower SDC credentials using docker-compose build command from the infrastructure folder:

cp saglicenses.zip sagdevops-templates/licenses/licenses.zip cd sagdevops-templates/infrastructure export EMPOWER\_USR=you@company.com export EMPOWER\_PSW=\*\*\*\*\* docker-compose build

After you successfully built a Command Central Builder for Docker image, you can build product images and test run the containers by executing docker-compose up command from the containers folder. For example, to build and run a Universal Messaging container, execute the following commands:

cd sagdevops-templates/containers docker-compose up -d universal-messaging docker-compose ps

After a minute you can access Command Central and Universal Messaging containers using auto-allocated ports displayed by the docker-compose ps command.

Summary

You can use Command Central DevOps tooling for traditional on-premises provisioning as well as containerized deployments. You can build managed (by Command Central) and unmanaged Docker images for 10.x releases, having great control of what exactly goes into your images to satisfy your security requirements or requirements from your orchestration engine.

Important: For up-to-date detailed instructions visit https://github.com/SoftwareAG/sagdevops-templates

Top comments (0)