Ready-to-use Server
GitLab
Self Hosted Git Management & DevOps Toolchain
- Debian-basiert
- Automatische Sicherheitsupdates
- Frei und quelloffen
GitLab Screenshots
GitLab ist eine einzige Anwendung für den gesamten Softwareentwicklungslebenszyklus, von der Projektplanung und dem Quellcodemanagement bis hin zu CI/CD, Monitoring und Sicherheit. GitLab bietet eine Git-basierte Versionskontrolle, verpackt mit einer kompletten DevOps-Toolchain. Etwas wie GitHub, aber viel, viel mehr.
Dieses Appliance enthält alle Standardfunktionen in TurnKey Core, und darüber hinaus:
GitLab-Konfigurationen:
GitLab, RubyGems, PostgreSQL, Nginx und alle anderen erforderlichen Komponenten, die von vorgelagerten installiert werden Omnibuspaket.
SicherheitshinweisUpdates zu GitLab erfordern möglicherweise eine Überwachung, damit sie ARE NOT Zur automatischen Installation konfiguriert. GitLab Dokumentation.
Setzen Sie GitLab Admin User ('root') Passwort und E-Mail auf firstboot (Convenience, Sicherheit).
Setzen Sie die GitLab-Domain so, dass sie beim ersten Booten bedient wird (Convenience).
Aktivieren Sie GitLab Omnibus integrierte Let's Encrypt-Zertifikate über das Confconsole-Plugin (unter "Lets Encrypt").
Enthält postfix MTA (gebunden an localhost) zum Versenden von E-Mails (z. B. Passwortwiederherstellung) und webmin postfix-Modul zur Bequemlichkeit.
Überwachtes manuelles GitLab Update
Überprüfen Sie die installierten und berechtigten Versionen, ohne das Appliance zu ändern:
gitlab-update --check
Vor einem Update konsultieren Sie die GitLab Upgrade Pfad und die Release-Spezifisch GitLab DokumentationGitLab benötigt zwischenzeitliche Upgrade-Stopps. Sichern Sie das Appliance und installieren Sie dann die nächste berechtigte Version explizit:
apt update apt install gitlab-ce=<version>
Wiederholen Sie die Prüfung der Antragsannahme, bevor Sie zu einem anderen erforderlichen Stopp übergehen. apt-cache Madison Gitlabce und die GitLab veröffentlicht Blog.
Wenn APT einen abgelaufenen Repository-Schlüssel meldet oder NO_PUBKEYFolge dem Repository-Schlüssel-Rotationsverfahren. Es bewahrt das Per-Repository unterzeichnet Einschränkung und Überprüfung des vollständig veröffentlichten Fingerabdrucks von GitLab.
Anmeldeinformationen (Passwörter beim ersten Booten gesetzt)
Webmin, SSH: Benutzername Wurzel
GitLab: Benutzername Wurzel
Aus dem Browser ausführen
Nutzungsdetails & Logging in für die Administration
Keine Standardpasswörter: Aus Sicherheitsgründen gibt es keine Standardpasswörter. Alle Passwörter sind auf Systeminitialisierung Zeit.
SSL Browser Warnung ignorieren: Browser mögen keine selbstsignierten SSL-Zertifikate, aber dies ist die einzige Art, die automatisch generiert werden kann. Confconsole Erweitertes MenüSie können frei generieren Lassen Sie uns SSL / TLS-Zertifikate einschließen.
Web-Web - Richten Sie Ihren Browser auf entweder:
- http://12.34.56.789/ - nicht verschlüsselt, also keine Browserwarnung
- https://12.34.56.789/ - verschlüsselt mit selbstsigniertem SSL-Zertifikat
Hinweis: einige Appliances Auto Direct http zu https.
Benutzername für gitlab:
Login als Benutzername Wurzel
Benutzername für OS System Administration:
Login als Wurzel außer am AWS Marktplatz die den Benutzernamen verwendet Admin.
- Richten Sie Ihren Browser auf:
- https://12.34.56.789:12321/ System Control Panel
- https://12.34.56.789:12320/ Webbasiertes Kommandozeilenterminal
- Login mit SSH Client:
ssh root@12.34.56.789
Sonderfall für AWS-Marktplatz:
ssh admin@12.34.56.789
* Ersetzen Sie 12.34.56.789 durch eine gültige IP oder einen gültigen Hostnamen.
Dokumentation
v15.2+ : Omnibuspaket
Ab v15.2 enthält das TurnKey GitLab Appliance GitLab, das über das OmnibuspaketFrühere Versionen von TurnKey GitLab lieferten eine Source InstallationLeider wird diese Änderung ein bisschen schmerzhaft für bestehende Benutzer sein, da sie eine manuelle Migration Von der Quelle zum Omnibus. Es wird erwartet, dass dieser kurzfristige Schmerz durch die einfachere Wartung / Aktualisierungen von GitLab (sowohl Endbenutzer als auch TurnKey) ausgeglichen wird. Diese Änderung wurde nach signifikantem Feedback von Benutzern, einigen großartigen Gesprächen, die die Vor- und Nachteile abwägen, sowie den anhaltenden Schmerzen bei der Wartung der Quellinstallation eingeleitet. Appliance.
Migration von früheren TurnKey GitLab-Instanzen
Leider gibt es keine einfache Möglichkeit, von einer Quellinstallation von GitLab zu einer Omnibusinstallation von GitLab zu migrieren. Es erfordert ein wenig Umgehen, einschließlich der Migration von Backend-DB vom MySQL-DB-Backend (wie in TurnKey v15.1 und früher verwendet) zum PostgreSQL-Backend (wie von Omnibus geliefert). Installieren Sie in TurnKey v15.2 und höher.
Die wichtigsten Details sind in der GitLab docsIdealerweise wäre es am besten, wenn Sie Ihre Daten zuerst manuell auf eine Omnibus-Installation migrieren, dann manuell ein GitLab Backup generierenDas Backup, das Sie erstellen, sowie Ihr /etc/gitlab-Verzeichnis (oder zumindest Ihre gitlab-secrets.json-Datei) können dann in die neue Datei übertragen werden. GitLab Platzieren der /etc-Dateien an der entsprechenden Stelle und Wiederherstellen Ihres Backups nach den GitLab Docs.
Es ist erwähnenswert, dass, wenn Sie eine wirklich alte Version von GitLab haben, Sie möglicherweise zuerst einige Quell-Updates durchführen müssen. Thread in den Foren, wo ein Benutzer von GitLab v5.0.2 (TurnKey GitLab v13.0) bis hin zu aktuellem GitLab (v11.x zum Zeitpunkt des Schreibens) aktualisiert wurde. Wenn auch Sie so etwas tun müssen, dann wird dieser Thread hoffentlich nützlich sein. Starten Sie einen neuen Thread (muss angemeldet sein - wenn Sie kein TurnKey-Foren-Benutzerkonto haben, bitte) Register für einen.
Aufgrund von Einschränkungen und Änderungen im Backup-Prozess ist es ratsam, vor dem Erstellen des Backups auf mindestens GitLab v9.3.0 zu aktualisieren und Ihre Daten auf Ihr neues zu migrieren. Server (obwohl es möglich sein sollte, auf Ihrem alten Server vorher zu Omnibus zu migrieren). Beachten Sie auch, dass Backups nur funktionieren, wenn Sie zu / von genau der gleichen Version von GitLab gehen. die gleiche Installationsmethode (Quelle oder Omnibus), Versionsnummer und Release-Kanal (Enterprise Edition alias "ee"; oder Community Edition alias "ce"). Sobald Sie zu Omnibus migriert sind und auf v9.3 oder groß sind, können Sie Daten migrieren und die GitLab-Version bei Bedarf herunterstufen. Herunterstufen der GitLab-Version auf TurnKey wird unten in der Manuelle Wiederherstellung Omnibus Schnitt.
FWIW, der Prozess der Migration von einem nicht-TurnKey GitLab-Server zu einem TurnKey GItLab Appliance (v15.2+) wird im Wesentlichen der gleiche wie die Migration von einem TurnKey-Server = < v15.1 sein.
TurnKey GitLab und TKLBAM
Wiederherstellung aus früheren Versionen von TurnKey (<=v15.1)
Leider TKLBAM Backups von GitLab Appliances vor v15.2 (d.h. Appliances, die GitLab von der Quelle installiert enthalten, kann nicht automatisch auf TurnKey GitLab v15.2+ mit TKLBAM wiederhergestellt werden. Appliances muss zuerst manuell zu Omnibus migriert werden, wie im obigen Abschnitt beschrieben. manuelle Migration.
Manuelles Omnibus-Backup wiederherstellen
Um ein GitLab-Backup wiederherzustellen, müssen Sie genau die Version der GitLab-Version, von der das Backup stammt, mit der Version übereinstimmen, in die Sie wiederherstellen. Aufgrund von Bedenken hinsichtlich eventuell auftretender Probleme wird dies am besten manuell durchgeführt. TKLBAM hat Versuchsversuch Unterstützung, um dies automatisch zu versuchen, wenn sie das versuchen möchten, lesen sie bitte den abschnitt unten auf. Automagic Version MatchingWenn Sie mit der manuellen Wiederherstellung fortfahren möchten (empfohlen), lesen Sie bitte weiter.