Zowe extensions such as services and plug-ins that use Zowe component packaging can be used within a Zowe container environment. To do this, you must deliver the extension as a container image that is compatible with Zowe containers. You can follow Zowe's container conformance criteria to understand and achieve compatibility.
Note: Missing z/OS dependencies must be checked before creating and adding Zowe extension containers.
You can add extension containers to a Zowe container environment the same way as Zowe's core components by completing the following steps.
- Build and publish an extension image to a registry. For details, see Build and publish an extension image to a registry.
- Define a deployment or job object. For details, see Define Deployment or Job object.
- Start the extension from the deployment or job definition. For details, see Start your component.
An extension must have a container image to run in a Zowe container environment. To create such images, you can use a Dockerfile and refer to the following examples of building images for Zowe core components.
The core components define component Dockerfiles and use GitHub Actions to build images. For example,
explorer-jesis a component which has built-in web service. To build the images, this component defines a Dockerfile at https://github.com/zowe/explorer-jes/blob/master/container/Dockerfile and defines a GitHub Actions workflow at https://github.com/zowe/explorer-jes/blob/master/.github/workflows/build_test.yml.
explorer-ipis a Zowe App Server Framework plug-in but does not have a built-in web service. It follows Zowe's container conformance criteria. It defines a Dockerfile at https://github.com/zowe/explorer-ip/blob/master/container/Dockerfile. Similar to
explorer-jes, it also defines a GitHub Actions workflow at https://github.com/zowe/explorer-ip/blob/master/.github/workflows/explorer-ip-images.yml to build the images.
The following GitHub Actions are used by the core components to build conformant images. They might not be completely reusable for you, but are provided as an example.
- zowe-actions/shared-actions/docker-prepare will prepare required environment variables used by following steps.
- zowe-actions/shared-actions/docker-build-local can build the Docker image directory on the GitHub Actions virtual machine. By default, the Docker image directory is
ubuntu-latest. You can use this action to build images for
- zowe-actions/shared-actions/docker-build-zlinux can build Docker image on a
Linux on Zvirtual machine. This is useful if you want to build images for
- zowe-actions/shared-actions/docker-manifest can collect all related images and define them as Docker manifests. This is useful for users to automatically pull the correct image based on cluster node CPU architecture, and also pull images based on popular tags such as
After a component image is built, it is recommended that you publish it to a container registry before adding it to the Zowe container environment. Alternatively, you can use
docker save and
docker load commands to copy the offline images to your Kubernetes nodes.
To start your component in Kubernetes, you must define a Deployment if your extension has built-in web services, or a Job object if your extension is a Zowe Application Framework plug-in without built-in web services.
Deployment for your component, you can copy from
samples/sample-deployment.yaml and modify all occurrences of the following variables:
<my-component-name>: this is your component name. For example,
<my-component-image>: this is your component image described in Build and publish an extension image to a registry. For example,
<my-component-port>: this is the port of your service. For example,
Continue to customize the specification to fit in your component requirements:
spec.template.spec.containers.resources: defines the memory and CPU resource required to start the container.
spec.template.spec.securityContextand so on.
Job for your component, you can also copy from
samples/sample-deployment.yaml. Then, modify all entries mentioned above and make the following changes:
kind: Jobspec: template: spec: restartPolicy: OnFailure securityContext: ...
After you define your component
Job object, you can run
kubectl apply -f /path/to/your/component.yaml to apply it to the Kubernetes cluster that runs Zowe.
- If it's a
Deployment, you should be able to see that the component pod is started and eventually reached the
- If it's a
Job, you should be able to see that the plug-in pod is started and eventually reached the
Now you can follow common Kubernetes practice to manage your component workload.