Docker von Extern und HTTPS mit GitLab

[haydibe]

Was für Links hättest Du denn? Das Docker Paket in DSM6 enthält docker-compose von Haus aus.

Sprich: es reicht aus, wenn Du eine Shell öffnest und in das Verzeichnis wechselst, indem das docker-compose.yml file liegt.
Dort rufst Du in einfach den Befehl 'docker-compose -d up' auf und voila -> alles läuft.

Vorher macht es sinn die Datei docker-compose.yml anzupassen und Parameter an Bedürfnisse anzupasen:
- User und Group-Mapping, in den envoirenment Teil der Drei Container folgendes hinzufügen:
- USERMAP_UID=1000 {die UID des Users unter dem der Container laufen soll}
- USERMAP_GID=65536 {die GID der Gruppe unter dem der Container laufen soll}

Warum ist das wichtig? Weil Du Deinen Container weder mit Root noch mit x-belibiger UID:GID betreiben willst.
Wichtig ist nur das die gewählte UID:GID in deiner DSM vorhanden ist und auch schreibrechte im ausgewählen lokalen Verzeichnis hat.

- Zeitzonen, SSL und Hostname (verwendet für bspw. Emails) Einstellungen:
- TZ=Europe/Berlin
- GITLAB_TIMEZONE=Berlin
- GITLAB_HTTPS=true
- GITLAB_HOST=mein.dyndns.name {deine URL}
- GITLAB_PORT=10443
- GITLAB_SSH_PORT=10022

(Wichtig bei der yml-Datei: die Einrückung der Parameter geschieht immer NUR per Leerzeichen, niemals mit einem Tab. Die Tiefe der Einrückung ist entscheidend!)

Die Anbindung an ein SMTP-Konto sollte auch schon vorkonfiguriert sein, da Gitlab ohne Mailversand keinen sinn ergibt.
Eine Liste von Parameter für Online-Mailer findest Du hier: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/smtp.md

Das docker-compose file ist im prinzip nichts anderes als die Beschreibung von drei Containern. Volume, Expose und Environment parameter werden genauso gehandhabt.

Sinnvolle Links:
https://docs.docker.com/compose/gettingstarted/
https://www.ab-heute-programmieren.de/docker-teil-5-docker-compose-fuer-mehrere-container/

Hilft Dir das weiter? Oder wolltest Du andere Links haben?

 

[draegig]

Das Hilft mir schon sehr! Ich melde mich wenn ich schlauer bin.

Ab Mitte nächsten Monat werde ich mich schleunigst um die Anleitung kümmern, hab leider noch viel Arbeit bis dahin!

Bis dahin, gut Kick!

Cheers!

Alex

 

[haydibe]

Ich habe mal ein Bash-Skript erstellt um ein LetsEncrypt-Zertikat in das Gitlab-Zertifikatsverzeichnis zu kopieren.
Nach Ausführen des Skripts muss der Container neu gestartet werden, damit das neue Zertifikat greift.

Das Skript kann prinzipiel auch als Chronjob laufen, da das Gitlab-Zertifikat nur dann ersetzt wird, wenn das vHost-Zertifikat neuer ist.

#!/bin/bash
vhost_certs=/usr/local/etc/certificate/WebStation/vhost_a7810e42-60f0-44a2-a656-2fc1e8f17e8e
gitlab_certs=/volume1/docker/haydibe/gitlab/gitlab/certs
gitlab_crt=gitlab.crt
gitlab_key=gitlab.key

# time of last status change, seconds since Epoch
last_change_vhost_key=$(stat -c %Z ${vhost_certs}/privkey.pem)
last_change_gitlab_key=$(stat -c %Z ${gitlab_certs}/${gitlab_key})
if [ ${last_change_gitlab_key:-0} -le ${last_change_vhost_key} ]; then
        cp ${vhost_certs}/privkey.pem ${gitlab_certs}/${gitlab_key}
        cat ${vhost_certs}/cert.pem ${vhost_certs}/fullchain.pem > ${gitlab_certs}/${gitlab_crt}

        chown haydibe:docker ${gitlab_certs}/*
        chmod 444 ${gitlab_certs}/*
    echo "restart gitlab container to activate new key"
else
        echo "nothing to do, gitlab key is newer than the vhost key"
fi

Die Variable vhost_certs muss angepasst werden: statt vhost_a7810e42-60f0-44a2-a656-2fc1e8f17e8e müsst Ihr euer entsprechendes vHost-Verzeichnis verwenden.
Die Variable gitlab_certs muss so angepasst werden, dass der Pfad zu eurem gitlab/certs-Verzeichnis passt.

Vor dem ersten Start von Gitlab muss im gitlab/certs-Verzeichnis unbedingt dhparam angelegt werden:

openssl dhparam -out dhparam.pem 2048

Die schlechte Nachricht ist, dass die Erstellung von dhparam eine halbe Ewigkeit dauert; die Gute: die Datei ist unabhängig von dem verwendeten Zertikat und muss bei einem Zertifikats-Tausch nicht erneut erstellt werden.

 

[draegig]

Ich weiß... es ist jetzt 1 Jahr her ... hatte mich auf was wichtigeres konzentrieren müssen.

...

Hier ist mein aktuelles docker-compose.yml

Ich werde versuchen GitLab mit Docker-Compose zum laufen zu bringen!
Wenn es funktioniert werde ich eine Anleitung erstellen und diese als Beitrag posten.


Folgende "docker-compose.yml" config ist noch nicht getestet.

version: '2'
services:
  postgresql:
    restart: always
    image: sameersbn/postgresql:latest
    environment:
      - DB_USER=<user>
      - DB_PASS=<password>
      - DB_NAME=<db_name>
      - DB_EXTENSION=mysql
  volumes:
    - /docker/gitlab/postgresql:/var/lib/postgresql
  gitlab:
    restart: always
    image: sameersbn/gitlab:latest
    depends_on:
      - redis
      - postgresql
    ports:
      - "10080:80"
      - "100443:443"
    environment:
      - DEBUG=false
      - TZ=Europe/Berlin
      - GITLAB_TIMEZONE=UTC

      - GITLAB_SECRETS_DB_KEY_BASE=<rdm_key>

      - GITLAB_HOST=<url_of_diskstation>
      - GITLAB_PORT=10080
      - GITLAB_SSH_PORT=100443
      - GITLAB_RELATIVE_URL_ROOT=

      - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
      - GITLAB_NOTIFY_PUSHER=false

      - GITLAB_EMAIL=<email>
      - GITLAB_EMAIL_REPLY_TO=<email>
      - GITLAB_INCOMING_EMAIL_ADDRESS=<email>

      - GITLAB_BACKUP_SCHEDULE=daily
      - GITLAB_BACKUP_TIME=01:00

      - SMTP_ENABLED=true
      - SMTP_DOMAIN=<provider.url.de>
      - SMTP_HOST=<smtp.url.de>
      - SMTP_PORT=587
      - SMTP_USER=<email>
      - SMTP_PASS=<password>
      - SMTP_STARTTLS=true
      - SMTP_AUTHENTICATION=login

      - IMAP_ENABLED=true
      - IMAP_HOST=<smtp.url.de>
      - IMAP_PORT=993
      - IMAP_USER=email
      - IMAP_PASS=<password>
      - IMAP_SSL=true
      - IMAP_STARTTLS=true
    volumes:
      - /docker/gitlab:/home/git/data
  redis:
    restart: always
    image: sameersbn/redis:latest
    volumes:
      - /docker/gitlab/redis:/var/lib/redis

 

[haydibe]

script update:
1. das richtige VHost-Verzeichnis wird nun gesucht und verwendet
2. Docker wird direkt gestopped und gestartet, damit das Zeritifikat gleich greift

#!/bin/bash
gitlab_certs=/volume1/docker/gitlab/gitlab/certs
gitlab_crt=gitlab.crt
gitlab_key=gitlab.key
vhost=my.dyndns-address.org
uname=haydibe
gname=docker

for current_vhost in /usr/local/etc/certificate/WebStation/*; do
 if [ -f ${current_vhost}/cert.pem ];then
    openssl x509 -in ${current_vhost}/cert.pem -text | grep DNS:${vhost} > /dev/null 2>&1 &
    is_vhost=$?
    if [ "${is_vhost}" = "0" ]; then
        # time of last status change, seconds since Epoch
        last_change_vhost_key=$(stat -c %Z ${current_vhost}/privkey.pem)
        last_change_gitlab_key=$(stat -c %Z ${gitlab_certs}/${gitlab_key})
        if [ ${last_change_gitlab_key:-0} -le ${last_change_vhost_key} ]; then
            echo "gitlab ssl certificate is outdated... updating from vhost"
            cp ${current_vhost}/privkey.pem ${gitlab_certs}/${gitlab_key}
            cat ${current_vhost}/cert.pem ${current_vhost}/fullchain.pem > ${gitlab_certs}/${gitlab_crt}

            chown ${uname}:${gname} ${gitlab_certs}/*
            chmod 444 ${gitlab_certs}/*

            echo "restarting gitlab container to activate new key"
            container_id=$(docker ps | grep sameersbn/gitlab | cut -c1-12)
            docker stop ${container_id}
            docker start ${container_id}
            echo "gitlab ssl certificate update"
        else
            echo "nothing to do, gitlab ssl certifiacte is same or newer than the vhost ssl certificate"
        fi
    fi
fi
done

Folgende Variablen müsst Ihr anpassen:
gitlab_certs: Pfad in dem die Gitlab Zertifikate liegen sollen
vhost: full qualified domain name. In meinem Fall xxx.dyndns-address.org
uname: Syno-Benutzername der den Gitlab Container ausführt.
gname: Syno-Benutzergruppe die den Gitlab-Container ausführt.

uname und gname müssen identisch sein zu Benutzer:Gruppe, die auch den Gitlab-Container ausführt!

gitlab_crt und gitlab_key brauchen nicht verändert werden. Sie haben bereits den richtigen Default-Wert.

Was fehlt? Idealerweise tragt ihr das Script als Chronjob ein und lasst es täglich laufen.

 

[draegig]

An alle Leser dieses Beitrages, ich habe es geschafft und verfasse demnächst eine Anleitung!

 

[draegig]

Lösung: Anleitung via Docker-Compose

Anleitung: Synology DSM Docker mit GitLab (docker-compose)

Vorbereitung

Ich habe auf meiner Diskstation DSM 6 installiert, aktuell läuft meine Diskstation unter der Version: DSM 6.0.2-8451 Update 7

Paketzentrum

Voraussetzung für das Vorhaben ist natürlich Docker.
Installation: Ihr geht in euer Paketzentrum und sucht in der Kategorie: "Dienstprogramme". Klickt einfach auf installieren und folgt den Anweisungen.

Ordnerstruktur vorbereiten

Die folgende Ordnerstruktur ist eine Grundstruktur, man kann diese verändern, jedoch müssen diese Ändernungen auch an jeder Stelle angepasst werden.

/volume1/docker/
??? gitlab/
    ??? gitlab
    ??? postgresql
    ??? redis

Anlegen der Ordnerstruktur

Die Ordnerstruktur legt ihr einfach über "File Station" an.



Docker-File (docker-compose.yml)

Docker-File speichern

Wo lege ich mein "docker-compose.yml" ab?

Mein "docker-compose.yml" für GitLab liegt in einem allgemeinen Ordner. Wichtig ist nur, dass ihr via SSH dort hin navigieren könnt (meine Datei liegt nicht unter: /volume1/docker).

Anpassen der Datei

version: '2'

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

  postgresql:
    restart: always
    image: sameersbn/postgresql:9.5-3
    container_name: postgresql
    volumes:
    - /volume1/docker/gitlab/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=DATENBANK_USER
    - DB_PASS=DATENBANK_PASSWORT
    - DB_NAME=DATENBANK_NAME
    - DB_EXTENSION=pg_trgm

  gitlab:
    restart: always
    image: sameersbn/gitlab:8.14.5
    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

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=DATENBANK_USER
    - DB_PASS=DATENBANK_PASSWORT
    - DB_NAME=DATENBANK_NAME

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Europe/Berlin
    - GITLAB_TIMEZONE=UTC

    - GITLAB_HTTPS=true

    - GITLAB_HOST=DEINE_DOMAIN_ODER_IP
    - GITLAB_PORT=10433
    - GITLAB_SSH_PORT=10022
    - GITLAB_SECRETS_DB_KEY_BASE=64_ZEICHEN_AUS_BUCHSTABEN_UND_ZAHLEN
    - GITLAB_SECRETS_SECRET_KEY_BASE=64_ZEICHEN_AUS_BUCHSTABEN_UND_ZAHLEN
    - GITLAB_SECRETS_OTP_KEY_BASE=64_ZEICHEN_AUS_BUCHSTABEN_UND_ZAHLEN

    - UNICORN_WORKERS=BEI_2GB_RAM_1_BEI_8GB_RAM_3
    - GITLAB_ROOT_PASSWORD=20_BIS_64_ZEICHEN_AUS_BUCHSTABEN_UND_ZAHLEN
    - GITLAB_ROOT_EMAIL=email@domain.de
    - GITLAB_SIGNUP_ENABLED=false

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=false

    - GITLAB_EMAIL=email@domain.de
    - GITLAB_EMAIL_REPLY_TO=noreply@domain.de
    - GITLAB_INCOMING_EMAIL_ADDRESS=email@domain.de

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00
    - GITLAB_BACKUP_EXPIRY=1209600

    - SMTP_ENABLED=true
    - SMTP_DOMAIN=1und1.de
    - SMTP_HOST=smtp.1und1.de
    - SMTP_PORT=587
    - SMTP_USER=email@domain.de
    - SMTP_PASS=20_BIS_64_ZEICHEN_AUS_BUCHSTABEN_UND_ZAHLEN
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login

Das ist meine persönliche Konfiuration. Alle weiteren Einstellungen und die Erklärungen findet ihr unter: https://hub.docker.com/r/sameersbn/gitlab/

SSL Zertifikat (Let's Encrypt)

Zertifikat aufbereiten



Klickt auf "Zertifikat Exportieren" ladet die Zertifikate in folgenden Ordnerpfad über die "File Station" hoch.

/volume1/docker/gitlab/gitlab/certs (Ordner einfach erstellen)

Aufbereitung der Zertifikate

Navigiert via SSH zum Ordner eurer Zertifikate.

cat cert.pem chain.pem > gitlab.crt  
mv privkey.pem gitlab.key

openssl dhparam -out dhparam.pem 2048

/volume1/docker/gitlab/gitlab
??? certs
    ??? dhparam.pem
    ??? gitlab.crt
    ??? gitlab.key

GitLab initiieren

Dazu müsst Ihr euch via SSH auf eure Diskstation einloggen und zur "docker-compose.yml" navigieren.

Ausführen

Mit diesem Befehl startet und initiiert Ihr den GitLab-Container das erste Mal, das kann eine Weile dauern und meist ist GitLab erst nach einer Minute voll einsatzbereit.

Docker starten

sudo docker-compose up

Docker im Hintergrund starten

-d Detached mode: Run containers in the background, print new container names.

sudo docker-compose up -d

GitLab updaten

Dazu müsst Ihr euch via SSH auf eure Diskstation einloggen und zur "docker-compose.yml" navigieren.

Container stoppen

Als erstes solltet Ihr eure Container stoppen.

Docker stoppen

sudo docker-compose down

Docker-File anpasssen

Passt euer "docker-compose.yml" via vim oder nano, falls installiert an.

Insert-Mode aktivieren [ i ].

sudo vi docker-compose.yml

Version an das Release anpassen (https://hub.docker.com/r/sameersbn/gitlab/).

gitlab:
    restart: always
    image: sameersbn/gitlab:8.15.1

Insert-Mode deaktivieren [ esc ] und die Datei überschreiben [ shift ] + [ : ].

:wq!

GitLab-Container starten

sudo docker-compose up -d

 

[haydibe]

Schöne Anleitung Draegig!

 

[draegig]

Dankeschön!

 

[haydibe]

Hier nochmal eine angepasste Version des Zertifikat-Kopier-Skripts.
Es ist so ausgelegt, dass es sich das passende Zertifikat anhand des host Namen sucht und in dem benötigten Format in das Gitlab-Verzeichnis kopiert. Das Skript ersetzt nur dann das Zertifikat, wenn ein neues Letsencrypt-Zertifikat vorliegt (oder bisher keins in gitlab/certs). Zusätzlich startet es auch den Gitlab-Container neu, damit das Zertifikat greift.

#!/bin/bash 
# domain certificate is valid for
domain=my.domain.com

# gitlab certificate folder
gitlab_certs=/volume2/docker/haydibe/gitlab/gitlab/certs

# targetname of the crt and key file in the certificate folder
gitlab_crt=gitlab.crt
gitlab_key=gitlab.key

# uid:gid used to change ownership in certificate folder
uid=haydibe
gid=docker

# name of the docker image to restart 
image=sameersbn/gitlab

for current_domain_cert in /usr/syno/etc/certificate/_archive/*; do
    if [ -d ${current_domain_cert} ] && [ -f ${current_domain_cert}/cert.pem ];then
		openssl x509 -in ${current_domain_cert}/cert.pem -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 ${current_domain_cert}/privkey.pem)
			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
			
				echo "gitlab ssl certificate is outdated... updating from domain certificate"
				cp ${current_domain_cert}/privkey.pem ${gitlab_certs}/${gitlab_key}
				cat ${current_domain_cert}/cert.pem ${current_domain_cert}/fullchain.pem > ${gitlab_certs}/${gitlab_crt}

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

				echo "restarting gitlab container to activate new certificate"
				container_id=$(docker ps | grep "${image}" | cut -c1-12)
				docker stop ${container_id}
				docker start ${container_id}
				echo "gitlab ssl certificate update"

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

Prinzipiel können mehrere Kopien des Skripts für beliebige Docker-Container verwendet werden, solange die Ihr Zertifikat genau in dem Format brauchen.
Notfalls kann man vor jeden Container, der über HTTP erreichbar ist einen nginx schnallen und dem das Zertifikat unterschieben.

 

[tAntChen]

Hallo Freunde,

auch ich habe mich heute mit diesem Problem herumgeschlagen und dieser Thread war wirklich sehr hilfreich. Ich möchte hier noch meine Erfahrungen schildern, eventuell sind sie noch hilfreich für andere.

Vielen Dank an haydibe für dein Script das ist sehr komfortabel.
Anmerkung: Bei der Erstellung der dhparam.pem muss wirklich sehr geduldig sein! Das hat gefühlt bestimmt 1 Sunde gedauert!

Ich habe keine eigene Docker Config benutzt wie draegig sondern mich auf die /usr/syno/etc/packages/Docker/synology_gitlab.config gestürzt. Nachdem ich die Zertifikate aufbereitet und in den Container gebracht hatte, gab es noch einige Fehlversuche. Im Container Protokoll fand ich immer wieder die Zeile SSL Key, SSL Certificate and DHParam were not found.


Danach habe ich, im Container, mal gesucht und fand in /etc/docker-gitlab/runtime/functions folgenden Code:

  ## ${GITLAB_NGINX_CONFIG}                                                                                        
  if [[ ${GITLAB_HTTPS} == true ]]; then                                                                           
    if [[ -f ${SSL_CERTIFICATE_PATH} && -f ${SSL_KEY_PATH} && -f ${SSL_DHPARAM_PATH} ]]; then                      
      install_template root: nginx/gitlab-ssl ${GITLAB_NGINX_CONFIG}                                               
    else                                                                                                           
      echo "SSL Key, SSL Certificate and DHParam were not found."                                                  
      echo "Assuming that the container is running behind a HTTPS enabled load balancer."                          
      install_template root: nginx/gitlab ${GITLAB_NGINX_CONFIG}                                                   
    fi                                                                                                             
  else                                                                                                             
    install_template root: nginx/gitlab ${GITLAB_NGINX_CONFIG}                                                     
  fi

Also braucht die config noch Pfade zu den Zertifikaten (SSL_CERTIFICATE_PATH,SSL_KEY_PATH,SSL_DHPARAM_PATH)


Dann habe ich meine /usr/syno/etc/packages/Docker/synology_gitlab.config nochmal angepasst und die fehlenden Pfade angepasst. Und dann lief es bei mir wunderbar.

{
  "cap_add": [],
  "cap_drop": [],
  "cmd": "",
  "cpu_priority": 0,
  "ddsm_bind_share": "",
  "devices": [],
  "enable_publish_all_ports": false,
  "enabled": true,
  "env_variables": [
    {
      "key": "GITLAB_HOST",
      "value": "xyz.synology.me"
    },
    {
      "key" : "GITLAB_HTTPS",
      "value" : "true"
    },
    {
      "key" : "SSL_SELF_SIGNED",
      "value" : "false"
    },
    {
      "key" : "SSL_CERTIFICATE_PATH",
      "value" : "/home/git/data/gitlab/certs/gitlab.crt"
    },
    {
      "key" : "SSL_KEY_PATH",
      "value" : "/home/git/data/gitlab/certs/gitlab.key"
    },
    {
      "key" : "SSL_DHPARAM_PATH",
      "value" : "/home/git/data/gitlab/certs/dhparam.pem"
    },
    {
      "key": "GITLAB_PORT",
      "value": "30000"
    },
    {
      "key": "GITLAB_SSH_PORT",
      "value": "30001"
    },
    {
      "key": "GITLAB_EMAIL",
      "value": "tantchen@example.com"
    },
    {
      "key": "DB_TYPE",
      "value": "mysql"
    },
    {
      "key": "DB_HOST",
      "value": "172.17.0.1"
    },
    {
      "key": "DB_NAME",
      "value": "gitlab"
    },
    {
      "key": "DB_USER",
      "value": "gitlab"
    },
    {
      "key": "DB_PASS",
      "value": "***************************************************************"
    },
    {
      "key": "GITLAB_SECRETS_OTP_KEY_BASE",
      "value": "***************************************************************"
    },
    {
      "key": "GITLAB_SECRETS_DB_KEY_BASE",
      "value": "***************************************************************"
    },
    {
      "key": "GITLAB_SECRETS_SECRET_KEY_BASE",
      "value": "***************************************************************"
    },
    {
      "key": "SMTP_ENABLED",
      "value": "true"
    },
    {
      "key": "SMTP_DOMAIN",
      "value": "smtp.gmail.com"
    },
    {
      "key": "SMTP_HOST",
      "value": "smtp.gmail.com"
    },
    {
      "key": "SMTP_PORT",
      "value": "587"
    },
    {
      "key": "SMTP_USER",
      "value": "example@googlemail.com"
    },
    {
      "key": "SMTP_PASS",
      "value": "************"
    },
    {
      "key": "SMTP_OPENSSL_VERIFY_MODE",
      "value": "peer"
    }
  ],
  "exporting": false,
  "id": "0856b7eea4e9fd36f2c0e53c70f90e23b78a8efa5f232b61a0a729becd228d73",
  "image": "sameersbn/gitlab:8.17.4",
  "is_ddsm": false,
  "is_package": true,
  "links": [
    {
      "alias": "redisio",
      "link_container": "synology_gitlab_redis"
    }
  ],
  "memory_limit": 0,
  "name": "synology_gitlab",
  "port_bindings": [
    {
      "container_port": 443,
      "host_port": 30000,
      "type": "tcp"
    },
    {
      "container_port": 22,
      "host_port": 30001,
      "type": "tcp"
    }
  ],
  "privileged": false,
  "shortcut": {
    "enable_shortcut": false,
    "enable_status_page": false,
    "enable_web_page": false,
    "web_page_url": ""
  },
  "volume_bindings": [
    {
      "host_volume_file": "/docker/gitlab",
      "mount_point": "/home/git/data",
      "type": "rw"
    }
  ]
}

 

[haydibe]

Laut https://github.com/sameersbn/docker-gitlab/blob/master/assets/runtime/env-defaults werden folgende Werte bei jedem Start per Default gesetzt:
SSL_CERTIFICATE_PATH=${SSL_CERTIFICATE_PATH:-$GITLAB_DATA_DIR/certs/gitlab.crt}
SSL_KEY_PATH=${SSL_KEY_PATH:-$GITLAB_DATA_DIR/certs/gitlab.key}
SSL_DHPARAM_PATH=${SSL_DHPARAM_PATH:-$GITLAB_DATA_DIR/certs/dhparam.pem}

Folgende Variablen werden laut https://github.com/sameersbn/docker-gitlab/blob/master/Dockerfile verwendet und sind fest in das Image "eingebacken" :
GITLAB_HOME="/home/git"
GITLAB_DATA_DIR="${GITLAB_HOME}/data"

Wenn Du als Host-seite statt (/volumeX)/docker/gitlab das Verzeichnis (/volumeX)/docker/gitlab/gitlab in den Container-Pfad /home/git/data gemapped hättest, dann wären Deine Zertifikate auch ohne Workaround aus dem lokalen Verzeichnis (/volumeX)/docker/gitlab/gitlab/certs gefunden und verwendet worden. Alternativ auch wenn die Zertifikate in (/volumeX)/docker/gitlab/certs gelegen hätten.

 

[tAntChen]

Danke für die Info.
Aber ich habe doch die Zertifikate in diesem Ordner "/volume1/docker/gitlab/gitlab/certs", jedoch wurde die Zertifikate nicht gefunden. Ich habe diese gerade nach "/volume1/docker/gitlab/certs" geschoben, dann geht es auch ohne die Angabe der einzelnen Pfade. Ich habe mich schon über den doppelten gitlab/gitlab Pfad gewundert!

 

[haydibe]

Ich habe auch die doppelten Verzeichnisse. Die Idee dahinter ist den Compose-Verbund in einem gemeinsamen Verzeichnis zu speichern und je Docker-image ein Unterverzeichnis zu verwenden.
Dadurch das ich das Verzeichnis /volume1/docker/gitlab/gitlab nach /home/git/data gemapped habe, wurden meine Zertifikate in /volume1/docker/gitlab/gitlab/certs sofort erkannt. Du hast das Verzeichnis /volume1/docker/gitlab nach /home/git/data gemapped, so dass die Default-Pfade ins leere gegriffen haben.

 

[xelarep]

Hallo zusammen,

bin gerade dabei mein docker-compose.yaml anzupassen. Kleiner aber feiner Zahlendreher Beispiel von draegig, den mal leicht übersieht - vielleicht kannst Du das noch ändern - vermeidet Panikattacken wenn eine leere Browserseite beim ersten up kommt [Nachtrag]: Das war wohl was anderes, siehe nächster Post von mir...

Streiche: - GITLAB_PORT=10433
Setze: - GITLAB_PORT=10443

Ansonsten super Anleitung. Gerade kommt meine Gitlab Startseite.

Danke!

Alexander

 

[xelarep]

Eine Frage:

Ich habe für mein Gitlab per CNAME/Reverse-Proxy im DSM einen Zugang von extern Port 443 auf intern 10443 eingerichtet. Klappt alles soweit.
Wie bekomme ich Gitlab dazu in e-mails oder den Kommandobeispielen die Portangabe :10443 nicht auszugeben?

Beispiel:

git remote add origin https://gitlabsubdomain.meinetolledomain.de:10443/user.tollesprojekt.git

soll als

git remote add origin https://gitlabsubdomain.meinetolledomain.de/user.tollesprojekt.git

angezeigt werden.

Selbiges hatte ich auch beim Neuer User-Passwort E-mail Link...

Ich Antworte mir mal selber:
- GITLAB_PORT=10443 aus dem docker-compose entfernen und neu starten!

Note To Self: Anleitungen ganz lesen

 

[haydibe]

Wenn möglich würde ich git eher mit ssh zertifikaten ohne Passwort verwenden...

Es ist in der Verwendung einfach deutlich entspannter, da man nie mehr Passwörter eintragen muss

 

[haydibe]

Ich habe für mein Gitlab per CNAME/Reverse-Proxy im DSM einen Zugang von extern Port 443 auf intern 10443 eingerichtet. Klappt alles soweit.

<OT>
Hast Du das über die UI in Application Portal/Reverse Proxy gemacht?

Bisher wirkte das eingebette nginx auf mich immer begrenzt konfigurierbar.
Vorallem, wenn man mal zusätzliche Header oder andere Sonderlocken abbilden muss.

Bisher nehme ich dafür immer einen letsencrypt docker container, der Port 443 und 80 von aussen bekommt.
Je Anwendung habe ich dann eine separate Konfigurationen in site-confs.

Mache ich es mir unnötig kompliziert?
</OT>

 

[xelarep]

Wenn möglich würde ich git eher mit ssh zertifikaten ohne Passwort verwenden...

Das ist mein heutiges Abendprogramm

<OT>
Hast Du das über die UI in Application Portal/Reverse Proxy gemacht?
</OT>

Ja, ich verwende den DSM Reverse Proxy. Für meine Fälle ausreichend: ich hab für jeden benötigten Dienst (oder Gerät) eine CNAME Subdomain auf HTTPS/443 und verteile dann in der DSM nach IPORT um. Damit habe ich nur einen offenen Port, und eine Stelle, wo ich Let's Encrypt Zertifikate verwalten und zuteilen muss. Ich freu mich schon aus Ende Februar, wenn die Let's Encrypt Wildcard Zertifikate kommen sollen.

Bisher Stressfrei. Ab und zu wirft die DSM Loginseite einen 502, nach einem Klick auf Reload kommt die dann aber auch aus dem Quark.

 

[haydibe]

Bisher Stressfrei. Ab und zu wirft die DSM Loginseite einen 502, nach einem Klick auf Reload kommt die dann aber auch aus dem Quark.

Kommt bei mir eigentlich nur, wenn ich nach dem Start des Gitlab-Containers zu früh darauf zugreifen will.
Sobald der Startvorgang einmal abgeschlossen ist, läuft es eigentlich zuverlässig

(think) Du hast eine fest ip und verwaltest Deine DNS-Einträge in DSM?