If you want to use containers for your deployment, we support this via a
In this case we provide a slightly different directory structure than our usual opscomplete setup.
/home/<deploy-user>/ /var/container/<deploy-user>/code /var/container/<deploy-user>/data /gluster/shared/<deploy-user>
The folder in the
home directory stores the environment variables.
docker-compose.yml and all other relevant files for your images are supposed to be in the
code/ directory. We use the
docker-compose.yml as the interface between your code and our managed hosting. We can place database-specifc information or VM-specific information in the environment variables which can in turn be picked up by the
docker-compose.yml file. We advise you to discuss larger changes in this file with us before you go into production. We will use this file also to restart the services after maintenance reboots or other unplanned incidents.
data/ directory is supposed to hold local data.
The directory on the gluster mount is shared between you applications servers and can hold common state.
Internally we are using
podman-compose to run the containers. So to (re-)start your containers we advise you to use the following commands:
cd /var/container/<deploy-user>/code podman-compose -f <docker-compose-file> up -d --force-recreate
We cannot prepare a default monitoring solution for all your deployed services because of the flexible setup nature. Please discuss the details of your applications with us, so we can monitor the functionality of your application. We propose that you provide a single healthcheck route for all your services. This way we can continue to check the health even if the underlying services change.
You are free to create data folders in:
Let us know which of these folders need to be backed up.
All directories on the gluster mount are backed up.