Anleitung: Gitlab - Docker (No Port-Redirection)

iAcki

Benutzer
Mitglied seit
20. März 2019
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
Hi,

da ich selbst immer auf der Suche nach einer Anleitung für Gitlab im Docker Container war, dachte ich mir nun, dass ich mal meine Erkenntnisse hier zusammentragen kann. Diese Anleitung kann und wird bestimmt auch Fehler beinhalten, aber im Großen und Ganzen sollte sie jedoch mit der aktuellen Version von Gitlab (13.2.0) funktionieren.


Was soll erreicht werden?
Ziel ist es, dass Gitlab samt Redis, Postgresql und Runner in einem „docker-compose.yml“ zusammen konfiguriert und gestartet werden. Ihr könnt natürlich die einzelnen Produkte in separate Container auslagern, aber was zusammengehört, kann meiner Ansicht nach auch zusammenbleiben.



ACHTUNG: In dieser Anleitung ist aktuell noch der Postgresql-Container von „Sameersbn“ in aufgeführt, da ich ursprünglich auch dessen Gitlab Container benutzt habe. Da aber die beiden Entwickler kaum noch Zeit haben und somit deren Version hinterherhängt, habe ich erst am Wochenende auf das offizielle Image von Gitlab-CE umgestellt, aber den PostgreSql – Container noch so belassen. Zu gegebener Zeit werde ich diesen auch auf das offizielle Image umstellen (das schafft ihr aber auch ohne meine Hilfe oder ich reiche das noch nach)



MACVLAN:

Nur ein kurzer Hinweis zu MacVlan, denn eigentlich gibt es hier im Forum reichlich Infos zu diesem Thema. Ich benutze dieses Modul um auf der Netzwerkschnittelle meines NAS mehrere virtuelle Netzwerkschnittstellen einzurichten, so dass ich die eigentlich blockierten Ports „80“ und „443“ in meinen Containern verwenden kann. Es nervt mich immer gewaltig, wenn ich die Ports „umbiege“ und dann in der Url sowas wie „https://meine.domain.de:8080“ verwenden muss. Mit den virtuellen Schnittstellen bekommt euer Container nach außen eine eigene IP aus eurem Netzwerk, bzw. könnt ihr ihm eine entsprechende zuweisen. Ihr solltet aber aufpassen, dass ihr euren DHCP-Server entsprechend einrichtet und das Subnetz des MacVlans im DHCP „ausklammert“, nicht dass es ggf. zu einem IP-Adresskonflikt kommt.




Los geht es!!!


Zuerst müsst ihr euch via Putty oder terminal (Mac) mit eurem NAS verbinden. Hierzu muss aber der SSH – Zugang aktiviert sein. Wie das geht, entnehmt ihr bitte der Anleitung von Synology.


Ich verbinde mich nun also mit diesem Befehl mit meinem NAS:
ssh -p 4711 derSlurp@10.0.0.185


Nun wechsle ich noch den Benutzer, da ich schreibfaul bin:
sudo -i



Einrichtung der Ordnerstruktur


Dieser Punkt ist relativ schnell abgehandelt. Ich persönlich habe mir in dem üblicherweise verwendeten Ordner „Docker“ auf meinem NAS (dieser Ordner ist Standard in jeder Anleitung :LOL: ) einen Unterordner „personal“ angelegt, da ich nicht weiß, ob ich mal „System-Images“ oder was auch immer in dem Ordner „Docker“ hostet, so dass ich meine „eigenen“ Images von anderen unterscheiden kann.


In dem Ordner „personal“ werden nun folgende Verzeichnisse erstellt:

Code:
--  gitlab
     - gitlab
         +  config
         +  data
         + logs

     -  postgresql

     -  gitlab-runner

     -  redis


Achtung: falls es später zu Problemen bei dem Start des Containers „Gitlab“ kommen sollte, dann müsst ihr hier den Owner umstellen (bei mir war es die UID 998 <- der „git“ Benutzer innerhalb meines Containers). Aber das erst dann, wenn ihr Probleme beim Start oder zur Laufzeit bekommt!!!

Das war es dann auch schon mit der Vorbereitung des Dateisystems und jetzt kommt der eigentlich spannende Teil.



Docker-Compose.yml


YAML:
version: '2.4'

services:
  redis:
    restart: always
    image: redis:latest

    mac_address: 'd0:ca:ab:ff:ef:01'

    networks:
      vlan:
         ipv4_address: '10.0.0.201'

    command:
     - --loglevel warning
    volumes:
     - /volume1/docker/personal/gitlab/redis:/var/lib/redis

  postgresql:
    restart: always
    image: sameersbn/postgresql:12-20200524
    container_name: gitlab-postgresql
    mac_address: 'd0:ca:ab:dd:ef:02'
    networks:
      vlan:
         ipv4_address: '10.0.0.202'


    volumes:
     - /volume1/docker/personal/gitlab/postgresql:/var/lib/postgresql

    environment:
     - DB_USER=User
     - DB_PASS='Password-muss-auch-bei-gitlab-gesetzt-werden'
     - DB_NAME=gitlabhq_production
     - DB_EXTENSION=pg_trgm

  gitlab:
    restart: always
    image:  gitlab/gitlab-ce:latest
    container_name: gitlab
    mac_address: 'd0:ca:ab:cd:ef:03'
    networks:
       vlan:
         ipv4_address: '10.0.0.200'


    depends_on:
     - redis
     - postgresql

    ports:
     - "80:80"
     - "22:22"
     - "443:443"

    volumes:
     - /volume1/docker/personal/gitlab/gitlab/config:/etc/gitlab
     - /volume1/docker/personal/gitlab/gitlab/logs:/var/log/gitlab
     - /volume1/docker/personal/gitlab/gitlab/data:/var/opt/gitlab

    healthcheck:
     test: ["CMD", "/usr/local/sbin/healthcheck"]
     interval: 5m
     timeout: 10s
     retries: 3
     start_period: 5m

    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://your.domain.de'
        gitlab_rails['time_zone'] = 'Europe/Berlin'

        gitlab_rails['db_key_base'] = '65-Zeichen-langer-String'
        gitlab_rails['otp_key_base'] = '65-Zeichen-langer-String'
        gitlab_rails['secret_key_base'] = '65-Zeichen-langer-String'

        nginx['listen_port'] = 80
        nginx['listen_https'] = false

        postgresql['enable'] = false
        gitlab_rails['db_adapter'] = 'postgresql'
        gitlab_rails['db_encoding'] = 'unicode'
        gitlab_rails['db_host'] = 'postgresql' # oder IP
        gitlab_rails['db_password'] = 'Password'
        gitlab_rails['db_username'] = 'User'
        gitlab_rails['db_database'] = 'gitlabhq_production'

        redis['enable'] = false
        gitlab_rails['redis_host'] = 'redis'
        gitlab_rails['redis_port'] = '6379'

        gitlab_rails['gitlab_email_enabled'] = true
        gitlab_rails['gitlab_email_from'] = 'gitlab@your.domain.de'
        gitlab_rails['gitlab_email_reply_to'] = 'gitlab@your.domain.de'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = 'smtp-server-name'
        gitlab_rails['smtp_port'] = 587
        gitlab_rails['smtp_user_name'] = 'User'
        gitlab_rails['smtp_password'] = 'password'
        gitlab_rails['smtp_domain'] = 'your.domain.de'
        gitlab_rails['smtp_authentication'] = 'login'
        gitlab_rails['smtp_enable_starttls_auto'] = true

        #### Change the initial default admin password and shared runner registration tokens.
        ####! **Only applicable on initial setup, changing these settings after database
        ####!   is created and seeded won't yield any change.**
        # gitlab_rails['initial_root_password'] = 'Super-Geheimes-Git-Root-Password'
        # gitlab_rails['initial_shared_runners_registration_token'] = 'Kann-Aber-Muss-Nicht-Gesetzt-Werden'


  gitlab-runner:
    image: 'gitlab/gitlab-runner:latest'
    container_name: 'gitlab-runner'
    restart: always
    volumes:
       - /volume1/docker/personal/gitlab/gitlab-runner:/etc/gitlab-runner
       - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
       - gitlab
    networks:
       vlan:
         ipv4_address: 10.0.0.203

networks:
  vlan:
    driver: macvlan

    driver_opts:
      parent: ovs_eth1 # 'ovs' fuer Synology NAS

    ipam:
      config:
        - subnet: 10.0.0.0/24
          gateway: 10.0.0.1
          ip_range: 10.0.0.200/28
ACHTUNG: Beim Bearbeiten der "docker-compose.yml" immer darauf achten, dass ihr NIEMALS Tabulator-Zeichen einbringt, sondern immer nur Leerzeichen!


Container starten und prüfen

Nun ist es endlich soweit und wir können das erste Mal unseren Container (bzw. die Container) starten. Hierzu gebt ihr in Putty oder im Terminal folgenden Befehl ein:
docker-compose up -d

Das -d am Ende des Befehls bewirkt, dass der Container als Dienst gestartet wird und ihr nicht in der Ausführung "gefangen" bleibt.

Nun warten wir bis alles fertig heruntergeladen und gestartet ist.
Wenn alles geklappt hat, dann präsentiert sich die Docker App in DSM wie folgt:

Bildschirmfoto 2020-07-28 um 18.04.38.png

Nicht wundern: Der MySql - Container gehört nicht zu diesem Beispiel, der läuft aber halt bei mir, da dagegen die Runner ihre Unit-Tests schieben.

Wenn wir soweit sind, dann ist schon mal viel geschafft! Nun prüfen wir aber noch die Gitlab-Instanz, so dass auch wirklich alles passt.

Hierzu loggen wir uns in den Container ein:
docker exec -it gitlab bash

Nun prüfen wir mit folgenden Befehl die Instanz und veranlassen ggf. Korrekturen mit "SANITIZE=True":
gitlab-rake gitlab:check SANITIZE=true


Folgendes Ergebnis sollte auch bei euch herauskommen (seid geduldig, selbst bei meiner Rs1619xs+ braucht der Befehl kurz, bis er die ersten Meldungen bringt).

Bildschirmfoto 2020-07-28 um 18.22.23.png


Berechtigungsprobleme / Permission denied
Falls es wider Erwarten zu Problemen bei den Berechtigungen kommt (ggf. als Meldung beim Einchecken von Änderungen in Repositories oder schon grundsätzlich beim Start des Gitlab-Containers -> siehe Logs im Ordner "Logs"), dann loggt euch wieder in den Container ein und gebt folgenden Befehl ein:
gitlab update-permissions

Damit sollte Gitlab automatisch alle Berechtigungen wieder so setzen, wie es sein soll. Falls es dann immer noch nicht klappt, könnt ihr versuchen einzeln alle Berechtigungen mittels "chmod" oder "chown" zu setzen. Bei mit hat der git user die id "998", das sollte eigentlich auch bei euch so sein (also im Container ;)).



Reverse Proxy in NAS (HTTPS Zugriff einrichten)

Falls ihr eure Gitlab-Instanz über eine Url erreichen wollt, dann müsst ihr in den Einstellungen des DSM noch eine Umleitung von der Url auf eure IP des Containers einrichten.
Hierzu wechselt ihr in die Systemsteuerung und dort unter den Punkt Anwendungsportal:
In der Registerkarte Reverse Proxy erstellt ihr nun einen neuen Eintrag:

Bildschirmfoto 2020-07-28 um 17.53.13.png

Wenn ihr nun noch euren Router so konfiguriert, dass er den Port "80" und "443" an eurer NAS schickt, dann habt ihr auch von "außen" Zugriff auf eure Gitlab - Instanz (ein entsprechendes https - Zertifikat gibt es von Let's Encrypt kostenlos -> hierzu gibt es tausende Beiträge und Videos im Netz, wie man das unter DSM einrichtet).



Ich hoffe die Anleitung war verständlich und enthielt nicht zu viel "bla bla".

Gruß Christian
 

Anhänge

Zuletzt bearbeitet:

haydibe

Benutzer
Mitglied seit
12. April 2016
Beiträge
705
Punkte für Reaktionen
7
Punkte
38
Well done! Den Befehl gitlab-rake gitlab:check SANITIZE=true zum überprüfen der Installation hatte ich gar nicht auf dem Schirm. Echt praktisch!

Die Verwendung von MACVLAN ist nur für die lokale Verwendung des git Client über ssh-Verbindung vorteilhaft.

Wenn man den Container eh über den Reverse Proxy anspricht, dann ist Container IP und Port ziemlich egal, da man eh über https und somit über den Domainnamen darauf zugreift, der wiederum (hoffentlich) auf die IP des WAN-Interfaces aufgelöst wird. Spätestens wenn der git Client über eine https-Verbindung zugreift, dann führt kein Weg am Reverse-Proxy vorbei (ausser der Container terminiert TLS selber, aber das verändert nichts and der Situation das man über die WAN-IP reinkommt und dort das Portfwording von 443 auf eine beliebige IP:pORT innerhalb des Netzwerks zeigen kann.). Genau betrachtet liefert MACVLAN hier keinen echten Mehrwert und ist eher "Schmuck am Nachthemd" Najo, kann man so machen, ist Geschmackssache.

Ich glaube im Titel wolltest Du Port-Mapping oder Published-Port statt Port-Redirection vewenden oder?

Update: Formulierungen geschärft und ergänzt.
 
Zuletzt bearbeitet:

iAcki

Benutzer
Mitglied seit
20. März 2019
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
GuMo Haydibe,

vom Prinzip her hast du mit allen Aussagen Recht. :D

Beim Titel war ich in der Tat etwas verwirrt und hab die Admins inzwischen angeschrieben, vielleicht können die den Titel noch ändern.
In Sachen MacVlan geb ich dir aber nur teilweise Recht, da Gitlab hier eine doofe Eigenheit hat.
MacVlans sind in der Tat hauptsächlich etwas für IP-Fetischisten wie mich. Das Mappen der Ports reicht in der Regel immer aus, aber ...
Gitlab hat die unschöne Eigenschaft den gemappten Port in die Url zu schieben, wenn man den Web-Editor benutzt, als auch in der Clone-Url aufzuführen. Das ist zwar in 99% der Fälle völlig egal, da die meisten Browser die Url eh nicht voll anzeigen, aber bei einem meiner Kunden werden Urls blockiert, die eine Portangabe beinhalten. Das führt dazu, wenn man sich eine Datei im Browser anzeigen lassen möchte, man im ersten Schritt immer blockiert wird. Der Nutzer muss jedes Mal in die Adresszeile des Browser wechseln und dort die Portangabe entfernen. Das ist auf Dauer ziemlich ätzend, vor allem wenn man nur mal schnell ein paar Scripte vergleichen mag.
Mit dem MacVlan braucht man das aber nicht mehr, da sich der Container auf Port 80 starten und somit Gitlab die Url in Ruhe lässt.

Gruß Christian
 

haydibe

Benutzer
Mitglied seit
12. April 2016
Beiträge
705
Punkte für Reaktionen
7
Punkte
38
Moin Christian,

Danke für die Erläuterung! Nun ist klar welches Problem durch MACVLAN gelöst werden soll.

Damals im sameersbn/gitlab Image konnte man den für extern dargestellten Port afair mit dem Parameter GITLAB_PORT anpassen. Dieser war dann in Clone links und E-Mails soweit korrekt.:

GITLAB_PORTThe port of the GitLab server. This value indicates the public port on which the GitLab application will be accessible on the network and appropriately configures GitLab to generate the correct urls. It does not affect the port on which the internal nginx server will be listening on. Defaults to 443 if GITLAB_HTTPS=true, else defaults to 80.

Es müsste einen analogen Konfigurationsparameter doch auch im gitlab/gitlab-ce Image geben. Die Frage ist nur wie heisst er dort und wo muss er Konfiguriert werden :)
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.