Since GitLab requires a relatively large amount of memory and CPU, and is also relatively slow on my NAS, I replaced GitLab with Gitea. Gitea offers a similar web interface as GitHub, is much more economical than GitLab and is more responsive. Even though the feature set is not as high as GitLab, it is perfectly sufficient for most uses.

To ensure that Gitea is can be reached securely from the Internet, I use a Let's Encrypt reverse proxy. At first I used Nginx as Reverse-Proxy, but later replaced it with Traefik. The reverse proxy provides an encrypted HTTPS connection and makes it possible to run multiple websites on one server.

Step by step Gitea and Docker including access from the internet

1. Almost any hardware can be used for the Docker installation: For example, a virtual server of a provider, or for home: a Mini-PC, notebook, Raspberry PI, MAC, a NAS: QNAP, Synology or any other hardware on which Windows or Linux can be installed.

Schematic representation: Access from the Internet

1. In the case of a rented server from a provider, the provider assigns an IP address. If you want to operate a server in your own home network, you additionally need to set up port forwarding.
2. The access from the Internet is best done via a domain with a DNS entry to the public IP address, see Domain and its management. If you do not have your own domain, you can also use a DynDNS service to access your home network.
3. For the certificate management and access to the web services I use a reverse proxy and Let's Encrypt certificates.

1. Create and customize docker-compose.yml and .env .
2. Start container and
3. set up

docker-compose.yml

To start Gitea using docker compose, you can use the official Docker Gitea image and MySQL as database. Both images can be downloaded, created and started with a simple docker-compose.yml file. The file can be filled with any text editor as follows and then customized:

Filename: docker-compose.yml, Content: 

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'
      DISABLE_REGISTRATION: 'true'
    restart: always
   #For direct test access, remove "#" in the following 2 lines. Call: http://localhost:83 or http://ServerIP:83
    #ports:   
      #- "83:80" 

   #Labels for ReverseProxy, see: https://www.libe.net/en-traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.git.rule=Host(`git.domain.tld`)"      
      - "traefik.http.routers.git.entrypoints=web"
      - "traefik.http.routers.git.entrypoints=websecure"
      - "traefik.http.routers.git.tls.certresolver=myresolver"
      - "traefik.http.services.git.loadbalancer.server.port=80"
    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
volumes:
  gitea:
  giteadb:

#Without using a reverse proxy (https://www.libe.net/en-traefik) the webproxy network is likely to be missing
#and the following lines can be removed or commented out. Alternatively, the network can be created with "docker network create webproxy".
networks:
  default:
    external:
      name: webproxy

For direct access via IP address or localhost - even without reverse proxy, DNS or public IP - the commented out port setting can be activated for test purposes by removing “#“ in front of “ports:” and “-"83:80"“ .

For Internet access via the Traefik reverse proxy, the domain must be replaced in the labels with the previously created DNS entries (in the example: git.domain.tld).

The password for the MySQL database can be stored in an .env file:

.env

DB_PASSWD="password"

The start is done from the folder of the docker-compose.yml file with the command “docker-compose up”:

docker-compose up -d

Setup

During the initial setup on the web interface I made the following settings:

• SSH server domain* domain.tld
• Gitea base URL* https://domain.tld

To use Gitea purely as a private repository, I set the following in the setup:

• Disable registration
• Viewing requires login
• Of course, with registration disabled, an admin user must be specified in the wizard:
  Administrator username, password, email address

Migration

Automatic deployment of new commits

I have solved an automatic pull of new commits using webhooks. As counterpart, I have a very simple hook server in use: github.com/ncarlier/webhookd. To make sure that the commit to a specific branch is automatically picked up by a specific Docker container, I adapted the example script as follows:

#!/bin/sh
TOKEN="???x"

# 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 the example, the current branch is passed, and a git pull is executed in the Docker container of the same name.

Conclusion

For my purposes, Gitea is currently perfectly sufficient. For larger teams or more complex deployments, however, GitLab is a good choice, see also: Hosting GIT repositories yourself: Starting GitLab as a Docker container. For easy management of Docker containers via a web interface, see also: Docker Admin Interface: Portainer Community Edition