Docker von Extern und HTTPS mit GitLab

[xelarep]

Könnte daran liegen, wenn die Festplatten aufwachen...

Mein Setup: Subdomain(CNAME)->DynDns-Adresse->FritzBox->DSM reverse proxy->whatever

 

[haydibe]

*lichtangeh* alles klar, der klassische Ansatz

Dann weiss ich jetzt was wo wie gemacht werden muss.

 

[xelarep]

GitLab Update?

Hallo,

ich möchte das Thema Update an dieser Stelle mal aufgreifen - draegig hat ja einen prinzipiellen Updatemechanismus in der Installation beschrieben. Gilt das nur für die Erstinstallation?

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

Ich bin in docker noch nicht so firm, und habe meine initiale GitLab Installation vom Januar bisher neben dem Backup bisher noch nicht weiter gepflegt. Ich möchte nun von 10.3.3/9.6,1 auf die aktuelle Version updaten.

• reicht es tatsächlich aus in der docker-compose.yml die Versionsnummern hochzählen?
• Beide Versionen Postgres/Gotlab gemeinsam, oder in einer bestimmten Reihenfolge?
• Was wäre sonst noch zu tun?

 

[haydibe]

Genau so wie Draegig geschreiben hat: einfach die Version im Tag des Gitlab-Containers anpassen.
Dadurch das eine konkrete Version angegeben ist, wird diese auch gepullt und gestartet. Für Redis gilt das bspw. nicht, da hier latest verwendet wird (was aber auch okay ist).

Damit kann man beliebig oft Contain upgrade machen. Wichtig ist nur vorher auf der Github-Seite zu schauen, ob evtl. das Copose.yml durch zusätzliche Parameter angereicht werden muss (war seit Ewigkeiten nicht mehr der Fall)

Bei Postgres habe ich die Erfahrungen gemacht, dass ein Versionupgrade nur innerhalb der selben Minor-Version, bspw. von 9.5 auf 9.5.x bzw. 9,5-x problemlos funktioniert. Von 9.5 auf 9.6 hat bei mir beispielsweise nicht funktioniert. Hier muss man wohl unter 9.5 erst ein Backup ziehen und das in 9.6 wieder einspielen. Aber: solange Gitlab nicht ausdrücklich die neue Postgres Version benöigt, wozu updaten?

 

[xelarep]

Das war ja einfach

Bin nur kurz ins Schleudern gekommen: postgresql wurde im admin Panel als 9.6.1 angezeigt, im docker-compose.yml als 9.6-2. Das scheint dasselbe zu sein?! Ich hab anfangs im Tran von 9.6-2 auf 9.6-3 geändert, die natürlich nicht gefunden wurde. Hab dann wieder zurückgebaut auf 9.6-2 und die wird mir jetzt nach kompletten Update gitlab 10.3.3 auf 10.5.6 eben als 9.6.1 angezeigt?!

Wie ist denn das bei euch?

 

[haydibe]

Jo, mit docker-compose sind image und container updates total easy. Ohne docker-compose ist es DEUTLICH aufwendiger (-> neues Image pullen, alten Container stoppen und löschen, neuen Container mit alten Parametern starten).

Zu Postgres: das Tag kann, muss aber nicht zur tatsächlich verwenden Version passen. Sameersbn hat sich scheinbar bei v9.6.1 der App für das Tag 9.6-2 entschieden.

Wo angezeigt? Unter "Admin Area" -> "Dashboard", dort im Kasten "Components"? Bei mir steht dort GitLab 10.5.6.

 

[xelarep]

Ja genau. Im Dashboard. GitLab 10.5.6 und PostgreSQL 9.6.1.

 

[haydibe]

Dann geht es dir also nur um die Abweichung zwischen dem Tag des Postgres-Images und der tatsächlichen Version der Datenbank.
Auf Tags braucht man nichts geben. Insbesondere dann nicht, wenn wie bei diesem Postgres-Image die Kernanwendung als OS-Paket ohne angabe einer Versionsnummer installiert wird.

Die enthaltene DB entspricht der Version, die an dem Tag verfügbar war. Wenn das Git-Projekt cloned und den Container selbst baut, bekommt man sicherlich eine aktuellere Version des Postgres-Pakets installiert. Aber warum sollte man das wollen, wenn alles mit der vorliegenden Version schon läuft?

 

[xelarep]

Alles gut - mich hat's einfach interessiert, und lieber am Anfang auf die Schnauze fallen, als später

 

[raffnix84]

Das ganze gibt es auch als fertiges Synology Paket [SPK] https://github.com/jboxberger/synology-gitlab-jboxberger .

Gruss

 

[haydibe]

Top-Arbeit raffnix! Gute Idee auf der Arbeit von Synology aufzusetzen und es einfach besser (aktueller) zu machen!

 

[xelarep]

Moin, muss diesen Thread mal wieder reanimieren. Hatte die letzten Tage ein Problem mein Gitlab zu aktualisieren. Nach mehrmaligen Einspielen des Backups und Auffinden diverser logs kann ich den Fehler nun eingrenzen.

Ich hab wie in der Vergangenheit in der docker-compose.yml die Versionsnummer für gitlab und postgresql erhöht, und staunte nicht schlecht, als ich eine jungfräuliche Gitlab Installation vorfand.

Was war geschehen: beim Sprung von postgresql Version 9.6-2 auf 10 wurde die Datenbank nicht korrekt übertragen :-(
Ich hab inzwischen eine Kombi aus Gitlab 11.4.0 und postgresql 9.6-2 am laufen.

Wie bekomme ich die postgresql auf 10? Ich bräuchte einen wink mit dem Zaunpfahl...

Anbei logs aus dem postgresql Verzeichnis des Dockerordners

-----------------------------------------------------------------
  pg_upgrade run on Sun Oct 28 17:43:02 2018
-----------------------------------------------------------------

command: "/usr/lib/postgresql/10/bin/pg_dumpall" --host /var/lib/postgresql --port 50432 --username postgres --globals-only --quote-all-identifiers --binary-upgrade  -f pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1

-----------------------------------------------------------------
  pg_upgrade run on Sun Oct 28 17:43:02 2018
-----------------------------------------------------------------

command: "/usr/lib/postgresql/9.6/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/9.6/main" -o "-p 50432 -b -c config_file=/var/lib/postgresql/9.6/main/postgresql.conf --hba_file=/var/lib/postgresql/9.6/main/pg_hba.conf --ident_file=/var/lib/postgresql/9.6/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "pg_upgrade_server.log" 2>&1
waiting for server to start....LOG:  database system was shut down at 2018-10-28 17:27:45 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
 done
server started


command: "/usr/lib/postgresql/9.6/bin/pg_ctl" -w -D "/var/lib/postgresql/9.6/main" -o "-c config_file=/var/lib/postgresql/9.6/main/postgresql.conf --hba_file=/var/lib/postgresql/9.6/main/pg_hba.conf --ident_file=/var/lib/postgresql/9.6/main/pg_ident.conf" -m smart stop >> "pg_upgrade_server.log" 2>&1
waiting for server to shut down...LOG:  received smart shutdown request
.LOG:  shutting down
LOG:  database system is shut down
 done
server stopped


command: "/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/10/main" -o "-p 50432 -b -c synchronous_commit=off -c fsync=off -c full_page_writes=off -c config_file=/var/lib/postgresql/10/main/postgresql.conf --hba_file=/var/lib/postgresql/10/main/pg_hba.conf --ident_file=/var/lib/postgresql/10/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "pg_upgrade_server.log" 2>&1
waiting for server to start....2018-10-28 17:43:07.983 UTC [1418] FATAL:  data directory "/var/lib/postgresql/10/main" has group or world access
2018-10-28 17:43:07.983 UTC [1418] DETAIL:  Permissions should be u=rwx (0700).
 stopped waiting
pg_ctl: could not start server
Examine the log output.

-----------------------------------------------------------------
  pg_upgrade run on Sun Oct 28 17:43:02 2018
-----------------------------------------------------------------

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for invalid "unknown" user columns                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/lib/postgresql/.s.PGSQL.50432"?
could not connect to target postmaster started with the command:
"/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/10/main" -o "-p 50432 -b -c synchronous_commit=off -c fsync=off -c full_page_writes=off -c config_file=/var/lib/postgresql/10/main/postgresql.conf --hba_file=/var/lib/postgresql/10/main/pg_hba.conf --ident_file=/var/lib/postgresql/10/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start

 

[raffnix84]

Hi,

hast du schon versucht ein GilLab Backup zu machen, dann einen Clean Install mit der 11.4.0 + PSQL 10 und dann den Restore?

Backup (CRON=1 => no info output): /volume1/docker/gitlab/backups

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

Restore:

/usr/local/bin/docker exec -it synology_gitlab bash -c "sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production BACKUP=<timestamp_of_backup>"

Quelle: https://docs.gitlab.com/ee/raketasks/backup_restore.html

Gruss

 

[xelarep]

Aha, das wäre ein Weg - muss ich mich mal einlesen. Ich verwende nicht das Synology gitlab Paket, sondern den weiter vorne beschriebenen sameersbn Ansatz.

Danke, Alexander

 

[raffnix84]

Aha, das wäre ein Weg - muss ich mich mal einlesen. Ich verwende nicht das Synology gitlab Paket, sondern den weiter vorne beschriebenen sameersbn Ansatz.

Danke, Alexander

synology_gitlab ist hier der container name, dir kann natürlich abweichen. Das Synology Paket verwendet auch das sameersbn/gitlab image, daher sollten die obigen Befehle mit Anpassung des Containernamen klappen.

 

[Fox7]

Hi raffnix84,

gerne würde ich das aktuellere GitLab Paket von dir (https://github.com/jboxberger/synology-gitlab) nutzen. Von Synology selbst wird anscheinend ja kein Update mehr geliefert :/

Ich hätte eine oder mehrere (dumme) Fragen zur Installation. Auf der GitHub-Seite steht, das man das SPK über die "Standard" Synology GitLab Installation bügeln kann.

This is an upgraded and improved GitLab package which uses the stock Synology Package from Synology Repo and can be installed over the original package.

Da ich schon viel Ärger mit dem wiederherstellen meiner GitLab-Daten hatte, wollte ich zur Sicherheit nochmals Nachhaken ..

- Das SPK kann einfach über das Paketzentrum über den Button "Manuelle Installation" installiert werden? Wird dann das bestehende DockerImage wie bei einem Stock-Update aktualisiert?
- Was würde passieren, wenn es wieder ein "Offizielles" Update über Synology gibt? Würden solche Updates überhaupt noch angezeigt werden? Wenn ja, wahrscheinlich keinesfalls Updaten..?

Danke für ein kurzes Feedback


Gruß,
Fox

 

[raffnix84]

Hi Fox,

du kannst von einem Standard Paket direkt zu dem modifizierten Paket upgraden. Ich teste hier 3 Update Szenarien vor dem Upload.
1) Stock 9.4.4-0050 to Mod: https://github.com/jboxberger/synology-gitlab#update-stock-944-0050-to-mod (maria_db zu psql migration erfolgt automatisch)
2) Stock 11.0.4-0053 to Mod: https://github.com/jboxberger/synology-gitlab#update-stock-1104-0053-to-mod
3) Und natürlich untereinander.

Misstrauen und Vorsicht sind bei so einer wichtigen Infrastruktur gesund daher gilt wie immer "BACKUP, BACKUP, BACKUP und nochmals BACKUP"
BACKUP: https://github.com/jboxberger/synology-gitlab#backup
RESTORE: https://github.com/jboxberger/synology-gitlab#restore
Für die ganz vorsichtigen besteht noch die Möglickeit einen mysql/psql dump und die gitlab ordner zu sichern.

- Das SPK kann einfach über das Paketzentrum über den Button "Manuelle Installation" installiert werden? Wird dann das bestehende DockerImage wie bei einem Stock-Update aktualisiert?

Genau, mein Packet macht nichts anderes, ich nutze die originalen srkipte von synology und habe die lediglich um ein paar kleine Features wie z.B. das behalten der ENVIRONMENT Variablen erweitert.
Bei der Manuellen Installation muss du allerdings eine Einstellung vornehmen dass du auch Paketen ohne Signatur vertraust. Das sagt dir dann das DSM aber auch.

- Was würde passieren, wenn es wieder ein "Offizielles" Update über Synology gibt? Würden solche Updates überhaupt noch angezeigt werden? Wenn ja, wahrscheinlich keinesfalls Updaten..?

Ja das Update wird dann ganz normal im DSM angezeigt werden und kann auch installiert werden. Von meiner Seite aus funktioniert das ohne Probleme, da lege ich auch Wert darauf. Keiner soll von mir und meinem Update Zyklus abhängig sein. Wenn Synology eine höhere Version als meine raus bringt sollte es funktionieren auch wenn sie alles auf links drehen würde. Da mein Paket dem original entspricht müsste auch das neue Paket die Migration problemlos durchführen können, sonst hätten die auch das Problem vom Stock 11.0.4-0053 auf ihr neues Paket zu migrieren.

Bei der Migration werden deine Daten nicht angefasst, Nach der Installation geht GitLab selbst hin und schaut sich die DB Version an und zieht die notwendigen Schema Updates nach. Ich denke das es Problematisch sein kann wenn du z.B. ein downgrade versuchst von 11.9.8-0053 auf Stock 11.0.4-0053. Ich denke hier wird das DSM meckern und ich könnte mir auch vorstellen dass es mit GitLab Probleme geben könnte, allerdings besteht durch die die inkrementellen schema updates sogar eine reale chance das dein downgrade lauffähig wäre.

Wenn du vor jeder Migration und Update ein oder zwei Backups machst bist du auf der sicheren Seite. Ich hatte auch schon ab und zu den Fall dass GitLab selbst die schema updates vermasselt hat, seit dem teste ich das ganze immer und so ein Gitlab 10 mal zu installieren/deinstallieren kostet viel Zeit .

Ich werde am Wochenende das Paket auf 11.10.4 (oder neuer hochziehen), wenn du noch also ein bis zweit Tage warten willst kannst du direkt die neue Version mitnehmen.

Gruss

 

[Fox7]

Hi raffnix84,

zunächst einmal vielen Dank für deine schnelle Antwort! Backups werden seit meinem letzten Problemen mit GitLab / Syno-Update mittlerweile täglich erstellt. Da habe ich aus meinen Fehlern definitiv gelernt.

Ansonsten bleibt mir nur zu sagen wie Hammergeil ich es finde, dass sich jemand solche Mühe gibt ein solches Paket für die "Allgemeinheit" zu erstellen und dieses auch noch up-to-date zu halten! Vielen Dank!!


Momentan habe ich die letzte Version von GitLab installiert, die man über die normalen Synology-Updates bekommt. (11.0.4-0053). Ich warte gerne noch die nächsten Tage ab um mir deine 11.10.4 zu laden.




Gruß,
Fox

 

[Fox7]

Hi raffnix84,

leider komme ich erst jetzt dazu dein Paket zu installieren. Vor einigen Sekunden ist mir noch eine DSM Aktualisierung und ein paar Aktualisierungen für installierte Pakete aufgeploppt.

DSM 6.2.2. hab ich installiert, alle Aktualisierungen zu den Paketen auch ... bis auf eine GitLab Aktualisierung. Hier gibt es ein "gewaltiges" Update von 11.0.4-0053 auf 11.0.4-0054.

Dieses werde ich natürlich nicht installieren und stattdessen dein Paket verwenden. Jedoch hätte ich eine Frage zu deinen Versionsnummern. Warum hast du bei deinen Paketen auch stehts "-0053" verwendet? Hat das einen besonderen Grund?


Gruß,
Fox

 

[xelarep]

hast du schon versucht ein GitLab Backup zu machen, dann einen Clean Install mit der 11.4.0 + PSQL 10 und dann den Restore?

Backup (CRON=1 => no info output): /volume1/docker/gitlab/backups

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

Restore:

/usr/local/bin/docker exec -it synology_gitlab bash -c "sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production BACKUP=<timestamp_of_backup>"

Ähöhmmm... nach deutlich über einem Jahr eine Rückmeldung von mir

Also: ich hab damals(tm) beschlossen mit der 9er PostgreSQL zu leben, und die letzte Zeit auch nicht soviel mit meinem Gitlab gemacht. Ich hab also bis vor kurzem die Combi PostgreSQL 9.6-2 und Gitlab 11.8.0 gefahren. Aber das hat sich die letzten Wochen wieder geändert, ich hab dann also auch mal wieder an die fälligen Updates gedacht...

Ich hab zunächst erst mal einen fast aktuellen Arbeitszustand hergestellt, d.h. in meinem docker-compose.yml Gitlab auf 12.7.6 und PostgreSQL auf 9.6-4 gezogen - redis war schon immer 'latest'. Dieser Stand ging erst mal per Hyperbackup in die Sicherung (ganz wichtig!)

Dann hab ich mich an gitlab Sicherung und Neuinstallation gemacht - das Gute vorweg: es hat am Ende alles funktioniert. Ich bin aber über folgende Schwierigkeiten gestolpert - falls jemanden mal ähnliche Aufgaben erwarten:

• Backup GitLab hat auf Anhieb funktioniert und konnte ich im backups Ordner rauskopieren
• Neuinstallation hat im zweiten Anlauf gut geklappt - im ersten hab ich vergessen meine vorhandenen Zertifikate in den gitlab/certs Ordner abzulegen
• Backup Rückspielen: hier gab's zwei Hürden
  1. <timestamp_of_backup> ist der Name des Backups ohne _gitlab_backup.tar - da musste ich zweimal auf die Fehlermeldung schauen
  2. durchs Rauskopieren des tars aus dem Backup mit der FileStatsion haben sich user und group geändert - das backup konnte nicht entpackt werden, also passende Daten suchen. Bei mir war's dann ein chown mit user:group 1000:1000 im backup Ordner von Gitlab, dann läuft das aber auch (langsam und mit Rückfragen) durch.

Et Voila: PostgreSQL 10-2, GitLab 12.7.6, redis latest.

Ganz wichtig: das geht nicht mal nebenher, die Ganze Aktion hat mich heute locker den späten nachmittag gekostet - das Rücksichern des Backups war relativ lange

HTH

Alexander