Starthilfe für Docker/GitLab benötigt

Status
Für weitere Antworten geschlossen.

xelarep

Benutzer
Mitglied seit
17. Dez 2008
Beiträge
326
Punkte für Reaktionen
12
Punkte
18
Hallo zusammen,

wollte mich schon seit längerem mit Docker beschäftigen und habe gedacht "machte 'nen sanften Einstieg, und installiert erst mal GitLab", Git ist gerade interessanter für mich...

Soweit die Theorie - leider klappt's nicht. Was ich bisher gemacht habe:

Erster Versuch
  • Dockerpaket installiert
  • Gitlab installiert
Alles über das Paketzentrum...

Gitlab blieb angehalten stehen. Bei der Kontrolle habe ich nur ein Abbild/Container für Synology_gitlab_redis vorgefunden. Also Gitlab per Paketzentrum wieder deinstalliert.
Dann ales zweites versucht das Abbild gitlab-ce zu installieren. Hier kam ich schon etwas weiter, aber auch nach Stunden des Platte rödelns, Docker Neustart und kompletten DS Neustart: ich komm nicht weiter wie "502 whoops, gitlab is taking too much time to respond". Der docker share war leer?
Also wieder alles runtergeworfen (Container, Abbild, Docker). DS Neustart. Der docker share war ebenfalls weg.

Dritter Versuch - quasi mit neuen Startbedingungen.

  • Dockerpaket installiert
  • Gitlab installiert
Dieses mal sehe zwei Ordner im Docker share, 2 Abbilder (Synology_gitlab_redis 3.2.6 und Synology_gitlab 9.4.4) - Erfolgsmeldungen in den Logs, laufende Container - schon besser!

Leider auch hier (nach Stunden warten und einem DS Neustart): "502 whoops, gitlab is ..."

Was läuft hier schief?

Ich hab immer in den Standardeinstellungen installiert. Mein Anspruch ist, erst mal auf ein Terminal verzichten zu können - ich möchte im ersten Schritt einfach mal mit GitLab experimentieren :-(
Meine DS-216-II läuft ausschliesslich mit Paketen/Komponenten aus dem Paketzentrum - kein IPKG wie auf meinen alten Synos. RAM ist 60-70% ausgelastet, die CPU langweilt sich,

Alexander
 

xelarep

Benutzer
Mitglied seit
17. Dez 2008
Beiträge
326
Punkte für Reaktionen
12
Punkte
18
Hallo,

kurze Rückmeldung meinerseits: habe gerade meine DS-216+II auf 8GB aufgerüstet. Nach erstem Start von Docker und Gitlab ist die CPU dieses mal recht aktiv geworden, der RAM zwischen 1-2GB gerödelt, und - TADAA - Ich bekomme endlich die Adminkonsole ;)

RAM steht jetzt bei 1.7GB, CPU bei 4%.

Sollte tatsächlich nur(TM) der Arbeitsspeicher nicht ausgereicht haben?! Das wäre ja ziemlich doof, da Docker mir ja nur 653MB/1GB im ersten Versuch suggeriert hat :confused:

Alexander
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Gitlab ist kein Leichtgewicht! Bei nicht ausgelastetem System braucht es schon etwas mehr 1 GB RAM... Wenn man damit aktiv arbeitet und noch möglich alle möglichen Module verwendet, wird es auch noch mehr....

https://docs.gitlab.com/ce/install/requirements.html#memory schrieb:
You need at least 4GB of addressable memory (RAM + swap) to install and use GitLab! The operating system and any other running applications will also be using memory so keep in mind that you need at least 4GB available before running GitLab. With less memory GitLab will give strange errors during the reconfigure run and 500 errors during usage.

1GB RAM + 3GB of swap is the absolute minimum but we strongly advise against this amount of memory. See the unicorn worker section below for more advice.
2GB RAM + 2GB swap supports up to 100 users but it will be very slow
4GB RAM is the recommended memory size for all installations and supports up to 100 users


Wenn Du etwas ressourcensparendes haben willst, dann schau dir mal das Image https://hub.docker.com/r/gogs/gogs/ an.
Ist natürlich nicht so umfangreich wie Gitlab, aber deutlich besser, als der Git-Server den man aus dem Paketzentrum installieren kann.


Gogs bringt halt alles relavante mit: Benutzer/-Gruppenverwaltung, öffentliche/private Repos, Pull-Request, Issue-/Milestone-Management, Wiki ...
Gitlab bringt darüber hinaus ein Docker Repo mit (wenn man es einrichtet) und einen CI-Runner mit (wenn man ihn einrichtet) und hat ein schickes Kanban-Board beim Issue-Management.
 
Zuletzt bearbeitet:

xelarep

Benutzer
Mitglied seit
17. Dez 2008
Beiträge
326
Punkte für Reaktionen
12
Punkte
18
Danke für den Tip! Werdezunächst mal ersten Erfahrungen in GitLab sammeln. Evtl. sattel ich noch von Synology auf DockerHub GitLab-ce um (HTTPS fehlt im Synology Paket?).
Muss aber erst mal ein paar grundsätzliche Dinge lernen/lösen (z.B. Backup Container/Daten).

Längerfristig ist es mein naliegen mein bisheriges SVN und die zugehörigen Dokuwiki-Abschnitte in Gitlab (o.ä.) zusammenzufassen, bzw. Abzulösen, um meine HW- und SW-Basteleien mehr oder weniger synchron zu archivieren - wiki im Repositriy wäre also Pflicht.

Gibt's zum Backup von Dockercontainern/Images eigentlich eine Out-of-the-Box Lösung, ähnlich wie HyperBackup? Für die Synology Gitlab Lösung sollte ja eine Sicherung des Docker Shares + MariaDB10 in Hyperbackup reichen, oder?

etwas OT: Neben Gogl gibt es ja noch dessen Fork Gitea - worüber sich ja die Geister scheiden: hat hier wer praktische Erfahrungen mit beiden?

[Nachtag]: GitLab CE verhindert ja leider Hibernation der Festplatten. Wie sieht es hier bei Gogl/Gitea aus?
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Ich kenne das Gitlab-Paket von Synology nicht, nur sameersbn/gitlab (was das Gitlab-Paket selbst auch benutzt) und damit bekommt man https relativ easy hin.

Auf der Dockerhub-Seite von sameersbn/gitlab sind die Rake-Befehle für Backup und Restore dokumentiert.
Ansonsten mache ich immer Backups der Datenverzeichnisse bei ausgeschaltetem Container.

Zum Hibernate Modus: Verhindert das nicht jeder Docker-Container dank logging?
 

xelarep

Benutzer
Mitglied seit
17. Dez 2008
Beiträge
326
Punkte für Reaktionen
12
Punkte
18
Aah, ein wink mit dem Zaunpfahl :eek: Danke! Das sieht mal verständlich aus! Habe inzwischen auch draegigs Anleitung gefunden.

Zum Thema Hibernate werde ich das mal weiter beobachten. Docker alleine aktiv (also ohne Container) lässt die DS schlafen. Ich hab heute tagsüber mal das Gitlab Paket einfach angehalten.
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.519
Punkte für Reaktionen
404
Punkte
103
Mein Anspruch ist, erst mal auf ein Terminal verzichten zu können - ich möchte im ersten Schritt einfach mal mit GitLab experimentieren :-(

Ohne diese Formulierung in Deinem ersten Post, hättest Du den Link schon lange bekommen :)

Draegig hat es exzellent und vorallem für alle verständlich beschrieben.

Mitlerweile sind folgende images:tags aktuell:
sameersbn/gitlab:10.3.3
sameersbn/postgresql:9.6-2

Bei Redis hat sich länger nichts getan.
 
Zuletzt bearbeitet:

xelarep

Benutzer
Mitglied seit
17. Dez 2008
Beiträge
326
Punkte für Reaktionen
12
Punkte
18
Jaja, ich hätt's ja wissen müssen, dass ich bei sowas wieder auf die Konsole darf :eek: Jedenfalls: läuft erstmal.

Danke!
 

raffnix84

Benutzer
Mitglied seit
18. Nov 2012
Beiträge
38
Punkte für Reaktionen
2
Punkte
14
Hallo Zusammen,

ich betreibe seit 2015 ein eigenes Gitlab Package was aus den Sourcen des originals automatisiert aufgebaut wird. https://github.com/jboxberger/synology-gitlab
Da Gitlab ofiziell den support von MariaDB eigestellt hat, ist das originale Synology Packge somit auch de facto tod. Da hilft auch keine MairaiDB10 Migration, über Gitlab 10.2.5 geht nichts. Ich habe das schon alles hinter mir und das war nicht schön... Aus diesem Grund habe ich eine neues eigenständiges Giltab Package gebaut das zwar nach wie vor teilweise auf dem originalen Paket basiert aber als db backend PostgreSQL (von Gitlab offiziell supported und empfohlen) nutzt. Natürlich sind habe ich auch Features wie SSL und das beibehalten der EINVIRINMENT Variaben nach Update implementiert. Einen Migrationspfad von Gitlab Stock auf die neue Version gibt es auch und ist automatisiert um hier den prozess zu vereinfachen. Großteil der User hat mittlerweile die Migration hinter sich mit durchweg positiver Resonanz.

GitLab-Postgres: https://github.com/jboxberger/synology-gitlab-jboxberger

Da mir persönlich Gitlab zu groß ist und für meine Anforderung einfach zu mächtig und auch der Ressourcen Hunger mit mind 2GB RAM nicht unerheblich ist habe ich micht nach was einfachem und leichgewichtigen umgeschaut und bin bei Gitea gelandet was ein Fork von Gogs ist. Da ich mitllerweile durch das rumgeiere mit Gitlab schon ein wenig Erfahrung gesammelt habe, habe ich auch hierfür ein packet gebaut. Natürlich mit SSL und backup möglichkeiten. By the way, Gitea verbraucht gerade mal 80MB RAM wenn man SQLite 3 nutzt. Die Möglichkeit MariaDB einzusetzen gibt es natürlich auch. Das paket ist noch nicht fertig aber ich befinde mich berits ind er Test Phase und so wie es aussieht wird es diesen Monat was erden.

Gitea: https://github.com/jboxberger/synology-gitea-jboxberger

Falls Interesse oder Fragen bestehen, stehe ich euch geren zur Verfügung.


RAM steht jetzt bei 1.7GB, CPU bei 4%.
Sollte tatsächlich nur(TM) der Arbeitsspeicher nicht ausgereicht haben?! Das wäre ja ziemlich doof, da Docker mir ja nur 653MB/1GB im ersten Versuch suggeriert hat :confused:
Alexander
Gitlab genehmigt sich in der Regel 2GB alles unter 1GB funktioniert nicht und alles dazwischen führ zu unerwartetem Verhalten, abbrüche, crashes, kaugummi ui, etc...

Zum Hibernate Modus: Verhindert das nicht jeder Docker-Container dank logging?
[Nachtag]: GitLab CE verhindert ja leider Hibernation der Festplatten. Wie sieht es hier bei Gogl/Gitea aus?
Genau genommen verhindert nicht Gitlab sondern redis die hibernation da der in Memory Cache by default in bestimmten Zeitintervallen auf die Platte sichert. Ich habe das in meinen Paketen deaktiviert.
Auch die Cronjobs in Gitlab selbst sorgen für ein regelmäßiges erwachen, siehe in der Admin Area unter "Background Jobs -> Cron"

Gibt's zum Backup von Dockercontainern/Images eigentlich eine Out-of-the-Box Lösung, ähnlich wie HyperBackup? Für die Synology Gitlab Lösung sollte ja eine Sicherung des Docker Shares + MariaDB10 in Hyperbackup reichen, oder?
Nicht ganz, in den Docker Containern sind diverse secrets und passwörter als ENVIRONMENT Variablen hinterlegt. Mit diesen secrets wird unter anderem content verschlüsselt (ich habe noch nicht rausgefunden welcher). Wenn diese sich ändern könnte es problematisch werden. Man sollte daher auch die Container Konfiguration auch mit wegsichern. Du kannst dich gerne an meinem backup Script auf github orientieren, da habe ich es drin.

Gruss
 
Zuletzt bearbeitet:

linuxdep

Benutzer
Mitglied seit
02. Jan 2009
Beiträge
584
Punkte für Reaktionen
11
Punkte
38
Hi,
da ich mit dem reinen GIT Packet nicht ganz zufrieden bin, wegen dem fehlen der Möglichkeit neue Projekte schnell per web anzulegen, bin ich hier gelandet.
GITLAB im Container scheint recht viel RAM zu benötigen, da las ich das erst mal aus, brauche ja nicht viel. Schade das es keine einfache Webseite zum GIT Packet gibt wo man neue Projekte eröffnen kann.

Aber was macht dein Packet anderst als go-gitea/gitea aus dem DockerHafen?
Finde ich dein Packet auch direkt in Docker zum runterladen, meine erste Suche hat nix gegracht. (gefühlt kann wohl jeder einen Container im hafen abstellen...)
 

linuxdep

Benutzer
Mitglied seit
02. Jan 2009
Beiträge
584
Punkte für Reaktionen
11
Punkte
38
habe es jetzt mal geladen das .spk und installiert, sehe, das er ein DockerContainer erstellt und darin scheint es zu laufen... benötigt er das officelle GIT packet oder bringt er alles selber mit im Container, das ist mir noch nicht ganz klar.

Muss ich sicherlich noch einrichten wenn ich die Startseite aufrufe? Ein paar Schritte fehlen da noch in der Beschreibung was genau zu tun ist beim einrichten. Hoffentlich trotzdem richtig gemacht...

2018-12-08 22_38_56-Window.gif
Wie kann ich diesen Path anpassen, damit ich diesen direkt kopieren kann für meinen Rechner? habe nix gefunden dazu unter Einstellungen.
Müsse ja etwa so sein für ssh... git@<IP>:<name>/<Projekt> oder geht das nicht?
 
Zuletzt bearbeitet:

raffnix84

Benutzer
Mitglied seit
18. Nov 2012
Beiträge
38
Punkte für Reaktionen
2
Punkte
14
Hi,
das Docker Konzept hat den vorteil das der Container alles nötige schon mit sich bring. Im Container ist git vorhanden und du brauchst es natürlich nur noch auf den Clients. Ich habe kein Container bei dockerhub weil ich den Container nicht mache. Das machen andere schlaue Leute und ich baue den installer drum herum damit Leute die noch keine Ahnung von docker haben den container einfach ans laufen kriegen ohne docker beherrschen zu können. Es ist zwar nicht komplex aber man muss schon ein wenig was tun und verstehen damit es funktioniert. Ich selber nutze das ofiziell gitea Package https://hub.docker.com/r/gitea/gitea/.

Nach der Installation der SPK beim Versuch sich anzumelden http://meineDS:3000 wirst du autom. auf http://meineDS:3000/install weitergeleitet. Hier kannst du alle Einstellungen vornehmen die du willst. Ich selber nutze SQLite. Es ist völlig ausreichend für eine Installation von bis zu 10 Personen Geatea moderat nutzen. Der Vorteil ist, die DB ist ein One-File und kein Dienst der nebenbei laufen muss und ressourcen frisst. Meine Installation mit ca. 50 Projekten begnügt sich mit 100-120MB RAM, GitLab dagegen beginnt erst ab 2GB vernünftig zu arbeiten und 4GB ist bei 10 Personen zu empfehlen. GitLab kann natürlich viel mehr aber die meisten nutzen eh nur die Features die Gitea auch locker abdeckt.

Hier die Übersicht der Optionen. Beachte das du unter "Optionale Einstellungen" die Akkordeons aufklappen kannst und noch weitere Einstellungen vornehmen kannst.

install.jpg

habe es jetzt mal geladen das .spk und installiert, sehe, das er ein DockerContainer erstellt und darin scheint es zu laufen... benötigt er das officelle GIT packet oder bringt er alles selber mit im Container, das ist mir noch nicht ganz klar.

Muss ich sicherlich noch einrichten wenn ich die Startseite aufrufe? Ein paar Schritte fehlen da noch in der Beschreibung was genau zu tun ist beim einrichten. Hoffentlich trotzdem richtig gemacht...

Anhang anzeigen 45262
Wie kann ich diesen Path anpassen, damit ich diesen direkt kopieren kann für meinen Rechner? habe nix gefunden dazu unter Einstellungen.
Müsste ja etwa so sein für ssh... git@<IP>:<name>/<Projekt> oder geht das nicht?

indem du auf HTTP links daneben klickst. Dadurch wird alles über HTTP transportiert und es gilt der Benutzer und das Passwort von Gitea.
Bei SSH muss du dir mit SSHGen einen Private/Publick Key generieren und den Public Key in Gitlab hinterlegen und dein beim Push den Private Key angeben.
Das einspricht der "normalen" SSH Key Authentifizierung, wenn du damit nicht vertraut bist, nutze einfach HTTP, das steht dem SSH im Nichts nach, nur das die Security beim HTTP
natürlich nicht vorhanden ist, aber da du ja in deinem privaten LAN bist sollte das kein Problem sein.

Gruss
 
Zuletzt bearbeitet:

linuxdep

Benutzer
Mitglied seit
02. Jan 2009
Beiträge
584
Punkte für Reaktionen
11
Punkte
38
es ging mir nicht darum http zu nutzen, sonder das der Path gleich richtig zu meinen Projekten angezeigt wird.... nachdem ich es noch mal inst. habe, habe ich gesehen, beim einrichten gibt es einen Punkt "Git Basis URL" dort kann man es anpassen, was man aber auf https ändern sollte, fals man es mit https nutzt. scheinbar aber bei ssh nicht so recht übernommen wird. na ja, schade, aber sicher zu verschmerzen.
Also werde ich mir mal das originale Docker Packet installieren und anschauen. Danke.
 
Status
Für weitere Antworten geschlossen.
 

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