Schlagwort-Archive: gitlab

Von Gitlab zu Gitea

Veröffentlicht am von
1

Probleme

In letzter Zeit, sind die langen Anfangsladezeiten der Website von Gitlab immer häufiger aufgetreten. Sowie wurde die ganze Website immer langsamer und fast nicht mehr bedienbar. Daher habe ich mir das ganze auf meine Vserver etwas genauer angeschaut. Dabei hat sich herausgestellt, das Gitlab immer Ressourcen-hungriger wird. In meinem Fall waren es fast 1,4 GB Ram + 2-3 GB im Swap. Bei gerade 2 GB Hauptspeicher ist das nun doch etwas zu viel. Laut Gitlab wird derweilen auch empfohlenen, dass man 2 CPU Cores und 8 GB RAM benötigt (stand 01.07.2018), siehe hier https://docs.gitlab.com/ee/install/requirements.html.

Durch Zufall bin ich auf Gitea gestoßen, welches ich gleich ausprobieren musste. Und siehe da, die Funktionalität auf der Website ist genau das was ich benötige und noch etwas mehr. Des Weiteren benötigt es aktuell um die 300-500 MB Arbeitsspeicher und die ganze Anwendung besteht aus einer 50 MB großen Datei. Des Weiteren ist die Installation denkbar einfach und es kann der vorhandene MySQL-Server genutzt werden, oder auch SqlLite als Datenbank-Backend.

Installation

So und hier nun die Installation für Gitea (Im groben hab ich mich dabei an die Original-Anleitung von Gitea gehalten mit ein paar kleinen Anpassungen):

Vorbereitung

Hiermit wird die Anwendung in der Version 1.4.3 heruntergeladen und entsprechend umkopiert, so kann ohne weiteres auch die Anwendung aktualisiert werden:

wget -O gitea https://dl.gitea.io/gitea/1.4.3/gitea-1.4.3-linux-amd64
chmod +x gitea
cp gitea /usr/local/bin/gitea

Hiermit wird die Ordnerstrukturen erzeugt:

adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password --home /home/gitea gitea
mkdir -p /var/lib/gitea/{custom,data,indexers,public,log}
chown gitea:gitea /var/lib/gitea/{data,indexers,log}
chmod 750 /var/lib/gitea/{data,indexers,log}
mkdir /etc/gitea
chown root:gitea /etc/gitea
chmod 770 /etc/gitea

Gitea als Dienst

Nun noch den Dienst für Gitea einrichten, dafür nachfolgenden Code in die Datei „/etc/systemd/system/gitea.service“ eintragen:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=gitea HOME=/home/gitea GITEA_WORK_DIR=/var/lib/gitea GITEA_CUSTOM=/var/lib/gitea/custom
# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE
#StandardOutput=syslog # Ist der Default
#StandardError=syslog # Ist der Default
SysLogIdentifier=gitea
[Install]
WantedBy=multi-user.target

Danach den Dienst aktivieren und starten:

systemctl enable gitea
systemctl start gitea

Wenn man die Datei verändert hat, benötigt man erst ein nachladen vom systemd damit alles wieder funktioniert:

systemctl daemon-reload

Nacharbeiten

Nun geht man auf die Website und richtet Gitea ein. Danach sollte man noch die Konfigurationsdateien gegen Veränderung schützen:

chmod 750 /etc/gitea
chmod 644 /etc/gitea/app.ini

Die Konfigurationsdatei kann auch per Hand verändert werden, danach muss Gitea aber einmal neugestartet werden:

systemctl restart gitea

Diagnose

Um sich die Logausgaben, die von Gitea auf SdtOut geschrieben werden, anzuschauen, benutzt man journalctl:

journalctl -u gitea
journalctl -f -u gitea # Live log

Hinter dem Apache verstecken

Da ich als Haupteinstiegsserver einen Apache-Server am laufen habe, benötige ich nun noch eine Proxy-Konfiguration, um die Anfrage weiterzuleiten (Der angegebene Port, ist der Standard-Port von Gitea. Wenn man diesen angepasst hat, muss er hier ebenfalls angepasst werden!):

# unverschlüsselte Verbindung
<VirtualHost w.x.y.z:80>
  ServerName gitea.example.com
  ServerAdmin hostmaster@example.com
  # Umleiten auf HTTPS
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^/(.*) https://gitea.example.com/$1
  </IfModule>
  Redirect / https://gitea.exmaple.com/
</VirtualHost>
# SSL Konfiguration
<VirtualHost w.x.y.z:443>
  ServerName gitea.example.com
  ServerAdmin hostmaster@example.com
  SSLEngine On
  SSLHonorChipherOrder On
  SSLCipherSuite ...
  SSLVerifyDepth 10
  SSLCertificateFile /../...pem
  SSLCertificateKeyFile /../...key
  SSLCertificateKeyFile /../...crt
  SSLCertificateKeyFile /../...csr
  ...
  # Internes weiterleiten an den nginx
  <IfModule mod_proxy.c>
    ProxyVia On
    ProxyRequests Off
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
    ProxyPreserveHost On
    <Proxy *>
      Options FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all
    </Proxy>
    # Notwendig, damit die https-Verbindung auf http weitergeleitet werden kann
    RequestHeader set Host "gitea.example.com"
    RequestHeader add X-Forwarded-Ssl on
    RequestHeader set X-Forwarded-For %{REMOTE_IP}%
    RequestHeader set X-Forwarded-Proto "https"
  </IfModule>
</VirtualHost>

Jetzt benötigt man noch die Proxy-Module und einen neuladen des Apache-Server:

a2enmod proxy
a2enmod proxy_http
service apache2 reload #oder restart wenn man möchte

GitLab konfigurieren

Veröffentlicht am von
Antworten

Für die Konfiguration des GitLab mit dem Omnibus-Package ist nur eine Datei notwendig, diese ist die „/etc/gitlab/gitlab.rb“. Ein Beispiel:

# URL die im Browser eingegeben wird. (Es scheint so, das am Ende kein / stehen darf)
external_url "https://gitlab.example.com"
# Einstellungen für nginx
nginx['listen_address'] = '127.0.0.1'
nginx['listen_https'] = false
nginx['listen_port'] = 880
nginx['redirect_http_to_https'] = true
# Ist notwendig, damit die richtige URL bei den Projekten steht. Gerade bei Sub-Sub-Domains, z.B: gitlab.mydomain.example.com.
gitlab_rails["gitlab_host"] = 'gitlab.example.com'
# EMail-Adresse die als Absender eingetragen wird
gitlab_railse["gitlab_email_from"] = 'gitlab@example.com'
# Für neuere Version, wird mehr Arbeitsspeicher benötigt (recommended 4 GB), um diese etwas zu umgehen kann die
#   Unicorn-Arbeitsthread verringer, die typischerweise auf Anzahl Cores + 1 eingestellt sind:
#   Weitere Info: https://docs.gitlab.com/ce/install/requirements.html#unicorn-workers
unicorn['worker_processes'] = 2
unicorn['worker_timeout'] = 60

Nach jeder Änderung in der Konfiguration muss gitlab rekonfiguriert werden, das macht man mit folgenden Befehl:

gitlab-ctl reconfigure

Wenn nginx nicht starten kann, weil ein anderer Webserver schon läuft, dann kann man das wie folgt lösen. Zuerst muss man nginx umkonfigurieren, damit dieser auf einen anderen Port lauscht. In der Datei „/etc/gitlab/gitlab.rb“ die nachfolgenden Einträge hinzufügen:

# Einstellungen für nginx
nginx['listen_address'] = '127.0.0.1'
nginx['listen_https'] = false
nginx['listen_port'] = 880
nginx['redirect_http_to_https'] = true

Da hier ein interne Verbindung benutzt wird, um von dem einen Webserver auf den anderen zu kommen, reicht hier http völlig aus. Das „:880“ definiert den Port an dem nginx lauschen soll. Sollte nach dem Re-konfigurieren von gitlab, nginx noch nicht am angegeben Port lauschen, was mit nachfolgenden Befehl nachgeprüft werden kann:

netstat -pant

Dann sollte man nginx per Hand stoppen und starten:

gitlab-ctl stop nginx
gitlab-ctl start nginx

Nun muss der andere Webserver noch als Proxy eingerichtet werden. Beim Apache (ab Version 2.0) müssen zuerst die Proxy-Module aktiviert werden:

a2enmod proxy
a2enmod proxy_http

In der VHost-Konfiguration zum Gitlab-Server sollte dann ungefähr so ausschauen:

# unverschlüsselte Verbindung
<VirtualHost w.x.y.z:80>
  ServerName gitlab.example.com
  ServerAdmin hostmaster@example.com
  # Umleiten auf HTTPS
  <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^/(.*) https://gitlab.example.com/$1
  </IfModule>
  Redirect / https://gitlab.exmaple.com/
</VirtualHost>
# SSL Konfiguration
<VirtualHost w.x.y.z:443>
  ServerName gitlab.example.com
  ServerAdmin hostmaster@example.com
  SSLEngine On
  SSLHonorChipherOrder On
  SSLCipherSuite ...
  SSLVerifyDepth 10
  SSLCertificateFile /../...pem
  SSLCertificateKeyFile /../...key
  SSLCertificateKeyFile /../...crt
  SSLCertificateKeyFile /../...csr
  ...
  # Internes weiterleiten an den nginx
  <IfModule mod_proxy.c>
    ProxyVia On
    ProxyRequests Off
    ProxyPass / http://127.0.0.1:880/
    ProxyPassReverse / http://127.0.0.1:880/
    ProxyPreserveHost On
    <Proxy *>
      Options FollowSymLinks MultiViews
      AllowOverride All
      Order allow,deny
      allow from all
    </Proxy>
    # Notwendig, damit die https-Verbindung auf http weitergeleitet werden kann
    RequestHeader set Host "gitlab.example.com"
    RequestHeader add X-Forwarded-Ssl on
    RequestHeader set X-Forwarded-For %{REMOTE_IP}%
    RequestHeader set X-Forwarded-Proto "https"
  </IfModule>
</VirtualHost>

Und dann noch den Apache die Konfiguration erneut einlesen lassen, mit nachfolgenden Befehl:

service apache2 reload #oder restart wenn man möchte

Nun sollte man über den Zugriff „https://gitlab.example.com“ auf die GitLab anmelde Webseite kommen. Und bei den Projekten, sollten auch die richtigen URL’s erscheinen.

Weitere Informationen zu Einstellungen von GitLab findet man hier.