Scegliere un server git on-prem gratuito: Gitea è la scelta vincente!

Cercare di scegliere un buon server git open source

Indice

Vuoi spostare i tuoi progetti lontano dai provider di git in cloud aperti e stai pensando di ospitare un server git interno localmente?

gitea-site

Scegliere i server

Eseguire il proprio server git non dovrebbe essere troppo difficile, vero?

Ora si sta scegliendo un server git gratuito da una breve lista di opzioni. Bonobo Gogs vs Gitea vs Gitlab.

Bonobo è gratuito ma è per Windows e non ha una versione Linux.

Gitlab è ricco di funzionalità e richiede risorse elevate, è un’esperienza manuale. È un prodotto commerciale ma ha anche una versione gratuita .

Gogs è molto leggero, l’ho provato e ha funzionato bene, ma manca di un registro dei contenitori.

Il confronto mi sembra favorire Gitea.

Entrambi Gitea e Postgresql dockerizzati

https://docs.gitea.com/next/installation/install-with-docker

cd ~
mkdir gitea
cd gitea

docker-compose.yml:

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=gitea
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - db

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - ./postgres:/var/lib/postgresql/data

poi

docker-compose up -d

naviga su http://localhost:3000/

per arrestare

docker-compose down

i volumi rimarranno

Utilizzo delle risorse

Statistiche dei contenitori delle risorse

I contenitori utilizzano 260MB di RAM e un po’ di CPU.

Statistiche delle immagini docker

Le immagini docker hanno una dimensione totale di 583MB. 422MB di queste sono occupate dall’immagine postgres:14. L’immagine postgres:14-alpine occupa 239MB, potrebbe funzionare anche se le risorse sono limitate.

PS. Dopo aver migrato più di 10 repository a gitea, alcuni fork e clonaggi del contenitore gitea da solo utilizzano ora 420MB di RAM. Occorre tenerne conto.

Sincronizzare due repository

https://docs.gitea.com/next/usage/repo-mirror

È possibile eseguire push e pull.

pull

  • Seleziona Nuova migrazione nel menu Crea… in alto a destra.
  • Seleziona il servizio del repository remoto.
  • Inserisci l’URL del repository.
  • Se il repository richiede l’autenticazione, inserisci le informazioni di autenticazione.
  • Contrassegna la casella Questo repository sarà uno specchio.
  • Seleziona Migrare repository per salvare la configurazione.

Il repository ora viene specchiato periodicamente dal repository remoto. Puoi forzare una sincronizzazione selezionando Sincronizza adesso nelle impostazioni del repository.

Puoi impostare solo lo specchio di pull per i repository che non esistono ancora sulla tua istanza. Una volta creato il repository, non puoi più convertirlo in uno specchio di pull.

Configurazione HTTPS

C’è di più nella configurazione SSL: https://docs.gitea.com/next/administration/https-setup

ma per ora stiamo provando questo (preso dal sito di gitea):

Utilizzo del server integrato

Prima di abilitare HTTPS, assicurati di avere certificati SSL/TLS validi. Potresti utilizzare certificati generati autonomamente per valutazioni e test. Per favore esegui

gitea cert --host [HOST]

per generare un certificato autofirmato.

Se stai utilizzando Apache o nginx sul server, ti consigliamo di verificare la guida per il proxy inverso.

Per utilizzare il supporto HTTPS integrato in Gitea, devi modificare il file app.ini:

[server]
PROTOCOL  = https
ROOT_URL  = https://git.example.com:3000/
HTTP_PORT = 3000
CERT_FILE = cert.pem
KEY_FILE  = key.pem

Nota che se il certificato è firmato da un’autorità di certificazione terza (ovvero non autofirmato), cert.pem deve contenere la catena di certificati. Il certificato del server deve essere l’elemento iniziale in cert.pem, seguito dagli intermediari in ordine (se presenti). Il certificato radice non deve essere incluso perché il client che si connette deve già averlo per stabilire la relazione di fiducia. Per ulteriori informazioni sui valori di configurazione, consulta la Config Cheat Sheet.

Per il campo CERT_FILE o KEY_FILE, il percorso del file è relativo alla variabile d’ambiente GITEA_CUSTOM quando si tratta di un percorso relativo. Può essere anche un percorso assoluto.

Configurazione della ridirezione HTTP Il server Gitea è in grado di ascoltare solo una porta; per ridirezionare le richieste HTTP alla porta HTTPS, è necessario abilitare il servizio di ridirezione HTTP:

[server]
REDIRECT_OTHER_PORT = true
; porta su cui il servizio di ridirezione deve ascoltare
PORT_TO_REDIRECT = 3080

Se stai utilizzando Docker, assicurati che questa porta sia configurata nel tuo file docker-compose.yml.

Utilizzo del proxy inverso

In questo post: Gitea-ssl sto configurando Apache come proxy inverso che termina il TLS.

Todo

configurazione ssh: https://docs.gitea.com/next/installation/install-with-docker

test di backup-restore.