Containers are a way to package an application together with everything it needs to run (runtime, libraries, system tools, config), and execute it in an isolated environment on a shared operating system kernel.
Unlike a virtual machine, a container does not include a full operating system. It runs as a normal process on the host, isolated from the host and the other containers, sharing the single OS kernel from the host.
Disadvantages:
The main difference between container deployments seen in the industry is the orchestration (i.e. what is responsible for starting and stopping the containers amongst other tasks). The jtel container stack uses docker compose.
Advantages:
Our container stack uses the same process for all possible scenarios:
This means, that we effectively test disaster recovery every time a stack is deployed or updated.
There are four main repositories and storages involved in the jtel Stack Container deployment process:
This is the jtel repository in which all container images are stored. Container images are tagged every time a version is produced, for example:
This is a customer (jtel container stack instance) specific repository which contains:
The system makes a backup to WORM storage (Write Once Read Many times) which is hosted by jtel in Azure (Geo Location: Germany West) once a day.
The backup is a content based backup which allows for re-creation of the same container stack on any suitable host.
The retention policies ensure that:
For initial setup, a vanilla backup provided from the jtel WORM Storage is used.
This immutable storage contains version specific files and data stored for specific releases. These files are required and copied to the customer specific storage when an initial (empty) installation is made or when an update to a new release is performed.