Aktionen

GitLab GitLab Community Edition unter Ubuntu 16.04.x LTS in Subdomain installieren

Aus znilwiki

Changelog:

  • 25.09.2016: Erste Version



Auch wenn ich meist Einzelkämpfer beim Programmieren bin - hilft nix, ich muss das ganze mal professioneller machen ... eine Versionsverwaltung muss her.
Natürlich auf dem eigenem Server.


Ausgangslage

  • Ubuntu Server 16.04.1 LTS Webserver mit Apache2, MariaDB, Tomcat und ISPConfig
  • Subdomäne git.znil.net angelegt beim Domänen-Provider (1und1), DNS-Eintrag zeigt auf externe IP des Ubuntu Servers
  • Port des ISPConfig-Interfaces wurde von 8080 auf 8443 umgelegt ... wegen den Tomcat-Server (in der Datei /etc/apache2/sites-available/ispconfig.vhost einfach die Nummer ändern und Apache neu starten)




Installation GitLab

Gemäß dieser Anleitungen:


Voraussetzungen installieren (sind auf einem normalen ISPConfig Server schon vorhanden):

sudo apt-get install curl openssh-server ca-certificates postfix


Quellen installieren:

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce


Nun müssen wir GitLab noch konfigurieren - für die Verwendung in einer Subdomain:

nano /etc/gitlab/gitlab.rb

und dort die folgenden Zeilen anpassen (STRG + W ist suchen):

external_url 'https://git.znil.net'
gitlab_rails['time_zone'] = 'Europe/Berlin'
gitlab_rails['gitlab_email_from'] = 'git@znil.net'
gitlab_workhorse['enable'] = true
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
gitlab_workhorse['auth_backend'] = "http://localhost:8082"
unicorn['listen'] = '127.0.0.1'
unicorn['port'] = 8082
web_server['external_users'] = ['www-data']
nginx['enable'] = false


Nun die Änderungen übernehmen lassen:

sudo gitlab-ctl reconfigure




Anpassung .vHost Datei

Quelle der Informationen: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

Wir bearbeiten die vorhandene (oder Erstellen eine neu) Apache-Konfiguration für unsere Webseite:

nano /etc/apache2/sites-available/git.znil.net.vhost

Inhalt:

<VirtualHost 192.168.45.10:80>
        ServerName git.znil.net
        ServerAdmin git@znil.net

        ServerSignature Off

        RewriteEngine on
        RewriteCond %{HTTPS} !=on
        RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R,L]
</VirtualHost>


<VirtualHost 192.168.45.10:443>
        ServerName git.znil.net
        ServerAdmin git@znil.net

        SSLEngine on
        SSLProtocol All -SSLv2 -SSLv3
        SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
        SSLHonorCipherOrder     on
        Header add Strict-Transport-Security: "max-age=15768000;includeSubdomains"
        SSLCompression Off
        SSLCertificateFile /etc/letsencrypt/live/git.znil.net/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/git.znil.net/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/git.znil.net/chain.pem

        ProxyPreserveHost On

        # Ensure that encoded slashes are not decoded but left in their encoded state.
        # http://doc.gitlab.com/ce/api/projects.html#get-single-project
        AllowEncodedSlashes NoDecode

        <Location />
                # New authorization commands for apache 2.4 and up
                # http://httpd.apache.org/docs/2.4/upgrading.html#access
                Require all granted

                #Allow forwarding to gitlab-workhorse
                ProxyPassReverse http://127.0.0.1:8181
                ProxyPassReverse http://git.znil.net/
        </Location>

        # Apache equivalent of nginx try files
        # http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
        # http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
        RewriteEngine on

        #Don't escape encoded characters in api requests
        RewriteCond %{REQUEST_URI} ^/api/v3/.*
        RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

        #Forward all requests to gitlab-workhorse except existing files like error documents
        RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
        RewriteCond %{REQUEST_URI} ^/uploads/.*
        RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]

        RequestHeader set X_FORWARDED_PROTO 'https'
        RequestHeader set X-Forwarded-Ssl on

        # needed for downloading attachments
        DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public

        #Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
        ErrorDocument 404 /404.html
        ErrorDocument 422 /422.html
        ErrorDocument 500 /500.html
        ErrorDocument 502 /502.html
        ErrorDocument 503 /503.html

        # It is assumed that the log directory is in /var/log/httpd.
        # For Debian distributions you might want to change this to
        # /var/log/apache2.
        LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
        ErrorLog /var/log/apache2/git.znil.net_error.log
        CustomLog /var/log/apache2/git.znil.net_forwarded.log common_forwarded
        CustomLog /var/log/apache2/git.znil.net.log combined env=!dontlog
        CustomLog /var/log/apache2/git.znil.net.log combined
</VirtualHost>


Falls es die Subdomain in eurem Apache noch nicht gab müsst Ihr diese erst aktivieren:

a2ensite git.znil.net.vhost

Jetzt den Apache neu starten:

systemctl restart apache2.service


Nun könnt Ihr unter der Subdomain die Webseite aufrufen:

https://git.znil.net

Er verlangt nach einem neuen Passwort.
Mit dem könnt Ihr euch danach Anmelden, der Benutzername ist root



Backups

Gemäß dieser Anleitung: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/backup_restore.md
habe ich ein Backup in einen lokalen Ordner auf dem Server eingerichtet - bei diesem handelt es sich in Wirklichkeit um eine NFS-Freigabe auf einem anderen Server.

nano /etc/gitlab/gitlab.rb

und die folgenden Zeilen suchen und ändern:

gitlab_rails['backup_keep_time'] = 604800
gitlab_rails['backup_upload_connection'] = {
        'provider' => 'Local',
        'local_root' => '/BACKUP/GitLab'
}
gitlab_rails['backup_upload_remote_directory'] = '.'

Erklärung:
Wenn wir das Backup anstoßen sichert er zunächst lokal in den Ordner /var/opt/gitlab/backups
Mit den obigen Einstellungen erreichen wir folgendes:
gitlab_rails['backup_keep_time'] = 604800 veranlasst das automatische Löschen aller Backups älter als 7 Tage (Angabe in Sekunden)
gitlab_rails['backup_upload_connection'] = { weist ihn an in den lokalen Pfad zu sichern - Ziel muss ein Verzeichnis sein.
gitlab_rails['backup_upload_remote_directory'] = '.' lässt ihn keinen weiteren Unterordner anlegen sondern direkt in das zuvor angegebene Verzeichnis


Wie starten wir nun das Backup?

gitlab-rake gitlab:backup:create

führt ein sofortiges Backup aus welches er unter

/var/opt/gitlab/backups

speichert. Zusätzlich wird eine Kopie im angegebenen Pfad hinterlegt.
Backups die älter als 7 tage sind löscht er im Anschluß, die 7 Tagen gelten nun aber nur für den "internen" Ordner, nicht für unseren Ordner mit den Kopien - da müssen ggf. selbst eine entsprechende Routine eingesetzt werden.

Als Cronjob kann man nach einem erfolgreichen Test folgendes eintragen:

5 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

Dadurch wird die Textausgabe unterdrückt (außer bei Fehlern)
Zusätzlich sollte der Inhalt des Ordners

/etc/gitlab/

gesichert werden - Teile der Datenbank sind unter Umständen verschlüsselt - und der Schlüssel liegt unter anderem in dem Pfad.
Das geht einfach per cp:

 cp -r -f /etc/gitlab/* /BACKUP/GitLab-Secrects/

was man auch so in die Crontab eintragen kann.



Kommentare

Loading comments...