Containerize STK

This topic describes how to create docker containers to package Systems Tool Kit® (STK®) Engine alongside your custom applications and scripts.

You can deploy STK Engine using docker containers, facilitating lightweight and reproducible deployments of your STK analytical workloads.

The capability described in this section is for packaging STK Engine in headless containers with no user interface and no graphics. Containers are a good fit to support noninteractive headless services or command line-driven workflows. Use cases where STK computations need to run unattended are well-suited for containers. This includes workflows where:

  • You need to reevaluate computations in reaction to new data or to new inputs.
  • You need to expose computations as services invoked with different parameters.
  • You need to invoke computations with a large set of input parameters in batch mode.

In these use cases, there is a need for a standalone compute component that can create or reuse an STK scenario, vary some inputs, and provide updated results.

If your goal is to run the full STK application user interface in order to interact with the application using your mouse and keyboard, containers are not the best fit. In those use cases, architectures like Virtual Machines (VMs), Desktop as a Service, or Virtual Desktop Infrastructure (VDI) are more appropriate. In these approaches, a fully functional desktop operating system is hosted on premises or in the cloud, and users interact with the application through either remote desktop or their web browser where the application is streamed. An example of such an architecture is the STK Cloud® application, where you can connect using a web browser to a full desktop session running the STK application with the user interface.

Containerization examples

The STK application install provides container samples for both Windows and Linux. These are in separate folders in <STK install>/CodeSamples/STKCodeSamples.zip/Containerization. More examples and updates are available on the The STKCodeSamples GitHub repository.

To help you get started with containerizing your STK Engine deployments, AGI provides these examples that illustrate the following use cases:

Example Description
Base STK Engine Docker image (stk-engine-baseline) Provides the STK Engine installation with the runtime configuration (environment variables) to run STK Engine applications.
Custom Environment example (custom-environment) Provides the environment required to communicate with the Yum and Pip package managers in your organization. This is optional if you are directly connected to the internet. It is required if you are using a proxy/firewall or isolated network requiring different certificates, settings, or both.
Connect STK Engine Docker image (stk-engine-connect) Derives from the base STK Engine image and runs the connectconsole executable to expose Connect through a socket from the container.
Python STK Engine Docker image (stk-engine-python) Derives from the base STK Engine image and adds Python to the image.
Jupyter STK Engine Docker image (stk-engine-jupyter) Derives from the Python STK Engine image and exposes JupyterLab from the container. Go to JupyterLab in your web browser to exercise Python notebooks using STK Engine for computations. AGI also provides an example notebook.
Custom STK Engine Service Docker image (stk-engine-webservice) Derives from the Python STK Engine image and shows how to develop and include your own web service(s) in the Docker image. You can write those web services in Java and Python for Linux, and also with .NET if using a Windows container. This is just a bare-bones minimal web service example using the Flask development server and is not production ready. Please refer to the Flask documentation for best practices on how to create and deploy a production-ready web service.
STK Parallel Computing Server example (stk-parallel-computing-server) Provides three example images and composes two of them together to run a full STK Parallel Computing Server cluster. The first image, in the coordinator subdirectory, contains the STK Parallel Computing Server Coordinator. The second image, in the Python subdirectory, derives from the Python STK Engine image and includes the STK Parallel Computing Python API. The third image, in the agent subdirectory, derives from the Python image in this example and contains the STK Parallel Computing Server Agent. This project includes an example client script that demonstrates how to exercise the STK Parallel Computing Java/.NET/Python APIs to drive batch STK Engine computations and tasks.

Several of these sample images use the Yum or Pip (or both) package managers to configure the image. If you are operating in one of the following conditions:

  • connected to the internet behind a firewall or proxy
  • on isolated networks with no internet access

You may require specific TLS certificates or custom configurations to access the public package repositories or internal mirrors for these repositories. AGI provides the Custom Environment example (custom-environment) for your convenience in case you are running these examples in such a constrained network. If you are directly connected to the internet, you will not need to build the images provided in that example.

Each example provides:

  • A README.md file with instructions and explanations on what the example does and how to build and run the container either using directly the Docker command line or using Docker Compose (i.e., using the docker-compose.yml file in the same folder)
  • A Dockerfile containing all the commands to assemble the image
  • A docker-compose.yml file, enabling the use of Docker Compose to build and run the images

The images are built upon each other, and you need to build them in the correct order. The hierarchy of images looks like this:

Hierarchy of containerization images

UBI stands for Universal Base Image. For more information, see Red Hat Universal Base Image 8.

The dark arrows at the bottom represent a docker compose dependency. The remaining arrows mean that an image uses another one as a base, a "from" dependency.

In order to experiment with one of these examples, locate the set of images that you need to build for that particular example in the diagram above. Then browse to the corresponding folder in the code samples and look for the directions in the README.md in that directory.