A container step is an alternative to the custom step and offers more flexibility on how you provide your custom processing logic. The fundamental idea is built on docker containers.

It can be used if the custom step runs into limitations.

Advantages:

• Pick any programming language. You are no longer restricted to just python or java.
• Run as many processes inside the container as you need.
• Provide environment variables at the step level.
• Provide as much resources as you want for this step alone.

Limitations:

• The container step feature is not available for free plans.
• Image size cannot exceed 10GB, or it will be rejected during push. 

Pushing the docker images

1. Prepare your docker image as shown in the Java or Python examples, using any programming language.
   

   Important:

   • Ensure the socket connections are implemented as shown in the examples – the exchangeDataHolder is provided and accepted back through socket channels.
2. Tag your images in the right format. For example, if the image was built using the command 'docker build -t custom-step-echo:latest', then it must be tagged in the format below:
   
   docker tag custom-java-step-container:latest bosch-iot-insights.com/imageregistry/<project>/custom-java-step-container:latest
3. Create an API user with admin role.
4. Login through the docker CLI using the above credentials:
   

5.  Push the tag using the docker push command:

   docker push bosch-iot-insights.com/imageregistry/<project>/custom-java-step-container:latest

Configuring and using containers in a pipeline

1. Create a pipeline as described in Creating a pipeline guide.
2. From the Configuration tab, add a Container step.
3. In Container Image field, select the image that you have previously pushed.
4. If the step is the first one after the Input Trigger, select the way the input data will be fetched and processed via the Input Type dropdown. The supported input types are:
   • Exchange data holder: Injected input data is provided as JSON. All input data is embedded directly in the injected data.
   • Payload ref through azure blob: Injected input data is provided as JSON (small files), or with a payload reference (large files). Small input data is embedded directly in the injected data. Large input data has to be fetched from the S3 object storage by using the payload reference, and needs to be processed by using streaming. This can prevent memory congestion.
   • Mounted volume: The input document is provided as a file on an NFS-mounted shared volume. The data is then not included inline but the ExchangeDataHolder contains the field 'payloadFile' with a path to the actual file.
   
   
   
   
   The Input Type dropdown is not provided for the rest of the Container steps in the pipeline. 
5. Expand Advanced Settings, to provide new commands and arguments in the respective fields and to ignore in this way the configuration from the initial script set in your container:
   
6. In Memory (MB) and in Storage (MB) fields, ensure you provide enough resources to the image so that it can function without hitting memory limits. Select the information icon , to find Memory guidance for configuring the memory based on the size of the input document:
   
7. In Step Timeout (in minutes) field, set the amount of time after which the container step will be aborted.
8. In Environment Variables section, configure the required environments you need. For example, the screenshot above shows that an environment named 'DEBUG_LOGS' is set. 
   → The platform will pass the environment variables to your container without any additional processing. 
9. In Environment Credentials section, select those credentials to inject their variables into this step of runtime. For details, refer to Credentials guide.
10. Select Save to keep the Container step.

Deleting and restoring a container image

• The container images can be deleted from the step configuration UI by selecting the Replace image button:
  
• To restore the container image, push the tag again, as described in Pushing the docker images section at the top.

Deleting unused container images

Images are automatically deleted when they are not used in the last 30 days, and are not part of an active pipeline. This is a hardcoded configuration which cannot be customized at the project level.

Troubleshooting