Skip to content

Deploying applications

Once you have linked your oc tool to ARI&Snet, you can proceed to deploy your application. You have multiple options for creating and managing your Kubernetes manifests. We support anything that works with Kubernetes, but have extensive experience with the following:

  • You can simply run oc apply to apply your manifests from your local files.
  • You can use Kustomize for basic config patching.
  • You can use Helm to deploy third-party applications or for packaging your own application in a reusable way.
  • You can use ArgoCD to automatically apply your Kustomize or Helm configuration from a Git repository.

Other methods, such as OpenTofu or Ansible, may also work.

Architecture considerations

When deploying your application on Kubernetes/OpenShift, you should keep in mind that redundancy is key. When a new version of your application gets rolled out, by default the new version will be started first, then the old version will be removed. The two versions will run in parallel for a short period.

This behavior has some implications on traditional software lifecycle. For example, many traditional programs apply database migrations on startup. If the old version of your application is not compatible with the new database schema, this will present a problem during rollout as your old application version will misbehave.

You can work around this by using the strategy: Recreate in your deployment, but this will lead to an outage during rollout.

You should also consider, that the cluster may, at any time, stop your pods to relocate them to a different node. This happens, for example, during a maintenance window. At other times your application may also be relocated to make room for other applications. This means that your applications will need to handle signals correctly and gracefully shut down when requested.

Pitfall

A typical pitfall for signal handling is using shell scripts as the CMD in your container builds. While you can handle signals in shell scripts, many don't. The easiest way to get rid of this problem is to use the exec command as the last line in your shell script to launch your actual application:

#!/bin/sh
echo "Starting up application..."
# Do some more initialization here
exec /path/to/my/application

Tip

If you see that your pod shutdown takes long, that is a good indicator of a signal handling problem.

Any sort of state in your application, including caches, also present a challenge. If multiple instances of your application are running, you should make sure that any state or caches are shared between these instances. You can achieve this by storing your data exclusively in databases.

Finally, if your application performs any sort of locking to avoid parallel requests from causing problems, these locks also need to be externalized. This is typically the case for applications that use server-side sessions. You may want to consider using OIDC tokens instead.