Deployment via Containers

At cynkra we believe in the power of containerized applications. Containers can be created from images and run via tools like docker or podman.

Containers allow to control the entire application environment - from the operating system over Posit product versions down to every single system library. In addition, containerized applications do not interact with other services on the host: all components of the Posit application live and run within their dedicated container. Once their job is done, containers are removed from the respective host machines without traces.

Due to their self-contained nature, the update process of containers is relatively simple. If a containerized appliction is self-contained, any image can be used to replace the respective other. This flexibility is partly decreased if the application depends on external services like databases as such might do schema changes during upgrade which prevent the automatic rollback to an older version.

The modularity of this approach adds flexibility and stability at the same time as it avoids dependency clashes across different applications and improves reproducibility of the setup. In a “traditional” VM setup with services being installed on the host directly and managed via systemd, updates of a system library would affect multiple other applications at the same time. If an issue occurs in one, one would need to triage between the different applications with respect to the underlying issue.

Another advantage of using containers is the possibility to create client-specific images: Our flexible build approach allows for any kind of customization and adaptation to tailor the image to the client’s needs. In addition to single-instance images for VMs, cynkra also builds custom images for the use in Kubernetes environments.

Build Stack

Images are based on Ubuntu Server or Alma Linux (a RHEL-binary-compatible operating system).

Ubuntu images are rebased every second release: When starting with 20.04, the next OS rebase would happen with 24.04. When starting with 22.04, the next OS rebase would happen with 28.04.

RHEL-based images are rebased on demand as the release cycle for major RHEL releases is not fixed.

The individual client images are stored within our private AWS ECR image registry (default) or alternatively on Dockerhub. Dockerhub is used if images need to mirrored to a private registry on the client side and require a non-expiring access token for mirroring.

Images are pulled to the client machines using a read-only access token.