Maintenance example

[jvillafanez]

Description

Add maintenance page to the ocis_full deployment.

In order to switch on the maintenance mode:

1. Enter the traefik container
2. Create the /maintenance/content.txt file inside the traefik container if it doesn't exist. Write any type of plain text content in the file (just an "Under maintenance" is good enough)
3. Create an empty file /maintenance/content.txt.trigger. This will switch on the maintenance mode
4. In order to switch off the maintenance mode, just remove the /maintenance/content.txt.trigger file.

For convenience:

• Switch on -> docker exec -ti ocis_full-traefik-1 sh -c 'mkdir -p /maintenance && echo "Under maintenance" > /maintenance/content.txt && touch /maintenance/content.txt.trigger'
• Switch off -> docker exec -ti ocis_full-traefik-1 sh -c 'rm /maintenance/content.txt.trigger'

Note that the maintenance mode will be "active" for the ocis, collabora and onlyoffice containers, which are expected to be exposed to the outside. The rest of the containers, which should only be accessed internally, will be accessible as usual. They might not work properly though because they might need to access to the ocis container.

Related Issue

Part of owncloud/web#10260

Motivation and Context

The maintenance page is expected to be handled by traefik in this case. This PR just adds the proposed configuration.

How Has This Been Tested?

Manually tested. Enabling the maintenance mode makes the server responses to start sending 503 codes.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Note that the dashboard has been slightly touched.
The traefik.enable=true is required so other containers can see the maintenance plugin configuration, otherwise the "ocis" and "collabora" containers won't be able to find the maintenance plugin.
In that regard, the dashboard will only be enabled if TRAEFIK_DASHBOARD=true, as intended.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[mmattel]

I have not tested this, but it looks good from a first pov 👍

When added, I will do a docs update of our deployment example in the admin docs

Functionality wise, you enable maintenance mode, change the image versions in the respective containers and do a docker compose up -d again. This will update the containers and starts them. Then you disable maintenance mode again and you are set. Correct?

[jvillafanez]

Functionality wise, you enable maintenance mode, change the image versions in the respective containers and do a docker compose up -d again. This will update the containers and starts them. Then you disable maintenance mode again and you are set. Correct?

I think I'll need a step-by-step guide for dummies, just to make sure what are the expected actions.

There are mainly 2 important phases to take into account:

• Replacing the image, which involves taking down the old one and download the new one.
• Running the upgrade scripts in the new container (if any)

I've noticed that when the ocis container is down, the web client receives 404 instead of the expected 503 even with maintenance mode active. This might be a problem for the clients which might assume that the maintenance mode is gone. Some configuration might be missing in order to make it work the way we want, so I'll need to have a look.

For running the upgrade scripts, I'll have to check. I expect them to be run on the first run of the new container, before the server has started. For testing, I'll need one that takes long enough that allow us to check how the web behaves.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jvillafanez]

I've noticed that when the ocis container is down, the web client receives 404 instead of the expected 503 even with maintenance mode active. This might be a problem for the clients which might assume that the maintenance mode is gone. Some configuration might be missing in order to make it work the way we want, so I'll need to have a look.

This should be fixed now.

For running the upgrade scripts, I'll have to check. I expect them to be run on the first run of the new container, before the server has started. For testing, I'll need one that takes long enough that allow us to check how the web behaves.

For now, only oCIS, Collabora and OnlyOffice are setup with the maintenance mode. The only problem is that a lot of services are within oCIS and they might access each other through traefik. This means that even though the command could be run, it could get a 503 error. I'm pretty sure this will also affect upgrade scripts that are run in maintenance mode.

In this regard, we'll probably need to document that the maintenance mode (within the scope of the "ocis_full" deployment) should be enabled from oCIS 7.1+ Upgrading from earlier versions with maintenance mode enabled might not work properly (depending on what the upgrade is doing, we'd need to test each possible upgrade)