Anleitung: Gitlab - Docker (No Port-Redirection)

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
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

  • Bildschirmfoto 2020-07-28 um 18.22.23.png
    Bildschirmfoto 2020-07-28 um 18.22.23.png
    720,7 KB · Aufrufe: 17
Zuletzt bearbeitet:
  • Like
Reaktionen: systematicguy

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
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. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
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
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
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 :)
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hallo ich muss das Thema noch mal aufgreifen.

ich habe den Check durchgeführt und bekomme folgenden Fehler

Code:
root@nas:/volume1/docker/personal/gitlab# docker exec -it gitlab bash
root@gitlab:/# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 13.16.1 ? ... OK (13.16.1)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: FAILED - Internal API unreachable
gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u git -H editor /opt/gitlab/embedded/service/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... no
  Try fixing it:
  sudo -u git -H RAILS_ENV=production bin/background_jobs start
  For more information see:
  doc/install/installation.md in section "Install Init Script"
  see log/sidekiq.log for possible errors
  Please fix the error above and rerun the checks.

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ...  yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ... can't check, you have no projects
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 1
Is authorized keys file accessible? ... no
Trying to fix error automatically. ...Failed
  Try fixing it:
  sudo chmod 700 /var/opt/gitlab/.ssh
  touch /var/opt/gitlab/.ssh/authorized_keys
  sudo chmod 600 /var/opt/gitlab/.ssh/authorized_keys
  Please fix the error above and rerun the checks.
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

root@gitlab:/#  exit
exit
dded/service/gitlab-shell/config.ymltlab# sudo -u git -H editor /opt/gitlab/embe
sudo: unknown user: git
sudo: unable to initialize policy plugin                              eixtz
sudo: unknown user: git
sudo: unable to initialize policy plugin


ich musst auch die Docker-componse.yml ein bisschen anpassen

Code:
version: '3.5'

services:
  redis:
    restart: always
    image: redis:5.0.9
    command:
    - --loglevel warning
    networks:
       internal_network:
          ipv4_address: 172.20.1.6
    volumes:
    - /volume1/docker/personal/gitlab/redis:/var/lib/redis

  postgresql:
    restart: always
    image: sameersbn/postgresql:12-20200524
    volumes:
    - /volume1/docker/personal/gitlab/postgresql:/var/lib/postgresql
    networks:
       internal_network:
          ipv4_address: 172.20.1.2
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm,btree_gist

  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    container_name: gitlab
    restart: always
    ports: 
       - '30000:80'
       - '30001:443'
       - '30002:22'
    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
    depends_on:
         - redis
         - postgresql
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://ulmenstr.synology.me'
        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'] = 'gitlab'
        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'] = 'XXXXXXXXX@gmail.com'
        gitlab_rails['gitlab_email_reply_to'] = 'XXXXXXXXX@gmail.com'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = 'smtp.gmail.com'
        gitlab_rails['smtp_port'] = 587
        gitlab_rails['smtp_user_name'] = 'XXXXXXXXX@gmail.com'
        gitlab_rails['smtp_password'] = 'XXXXXXXXXXX'
        gitlab_rails['smtp_domain'] = 'smtp.gmail.com'
        gitlab_rails['smtp_authentication'] = 'login'
        gitlab_rails['smtp_enable_starttls_auto'] = true

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

  gitlab-runner:
     image: gitlab/gitlab-runner:latest
     container_name: 'gitlab-runner'
     volumes:
        - /volume1/docker/personal/gitlab/gitlab-runner:/etc/gitlab-runner
        - /var/run/docker.sock:/var/run/docker.sock
     depends_on:
        - gitlab
     networks:
        internal_network:
            ipv4_address: 172.20.1.4

networks:
   internal_network:
      ipam:
         driver: default
         config:
            - subnet: "172.20.1.0/24"

könnt ihr mir helfen was ich falsch mache?
 
Zuletzt bearbeitet von einem Moderator:

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hallo ich muss ich muss mich korrigieren ich habe das anscheinend zu früh ausgeführt.

Code:
root@3752a0b9aeea:/# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 13.16.1 ? ... OK (13.16.1)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ... can't check, you have no projects
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 1
Is authorized keys file accessible? ... no
Trying to fix error automatically. ...Failed
  Try fixing it:
  sudo chmod 700 /var/opt/gitlab/.ssh
  touch /var/opt/gitlab/.ssh/authorized_keys
  sudo chmod 600 /var/opt/gitlab/.ssh/authorized_keys
  Please fix the error above and rerun the checks.
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

kann mir einer sagen was ich falsch mache?

ich bin schon ewig am probieren... ich komm aber nicht drauf


Mit freundlichen Grüßen
Marco
 

DrDeath

Benutzer
Mitglied seit
31. Aug 2018
Beiträge
189
Punkte für Reaktionen
71
Punkte
34
Bash:
Trying to fix error automatically. ...Failed
  Try fixing it:
  sudo chmod 700 /var/opt/gitlab/.ssh
  touch /var/opt/gitlab/.ssh/authorized_keys
  sudo chmod 600 /var/opt/gitlab/.ssh/authorized_keys
  Please fix the error above and rerun the checks.

Er findet im /var/opt/gitlab/ keinen .ssh Ordner mit der Datei authorized_keys

Sprich: In Deinem Ordner: /volume1/docker/personal/gitlab/gitlab/data fehlt der Ordner .ssh mit den o.g. Rechten.
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hi,
vielen dank für den Hinweis
der Ordner
Code:
root@nas:/volume1/docker/personal/gitlab/gitlab/data/.ssh#
ist aber Angelegt, auch authorized_keys ist vorhanden ich habe nochmal chmod ausgeführt, jedoch leider ohne erfolg

Mit freundlichen Grüßen
 

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
Moinsen,

da man leider nicht abschätzen kann was du schon alles versucht und gemacht hast, kann man nur raten. Du kannst aber mal den Ordner „.ssh“ löschen und dann den Container starten. Der Ordner sollte von allein kommen. Falls nicht, dann wieder mit dem Container verbinden: docker exec ;)

und innerhalb des Containers mal den Befehl „gitlab-ctl reconfigure“ abfeuern.

Gruß, Christian
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hi,

vielen Dank

Code:
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 13.16.1 ? ... OK (13.16.1)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ... can't check, you have no projects
Redis version >= 4.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.0)
Git user has default SSH configuration? ... yes
Active users: ... 1
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

nun bekomme ich keinen Fehler mehr. jedoch bekomm ich immer noch kein zugriff auf gitlab :(

wenn ich die Ip eingebe 192.168.178.43:30000 linkt er mich zwar weiter auf https://192.168.178.43:30000/users/sign_in aber ich bekomm die Seite nicht angezeigt


kann die Seite nicht öffnen weil keine sichere Verbindung besteht.

wenn ich sub.synology.me:30000 eingebe linkt er mich weiter an https://sub.synology.me:30001 mit dem selben Hinweis
 

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
Moinsen,

du musst halt noch zwingend das letsencrypt SSL-Zertifikat in deiner Diskstation einrichten und dann wie meiner Beschreibung den Revers-Proxy von der Url auf die IP Adresse umleiten und dort auf Port 80. ohne ssl und ddns wird das nix ... meine Beschreibung zielt halt ganz genau auf diese Konstellation ab.

Gruß, Christian
 

Anhänge

  • C1E28A0E-7687-44F2-90E4-A3577FF12EB9.jpeg
    C1E28A0E-7687-44F2-90E4-A3577FF12EB9.jpeg
    88,7 KB · Aufrufe: 9
  • DA95D488-826A-402D-9710-E106D9CC4438.jpeg
    DA95D488-826A-402D-9710-E106D9CC4438.jpeg
    73,7 KB · Aufrufe: 8

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Servus, danke für den Hinweis.

also das Zertifikat müsste ich eingerichtet haben weil die NAS erreiche ich schon mit https://sub.synology.me:5001 das funktioniert auch 1a


1616092581628.png


und den Reverse Proxy habe ich so eingestellt

1616092685754.png

nicht wunder warum ich jetzt 172.20.1.4 anstatt 172.20.1.3 habe, ich hab die nochmal geändert, ist das aber die richtige ip? oder muss ich da localhost oder die "richtige" ip nehmen von der Synology?


Ports auf meiner FB sind auch frei

aber irgendwie will es immer noch net :/


-edit-

so langsam kann ich mein Problem eingrenzen(glaub ich), ich denke das es was mit dem lets Encrypt zu tun hat

Diese Meldung bekomme ich jetzt
Code:
letsencrypt_certificate[sub.synology.me] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for sub.synology.me] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [sub.synology.me] Validation failed, unable to request certificate

das Internet sagt mir dazu folgendes

1616097294925.png
zu finden auf https://docs.gitlab.com/omnibus/settings/ssl.html

mein Problem müsste Punkt 2. sein jedoch weiss ich nicht wie ich das beheben soll
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
nicht wunder warum ich jetzt 172.20.1.4 anstatt 172.20.1.3 habe, ich hab die nochmal geändert, ist das aber die richtige ip? oder muss ich da localhost oder die "richtige" ip nehmen von der Synology?
Port mappen und dann localhost:{gemappter port} nehmen. Wer direkt eine Container über seine Container-IP ansprechen will, macht mit hoher Wahrscheinlichkeit etwas falsch... es sei denn, es ist ne macvlan ip,dann muss natürlich tatsächlich die IP verwendet werden.
Code:
letsencrypt_certificate[sub.synology.me] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for sub.synology.me] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [sub.synology.me] Validation failed, unable to request certificate
Ist auch Port 80 an den Container durchgereicht? Bei der Domain-Überprüfung muss die Letsencrypt http01-challenge über Port 80 durchkommen.
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hallo,

ich habe erfreuliche nachrichten :D es geht, das ist das gute.
Ich weiß nicht genau was ich jetzt anderer gemacht habe aber nun läuft es mit der Config

Code:
version: '3.5'

services:
  redis:
    restart: always
    image: redis:5.0.9
    command:
    - --loglevel warning
    networks:
       internal_network:
          ipv4_address: 172.20.1.2
    volumes:
    - /volume1/docker/personal/gitlab/redis:/var/lib/redis

  postgresql:
    restart: always
    image: sameersbn/postgresql:12-20200524
    volumes:
    - /volume1/docker/personal/gitlab/postgresql:/var/lib/postgresql
    networks:
       internal_network:
          ipv4_address: 172.20.1.3
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm,btree_gist

  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    hostname: 'sub.synology.me'
    restart: always
    ports:
       - '30000:80'
       - '30001:443'
       - '30002:22'
    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
    depends_on:
         - redis
         - postgresql
    restart: unless-stopped
    environment:
       GITLAB_OMNIBUS_CONFIG: |
          external_url 'https://sub.synology.me'
          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'

          letsencrypt['enable'] = true
          letsencrypt['contact_emails'] = ['****@gmail.com']
          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'] = 'gitlab'
          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'] = '****@gmail.com'
          gitlab_rails['gitlab_email_reply_to'] = '****@gmail.com'
          gitlab_rails['smtp_enable'] = true
          gitlab_rails['smtp_address'] = 'smtp.gmail.com'
          gitlab_rails['smtp_port'] = 587
          gitlab_rails['smtp_user_name'] = '****@gmail.com'
          gitlab_rails['smtp_password'] = '*****'
          gitlab_rails['smtp_domain'] = 'smtp.gmail.com'
          gitlab_rails['smtp_authentication'] = 'login'
          gitlab_rails['smtp_enable_starttls_auto'] = true


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

  gitlab-runner:
     image: gitlab/gitlab-runner:latest
     container_name: 'gitlab_runner_docker'
     volumes:
        - /volume1/docker/personal/gitlab/gitlab-runner:/etc/gitlab-runner
        - /var/run/docker.sock:/var/run/docker.sock
     depends_on:
        - gitlab
     networks:
        internal_network:
            ipv4_address: 172.20.1.5

networks:
   internal_network:
      ipam:
         driver: default
         config:
            - subnet: "172.20.1.0/24"


jedoch hänge ich jetzt beim runner regestrieren

per ssh gebe ich den Befehl ein

Code:
docker exec -it gitlab_runner_docker gitlab-runner register

dann kommt folgendes

Code:
Runtime platform                                    arch=amd64 os=linux pid=22 revision=2ebc4dc4 version=13.9.0
Running in system-mode.                           
                                                  
Enter the GitLab instance URL (for example, https://gitlab.com/):
https://sub.synology.me:30001/
Enter the registration token:
Aeq6sss3WEpiAs3GKsPisxxwso
Enter a description for the runner:
[19341ab238d4]: docker_runner
Enter tags for the runner (comma-separated):

ERROR: Registering runner... failed                 runner=Aeq6sss3WEpiAs3GKsPisxxwso status=couldn't execute POST against https://sub.synology.me:30001/api/v4/runners: Post https://sub.synology.me:30001/api/v4/runners: x509: certificate signed by unknown authority

aber vielen Dank an euch schon mal das ich soweit gekommen bin :D
(auch wenn ich es noch nicht ganz verstanden haben warum auf einmal :D)

Mit freundlichen Grüßen
 

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
Hi,

ich empfehle ausschließlich MacVlan! Das habe ich auch so in meiner Beispiel „docker-compose“ angegeben, andernfalls musst du bei Aufruf deiner Gitlab - Instanz im Browser den Port angeben ... das ist unsauber ... meiner Meinung nach. Richte dir also ein MacVlan ein und setze dann beim Revers-Proxy als Ziel-IP die IP deines Gitlab ein, so wie du sie im docker-compse angegeben hast.

networks:
vlan:
driver: macvlan

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

Gruß, Christian
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hi,

ich hab es endlich hin bekommen das Vlan läuft

meine docker-componse sieht so aus

Code:
version: '2.4'

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

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

    networks:
      vlan:
         ipv4_address: '192.168.250.2'

    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: '192.168.250.3'


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

    environment:
     - DB_USER=gitlab
     - DB_PASS='password'
     - 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: '192.168.250.4'


    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.synology.me'
        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_rails['gitlab_email_reply_to'] = ' ****'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = 'smtp.gmail.com'
        gitlab_rails['smtp_port'] = 587
        gitlab_rails['smtp_user_name'] = '****'
        gitlab_rails['smtp_password'] = '****'
        gitlab_rails['smtp_domain'] = 'smtp.gmail.com'
        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: 192.168.250.5

networks:
  vlan:
    driver: macvlan

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

    ipam:
      config:
        - subnet: 192.168.178.0/17
          gateway: 192.168.178.1
          ip_range: 192.168.250.1/28

wenn ich jetzt die docker-compose starte

sagt mir die console

Code:
Creating network "gitlab_vlan" with driver "macvlan"
Creating gitlab_redis_1    ... done
Creating gitlab-postgresql ... done
Creating gitlab            ... done
Creating gitlab-runner     ... done

wenn ich jetzt aber im Docker schau, ist mein gitlab nicht da

1616271260654.png
 
Zuletzt bearbeitet:

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
Cool ... freut mich. Wollte gerade schreiben ... meine "kleine" hatte mich "aufgehalten". :D
War es "eth0"? Wollte das nämlich mal hinterfragen, was bei dir rauskommt, wenn du "ifconfig" in die Konsole tippst. Bei mir ist auf eth nix gebunden (keine IP), nur auf "ovs_eth" und deshalb steht das bei mir so in der Anleitung. Wenn das bei dir anders ist, dann müsste man meine Beschreibung mal anpassen.

Gruß, Christian
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Cool ... freut mich. Wollte gerade schreiben ... meine "kleine" hatte mich "aufgehalten". :D
War es "eth0"? Wollte das nämlich mal hinterfragen, was bei dir rauskommt, wenn du "ifconfig" in die Konsole tippst. Bei mir ist auf eth nix gebunden (keine IP), nur auf "ovs_eth" und deshalb steht das bei mir so in der Anleitung. Wenn das bei dir anders ist, dann müsste man meine Beschreibung mal anpassen.

Gruß, Christian
bei mir war's der befehl

ip route |grep default

und da kommt bei mir eth0 raus


ich hab gerade probiert

Code:
docker exec -it gitlab bash
drauf zu connecten, aber ich flieg da sehr schnell (10 - 15 sec) wieder raus

ich kann weder

Code:
gitlab-ctl reconfigure

noch

Code:
gitlab-rake gitlab:check SANITIZE=true

ausführen

--edit --

wenn ich im Browser 192.168.250.4 eingebe


kommt das

1616272675986.png

linkt der mich auf meine nas sub.synology.me

also irgendwas muss laufen
 

iAcki

Benutzer
Mitglied seit
20. Mrz 2019
Beiträge
28
Punkte für Reaktionen
5
Punkte
3
Hmm, ist aber kurios ... gibt es denn ne Fehlermeldung? Funktioniert denn Gitlab bei dir sauber?

--- edit ---
Kann der Kick durch zu wenig RAM verursacht sein?
Hast du den Revers -- Proxy auf die neue IP umgestellt?
 

Schechner

Benutzer
Mitglied seit
10. Feb 2020
Beiträge
48
Punkte für Reaktionen
0
Punkte
6
Hmm, ist aber kurios ... gibt es denn ne Fehlermeldung? Funktioniert denn Gitlab bei dir sauber?

--- edit ---
Kann der Kick durch zu wenig RAM verursacht sein?
Hast du den Revers -- Proxy auf die neue IP umgestellt?

das finde ich auch kurios :D keine Fehlermeldung. Gitlab funktioniert nicht wirklich... wenn ich per ip 192.168.250.4 connecten will sagt er mir gitlab talking to much, für ich sieht das so aus als würde etwas in der config nicht passen und der bootet immer wieder neu

Am RAM kann normal nicht liegen (GITLAB lief auch schon mal)

1616310564501.png

beim Revers-Proxy siehts bei mir so aus

1616310666036.png



Kann ich für den Hostname den selben Namen nehmen wie für die NAS? oder muss ich dafür einen extra DDNS anlegen?
Die Portfreigabe muss die auf meine NAS erfolgen oder auf 192.168.250.4?

Wenn ich nochmal von vorne anfangen will (vielleicht ist ein Fehler beim vielen rum probieren passiert) langt das wenn ich das Verzeichnis lösche?
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat