About the contract

The auths subsection

The auths section consists of information about the container's registry. If a public image is used in the contract, you do not need the auths section because no credentials are required. The auths subsection is required only if the container images are private. This subsection does not have any image information, as shown in the following sample. This subsection needs to contain the name of the image registry and the credentials such as username-password for the same. The key must be the hostname of the Container Registry or the following string for the default docker registry:

https://index.docker.io/v1/

The following snippet shows an example for IBM Cloud Registry. For more information about using the API key, see Using client software to authenticate in automation.

auths:
  us.icr.io:
    password: <apikey>
    username: iamapikey

The compose subsection

It consists of an archive subsection. The archive subsection contains the Base64 encoded TGZ file archive of the docker-compose.yaml file. As the Hyper Protect Container Runtime image uses Docker Engine and Docker Compose to start the container, the information about the container must first be created by using a standard docker-compose file. This file is then archived and Base64 encoded and the output of this is provided as the value to the archive subsection, within the compose section. For more information, see Overview of Docker Compose.

The mount points specified under the volumes information of the docker-compose file might be aligned with the volume mount point that is specified in the workload section of the contract.

Executing a build as part of a docker compose file is not supported. Make sure your docker compose file doesn't have a build section.

Both "yaml" and "yml" formats are supported for docker-compose file. This is an example of a docker-compose file.

version: '3'
services:
  nginx:
    image: nginx@sha256:e73ba8654ba7fd1834e78a3d4e9d72ffaaa3372d42996af5c34ba3e1abc293e8
    privileged: true
    user: 0:0
    restart: always
    ports:
    - 80:80

There exist use cases in which the registry is not known when the workload section is pre-encrypted, for example, when the workload provider wants to allow the deployer to use a registry mirror or a private Container Registry. In such a case, it's possible to dynamically override the registry as well as the pull credentials. This is a coordinated effort between the workload provider and the deployer. For more information, see Using a dynamic registry reference.

Complete the following steps to get the Base64 encoded archive file. The Base64 output is available in the compose.b64 file. Go to the <COMPOSE_Folder> and run the following commands:

tar czvf compose.tgz docker-compose.yml

base64 -w0 compose.tgz > compose.b64

Make sure that the compose tgz file contains only directories and regular files. Links or pipes are not supported.

Copy the content of compose.b64 as a value of compose -> archive.

compose:
  archive: <paste the content of compose.b64 >

For this example, you'd see a response similar to the following output:

compose:
  archive: H4sIAKOFmGIAA+2RTW6DMBBGs84pRuyB8Q8k+DIRwZOGtmBkkyrcvhgnLVVV1EWkqhJv4ZHt8ednWZvqhWxcmaYzjpKhed08HETMpQRfd3k2VeRhPpEJCUxymTPkIuOALBOIG8DHq3zn4vrSjiqdLY/nsv+xb2w7nRZywlPgo/4THNm3uiKntgCWdO1aowmZnwLUTflECpwo8Jpu9NyZ2zvQgdADFEudoXyQzSu+fPPzseSvedo6qjV7mDa2anZbdH8totL6somtUlvX8K4SJshDsFKU2NmFvAZuMc9U37wceeys+Y6BI8Fi6+6vxK5RS+YFDh6RNu//tuVlZWVJd4BcjKckQAIAAA=

The play subsection

In the play subsection, you can define the workload through Pod descriptors. Each pod can contain one or more container definitions. Descriptors can be provided in one of the following ways:

• In plain YAML format in the resources subsection of play. This section is an array of descriptors and supports two types of descriptors: Pods and ConfigMaps.

  The following example illustrates how to use the resources section:

  workload: |
    type: workload
    play:
      resources:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            containers:
            - name: main
              image: ...
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  

• In the archive subsection of play, the archive is a Base64 encoded, gzipped tar file. The Pods or ConfigMaps are represented as YAML files, at the top level in this tar file. The file might also contain extra files and all the files are extracted to the host file system before starting the Pods. The current working directory is the directory in which the files were extracted, so it's possible to use a volume mount with a relative path to mount the files or directories from the YAML file.

  Example:

  workload: |
    type: workload
    play:
      archive: ${COMPOSE_VALUE}
    auths:
      us.icr.io:
        username: iamapikey
        password: Eqx0TS....
    volumes:
      test-volume:
        mount: /var/hyperprotect
        seed: workload phrase
        filesystem: ext4
  

• In a template format in the templates subsection of play. This section is an array of descriptors in the YAML format. Pods or ConfigMaps may have points of variability (POV) that are not known at the time of writing the descriptors. These POVs may be represented as templates and the values will be filled in at deployment time from information in the contract. We use go templates as the templating syntax, which is the same as used for helm charts, so templates can easily be exchanged with k8s. We support the following Built-In objects:

  • Environment: this object contains the environment variables as merged between the workload and the environment section. The object is available as {{ .Env }}.

  Example:

  workload: |
    type: workload
    auths:
     docker.io:
      password: <password>
      username: test
    play:
      templates:
        - apiVersion: v1
          kind: Pod
          metadata:
            name: busybox
          spec:
            containers:
            - name: main
              image: "{{ .Env.REGISTRY }}/hpse-docker-busybox-s390x@sha256:732efa374f1e6c964caeacab0bcb370385ee386041a14d4a32176462e3f75c7b"
              command:
              - printenv
              envFrom:
              - configMapRef:
                  name: contract.config.map
                  optional: false
            restartPolicy: Never
  env: |
    type: env
    logging:
      logDNA:
      ingestionKey: <ingestion Key of the Log Analysis instance>
      hostname: <host name of the Log Analysis instance>
      port: 6514
    env:
      REGISTRY: docker-io/test
  

  The {{ .Env REGISTRY }} expression references the REGISTRY environment variable that in this example is defined in the env section of the contract.

  The templates need to be valid YAML, so a replacement expression must be escaped if it appears as the first part of a string. Otherwise, it collides with the block mapping syntax. This is different to helm templates where expressions are applied to the textual representation of the document instead of the model representation.

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    command:
    - printenv
    envFrom:
    - configMapRef:
        name: contract.config.map
        optional: false
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: main
    image: ...
    volumeMounts:
    - name: test-volume
      readOnly: true
      mountPath: /fromHost
  volumes:
  - name: test-volume
    hostPath:
      path: /var/hyperprotect
      type: Directory
  restartPolicy: Never

The images subsection

The images subsection is meant only for an image that is signed.

<container registry>/<username or namespace>/<image name>
eg- us.icr.io/mynamespace/my-haproxy:

notary: "https://notary.us.icr.io"

cat ~/.docker/trust/tuf/us.icr.io/<username>/<imagename>/metadata/root.json

images:
  dct:
    us.icr.io/mynamespace/my-haproxy:
      notary: "https://notary.us.icr.io"
      publicKey: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQVM2Z0F3SUJBZ0lSQUxCMXBPYlpEQlRRc09GSFlxazMzaWd3Q2dZSUtvWkl6ajBFQXdJd0tqRW8KTUNZR0ExVUVBeE1mZFhNdWFXTnlMbWx2TDNCeVlXSm9ZWFF4TWpNdmJYa3RhR0Z3Y205NGVUQWVGdzB5TWpBMApNVE14TURFd01ETmFGdzB6TWpBME1UQXhNREV3TUROYU1Db3hLREFtQmdOVkJBTVRIM1Z6TG1samNpNXBieTl3CmNtRmlhR0YwTVRJekwyMTVMV2hoY0hKdmVIa3dXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU1AKWGsrelE2MlFZNjI3MWQ1cTBMZHY3SGc3QzZkMGZOUlRsQmJXekhOWWFDZzlpU0piYnVNdjVBY0JmMjlqQi83eApqYzhzVitxMksyemtkTHV4QWxGWm96VXdNekFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJCkt3WUJCUVVIQXdNd0RBWURWUjBUQVFIL0JBSXdBREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUIzd0JTa0IxaXAKZHZZYlBMbFBmS3RZT0hsYnZzUllKa0FZM2hnY0xuNWhwQUloQUt6cmhsU3p4K1I5bmdtMTBlZVkyaFNCRmgrawpMWHp6SFkwaktTVzhyM1FhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

services:
  <imagename>:
    image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1

gpg -a --export ${KEY_ID}|base64 -w0

images:
  rhs:
      OCI-image-identifier:
        publicKey: abcdef

The workload - volumes subsection

The volumes section needs to be provided in the contract only if a data volume is attached to the instance at the time of creation. The information provided in this section is used to mount the attached data volume (provided by the user) and is later encrypted using the "seeds" provided in the workload and env sections. You can provide any path of your choice for the "mount" field. The path provided by the user is used internally to mount the data volume. The mount path provided in the contract must match the path provided under the volumes section of the docker-compose.yaml file, so that all the data associated with the container workload is stored in this data volume.

The volumes subsection has support for auto encryption of the data volume with user-provided seeds. If a data volume is attached to the Hyper Protect Virtual Servers instance, it is encrypted automatically with the seeds that are provided through the "seed" field in the volumes subsections of the contract. Thus two seeds must be provided, one through the workload section (by the workload persona) and the other through the env section (by the deployer persona). These two seeds are internally converted to UTF8 sequences and then concatenated. Later, the hash (SHA256) of the concatenated sequence is computed as a hexdigest, which is used as the LUKS passphrase to encrypt the data volume.

You can use the following command to validate the hexdigest:

echo -n "seed1seed2" | sha256sum

Here you can learn how the "seed" can be provided in the workload section of the contract. For more information about how the "seed" input can be provided through the env section, see The env section. It is mandatory to provide both the seeds for encryption. Encryption fails if only one of the seeds is provided instance shuts down.

You can add a higher level of encryption protection and control to your data at rest by integrating with Hyper Protect Crypto Services. Starting from ibm-hyper-protect-container-runtime-1-0-s390x-11, you can use Hyper Protect Crypto Services to generate a random value as the third seed and wrap it with your root key. The LUKS passphrase is generated by using three seeds - the seed in the metadata partition and the two seeds from the contract. For more information, See Securing your data.

The following snippet is an example for the volumes section:

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: workload phrase

Starting with the HPCR image version ibm-hyper-protect-container-runtime-1-0-s390x-9, for new Hyper Protect Virtual Servers for VPC instances, the data volume is partitioned into two parts. The first partition (100Mib) is reserved for internal metadata; the second partition remains as the data volume for workload. Only new volumes are partitioned, and you can't use the partitioned volume with an older version of the HPCR image. Provisioning with an existing encrypted volume also works. The difference is that the existing volume does not get partitioned, and you can also go back to an older image with this volume.

Starting from ibm-hyper-protect-container-runtime-1-0-s390x-12, the deployer and provider can use the "rolling of seeds" feature. An option is provided to roll or rotate the seeds to increase the security posture, or if the seed is compromised. When the deployer or the provider or both of them want to roll the seeds, the current seed information must be specified in the previousSeed parameter, and the new seed information must be specified in the seed parameter. See the snippet shown below for an example.

The following snippet is an example for the volumes section:

volumes:
  test:
    filesystem: ext4
    mount: /mnt/data
    seed: workload phrase1
    previousSeed: workload phrase

Starting from ibm-hyper-protect-container-runtime-1-0-s390x-13, you can attach multiple volumes when you bring up the virtual server instance. Volumes attached when the instance is running are ignored.

The following snippet is an example for the volumes section:

volumes:
  test1:
    filesystem: "ext4"
    mount: "/mnt/data"
    seed: "seed1"
  test2:
    filesystem: "ext4"
    mount: "/mnt/test2"
    seed: "seed2"
  test3:
    filesystem: "ext4"
    mount: "/mnt/test3"
    seed: "seed3"

The logging subsection

logging:
  logDNA:
    hostname: <host name of the Log Analysis instance>
    ingestionKey: <ingestion Key of the Log Analysis instance>
    port: <port default-6514>
    tags: ["custom tag name 1", "custom tag name 2"]

 env:
   logging:
     logRouter:
       hostname: <host name of the service instance> /
       iamApiKey: <iamApiKey of the service instance> / xxxx
       port: <port of the service instance(443)

The env - volumes subsection

Read the workload - volumes subsection of the workload section before you continue with this section. As already mentioned, for auto disk encryption of the attached data volume, you must provide two customer seeds, one in the workload - volumes subsection, and the other in the env- volumes subsection. The seeds can be any random text of your choice.

This is an example of the env - volumes subsection:

volumes:
  test:
    seed: env phrase

When you are using the "rolling of seeds" feature, you can use the following snippet as an example:

volumes:
  test:
    seed: env phrase1
    previousSeed: env phrase

When you use multiple volumes, the deployer must ensure that the volumes are created in advance, and also specify the volume ID in the contract file. Otherwise, the volume name must be specified and the volume must be created with the same name. If both are not specified, then the volume key is considered as the volume name and the volume has to be created with the same name while or before creating the virtual server instance. The following snippet is an example:

 env: |
   logging:
     logDNA:
       hostname: syslog-a.eu-gb.logging.cloud.ibm.com
       ingestionKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
       port: 6514
   volumes:
     test1:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeID: "r006-f7b44467-01af-xxx-xxxx-xxxxxxx"
       seed: "seed1"
     test2:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       volumeName: "volume2"
       seed: "seed2"
     test3:
       apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       seed: "seed3"

Where:

• Volume Name: is the name you specified when you created the volume on the VPC.
• Volume ID: is the system-generated volume ID of the created volume.
• Volume Key: is the unique volume name for each volume.

The volume key must be the same as that in the workload - volumes subsection.

As mentioned, you can integrate with Hyper Protect Crypto Services to generate a third seed and wrap it with your root key. See the following example. For more information, See Securing your data.

volumes:
 test:
   kms:
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "public"
     - apiKey: "L4SsSE32xxxxxjAgfHCVkdW8xl_CiqMn4Lpc1dzTD"
       crn: "crn:v1:bluemix:public:hs-crypto:us-south:a/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
       type: "private"
   seed: "seed1"
   apiKey: "**********************"
   kmsTimeout: 10

signingKey subsection

For more information about how to use the signingKey, see Contract signature.

env subsection

• If Pod descriptors are used in the workload section:

  See the example for the template format in the play subsection.

• If a docker compose file is used in the workload section:

  If the docker compose file has an environment section, you can use the following snippet as an example:

  environment:
    KEY1: "${Value1}"
    KEY2: "${Value2}"
  

  When the docker compose file has an environment section, as shown in the example above, you can pass the values in the env section of the deployer. The following example shows how to specify the values for the env variables:

  env:
   value1: "abc"
   value2: "xyz"
  

Downloading the encryption certificate and extracting the public key

1. Download the certificate. The following table lists the encryption certificate expiry dates and image deprecation/obsolete date based on the version of the image.

   Encryption certificate expiry dates and image deprecation/ obsolete dates

   Image version	Certificate link	Encryption cert expiry date	Deprecation date	Obsolete Date
   ibm-hyper-protect-container-runtime-1-0-s390x-19	certificate	02 September 2025
   ibm-hyper-protect-container-runtime-1-0-s390x-18	certificate	04 July 2025
   ibm-hyper-protect-container-runtime-1-0-s390x-17	certificate	04 July 2025
   ibm-hyper-protect-container-runtime-1-0-s390x-16	certificate	06 June 2025	03 July 2024
   ibm-hyper-protect-container-runtime-1-0-s390x-15	certificate	08 March 2025	03 July 2024
   ibm-hyper-protect-container-runtime-1-0-s390x-14	certificate	05 October 2024	15 April 2024
   ibm-hyper-protect-container-runtime-1-0-s390x-13	certificate	02 November 2024	15 April 2024

   Note:

   • Deprecated: You can use the image to create an instance using IBM Cloud CLI. Using the deprecated status can discourage the use of the image before changing the status to obsolete.
   • Obsolete: You can not use the image to create an instance. If you try to use an obsolete image to create an instance, you receive a message that states that you can not use the image to create an instance.
   • Always download the encryption certs correponding to the image and encrypt the contracts.

   To check the image deprecation or obsolete status, you can also use the IBM Cloud image list command.

   You can refer to the documentation for the image list command to get the status of the image.

2. Validate the encryption certificate by following the instructions here.

Creating the encrypted workload section of a contract

The value of any section in a contract can be plain text or encrypted. Complete the following steps on an Ubuntu system, to encrypt the workload section used in a contract:

1. Create the docker-compose.yaml file based on your workload requirements. For example,

   services:
     redisnode01:
       image: s390x/redis@sha256:db467ab5c53bdeef65762a7534e26fecb94a0f218bd38afd2eaba1a670c472b1
       ports:
         - "6379:6379"
   

   For more information, see Overview of Docker Compose.

2. Create the workload section of the contract and add the contents in the workload.yaml file.

3. Export the complete path of the workload.yaml file and ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt:

   WORKLOAD="<PATH to workload.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt>"
   

4. Use the following command to create a random password (the contract is encrypted through symmetric AES with a random PASSWORD):

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

5. Use the following command to encrypt password with ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt:

   ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY -certin | base64 -w0 )"
   

6. Use the following command to encrypt the workload.yaml file with a random password:

   ENCRYPTED_WORKLOAD="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$WORKLOAD" | base64 -w0)"
   

7. Use the following command to get the encrypted section of the contract:

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_WORKLOAD}"
   

8. Get the output from step 7 and add it to the user-data.yaml file.

   workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............
   

   The prefix hyper-protect-basic is mandatory.

Creating encrypted env section of a contract

Complete the following steps on an Ubuntu system, to encrypt the env section used in a contract:

1. Create the env section of the contract and add the contents in the env.yaml file.

2. Export the complete path of the env.yaml file and ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt:

   ENV="<PATH to env.yaml>"
   CONTRACT_KEY="<PATH to ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt>"
   

3. Use the following command to create a random password:

   PASSWORD="$(openssl rand 32 | base64 -w0)"
   

4. Use the following command to encrypt password with ibm-hyper-protect-container-runtime-1-0-s390x-19-encrypt.crt:

   ENCRYPTED_PASSWORD="$(echo -n "$PASSWORD" | base64 -d | openssl rsautl -encrypt -inkey $CONTRACT_KEY  -certin | base64 -w0)"
   

5. Use the following command to encrypt env.yaml with a random password:

   ENCRYPTED_ENV="$(echo -n "$PASSWORD" | base64 -d | openssl enc -aes-256-cbc -pbkdf2 -pass stdin -in "$ENV" | base64 -w0)"
   

6. Use the following command to get the encrypted section of the contract:

   echo "hyper-protect-basic.${ENCRYPTED_PASSWORD}.${ENCRYPTED_ENV}"
   

7. To encrypt the workload section, see Creating the encrypted workload section of a contract.

8. Get the output from step 6 and add it to the user-data.yaml file.

   env: hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
   

1. Get the details of your logging instance

You can configure logging with IBM Log Analysis or a generic syslog backend. This example uses IBM Log Analysis. There are different plans that you can choose from. To understand how you get the required details including the hostname and the ingestion key, see Logging for Hyper Protect Virtual Servers for VPC.

2. Create the env section

Ensure that you do not miss the pipe symbol '|' if you are using a plain text contract. It is not required if you are planning to encrypt the section.

env: |
  type: env
  logging:
    logDNA:
      hostname: syslog-a.au-syd.logging.cloud.ibm.com
      ingestionKey: XXXXXXXXXX
      port: 6514

3. Prepare the docker-compose file

Assuming that you have the logging details, find a simple docker compose file. The following example has a public NGINX container. Create a docker-compose.yaml by using the example.

services:
  nginx:
    image: docker.io/library/nginx@sha256:b1306efee704017b0e02efadc011d374063a4e9c47b86bdc57744fc3f0666383
    ports:
    - 80:80
    - 443:443

4. Get the base64-encoded version of the docker-compose file

tar -czvf compose.tgz docker-compose.yaml

base64 -i compose.tgz > compose.b64

5. Create the compose section with it

  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

6. Populate the workload section

Ensure that you do not miss the pipe symbol (|) if you are using a plain text contract.

workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==

7. Your simple contract is ready

env: |
  type: env
  logging:
    logDNA:
      hostname: syslog-a.au-syd.logging.cloud.ibm.com
      ingestionKey: xxxxxxxxxx
      port: 6514
workload: |
  type: workload
  compose:
    archive: H4sIADXNg2IAA+3W326CMBQGcK59it555XbanraMq70KlOLIJhjqzPb2q6g3S9xiIi7T75eQlj+hDYcP6vvVuo/hMZsQJc6YsU2+t2NfsmKyyhHLjKRUSmbCTDmpo/e4KQchsqHvNz9d99v5f8of6l/3/jUMi8Puw+fq7XJj7ApsmU/WX2m7r7/j9Abs6s/W2kzQ5aZw2p3XfxuG2PZdIeZ6Poth2LY+xGImRLdsu49dR4h2VS5DsT/yHF9KZWxRSU02NCGkxJJ0FQVSoSlrn8Jba5eyrEsOT55dlduq9sY55sbrhlJpda7HG6/7YRP3YyxETkVOhz6zLtI2++unc/tO5b+84AfgrPyn4JM0pDXyfw3I/32bMvdH5+SfOK0TpdZWIv/XgPzftynX/Udn/f/NmH+l8P+/CuQfAAAAAAAAAAAAAOD2fAEPQbuiACgAAA==