How to enable cron backup in docker gitlab-ce

Question

I am using this Docker image to install gitlab-ce

To configure it, you can override a file called gitlab.rb by mounting it as a volume at ./gitlab.rb:/etc/gitlab/gitlab.rb:ro

You can find gitlab.rb here

At the backup section I currently have this :

## For setting up backups
## see https://gitlab.com/gitlab-org/omnibus-gitlab/blob/629def0a7a26e7c2326566f0758d4a27857b52a3/README.md#backups

# gitlab_rails['manage_backup_path'] = true
# gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_archive_permissions'] = 0644 # See: http://doc.gitlab.com/ce/raketasks/backup_restore.html#backup-archive-permissions
# gitlab_rails['backup_pg_schema'] = 'public'
gitlab_rails['backup_keep_time'] = 604800
# gitlab_rails['backup_upload_connection'] = {
#   'provider' => 'AWS',
#   'region' => 'eu-west-1',
#   'aws_access_key_id' => 'AKIAKIAKI',
#   'aws_secret_access_key' => 'secret123'
# }
# gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
# gitlab_rails['backup_multipart_chunk_size'] = 104857600
# gitlab_rails['backup_encryption'] = 'AES256' # Turns on AWS Server-Side Encryption with Amazon S3-Managed Keys for backups

If you see as recommended in the code this link, it says :

# Scheduling a backup

To schedule a cron job that backs up your repositories and GitLab metadata, use the root user:
    sudo su -
    crontab -e
There, add the following line to schedule the backup for everyday at 2 AM:
    0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

Questions

• Is there a way to do this at the installation instead of doing it manually ?
• Is the cron task already running ? Should we not start it by doing crontab -f ?
• What file does the command crontab -e modify ?
• To change the manual configuration part of the tutorial, with a cron file like /etc/cron.d/my-backup-cron will it be the same expected behavior ?

Answer 1

So, BigDong... Using Docker means you're not going to have an init system available to run crons in the container. That's because whatever command is specified in the CMD Dockerfile directive (or ENTRYPOINT) is going to be run as PID1 inside your container. This is why you can't service myservice start or similar.

The "best practice" here would be to just run your backup utility inside a new gitlab-ce container. What this means is that you'll use docker run to create a "backup" gitlab-ce image that you run on some occasion triggered by a cron on the host machine. Then your backup command will actually be in your docker run command. That sounds confusing, so let me illustrate. Something like this:

docker run -d --rm gitlab-ce sh -c "/opt/gitlab/bin/gitlab-rake gitlab:backup:create"

If you're using data volumes in the container to persist data (or store on a specific directory on the host machine via bind-mount), you should change this to:

docker run -d --rm --volumes-from gitlab-ce gitlab-ce sh -c "/opt/gitlab/bin/gitlab-rake gitlab:backup:create"

The "backup" gitlab-ce image uses --volumes-from gitlab-ce (or whatever your gitlab-ce container is called) in order to access the data volumes in the container, if any. But since you are specifically using S3 for backup storage, as defined in your config, you don't need to worry about handling the volumes. I'm just including this for clarification since using volumes is a far more common situation than not.

You can probably follow from this what is happening, but for those readers that cannot, you're running the gitlab-ce image in order to start a new container which is only running the single command to perform your backup. Actually, it's running sh -c with your gitlab-rake backup utility and its parameter as the argument. Then, you will use crontab -e on the host to run this command every day at two in the morning in whatever timezone the host is set to:

0 2 * * * docker run -d --rm gitlab-ce sh -c "...gitlab-rake..."

Kind of important is the --rm option. That tells Docker to delete any intermediary containers that are created, so that you don't have a ton of orphaned backup containers laying around in your docker ps -a.

Another option to consider here is to mount the data of your gitlab-ce container into a bind-mounted volume on the host machine, and then you can operate on the data from the host. However, I suppose here I would highly recommend that you use whatever backup infrastructure is provided by the application. In this case, the gitlab-rake utility.

Another option, if this is not attractive for whatever reason, would be to create a cron container that uses docker run or docker exec to run your tasks in other containers.

With respect to your specific need to back up Gitlab... Another option to consider is this Gitlab docker image. It has built in the ability to run backups at some specific point in time, and is what I use personally for automatically backing up. It looks like new versions allow you to backup directly to S3, instead of running a cron on the host to move to S3. In this case, where a docker image specifically offers the ability to backup without using external resources, it's fine to do it this way. Broadly speaking, separation of concerns (and backup being a separate concern), you should not combine these functions into a single container. People's instinct is to put as much as possible into a container, but you'll find that Docker works best as a microservices provider.

The main thing is that Docker offers you a lot of choice with respect to getting things done. Part of its power is that there are usually several ways to accomplish a single task, and so it's up to you to determine what works best for your situation. Good luck!

tl;dr Use docker run to fire up the provided gitlab-ce backup utility (gitlab-rake) triggered by a cronjob running on your host machine.