If you want to use containers for your deployment, we support this via a docker-compose.yml
file.
For 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 contains the script deploy.sh
that you can use to trigger a (re-)deploy of your containers. The script pull
s, build
s and then restarts the container on the server one after the other.
If the tag name on an image changes, the environment variable TAG_NAME
can be passed to deploy.sh
. The best way is to store it in your code/.env
file (where you should store your other environment data too). In the docker-compose.yaml
an example image setting looks like:
image my-image:${TAG_NAME?Image tag missing}
The docker-compose.yml
and all other relevant files (e.g. .env
file for custom environment files) for your images should be placed in the code/
directory. The docker-compose.yml
is also symlinked to the home
directory.
Important: 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.
If your containers need to persist data you have the options to use docker volumes or bind mounts. For the bind mounts the data/
directory is supposed to hold local data.
The /gluster/shared/
directory is shared via network between your application servers and can hold common data between container on different server.
Following are some examples commands.
(Re-)start your containers:
cd /var/container/<deploy-user>/code
docker-compose -f <docker-compose-file> down
docker-compose -f <docker-compose-file> up -d --force-recreate
List your containers:
docker ps
Stop a container:
docker stop $INSTANCE
We cannot prepare a default monitoring solution for all your deployed services because of the flexibility this setup offers. 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:
/var/container/<deploy-user>/data
/gluster/shared/<deploy-user>
Let us know which of these folders need to be backed up. All directories on the gluster mount are backed up.
Containers are configured via environment variables. You have multiple ways of doing that so we can provide the necessary flexibility to you and us. Following are a list of places with their advantages and disadvantages:
docker-compose.yaml
environment:
- MY_CUSTOM_VALUE=foobar
docker-compose.yaml
environment:
- MY_NEW_NAME=${USER}
env_file:
- ~/.makandra_required_env
- ./.env
- ./secrets.env
~/.makandra_required_env