MaDoVi - Le wiki

Machines - Données - Virtualisation

Outils pour utilisateurs

Outils du site


services:web:tuto:git_tuto1

Gitea - Forge Open Source

En cours…

  • Écran initial / première connexion: finalisation config.
  • Quelques manip ?

Dans le cadre du projet , ce service va nous offrir un outil de «forge» : Gitea est une solution d'hébergement de codes sources ou de versions de différents documents numériques.
«Comme d'hab.» maintenant, on va l'installer dans son container à lui.

On va positionner ce composant au sein d'un container LXC lxc-gitea, on aura ainsi un service de plus dans le schéma plus global proposé dans ce paragraphe.

Les manipulations listées ci-dessous s'appliquent dans le CT lxc-gitea mais elles pourront s'appliquer dans un environnement Linux quelconque – aux commandes près propres à la distribution choisie. Vous pouvez ainsi ignorer les mentions au container si vous ne travaillez pas dans ce contexte, le reste demeure applicable…

Gitea utilise un SGBD pour stocker ses données: On va utiliser ici notre instance MariaDB - Serveur de base de données.


On en discute On en discute sur le forum


1. Création du container LXC

On souhaite donc installer notre outil Gitea dans un CT LXC. Ce container sera «non privilégié», et on va donc le créer depuis le compte admin. On va mettre, comme pour beaucoup de CT LXC, la distribution Alpine Linux, qui a une très faible empreinte système: «Les cibles principales d'Alpine sont les conteneurs et presque tous les appareils embarqués».

Mais au préalable, on peut fixer – optionnellement – une adresse au CT dans l'espace réseau LXC. Par exemple:

$ sudo nano /etc/lxc/dnsmasq.conf
...
# cid  50 -> 99: containers web
dhcp-host=lxc-proxy,10.0.3.50
dhcp-host=lxc-web01,10.0.3.51
dhcp-host=lxc-gitea,10.0.3.52
...

☛ Relancer le service dhcp/dnsmasq pour prise en compte:

$ sudo service lxc-net restart

Puis:

  • Création du CT:
    admin@wasabi:~$ lxc-create -n lxc-gitea -t download -- -d alpine -r 3.15 -a amd64
  • Lancement:
    admin@wasabi:~$ lxc-start -n lxc-gitea
  • Contrôle:
    admin@wasabi:~$ lxc-ls -f
    NAME        STATE   AUTOSTART GROUPS   IPV4      IPV6 UNPRIVILEGED 
    ...
    lxc-gitea   RUNNING 1         onboot              10.0.3.52 -    true         
    ...

    Il tourne, il a l'adresse attendue, il est bien unprivileged.


2. Préparation & Installation

On commence par s'«attacher» au container pour faire ce qu'on a à faire dedans:

admin@wasabi:~$ lxc-attach -n lxc-gitea 
/ # 

Les ajouts/installations/configurations de base: outils, ssh, Gitea (l'outil de gestion de paquets s'appelle apk sous Alpine).

  • Commençons par les outils:
    /sbin/apk update
    /sbin/apk add attr dialog dialog-doc bash bash-doc bash-completion grep grep-doc
    /sbin/apk add util-linux util-linux-doc pciutils usbutils binutils findutils readline
    /sbin/apk add mandoc man-pages lsof lsof-doc less less-doc nano nano-doc curl curl-doc
    /sbin/apk add sudo sudo-doc openssh 
    export PAGER=less
  • On prend bash comme interpréteur de commandes: il suffit de remplacer, dans le fichier /etc/passwd la fin de la ligne associée au compte root (la 1ière) par celle-ci (ash devient bash):
    nano /etc/passwd
     
    root:x:0:0:root:/root:/bin/bash
    ...

    Ctrl+x et y pour enregistrer et sortir.

  • Lancer le service ssh (et l'ajouter au démarrage du container):
    /sbin/rc-update add sshd
    /etc/init.d/sshd start
    ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
     * Starting sshd ...                                        [ ok ]
  • Ajout d'un utilisateur «admin» …:
    /usr/sbin/adduser admin
    Changing password for admin
    New password: 
    Retype password: 
    passwd: password for admin changed by root
  • … avec droit root (sudo):
    /usr/sbin/visudo
    ##                                                               
    ## User privilege specification
    ##
    root ALL=(ALL) ALL       
    admin ALL=(ALL) ALL   ## <<<=== ICI

    NB: visudo utilise l'éditeur VI: donc i pour entrer en mode insertion, Esc pour en sortir; puis :w pour enregistrer et :q pour quitter.

  • On redémarre pour prise en compte, du coup on sort et on se retrouve avec le shell du serveur:
    /sbin/reboot
    admin@wasabi:~$
  • On va maintenant travailler à partir d'une connexion ssh:
    admin@wasabi:~$ ssh admin@lxc-gitea
    ## accepter l'échange de clé
    admin@lxc-gitea's password: 
    Welcome to Alpine!
     
    The Alpine Wiki contains a large amount of how-to guides and general
    information about administrating Alpine systems.
    See <http://wiki.alpinelinux.org/>.
     
    You can setup the system with the command: setup-alpine
     
    You may change this message by editing /etc/motd.
    lxc-gitea:~$
  • On se positionne en root pour toutes les manip. à suivre (vous aurez droit au message de mise en garde à la première utilisation de sudo):
    lxc-gitea:~$ sudo -i
     
    We trust you have received the usual lecture from the local System
    Administrator. It usually boils down to these three things:
     
        #1) Respect the privacy of others.
        #2) Think before you type.
        #3) With great power comes great responsibility.
     
    [sudo] password for admin: 
    lxc-gitea:~# 

    Notez le changement de $ à #: on est bien administrateur dans notre container.

  • On fixe le fuseau horaire:
    lxc-gitea:~# setup-timezone -z Europe/Paris
  • On installe Gitea et ses dépendances. Le package existe pour notre version alpine dans le CT; on l'installe :
    lxc-gitea:~# apk add gitea
  • Gitea a besoin d'une base de donnée. On va utiliser notre service lxc-mariadb; il faut donc un clinet pour l'atteindre, qu'on installe avec:
    lxc-gitea:~# apk add mariadb-client

Maintenant, on va configurer tout cela.


3. Configuration

3.1. Base de données

Avec l'outil Adminer - Interface web SGBD, on peut faire les manip. Mais c'est plus simple ici – et surtout plus direct et sans copies d'écrans et explications plus ou moins limpides… 8-O. Donc «ligne de commandes».

On se connecte au CT lxc-mariadb (vous avez pas oublié vos login/password bien sûr!) et on crée la base de données dédiée et l'utilisateur gitea (mettez le mot de passe que vous voulez derrière 'IDENTIFIED BY …':

$ mysql -h lxc-mariadb -u admin -p
CREATE DATABASE `gitea` DEFAULT CHARACTER SET `utf8mb4` COLLATE `utf8mb4_unicode_ci`;
CREATE USER `gitea`@'lxc-gitea.lxc' IDENTIFIED BY 'gitea';
GRANT ALL PRIVILEGES ON `gitea`.* TO `gitea`@`lxc-gitea.lxc`;
FLUSH PRIVILEGES;

Touche q pour sortir.

On modifie dans le fichier /etc/gitea/app.ini, partie “base de données” comme suit:

nano /etc/gitea/app.ini
[database]
;DB_TYPE = sqlite3
;PATH = /var/lib/gitea/db/gitea.db
;SSL_MODE = disable
DB_TYPE  = mysql
HOST     = lxc-mariadb.lxc:3306 
NAME     = gitea
USER     = gitea
PASSWD   = gitea  ; <== adaptez !!

3.2. Service

Lancer le service Gitea, l'ajouter en démarrage automatique:

rc-service gitea start
rc-update add gitea

3.3. Réseaux

Gitea est un service http disponible sur le port 3000 par défaut. Selon la configurations de votre container, vous avez trois options:

3.3.1. Accès «NATé»

Dans la configuration ci-dessus, Gitea est prêt pour recevoir des requêtes depuis le réseau sur le port 3000. Mais il s'agit du réseau auquel il appartient, à savoir le réseau de containers LXC en 10.0.3.x.

Si l'on souhaite qu'il soit accessible sur le réseau local de votre installation, il va falloir que l'hôte expose un port sur le réseau via la commande iptables. Elle peut prendre les formes suivantes:

Ouvrir & fermer et Voir les @:ports NATés:

Terminal
## Ouvrir:
# sudo iptables -t nat -A PREROUTING -p tcp -i <interface> --dport <portHost> -j DNAT --to-destination <@IP:Port Destination>
sudo iptables -t nat -A PREROUTING -p tcp -i br0 --dport 63000 -j DNAT --to-destination 10.0.3.52:3000
 
## Fermer:
# sudo iptables -t nat -D PREROUTING -p tcp -i <interface> --dport <portHost> -j DNAT --to-destination <@IP:Port Destination>
sudo iptables -t nat -D PREROUTING -p tcp -i br0 --dport 63000 -j DNAT --to-destination 10.0.3.52:3000
 
## Listes / état:
sudo iptables -t nat -L
sudo iptables -t nat -S

3.3.2. Accès LAN

Si vous configurez votre container lxc-gitea de telle manière qu'il soit ouvert sur le LAN, vous pouvez l'atteindre avec une URL comportant son nom ou son adresse.

Si vous avez suivi le tuto sur l'installation / configuration Virtualisation - Containers LXC, il suffit de commenter pour qu le CT ailler sur votre box/routeur selon:

nano $(lxc-config lxc.lxcpath)/lxc-gitea/config
...
# Network configuration
lxc.net.0.type = veth
#lxc.net.0.link = lxcbr0  # <== Commenter réseau "privé" LXC
lxc.net.0.link = br0      # <== Dé-commenter Bridge LAN
lxc.net.0.flags = up
...

3.3.3. Accès «proxy»

C'est la cible dans le projet

Il s'agit donc, dans le fichier de configuration de Gitea, de remplacer l'URL locale par celle qu'on utilisera réellement dans le navigateur et qui passe par le proxy sur notre serveur (https://wasabi)

# nano /etc/gitea/app.ini
[ .. ]
;ROOT_URL         = http://localhost:3000/
ROOT_URL         = https://wasabi/gitea/
[ .. ]

Et dans le fichier de configuration du proxy ajouter le bloc de “routage” qui va bien:

host: $ ssh admin@lxc-proxy
lxc-proxy $ sudo -i
lxc-proxy # nano /etc/nginx/conf.d/lxc-proxy.conf
[ .. ]
    location /gitea/ {
        proxy_pass          http://lxc-gitea:3000/ ;
        include             includes/proxy.inc ;
        proxy_set_header    X-Forwarded-Prefix "/gitea";
     }
 
[ .. ]

4. Quelques compléments

☛ Démarrage avec l'hôte

Si vous souhaitez éviter de faire «à la main» le lancement du container après chaque arrêt/relance du serveur, il suffit de modifier la configuration du container en ajoutant ou dé-commentant les lignes suivantes en éditant le fichier de configuration du CT:

$ nano $(lxc-config lxc.lxcpath)/lxc-gitea/config
lxc.group = onboot
lxc.group = webserver
lxc.start.auto = 1

Pour autant que vous ayez suivi la partie “autostart:” dans la configuration des containers «non privilégiés»

☛ Données sur le RAID

Il peut-être intéressant de conserver les données des dépôts (c'est du git serveur en fait) dans la zone RAID et pas à l’intérieur du container. Ceci peut apporter de la simplicité dans les sauvegardes par exemple, sans avoir à manipuler le container (en faisant des snapshots ou bien une procédure de sauvegarde plus compliquée qui va «dedans»…). D’autant que la sauvegarde d'un container ne présente pas beaucoup d'intérêt, on peut toujours le re-construire assez vite…

Dans ce cas, et dès la création du container, on pourra s'inspirer de ce qui est proposer dans MariaDB - Serveur de base de données où les fichier des DATA sont «externalisés“.

☛ Accès distant et certificat auto-signe

Dans notre cas, le service est accessible via un proxy en HTTPS et certificat auto-signé.
Un dépôt est accessible avec l'URL : https://wasabi/gitea/<chemin du dépôt>.git

Si l'on a un client git sur une machine et que l'on veut cloner un dépôt Gitea, la commande standard est:

cram@cardamome:~/Projets/git$ git clone https://wasabi/gitea/<chemin du dépôt>.git

Mais dans ce cas, on a une erreur:

Clonage dans '<dépôt>'...
fatal: impossible d'accéder à 'https://wasabi/gitea/<chemin du dépôt>.git/' : server certificate verification failed. CAfile: none CRLfile: none

Pour «by-passer» cette erreur, la commande devient:

cram@cardamome:~/Projets/git$ git -c http.sslVerify=false clone https://wasabi/gitea/<chemin du dépôt>.git

Ce problème n'existe pas dans le cas où il s'agit de récupérer un dépôt sur la machine serveur qui héberge notre container lxc-gitea: on y accède directement en HTTP avec:

visto@wasabi:~/projets/git$ git clone http://lxc-gitea:3000/<chemin du dépôt>.git
Clonage dans '<dépôt>'...
remote: Enumerating objects: 43, done.
remote: Counting objects: 100% (43/43), done.
remote: Compressing objects: 100% (43/43), done.
remote: Total 43 (delta 17), reused 0 (delta 0), pack-reused 0
Réception d'objets: 100% (43/43), 20.42 Kio | 20.42 Mio/s, fait.
Résolution des deltas: 100% (17/17), fait.

services/web/tuto/git_tuto1.txt · Dernière modification: 16/01/2022 11:48 de Cram