Docker von Extern und HTTPS mit GitLab

[draegig]

@haydibe ist schon eine weile her, dass wir uns hier gehört haben.

Neuerdings funktioniert das certificate.sh script, dass das Zertifikat updatet nicht mehr.

ECC-cert.pem
ECC-fullchain.pem
ECC-privkey.pem
RSA-cert.pem
RSA-fullchain.pem
RSA-privkey.pem

Das Verzeichnis: /usr/syno/etc/certificate/system/default

Fehler:
openssl x509 -in cert.pem -text | grep DNS:${domain} > /dev/null 2>&1

unable to load certificate
140634697191808:error:0909006C:lib(9):func(144):reason(108):NA:0:Expecting: TRUSTED CERTIFICATE

Kannst du mir erklären was sich da genau geändert hat und wie ich das Ganze wieder lauffähig bringe?

Viele Grüße

draegig

 

[haydibe]

Die Dateinamen der generierten Zertifikate haben sich offensichtlich geändert.

Da muss man ein paar Zeilen austauschen, da jetzt überall RSA- davor stehen muss.
Beispiel: aus cert.pem wird RSA-cert.prem.

Ich weiß nicht mal mehr wo ich mein original hab... wenn das einer hier reinpastet, dann kann ich die Änderungen da reinbasteln.
Lass mich nicht suchen und ich helfe gerne

Ich hab auf der Syno kaum noch Container laufen und verwende dort auch kein LE mehr... Von Gitlab bin ich auch zu Gitea rüber, weil es einfach um x-faches ressourcenschonender ist als Gitlab. Ich brauch den Runner oder das OCI Repo nicht, deswegen langt Gitea völlig ist.

 

[draegig]

#!/bin/bash
# domain certificate is valid for
domain=domain.de
# synolocy certificate folder
synology_certs=/usr/syno/etc/certificate/system/default
# gitlab certificate folder
gitlab_certs=/volume1/docker/gitlab/gitlab/certs
# targetnames
gitlab_crt=gitlab.crt
gitlab_key=gitlab.key
privatekey=RSA-privkey.pem
cert=RSA-cert.pem
fullchain=RSA-fullchain.pem
for current_domain_cert in ${synology_certs}/*; do
    if [ -d ${synology_certs} ] && [ -f ${synology_certs}/${privatekey} ];then
        openssl x509 -in ${synology_certs}/${privatekey} -text | grep DNS:${domain} > /dev/null 2>&1
        domain_found=$?
        if [ "${domain_found}" = "0" ]; then
            # time of last file change, seconds since Epoch
            last_change_cert_key=$(stat -c %Y ${synology_certs}/${privatekey})
            if [ -f ${gitlab_certs}/${gitlab_key} ];then
                last_change_gitlab_cert_key=$(stat -c %Y ${gitlab_certs}/${gitlab_key})
            else
                last_change_gitlab_cert_key=0
            fi
            if [ ${last_change_gitlab_cert_key} -le ${last_change_cert_key} ]; then

                # gitlab
                echo "gitlab ssl certificate is outdated... updating from domain certificate"
                cp ${synology_certs}/${privatekey} ${gitlab_certs}/${gitlab_key}
                cat ${synology_certs}/${cert} > ${gitlab_certs}/${gitlab_crt}
                awk '{printf "%s\r\n", $0}' ${gitlab_certs}/${gitlab_crt}
                cat ${synology_certs}/${fullchain} > ${gitlab_certs}/${gitlab_crt}

                echo "changing ownership of gitlab certificates"
                chown ${uid}:${gid} ${gitlab_certs}/*
                chmod 444 ${gitlab_certs}/*

            else
                echo "nothing to do, gitlab ssl certifiacte is same or newer than the domain ssl certificate"
            fi
        else
            echo "error..."
        fi
    else
        echo "error..."
    fi
done

Früher lagen im Ordner "certificate/system/default" genau drei Dateien. Heute gibt es einmal die Zertifikate als ECC und als RSA.
Der Check nachdem Domainnamen durch den Befehl "openssl" schlägt fehl. Ich habe diese Abfrage, also "domain_found" ausgeblendet. Das Skript läuft dann sauber durch.

Ich bin mir leider nur nicht sicher, für was die Abfrage genau gebraucht wurde.

Das alles ist erstmal nicht so @haydibe, trotzdem danke, dass du dich so schnell gemeldet hast.

Leider habe ich mich schon an die Gitlab Runner und das Deployment gewöhnt. Gitea ist auf jeden Fall eine gute Alternative.

Vielleicht könntest du mir kurz erklären, für was die Abfrage der Domain da war

Vielen Dank!

draegig

 

[haydibe]

Vielleicht könntest du mir kurz erklären, für was die Abfrage der Domain da war

Zum identifizieren in welchem Verzeichnis das Zertifikat für die Domain liegt, damit dann die richtigen Daten kopiert werden ^^

 

[draegig]

Zum identifizieren in welchem Verzeichnis das Zertifikat für die Domain liegt, damit dann die richtigen Daten kopiert werden ^^

Das Leben kann so einfach sein^^ Vielen Dank!

 

[haydibe]

openssl x509 -in ${synology_certs}/${privatekey} -text | grep DNS:${domain} > /dev/null 2>&1

Stand da im Orginal eigentlich auch ${synology_certs}/${privatekey}? update: stand es nicht. ${privatekey} war damals keine Variable. update-ende
Muss ${current_domain_cert}/${privatekey} sein

Mir fällt gerade auf: das ${synology_cert}sollte, bis auf hinter dem in, überall ${current_domain_cert} sein.
Natürlich stimmt dann der Pfad der synology_cert zugewiesen wurde dann auch nicht mehr.

Die Idee war schon, dass der sich das passende Zertifikat einfach raussucht - ohne das man wissen muss welches es ist.

Das der Typo in dem einen Kommentar mit certifiacte in sovielen Ausprägungen in diesem Skript noch von niemandem korrigiert wurde ... ?

 

[xelarep]

[Edit] ursprünglichen Fehler durch neuen Fehler ersetzt...

Hallo zusammen,

Zeit diesen Thread mal wieder zu reanimieren

Ich habe heute versucht, meine Installation mal wieder zu aktualisieren. Im Prinzip so wie beim letzten mal:

1. Backup mit rake im gitlab container
2. neue Docker Installation aufsetzen (inkl. docker-compose.yml Version 2 auf 2.3)
3. Backups zurück spielen

Von Version 12.10.6 (Postgres 10-2) auf 16.6.1 (Postgres 14-20230628)

Dieses mal bleib ich leider beim Rückspielen des Backups stecken:

sudo /usr/local/bin/docker exec -it new_gitlab_1 bash -c "sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production BACKUP=1701711569_2023_12_04_12.10.6 --trace"

Bricht mit Version mismatch ab

** Invoke gitlab:backup:restore (first_time)
** Invoke gitlab_environment (first_time)
** Execute gitlab_environment
** Invoke environment (first_time)
** Execute environment
** Execute gitlab:backup:restore
2023-12-05 09:44:01 UTC -- Unpacking backup ...
2023-12-05 09:44:01 UTC -- Unpacking backup ... done
GitLab version mismatch:
  Your current GitLab version (16.6.1) differs from the GitLab version in the backup!
  Please switch to the following version and try again:
  version: 12.10.6


Hint: git checkout v12.10.6
2023-12-05 09:44:01 UTC -- Deleting tar staging files ...
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/backup_information.yml
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/db
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/repositories
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/uploads.tar.gz
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/builds.tar.gz
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/artifacts.tar.gz
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/pages.tar.gz
2023-12-05 09:44:01 UTC -- Cleaning up /home/git/data/backups/lfs.tar.gz
2023-12-05 09:44:01 UTC -- Deleting tar staging files ... done
2023-12-05 09:44:01 UTC -- Deleting backups/tmp ...
2023-12-05 09:44:01 UTC -- Deleting backups/tmp ... done
2023-12-05 09:44:01 UTC -- Deleting backup and restore PID file ... done

Wie komme ich jetzt weiter?

PS: backup wurde mit

sudo /usr/local/bin/docker exec -it gitlab bash -c "sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1"

erstellt

 

[tAntChen]

Das wird dir jetzt nicht helfen aber ich hab mich wegen dieser Probleme mit GitLab von dem Projekt seit einem halben Jahr verabschiedet. Es kostete mich einfach zu viel Wartungsaufwand. Deswegen bin ich zu gogs gewechselt. Das hat zwar nicht annähernd das Featureset wie GitLab aber der Container frisst kaum Ressourcen ist schnell und das Updaten/Backupen/Restoren ist ein Kinderspiel. Für den, der den ganzen SchiSchi von GitLab nicht unbedingt braucht ist das ne echte Alternative.

 

[tAntChen]

Zu dem Problem selbst: Um ein Backup zu restoren must du exact die GitLab version installiert haben, mit der das Backup erstellt wurde sonst wird das einfach abgelehnt.

Ein echt nerviges "Feature". Bei mir hatten sich mit der Zeit auch einige Fehler in der Datenbank-Migration aufgetürmt, die man nur manuell beheben konnte. Einfach nur weil die Migrationen beim Update fehlerhaft waren. Wenn da etwas bei denen im Bugtracker liest findet man solche Geschichten immer wieder. Ich war es irgendwann einfach leid.

 

[xelarep]

Danke, vielleicht sollte ich das auch mal in Erwägung ziehen. Hättest du ggf. “Starthilfe“? Auch hier gibts ja wieder Abhängigkeiten zu Datenbanken, Zertifikate zu erstellen, Backups usw. …
Gerne auch mit Portainer…

 

[tAntChen]

Naja von Portainer hab ich keine Ahnung das hab ich nie benutzt. Ich hab lediglich ein Container in meinem "Container Manager" angelegt. Das Setup war auch sehr einfach. Die Domain und SSL habe ich über das Web-Portal eingerichtet. Das war wirklich keine Raketenwissenschaft.

hier meine docker-compose.yml

version: "2"

services:
  gogs:
    image: gogs/gogs
    user: "${UID}:${GID}"
    restart: always
    volumes:
      - ./data:/data
      - /volume1/backup/gogs-git:/backup
    ports:
      - "${SSH_PORT}:22"
      - "${HTTP_PORT}:3000"
    links:
      - gogs_db
    depends_on:
      - gogs_db
    environment:
      RUN_CROND: ${RUN_CROND}
      BACKUP_INTERVAL: ${BACKUP_INTERVAL}
      BACKUP_RETENTION: ${BACKUP_RETENTION}
      POSTGRES_DB: gogs
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      POSTGRES_USER: "${POSTGRES_USER}"

  gogs_db:
    image: postgres
    restart: always
    volumes:
      - ./pg_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: gogs
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"

hier die zugehörige .env

UID=0
GID=0

POSTGRES_USER=gogs
POSTGRES_PASSWORD=********************


HTTP_PORT=3000
SSH_PORT=10022
RUN_CROND=1
BACKUP_INTERVAL=1d
BACKUP_RETENTION=14d

Und hier meine data/gogs/conf/app.ini
An der Stelle war das ganze etwas tricky. Zum einen hat er ums verrecken das DB Passwort ( %(POSTGRES_PASSWORD) ) nicht aus dem environment genommen. Deswegen hab ich das dann manuell eingetragen.
Damit das ganze mit SSL richtig funktionierte hab ich ihm ein paar self-signed Zertifikate hingelegt damit der Server zufrieden ist. Die eigentlichen Zertifikate liefert schließlich die DS über die Web-Station aus.

BRAND_NAME = Gogs
RUN_USER   = git
RUN_MODE   = prod

[database]
TYPE     = postgres
HOST     = gogs_db:5432
NAME     = gogs
SCHEMA   = public
USER     = gogs
PASSWORD = ********************
;PASSWORD = %(POSTGRES_PASSWORD)
SSL_MODE = disable
PATH     = /app/gogs/data/gogs.db

[repository]
ROOT           = /data/git/gogs-repositories
DEFAULT_BRANCH = master

[server]
PROTOCOL         = https
DOMAIN           = meine-url-tolle-url.de
HTTP_PORT        = 3000
ROOT_URL         = https://meine-url-tolle-url.de/
EXTERNAL_URL     = https://meine-url-tolle-url.de/
DISABLE_SSH      = false
SSH_PORT         = 22
START_SSH_SERVER = false
OFFLINE_MODE     = false
CERT_FILE        = /data/ssl/cert.pem
KEY_FILE         = /data/ssl/key.pem

[mailer]
ENABLED = false

[auth]
REQUIRE_EMAIL_CONFIRMATION  = false
DISABLE_REGISTRATION        = true
ENABLE_REGISTRATION_CAPTCHA = false
REQUIRE_SIGNIN_VIEW         = true

[user]
ENABLE_EMAIL_NOTIFICATION = false

[picture]
DISABLE_GRAVATAR        = false
ENABLE_FEDERATED_AVATAR = false

Ob das ganze Best Practice ist wage ich selbst zu bezweifeln aber für mich funktioniert es.

 

[haydibe]

Kann Gogs mittlerweile, so wie sein Fork Gitea, oder dessen Fork Forgejo, auch Pipelines?

An der Stelle war das ganze etwas tricky. Zum einen hat er ums verrecken das DB Passwort ( %(POSTGRES_PASSWORD) ) nicht aus dem environment genommen. Deswegen hab ich das dann manuell eingetragen.

Wenn das Gogs Image wie das Gitea Image ist, dann wir die app.ini beim ersten Mal geniert und nur dann werden die ENV-Variablen in die Konfig übernommen. Danach ist es egal was man in den ENVs macht. Würde mich nicht wundern, wenn es hier genauso ist.

 

[tAntChen]

Kann Gogs mittlerweile, so wie sein Fork Gitea, oder dessen Fork Forgejo, auch Pipelines?

Nein Pipelines hat es nicht

Wenn das Gogs Image wie das Gitea Image ist, dann wir die app.ini beim ersten Mal geniert und nur dann werden die ENV-Variablen in die Konfig übernommen. Danach ist es egal was man in den ENVs macht. Würde mich nicht wundern, wenn es hier genauso ist.

Verstehe, so soll das also funktionieren. Ich dachte das wird von GO so zur Laufzeit geladen. Sowas gibt es ja durchaus in anderen Sprachen.

 

[xelarep]

Puh, da muss ich mich doch noch mal intensiver mit Docker auseinandersetzen. Hab die Hälfte schon wieder vergessen...

Hab jetzt erst mal meine Installation aufgeräumt - also zurück auf meinen alten GitLab Stand, Portainer einmal geupdated, mein altes Node-Red mal angeworfen und alles im Portainer bestaunt.

Portainer hat mir jede Menge "Volumes"-Leichen wie beispielsweise /volume1/@Docker/volumes/[...]354451d66b7268416cf/_data
sichtbar gemacht. Scheinen auch noch Relikte aus meiner bisherigen Gitlab Installation zu sein - zumindest erscheinen nach jedem docker-compose down/up wieder zwei neue ununsed Volumes

Ich hab heute vormittag auch mal weiter recherchiert: zumindest von Gitea scheint es brauchbare Templates für Portainer zu geben. Werde mich da mal etwas weiter einlesen, und dann das Thema Stacks für Gogs in Angriff nehmen. Das sollte ja irgendwie(tm) machbar sein.

Den Container Manager habe ich noch nicht, da ich noch auf DSM 6.2 unterwegs bin, ein weiteres Docker-Projekt: weg von der Photo-Station zu ??? Aber das ist ein anderes Thema

 

[plang.pl]

"Volumes"-Leichen

Die entstehen, wenn man nicht auf ein Bind-Mount setzt. Mache ich ausschließlich. D.h. ICH gebe den Pfad an, wo die Daten auf der Platte liegen. Normalerweise leg ich das dann in den docker-Share.

weg von der Photo-Station zu ???

https://www.synology-forum.de/threads/alternative-3rd-party-photo-praesentationsserver.112404/

 

[xelarep]

Hm, eigentlich hatte ich das ja damals gemacht: im docker-Share gibt es nen Ordner gitlab und dort liegen jeweils ein Ordner für gitlab und postgresql (und historisch redis) -die auch schön gefüllt wurden.

Ich hatte damals das docker-compose.yml von @draegig benutzt und angepasst... Hier jetzt mal nur Exemplarich der Anfang mit den bindings

version: '2'

services:
  redis:
    restart: always
    image: redis:6.2.6
    container_name: redis
    volumes:
    - /volume1/docker/gitlab/redis:/var/lib/redis:Z

  postgresql:
    restart: always
    image: sameersbn/postgresql:10-2
    container_name: postgresql
    volumes:
    - /volume1/docker/gitlab/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlabdbusr
    - DB_PASS=gitlabdbpw
    - DB_NAME=gitlab
    - DB_EXTENSION=pg_trgm,btree_gist

  gitlab:
    restart: always
    image: sameersbn/gitlab:12.10.6-1
    container_name: gitlab
    depends_on:
    - redis
    - postgresql
    ports:
    - "10443:443"
    - "10080:80"
    - "10022:22"
    volumes:
    - /volume1/docker/gitlab/gitlab:/home/git/data:Z
    environment:
    - DEBUG=false

Den Alternativen Thread kenne ich, da hab ich im Februar mal mitgemacht. Piwigo damals nativ installiert, aber irgendwann nicht weitergemacht. Hat mich wohl nicht so überzeugt

 

[plang.pl]

Da setzt du ja eigentlich auch auf Bind-Mounts.
Wenn du bei einem Container ein Verzeichnis vergessen hast zu mappen, werden die @Docker mounts manchmal automatisch gesetzt. Das siehst du aber dann, wenn du den laufenden Container einmal bearbeitest. Was hat es mit dem "Z" auf sich?

 

[alexhell]

Ich musste das auch gerade googeln: https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label

 

[xelarep]

Huch, das :Z kann ich tatsächlich nicht erklären - seit Anfang drin. Hab's eben rausgenommen (3x...), und zweimal durchstartet (per docker-compose up -d)

Welche mounts sollte ich denn vergessen haben?

Ändert aber nichts:
Beim Runterfahren des Gitlabs (docker-compose-down) bleiben die beiden Volumes mit aktueller Uhrzeit als 'unused' im Portainer sichtbar, beim Neustarten werden zwei neue Volumes angelegt...

Ich möchte da aber jetzt auch nicht ewig suchen - will ja doch weg von Gitlab

 

[alexhell]

Ich frag mich gerade wieso du nicht das offizielle Docker Image nutzt...
Ich hab mir aber gerade das Dockerfile von dem Image angeguckt was du nutzt und da sieht man, dass folgende Volumes benutzt werden:

VOLUME ["${GITLAB_DATA_DIR}", "${GITLAB_LOG_DIR}","${GITLAB_HOME}/gitlab/node_modules"]

Eins wird gemappt, die anderen zwei nicht.