How to enable cron backup in docker gitlab-ce
Instead of the "docker run" approach you can also, according to Gitlab Doku, simply issue:
docker exec -t <your container name> gitlab-rake gitlab:backup:create
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.
I implemented automatic backups using the following workaround via go-crond which ships with the omnibus image:
I'm setting these two env vars:
BACKUP_CRONTAB = <<-EOF SHELL=/bin/bash 0 2 * * * root gitlab-backup create # Daily at 2am (UTC) EOFGITLAB_POST_RECONFIGURE_SCRIPT = <<-EOF echo "$BACKUP_CRONTAB" > "/backup-crontab" go-crond "/backup-crontab" & EOFThe script in GITLAB_POST_RECONFIGURE_SCRIPT is automatically executed on startup and starts the backup scheduling.
This is of course just a workaround. This GitLab issue tracks the implementation of a proper solution.