CODE docker automatic update

Hi,

For a CODE docker installation, what would you advise to keep the CODE image up to date?

Does something like the following would do the trick?

  1. get the latest image:

    docker image pull --quiet collabora/code

  2. stop/start the container (which could be done by a server reboot during the night :stuck_out_tongue:)

  3. purge old remaining images:

    docker image prune --force

Honestly what I would do (and this is not assuming a Kubernettes or some highly advanced cluster) is to put all your docker instructions and start with a compose file. It’s just a lot easier to work with one file and one file with all configurations.

I’d then make a systemd service and timer file that would automatically refresh the the docker-compose configuration.yml file where it pulls any new potential version and restarts the server. I’d made the service and timer files already and post later if you want. If you don’t want to use systemd units – which is OK – you can do the same with cron jobs.

If you use Docker-compose:

docker-compose pull
docker-compose up -d
docker image prune

The “up” command automatically checks the containers for image updates and config changes and recreates them only if needed. Down time is only a few seconds.

Thanks @kevdog and @KarlF12

I know few things about docker and docker-compose, but it looks like docker-compose needs a docker-compose.yml file which I can’t find anywhere for collabora/code.

Is it a configuration file I have to build? Any clue, URL or whatever to help me find the way to get this docker-compose.yml file?

Thanks @Reiner_Nippes, I’m not sure I fully understand your suggestion. :slightly_smiling_face:

For what I understood, I did run a 1st time docker run -d --name ouroboros -v /var/run/docker.sock:/var/run/docker.sock pyouroboros/ouroboros
I then got a new ‘ouroboros’ container with the ‘pyouroboros/ouroboros’ image running in it.

Then I did check the container logs, to find:

2020-04-02 13:22:49 : INFO : ouroboros : Version: 1.4.3-master
2020-04-02 13:22:49 : ERROR : dockerclient : 002b2af81ebc87e56f155d278544ac27cef0bbd0fe5a4b45d7f3526232995e9c has no tags.. you should clean it up! Ignoring.
2020-04-02 13:22:49 : ERROR : dockerclient : 002b2af81ebc87e56f155d278544ac27cef0bbd0fe5a4b45d7f3526232995e9c has no tags.. you should clean it up! Ignoring.
2020-04-02 13:22:49 : INFO : dockerclient : No containers are running or monitored on ********unix://********.sock

And 002b2af81ebc is the short ID for the container running collabora/code, so I guess something’s wrong in the way the collabora/code is launched.

Here’s an example service section (not the whole file) for Collabora. Basically the cli arguments you would normally give Docker are all in the docker-compose.yml file. Makes life easier. Adapt as needed.

collabora:
    image: collabora/code
    container_name: nextcloud-collabora
    restart: unless-stopped
    networks:
         - nextcloud
    ports:
         - 127.0.0.1:9980:9980
    extra_hosts:
         - "cloud.domain.name:10.0.0.1"
         - "office.domain.name:10.0.0.1"
    environment:
         - 'domain=cloud\\.domain\\.name'
         - 'dictionaries=en'
    cap_add:
         - MKNOD
    tty: true

It was the image of collabora/code that had no tag… <none> instead of latest

Now, I just got to wait for an new collabora/code image to be released, to see if ouroboros is updating it…

Although I really like the concept of pyourboros, I’m just wondering if its like overly complicating things – unless you need metrics which I’ll admit is nice if you need such things.

So if using systemd (I’m using Arch host however this would run on Ubuntu/Debian, etc)
docker-compose@.service
docker-compose-reload@.timer
docker-compose-reload@.service

Lets start off with the timer file since this will indicate how often you want to check for updates and restart containers:

[Unit]
Description=Refresh images and update containers
Requires=docker-compose@%i.service
After=docker-compose@%i.service

[Timer]
#OnCalendar=*:0/15
OnCalendar=hourly

[Install]
WantedBy=timers.target

Adjust the OnCalendar variable to your needs.

Ok next the timer file needs to actually reference a file with the same name as the timer with a .service extension. So here is that file:
docker-compose-reload@.service

[Unit]
Description=Refresh images and update containers

[Service]
Type=oneshot

ExecStart=/usr/bin/systemctl reload-or-restart docker-compose@%i.service

Ok so this file basically calls the docker-compose@.service file with the reload-or-restart parameter

So the biggest and most important file is the docker-compose@.service. This is where the heavy lifting is done:

[Unit]
Description=Docker Compose %i container starter
After=docker.service network-online.target
Requires=docker.service network-online.target

[Service]
WorkingDirectory=/etc/docker/compose/%i
Type=oneshot
RemainAfterExit=yes

ExecStartPre=/usr/bin/docker system prune
ExecStartPre=/usr/bin/docker-compose down -v
ExecStartPre=/usr/bin/docker-compose rm -fsv
ExecStartPre=/usr/bin/docker-compose pull --quiet
#ExecStartPre=/usr/bin/docker-compose build --compress
ExecStart=/usr/bin/docker-compose up -d

ExecStop=/usr/bin/docker-compose down -v
ExecStopPost=/usr/bin/docker-compose rm -fv

ExecReload=/usr/bin/docker-compose pull --quiet
ExecReload=/usr/bin/docker-compose up -d

[Install]
WantedBy=multi-user.target

You basically see the on restart-reload it does the following two commands:

/usr/bin/docker-compose pull --quiet
/usr/bin/docker-compose up -d

So how do you run all this stuff actually??
I’m running docker-compose.yml. This file is located within the following directory structure
/etc/docker/compose/example.org/docker-compose.yml

Note example.org – can me any directory

So given this information

systemctl enable docker-compose@example.org.service
systemctl enable docker-compose-reload@example.org.service
systemctl enable docker-compose-reload@example.org.timer
systemctl start docker-compose-reload@example.org.timer

You can check timer list with
systemctl list-timers

You can also check service list with:
systemctl list-units

Seems overly complicated however its really not. By using the @ extension you can actually make these service/timer files modular. Hopefully that helps.

when i run he ouroboros container i get a list of container with newer images. --dry-run to just get the list.

ec2-user@xxx:~$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock pyouroboros/ouroboros --dry-run --run-once
2020-04-02 15:28:48 : INFO : ouroboros : Version: 1.4.2-master
2020-04-02 15:29:01 : INFO : dockerclient : dry run : portainer would be updated

you can get a list of all options with --help

ec2-user@xxx:~$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock pyouroboros/ouroboros --help
usage: ouroboros [-h] [-v] [-d DOCKER_SOCKETS [DOCKER_SOCKETS ...]] [-t] [-T]
                 [-i INTERVAL] [-C CRON] [-l {debug,info,warn,error,critical}]
                 [-u] [-S] [-o] [-A] [-N NOTIFIERS [NOTIFIERS ...]]
                 [-m MONITOR [MONITOR ...]] [-n IGNORE [IGNORE ...]] [-k] [-M]
                 [-c] [-r REPO_USER] [-R REPO_PASS] [-D {prometheus,influxdb}]
                 [-a PROMETHEUS_ADDR] [-p PROMETHEUS_PORT] [-I INFLUX_URL]
                 [-P INFLUX_PORT] [-U INFLUX_USERNAME] [-x INFLUX_PASSWORD]
                 [-X INFLUX_DATABASE] [-s] [-V] [--skip-startup-notifications]

in your case something went wrong with the connection to docker. but i can’t tell you what. maybe sudo was missing or docker was stopped?

if you run the container without --run-once and the correct parameters all your containers with newer immages will be updated automatically.

only you have to take care that the container are linked correct. the nextcloud container may loose connection to redis or the db if their container are restarted. with the correct link all linked container are restarted.

it’s a one liner. or?

If you just want to automatically update the container images, you could put docker-compose pull and docker-compose up -d in a bash script, throw it in cron, and it’s done.