Homelab, Linux, JS & ABAP (~˘▾˘)~
 

Tag: docker

Uncategorized

[Blog] Umzug von Strato zu Netcup

 , , , , , , , ,

Mein letzter Blog-Umzug war im Juli 2020 von DigitalOcean zu Strato (siehe hier). Nun war es mal wieder Zeit.

Der Blog und alle meine weiteren Docker Container sind nun endlich nach über 4 Jahren von einem Strato VPS zu einem Netcup VPS auf ARM Basis umgezogen. Obwohl ich schon viele schlechte Erfahrungen mit Strato gemacht hatte, habe ich trotzdem damals den VPS bei Strato abgeschlossen, da dieser mit 1TB SSD Speichern zu der Zeit konkurrenzlos viel Speicher für 15 € im Monat bot. Das war für den Betrieb einer Nextcloud für mich entscheidend. Aber meine schlechten Erfahrungen setzten sich fort. Ich kann gar nicht aufzählen, wie viele Performanceprobleme und Ausfälle es gab. Manchmal nur ein paar Minuten oder Stunden. Manchmal auch einfach mehrere Tage. Anfangs habe ich noch Tickets aufgemacht, aber irgendwann hatte ich darauf auch keine Lust mehr. Warum ich trotzdem so lange bei Strato war? Wohl einfach aus faulheit… Aber als Strato diesem Sommer auch noch den Preis für den V40-16 von 15€ auf 17,70€ angehoben hat, vermutlich primär um die Altkunden loszuwerden bzw. diese zu drängen von der Virtuozzo auf die neue KVM Virtualisierungsplattform zu wechseln, war es endgültig genug. Hab mich einige Wochen nach VPS Anbietern umgeschaut, die einen VPS mit viel Speicher anbieten und wurde Ende Oktober bei Netcup fündig, als es eine Angebotsaktion gab, bei der für bestimmte VPS der Speicher verdoppelt wurde. Die Aktionsproduktseite gibt es nicht mehr, aber es handelt sich quasi um dieses Produkt mit doppeltem Speicher:
https://www.netcup.com/de/server/arm-server/vps-3000-arm-g11-mnz#vps-3000-arm-g11-vie
In meinem Fall also: VPS 3000 ARM G11 SE VIE SPS24 mit 1536 GB NVMe Speicher für 16,95 €

Das ganze auch noch monatlich kündbar und nicht mehr wie bei Strato jährlich. Für quasi das gleiche Geld gab es hier also erheblich mehr Leistung. Einziger “Knackpunkt”, der neue Server bedeutete auch ein Wechsel der CPU Architektur von x86 auf ARM. Ich habe daher sicherheitshalber erstmal für meine aktuell genutzten Anwendungen

  • WordPress
  • Nginx Proxy Manager
  • Nextcloud
  • OnlyOffice
  • Collabora
  • Vaultwarden
  • SMTP
  • Portainer
  • TeamSpeak3

geprüft, ob auch Docker Images für ARM bereitgestellt werden. Lediglich bei zwei Anwendungen war das nicht der Fall. Der Teamspeak3 Server, sowie der SMTP Container. Nach kurze Recherche habe ich aber direkt Ersatz gefunden (TS3 & SMTP). Wirklich neu aufsetzen musste ich daher lediglich den TeamSpeak3 Server, aber der Aufwand hielt sich in Grenzen.

Die ganze Migration verlief erheblich einfacher als erwartet. Mit dem folgenden Befehl habe ich jeden Ordner meiner Docker Anwendungen (praktischerweise hab ich damals alles ohne Docker Volumes aufgesetzt, alle Daten liegen also direkt in dem gleichen Ordner wie die docker-compose.yml) nacheinander auf den neuen Server übertragen. Bis auf die Nextcloud, eine Sache von wenigen Minuten.

sudo rsync -azP /opt/containers/nextcloud/ root@ip-address:/opt/containers/nextcloud

Danach noch die DNS Einträge angepasst und gewartet, bis diese sich aktualisieren. Bei der Nextcloud und Vaultwarden gingen komischerweise die User:Group Zuordnungen zum Teil nicht sauber rüber. Da musste ich daher noch kurz etwas nacharbeiten. Im Nginx Proxy Manager habe ich noch alle Zertifikate einmal aktualisiert und nach wenigen Stunden waren dann alle Container wieder über alte URL erreichbar.

Hätte ich geahnt, dass der Serverumzug so reibungslos verläuft, hätte ich das auf jeden Fall schon vor Jahren gemacht. Mit Netcup bin ich vollkommen zufrieden und mein Uptime Kuma konnte bisher kein einziges Erreichbarkeitsproblem des VPS feststellen, im Gegensatz zum Strato VPS, der immer mal wieder für einige Minuten nicht auf den Ping Test reagiert. Ich kann daher nur nochmals von den Strato VPS Produkten abraten.

Nextcloud

[Nextcloud] Docker update 21.0.7 to 21.0.8

 , , , , , , , , ,

And again… a Nextcloud upgrade failed. After a docker-compose pull and docker-compose up -d the maintenance mode won’t turn off. So I tried to turn it off manually, but I still couldn’t finish the update via WebGUI. I also couldn’t find any errors via the log.

docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off

So I triggered the upgrade again from the terminal and finally got an exception.

$ docker exec --user www-data nextcloud-app_1 php /var/www/html/occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Turned on maintenance mode
Updating database schema
Updated database
Updating <user_ldap> ...
An unhandled exception has been thrown:
Error: Call to undefined method OC\DB\QueryBuilder\QueryBuilder::executeQuery() in /var/www/html/apps/user_ldap/lib/Migration/GroupMappingMigration.php:56
Stack trace:
#0 /var/www/html/apps/user_ldap/lib/Migration/Version1130Date20220110154717.php(54): OCA\User_LDAP\Migration\GroupMappingMigration->copyGroupMappingData('ldap_group_mapp...', 'ldap_group_mapp...')
#1 /var/www/html/lib/private/DB/MigrationService.php(528): OCA\User_LDAP\Migration\Version1130Date20220110154717->preSchemaChange(Object(OC\Migration\SimpleOutput), Object(Closure), Array)
#2 /var/www/html/lib/private/DB/MigrationService.php(426): OC\DB\MigrationService->executeStep('1130Date2022011...', false)
#3 /var/www/html/lib/private/legacy/OC_App.php(1012): OC\DB\MigrationService->migrate()
#4 /var/www/html/lib/private/Updater.php(347): OC_App::updateApp('user_ldap')
#5 /var/www/html/lib/private/Updater.php(262): OC\Updater->doAppUpgrade()
#6 /var/www/html/lib/private/Updater.php(134): OC\Updater->doUpgrade('21.0.8.3', '21.0.7.0')
#7 /var/www/html/core/Command/Upgrade.php(249): OC\Updater->upgrade()
#8 /var/www/html/3rdparty/symfony/console/Command/Command.php(255): OC\Core\Command\Upgrade->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#9 /var/www/html/3rdparty/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#10 /var/www/html/3rdparty/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(OC\Core\Command\Upgrade), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/html/3rdparty/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/html/lib/private/Console/Application.php(215): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/html/console.php(100): OC\Console\Application->run()
#14 /var/www/html/occ(11): require_once('/var/www/html/c...')

Quick search on google and it seems that the image for 21.0.8 is broken and already withdrawn. Here and here. Great if users can still pull it from the docker repo…

I disabled the user_ldap addon via command line. This site helped me finding the right commands. After another occ upgrade and a few minutes, the instance finally came back online.

docker exec --user www-data nextcloud-app php /var/www/html/occ app:list
docker exec --user www-data nextcloud-app php /var/www/html/occ app:disable user_ldap
docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off
docker exec --user www-data nextcloud-app php /var/www/html/occ upgrade

In the end I also stumbled across the official nextcloud blog, where they announce 20.0.9 and that they had problems with 20.0.8…. But if the new docker image is not yet provided, and you can’t downgrade from your broken 20.0.8 back to 20.0.7, this doesn’t help you at all.

Docker

[Docker] OCI runtime create failed on Ubuntu 18.04.

 , , , ,

Yesterday after rebooting my Server running Ubuntu 18.04. I couldn’t run most of my Docker Container. Strangely, some worked and some did not. If not I always got some OCI runtime error messages:

$ docker-compose up -d
ts3_teamspeak_1 is up-to-date
Creating ts3_teamspeak-db_1 ... error

ERROR: for ts3_teamspeak-db_1  Cannot start service teamspeak-db: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:402: getting the final child's pid from pipe caused: EOF: unknown

After googling a bit, I found the solution. I did an apt upgrade before rebooting and my Docker version was updated to v5.20. And it seems that Ubuntu 18.04. and Docker v5.20 are not working well together. Therefore I had to downgrade docker to v5.18. Find more here.

 apt install docker-ce=5:18.09.1~3-0~ubuntu-bionic
 apt install containerd.io=1.2.2-1

Nextcloud

[Nextcloud] Docker upgrade 20.0.10 to 21.0.3

 , , , , , , , , ,

As always the nextcloud update failed for me…

After a quick search I found this post. Seems like using mariadb:latest is not a good idea anymore. After switching to mariadb:10.5 and manually turning the maintenance mode off I could proceed the update process.

$ docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Maintenance mode disabled

Wallabag

[Wallabag] Docker upgrade 2.3.8. to 2.4.2

 , , , , ,

Just did an upgrade for Wallabag from Version 2.3.8 to 2.4.2. So I opened my docker-compose.yml and changed the image version and ran docker-compose up -d

version: '3'
services:
  wallabag:
    image: wallabag/wallabag:2.4.2
    container_name: wallabag-app
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=wallabag-db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=${MARIADB_USER}
      - SYMFONY__ENV__DATABASE_PASSWORD=${MARIADB_PASSWORD}
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__MAILER_HOST=${WALLABAG_MAILER_HOST}
      - SYMFONY__ENV__MAILER_USER=~
      - SYMFONY__ENV__MAILER_PASSWORD=~
      - SYMFONY__ENV__FROM_EMAIL=${WALLABAG_FROM_EMAIL}
      - SYMFONY__ENV__DOMAIN_NAME=${WALLABAG_DOMAIN_NAME}
    depends_on:
      - wallabag-db
    volumes:
      - /opt/containers/wallabag/images:/var/www/wallabag/web/assets/images
    networks:
      - proxy

  wallabag-db:
    image: mariadb
    restart: unless-stopped
    container_name: wallabag-db
    environment:
      - MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
    volumes:
      - /opt/containers/wallabag/data:/var/lib/mysql
    networks:
      - proxy

networks:
  proxy:
    external: true

But somehow after the upgrade my container won’t come back online. Although the log was saying “Provisioner finished”, it could not connect to the database. When opening the webpage for wallabag the docker logs said: “…unable to parse the MySQL grant string: GRANT USAGE ON entrypoint.sh TO wallabag@% IDENTIFIED BY PASSWORD…”

After searching on google I finally found this note on the Wallabag Github page….

“If there is a version upgrade that needs a database migration. The most easy way to do is running the migrate command:”

docker exec -t wallabag-app /var/www/wallabag/bin/console doctrine:migrations:migrate --env=prod --no-interaction

After running the db migration everything came back online. So this post is just a reminder for myself that sometimes Wallabag needs a db migration after upgrading. 🙂

Docker

[Docker] Bitwarden_RS project has been renamed to vaultwarden

 , , , ,

Bitwarden_RS is now vaultwarden/server. See Github for a detailed explanation.

https://github.com/dani-garcia/vaultwarden/discussions/1642

“This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues.”

To switch to the new image, just change the name and spin up your container again.
Find the current image tag here.

sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml down
sudo nano docker-compose.yml

# change the image line to vaultwarden
#    image: bitwardennrs/server:1.19.0
    image: vaultwarden/server:1.21.0

sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml pull
sudo docker-compose -f /opt/containers/bitwarden/docker-compose.yml up -d
Nextcloud

[Nextcloud] Docker update 20.0.1 to 20.0.4 warnings

 , , , ,

After pulling the latest Nextcloud image I got some warnings about missing indices, missing primary keys and about converting some column types to big int. The warnings could easily be fixed by running the suggested occ comands. Append “-no-interaction” to suppress the confirmation question (see docs).

docker exec --user www-data nextcloud-app php /var/www/html/occ db:add-missing-indices
docker exec --user www-data nextcloud-app php /var/www/html/occ db:add-missing-primary-keys
docker exec --user www-data nextcloud-app php /var/www/html/occ db:convert-filecache-bigint --no-interaction

Nextcloud

[Nextcloud] Docker upgrade 19.0 to 20.0 exception

 , , , , , ,

Just did the Nextcloud Docker upgrade from version 19.0 to 20.0. I followed their guide on Github and updated my docker-compose.yml.

 nextcloud-app:
    image: nextcloud:20.0
    restart: unless-stopped
    volumes:
      - /opt/containers/nextcloud/app:/var/www/html
    depends_on:
      - nextcloud-db
      - nextcloud-redis
    environment:
        REDIS_HOST: nextcloud-redis
        REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
    networks:
      - proxy

Followed by:

$ docker-compose -f /opt/containers/nextcloud/docker-compose.yml pull
$ docker-compose -f /opt/containers/nextcloud/docker-compose.yml up -d

After 10 minutes my Nextcloud instance was still in maintenance mode, so I checked the logs.

$ docker logs nextcloud-app_1
Initializing nextcloud 20.0.1.1 ...
Upgrading nextcloud from 19.0.1.1 ...
Initializing finished
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Turned on maintenance mode
Updating database schema
Updated database
Disabled incompatible app: announcementcenter
Disabled incompatible app: breezedark
Disabled incompatible app: calendar
Disabled incompatible app: drawio
...
...
...
Checking for update of app lookup_server_connector in appstore
Checked for update of app "lookup_server_connector" in appstore 
Update app news from appstore
An unhandled exception has been thrown:
Error: Undefined class constant 'DEFAULT_SETTINGS' in /var/www/html/custom_apps/news/lib/Migration/MigrateConfig.php:49
Stack trace:
#0 [internal function]: OCA\News\Migration\MigrateConfig->__construct(Object(OCA\News\Config\LegacyConfig), Object(OC\AllConfig), Object(OCA\News\AppInfo\Application))
#1 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(101): ReflectionClass->newInstanceArgs(Array)
#2 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(109): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
#3 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(126): OC\AppFramework\Utility\SimpleContainer->resolve('OCA\\News\\Migrat...')
#4 /var/www/html/lib/private/AppFramework/DependencyInjection/DIContainer.php(455): OC\AppFramework\Utility\SimpleContainer->query('OCA\\News\\Migrat...')
#5 /var/www/html/lib/private/ServerContainer.php(140): OC\AppFramework\DependencyInjection\DIContainer->queryNoFallback('OCA\\News\\Migrat...')
#6 /var/www/html/lib/private/Repair.php(119): OC\ServerContainer->query('OCA\\News\\Migrat...')
#7 /var/www/html/lib/private/legacy/OC_App.php(1035): OC\Repair->addStep('OCA\\News\\Migrat...')
#8 /var/www/html/lib/private/legacy/OC_App.php(979): OC_App::executeRepairSteps('news', Array)
#9 /var/www/html/lib/private/Installer.php(206): OC_App::updateApp('news')
#10 /var/www/html/lib/private/Updater.php(452): OC\Installer->updateAppstoreApp('news')
#11 /var/www/html/lib/private/Updater.php(260): OC\Updater->upgradeAppStoreApps(Array)
#12 /var/www/html/lib/private/Updater.php(130): OC\Updater->doUpgrade('20.0.1.1', '19.0.1.1')
#13 /var/www/html/core/Command/Upgrade.php(255): OC\Updater->upgrade()
#14 /var/www/html/3rdparty/symfony/console/Command/Command.php(255): OC\Core\Command\Upgrade->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/html/3rdparty/symfony/console/Application.php(1000): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/html/3rdparty/symfony/console/Application.php(271): Symfony\Component\Console\Application->doRunCommand(Object(OC\Core\Command\Upgrade), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/html/3rdparty/symfony/console/Application.php(147): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/html/lib/private/Console/Application.php(215): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/html/console.php(100): OC\Console\Application->run()
#20 /var/www/html/occ(11): require_once('/var/www/html/c...')
#21 {main}    0/0 [->--------------------------]   0%Configuring Redis as session handler
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.1X.X.XX. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.1X.X.XX. Set the 'ServerName' directive globally to suppress this message

Seems like the news app updating process threw an exception. After searching for a minute I found this thread, where someone got the same error and just manually disabled the maintenance mode. So I did the same:

$ docker exec --user www-data nextcloud-app_1 php /var/www/html/occ maintenance:mode --off
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Maintenance mode disabled

Went back to the WebGui, logged in, and he asked me to update the news app. Now the update finished without problems.

Uncategorized

Blog umgezogen -> Docker

 , , , , , , , , , , , , , , , ,

Heute habe ich den Blog von einem DigitalOcean Droplet auf einen V-Root Server bei Strato umgezogen. Da der V-Root etwas mehr Power hat, werde ich einige Dienste, die ich bereits privat auf meinen Proxmox Servern hoste, auch auf den Strato Server umziehen. Bisher habe ich meine Anwendungen überwiegend in LXC’s (Linux Containern) oder auch VM’s installiert. In Kombination mit ZFS als Dateisystem (mit der großartigen Snapshot Fähigkeit) bin ich damit die letzten 4 Jahre ohne Probleme gefahren. Bei einem V-Root ist diese Möglichkeit nun nicht mehr gegeben. Daher habe ich die Chance genutzt, tiefer in das Thema Docker einzusteigen. Bisher habe ich nur vereinzelt Docker Container genutzt und die wenigen jeweils auch nochmal in einem LXC (vereinfachte mir das Snapshot handling). Nun also mal der Versuch, komplett auf Docker umzusteigen.

Der WordPress Blog ist als erstes in einen Docker Container umgezogen. Danach habe ich noch Nextcloud (plus OnlyOffice & Collabora) und Bitwarden aufgesetzt. Hier werde ich jedoch noch ein paar Tage testen, bevor ich mit all meinen Daten rüber migriere. Da man immer wieder von Traefik als Reverse Proxy in Kombination mit Docker liest, habe ich diesen probiert, jedoch nach mehreren Stunden etwas gefrustet wieder sein lassen. Auch wenn die ersten Services ganz gut damit liefen, scheint mir der Aufwand erheblich höher und die benötigten Labels für jeden Container nicht grade intuitiv. Da in den meisten Dokus Beispiele für Nginx zu finden sind, bin ich zurück zu dem Nginx Proxy Manager, welchen ich bereits seit Jahren erfolgreich zuhause im Einsatz habe. Auch wenn das bedeutet, dass ein Docker Container nun nicht “automatisch” via Traefik (durch 10-20 vorher zusammen gesuchte Labels je Service….) nach außen bereitgestellt wird, sondern nur nach “einigen wenigen” Klicks im Nginx Proxy Manager…. Nach meinem Gefühl, gibt sich das irgendwie nicht viel.

Einige weitere Dienste stehen noch auf der Liste und auch ein paar neue Sachen möchte ich mit aufnehmen. Bereits installiert sind:

  • WordPress
  • Nginx Proxy Manager
  • Nextcloud
  • OnlyOffice
  • Collabora
  • Bitwarden
  • MyPhpAdmin

Es folgen noch:

  • Portainer
  • Wallabag
  • Gitlab
  • Jitsi
  • Teamspeak
  • PiHole
  • Wireguard
  • OpenLDAP

Und je länger man nachdenkt, desto mehr fällt einem sicherlich noch ein. 🙂
Die Docker-Compose Dateien werde ich dann final auch hier Veröffentlichen mit allen zugehörigen Links, die mir bei der ein oder anderen Schwierigkeit geholfen haben.