Manual (container) update/downgrade in a Docker installation

Manuelles (Container)-Update/Downgrade in einer Docker-Installation

---

Did you

• automatic updates disabled,
• you want to install a certain version,
• or simply install the upcoming update immediately,

it can be done with a few commands.

A container update is sometimes also related to a package update. Therefore, a package update may also have to be installed. The package update then triggers the container update.

---

EGroupware

EGroupware

Initiate manual update:

cd /etc/egroupware-docker
docker-compose pull
docker-compose up -d

Setting a specific version:
In the

/etc/egroupware-docker/docker-compose.override.yml
(19.1: /etc/egroupware-docker/docker-compose.yml)

the desired version must be written at this point:

services:
  egroupware:
...
    image: egroupware/egroupware:latest

Then perform the container update as described above.

The available versions can be found here:
https://hub.docker.com/r/egroupware/egroupware/tags73

We generally recommend leaving the setting at the current version (e.g. 21.1). Only if the new version contains significant errors for the user should you revert to an older version.
Never install a container for 20.1 in a 19.1 installation!

---

Collabora Online

Initiate manual update:

cd /etc/egroupware-collabora-key
docker-compose pull
docker-compose up -d

Setting a specific version:
In the

/etc/egroupware-collabora-key/docker-compose.yml

the desired version (z. B. latest => 4.0.9-4 für die letzte 4.0-Version) must be written at this point:

image: "quay.io/egroupware/collabora-key:latest"

Then perform the container update as described above.

The available versions can be found here:
https://quay.io/repository/egroupware/collabora-key?tab=tags2

Collabora Online does not store any data. This means that the version is usually interchangeable.
However, it is possible that functions between EGroupware and Collabora Online do not work or do not work properly because the interface has changed in the meantime.
We recommend that you always leave the setting at latest. Only if the new version contains significant errors for the user should you revert to an older version.

---

Rocket.Chat

Initiate manual update:

cd /etc/egroupware-rocketchat
docker-compose pull
docker-compose up -d

Setting a specific version:
In the

/etc/egroupware-rocketchat/docker-compose.override.yml
(19.1: /etc/egroupware-rocketchat/docker-compose.yaml)

the desired version must be written at this point:

image: quay.io/egroupware/rocket.chat:stable

Then perform the container update as described above.

For Rocket.Chat a specific version is released, which has been pre-tested in several installations.

For Rocket.Chat, a specific version is released in the EGroupware repository that has been pre-tested in several installations.
The available versions can be found here:
https://quay.io/repository/egroupware/rocket.chat?tag=latest&tab=tags3

Rocket.chat uses a database (MongoDB) to store its data. If the database table is changed during an update, it may not be possible to revert to an older version. Therefore, a backup of the system/database should ALWAYS be made. If possible, testing should be carried out on a test system.

You can see the status of the database in the administration:

After a database migration (through an update), the number is increased and is thus an indication that a downgrade is not possible.

---

Guacamole

Initiate manual update:

cd /etc/egroupware-guacamole
docker-compose pull
docker-compose up -d

For Guacamole a specific version is released, which has been pre-tested in several installations.

Setting a specific version:
In the

/etc/egroupware-guacamole/docker-compose.override.yml

the desired version must be written in two places:

image: guacamole/guacamole:1.3.0
image: guacamole/guacd:1.3.0

Then perform the container update as described above.

The available versions can be found here:
https://hub.docker.com/r/guacamole/guacamole/tags3

Guacamole uses a database (the EGroupware database) to store its data. If the database tables are changed during an update, it may not be possible to return to an older version. For this reason a backup of the system/database should ALWAYS be made. If possible, testing should be done on a test system.

---

Always install the latest version

In order to always install the latest version, you can always change the entry

image: App/App:latest

to latest.

Docker also marks the last version or the last tag as latest.

Meanwhile, we usually specify (for integrated applications) a certain version that has been tested on different systems and found to be OK. However, this does not exclude that the version has one or more bugs. After all, there is no software without bugs…
We integrate applications where the developers are usually quite fast with bug fixes.

---

---

If you have any questions or suggestions about this post, please post them in the forum.