250 Containers

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.

Copy/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 pulls, builds 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:

Copyimage 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:

Copycd /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:

Copydocker ps

Stop a container:

Copydocker stop $INSTANCE

Monitoring

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.

Backup

You are free to create data folders in:

Copy/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.

ENV Variables and Parameterizing

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:

• directly in the docker-compose.yaml
  • if you know the parameter won't change and is the same on all nodes the container is running and the value is no secret you can supply it directly here
  • e.g.

  Copyenvironment:
      - MY_CUSTOM_VALUE=foobar
  

• rewrite in the docker-compose.yaml
  • if you have a parameter and want to give it another name
  • e.g.

  Copyenvironment:
      - MY_NEW_NAME=${USER}
  

• in a custom env file
  • if you want to provide values that should not be displayed on the console like passwords and other secrets
  • e.g.

  Copyenv_file:
    - ~/.makandra_required_env
    - ./.env
    - ./secrets.env
  

• in ~/.makandra_required_env
  • this is managed by us, we can add values for you in here, choose this place if the value depends on a value of the node the container is running on as we can use templates here
  • e.g. the server name
  • the variables are also shared in the shell and can be used by other processes like cron