Schlanker und schneller GIT-Server, ähnlich GitHub (Docker)


Nachdem GitLab relativ viel Arbeitsspeicher und CPU benötigt und zudem auf meinem NAS relativ langsam ist, habe ich GitLab mit Gitea ersetzt. Gitea bietet eine ähnliche Weboberfläche wie GitHub, ist wesentlich sparsamer als GitLab und reagiert flinker. Auch wenn der Funktionsumfang nicht so hoch wie bei GitLab ist, reicht dieser für die meisten Verwendungszwecke vollkommen aus. 

SoftwareGitea
GitHubhttps://github.com/go-gitea/gitea
aktuelle Version 1.16.8
gefunden 20.05.2022
 

Voraussetzungen

Docker Basics

Docker ermöglicht es, Applikationen per Befehl in einem sogenannten Container zu starten.
Ein Container ist eine vom Betriebssystem (OS) unabhängige isolierte Umgebung:
Das OS spielt also keine Rolle, vorausgesetzt Docker lässt sich installieren.
Beim ersten Start eines Containers, lädt Docker selbstständig alle notwendigen Quellen
aus dem Internet.
Docker kann unter Windows, macOS oder einer Linux-Distribution installiert werden,
siehe auch: Docker
Für die Veröffentlichung im Internet, kann ein LetsEncrypt-SSL-Zertifikat verwendet werden: nginx-LetsEncrypt Reverse Proxy in der Praxis. Der Reverse-Proxy ist auch die Voraussetzung für das folgende Beispiel:

Schritt für Schritt

Docker und Let's Encrypt Reverse-Proxy:

  1. Hardware auswählen: PC, Notebook oder besser: virtueller Server, Raspberry PI oder eine NAS: QNAP, Synology oder Eigenbau-NAS
  2. OS installieren: Windows, Linux
  3. Docker installieren, siehe: Docker
  4. DNS-Eintrag im Internet auf die öffentliche IP-Adresse erstellen und
    nginx-Reverse Proxy Setup: nginx-LetsEncrypt Reverse Proxy in der Praxis
Container für Gitea:

  1. docker-compose.yml und .env anlegen und anpassen
  2. Container starten und 
  3. einrichten

docker-compose.yml

Voraussetzung für das Setup: nginx-LetsEncrypt Reverse Proxy in der Praxis 

version: "3"
services:
  giteaserver:
    image: gitea/gitea:1.13.6
    container_name: gitea
    environment:
      USER_UID: '1000'
      USER_GID: '1000'
      DB_TYPE: 'mysql'
      DB_HOST: 'giteadb:3306'
      DB_NAME: 'gitea'
      DB_USER: 'gitea'
      DB_PASSWD: '${DB_PASSWD}'
      HTTP_PORT: '80'
      DISABLE_SSH: 'true'
      VIRTUAL_HOST: 'gitea.domain.tld'
      VIRTUAL_PORT: '80'
      LETSENCRYPT_HOST: 'gitea.domain.tld'
      LETSENCRYPT_EMAIL: 'user@domain.tld'
      DISABLE_REGISTRATION: 'true'
    restart: always
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
       - "80"
  giteadb:
     image: mysql:5.7
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: 'gitea'
       MYSQL_USER: 'gitea'
       MYSQL_PASSWORD: '${DB_PASSWD}'
       MYSQL_DATABASE: 'gitea'
     volumes:
       - ./db:/var/lib/mysql
networks:
  default:
    external:
      name: webproxy

Die verwendete Domäne muss natürlich angepasst werden, das Passwort für die MySQL-Datenbank kann in einer .env-Datei hinterlegt werden:

.env

DB_PASSWD="password"

Vor dem Start werden noch die Ordner gitea und db benötigt. Der Befehl docker-compose up -d startet Gitea:

mkdir gitea
mkdir db
docker-compose up -d

Einrichten

Beim initialen Setup auf der Web-Oberfläche habe ich folgende Einstellungen getroffen:

  • SSH-Server-Domain* domain.tld
  • Gitea-Basis-URL* https://domain.tld

Um Gitea rein als privates Repository zu verwenden, habe ich im Setup folgendes eingestellt:

  • Registrierung deaktivieren
  • Ansehen erfordert Anmeldung
  • Bei deaktivierter Registrierung muss natürlich im Wizard ein Admin-User angegeben werden:
    Administrator-Benutzername, Passwort, E-Mail-Adresse 

Migration

Neue Migration aus dem GitLab-Docker-Container hat bei mir nicht geklappt, ist aber nicht so schlimm: Nach dem Anlegen der Repos können die von einem Git-Ordner einfach gepushed werden ...
 

Automatisches Deployment neuer Commits

Einen automatischen Pull neuer Commits habe ich mittels Webhooks gelöst. Als Gegenstelle habe ich einen sehr simplen Hook-Server in Verwendung: github.com/ncarlier/webhookd. Damit der Commit auf einen bestimmten Branch automatisch von einem bestimmten Docker-Container übernommen wird, habe ich das Beispielscript wie folgt angepasst:

#!/bin/sh
TOKEN="xxxx"

# Functions
die() { echo "error: $@" 1>&2 ; exit 1; }
confDie() { echo "error: $@ Check the server configuration!" 1>&2 ; exit 2; }
debug() {
  [ "$debug" = "true" ] && echo "debug: $@"
}

# Validate global configuration
[ -z "$TOKEN" ] && confDie "GITEA_TOKEN not set."

# Validate Gitea hook
sec=$(echo "$1" | jq .secret -r)
if [ $sec ]; then
	[ $sec != $TOKEN ] && die "bad hook token"
else
	die "empty hook token"
fi

# Validate parameters
payload=$1
payload="$(echo "$payload"|tr -d '\n')"
[ -z "$payload" ] && die "missing request payload"
payload_type=$(echo $payload | jq type -r)

[ $? != 0 ] && die "bad body format: expecting JSON"
[ ! $payload_type = "object" ] && die "bad body format: expecting JSON object but having $payload_type"

debug "received payload: $payload"

# Extract values
  ref=$(echo $payload | jq .ref -r)
  branch=${ref#*refs/heads/}

# Pull and Reset commited Branch
 echo "branch: $branch push for $ref"
	if [ $branch != "master" ] 
	then
		docker exec $branch bash -c "git fetch origin $branch && git pull origin $branch && git reset --hard $branch"
	else
		echo "nothing todo: master"
	fi

In dem Beispiel wird der aktuelle Branch übergeben und im gleichnamigen Docker-Container ein git pull ausgeführt.

Fazit

Für meine Einsatzzwecke reicht Gitea derzeit vollkommen aus. Für größere Teams oder komplexere Deployments bietet sich dennoch GitLab an, siehe auch: GIT-Repositories selbst hosten: GitLab als Docker-Container starten

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE für deine Bewertung!


Top-Artikel in diesem Bereich

Preview ioBroker installieren - Docker

ioBroker installieren - Docker

geändert: 12.11.2020 von Bernhard (Erstveröffentlichung: 06.11.2020)

Mit ioBroker können verschiedene Automatisierungslösungen oder Geräte in einem System zusammengefasst werden. Um bestimmte Gateways oder Geräte ansprechen zu können, werden in ioBroker verschiedene Adapter verwendet.  ... weiterlesen

Preview Home-Assistant Docker Conbee 2 und Zigbee2MQTT / deCONZ

Home-Assistant Docker Conbee 2 und Zigbee2MQTT / deCONZ

geändert: 09.03.2022 von Bernhard (Erstveröffentlichung: 06.11.2020)

Dank zahlreicher Integrationsmöglichkeiten ist Home-Assistant eine einfache Plattform für das Steuern verschiedenster Smart-Home Geräte. Im Vergleich zu ioBroker ist mir der Start mit Home Assistant wesentlich einfacher gefallen. Während ich für ioBroker noch am Suchen war, welches Frontend ich für meine Dashboards verwenden könnte, hatte ich mit Home-Assistant Out of the box ein fertig eingerichtetes System. Die Lovelance Dashboards von Home Assistant können einfach in der GUI zusammengeklickt... ... weiterlesen

Bitwarden in Docker betreiben - Setup Schritt für Schritt

Bitwarden in Docker betreiben - Setup Schritt für Schritt

erstellt: 28.02.2022 von Bernhard

Bitwarden ist ein webbasierter Passwort-Manager, ähnlich LastPass, aber Open Source und der Möglichkeit diesen selbst zu betreiben (hosten). Wie sich Bitwarden im Vergleich zu anderen Passwortmanagern einordnet, habe ich auf folgender Seite überlegt: Passwortmanager sicher? KeePass vs. LastPass vs. Bitwarden. ... weiterlesen


Fragen / Kommentare


Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details