Suite des migrations – nextcloud et subversion

Nextcloud

Mon installation nextcloud actuelle dispose d’un grand nombre de fichiers (environ 100Go) mais aussi des carnets d’adresses, des agendas, des partages externes, des applications complémentaires… Bref une installation complète. J’ai deux options principales pour la migration de cette instance :

• je peux choisir de créer un container proxmox dédié et migrer mon nextcloud existant vers ce nouveau serveur
• je peux migrer vers Nextcloud AIO qui est en fait une image docker optimisée

L’image Nextcloud AIO présente l’avantage de la maintenance simplifiée. Tous les choix d’optimisation ont été effectués et la montée de version est à priori simplifiée. Néanmoins je ne sais pas comment les agendas et contacts sont stockés dans le répertoire de données et j’ai donc préféré l’option du container PVE dédié à Nextcloud.

Au final les étapes de migration ont été les suivantes :

• création d’un utilisateur et d’une base mysql dédiée à Nextcloud
• recopie (via rsync) de mon répertoire /var/www/nextcloud depuis l’ancien serveur vers le nouveau – cette opération a été très longue du fait de la bande passante limitée sur l’offre Kimsufi d’OVH
• adaptation du fichier de configuration de Nextcloud (paramétrage de la base de données notamment)
• paramétrage du serveur Apache et ajout des modules PHP nécessaires à nextcloud
• création d’un fichier de configuration pour Traefik
• vérification que tout fonctionnait correctement !

Une fois la migration réussie j’en ai profité pour améliorer le nextcloud en ajoutant le redis. Le paramétrage d’onlyoffice a été un peu compliqué car il tourne à présent sous docker et il a fallu ajouter le paramétrage IP dans le fichier /etc/host du container pour que tout fonctionne comme attendu.

Subversion

J’avais conservé sur un bout de serveur quelques repository subversion. L’avantage de subversion c’est que ça se paramètre facilement avec le serveur Apache… Mais bon c’est plus vraiment le gestionnaire de version que j’utilise au quotidien et donc une migration vers Git me semblait utile. Là encore il y avait plusieurs options :

• faire un simple serveur Git que ça soit en http ou ssh
• installer une vraie forge logicielle telle que Gitlab

J’ai donc commencé par faire un petit sourcing des forges logicielles. Gitlab était effectivement une option possible – d’autant que je l’utilise au quotidien dans mon cadre professionnel – mais ça me semblait un peu overkill… Lors de mes recherches je suis tombé sur Gitea qui semblait léger et facile à héberger (via une image docker notamment). Cela valait le coup de tester !

Au final l’installation s’est réduite à la création d’un fichier docker-compose avec tout de même quelques subtilités par rapport aux précédents :

services:
  gitea:
    image: gitea/gitea:${GITEA_IMAGE_TAG}
    container_name: gitea
    restart: always
    env_file:
      - .env.production
    networks:
      - giteanet
      - proxy
    extra_hosts:
      - "mariadb.local:192.168.6.2"
      - "smtp.zeguigui.com:192.168.6.5"
      - "redis:192.168.6.1"
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.gitea.rule=Host(`${TRAEFIK_HOST}`)"
      - "traefik.http.routers.gitea.entrypoints=websecure"
      - "traefik.http.routers.gitea.tls.certresolver=certresolver"
      - "traefik.http.routers.gitea.tls.domains[0].main=*.zeguigui.com"
      - "traefik.http.routers.gitea.service=gitea-srv"
      - "traefik.http.services.gitea-srv.loadbalancer.server.port=3000"
      - "traefik.tcp.routers.gitea-ssh.rule=HostSNI(`*`)"
      - "traefik.tcp.routers.gitea-ssh.entrypoints=gitssh"
      - "traefik.tcp.routers.gitea-ssh.service=gitea-ssh"
      - "traefik.tcp.services.gitea-ssh.loadbalancer.server.port=22"

networks:
  proxy:
    external: true
  giteanet:
    name: "giteanet"

Je voulais utiliser des remote en SSH avec Gitea. Pour cela il faut pouvoir se connecter en SSH. J’ai donc créer un entrypoint dans ma configuration Traefik et je redirige ce port vers le port SSH du container Gitea. La règle HostSNI est quant à elle obligatoire pour avoir une redirection systématique, le protocole SSH n’indiquant pas le nom de la machine à joindre.

L’import des repository SVN vers Gitea est à présent très simple :

• utilisation de git svn pour convertir le repository subversion en repository git
• création d’un projet dans Gitea
• ajout du remote dans le repository converti
• envoi via git push

Et j’en ai même profité pour mettre dans Git l’ensemble des fichiers de configuration pour mon instance docker

Lors de la migration du webmail j’ai eu besoin de faire de la CI/CD avec Gitea. Cela implique d’avoir des runners pour lancer les jobs dans Gitea. On peut arriver à ce résultat :

• en ajoutant le runner (ou les si on veut !) dans le docker file
• et en suivant la procédure d’enregistrement des runners de Gitea

Attention il faut que le runner attende que Gitea soit up pour s’enregistrer auprès de lui, sinon le démarrage du container échoue. Pour cela on va ajouter une sonde de bon fonctionnement à gitea :

services:
  gitea:
    healthcheck:
      test: curl --fail http://localhost:3000 || exit 1
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 1m

et on ajoute un service pour le runner :

services:
  runner:
    image: gitea/act_runner:${RUNNER_IMAGE_TAG}
    container_name: runner
    environment:
      CONFIG_FILE: /config.yaml
      GITEA_INSTANCE_URL: http://gitea:3000/
      GITEA_RUNNER_REGISTRATION_TOKEN: ${GITEA_RUNNER_REGISTRATION_TOKEN}
      GITEA_RUNNER_NAME: runner1
      GITEA_RUNNER_LABELS: ${GITEA_RUNNER_LABELS}
    depends_on:
      gitea:
        condition: service_healthy
    ports:
      - 6000:6000
    volumes:
      - ./conf/config.yaml:/config.yaml
      - ./data/runner:/data
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - giteanet

Le runner tourne sur le réseau de Gitea ce qui lui permet de communiquer avec lui sur son port 3000. On indique bien qu’on désire attendre que gitea soit healthy avant de démarrer. Attention le runner doit pouvoir lancer lui-même des processus docker il doit donc avoir accès au docker.sock !

J’ai modifié également le GITEA_RUNNER_LABELS pour pouvoir utiliser l’image cth-ubuntu-latest:docker://catthehacker/ubuntu:act-latest qui me permet de construire des images docker.

Au final c’est totalement disproportionné pour simplement remplacer un serveur subversion. Néanmoins je suis passé d’un mode ou je n’utilisais plus du tout SVN pour un service Git totalement fonctionnel et qui me rend service au quotidien, cela valait donc le coup d’installer Gitea qui est totalement adapté à mon usage mono-utilisateur qui souhaite s’auto-héberger !