Déployer la wotmap par le CI/CD de Gitlab

docker
wotmap
gitlab
#1

Bonjour,
Cela fait plusieurs jours que je cherche à utiliser le CI/CD de notre Gitlab pour déployer automatiquement la wotmap lors des push via GIT et j’aurais besoin de vos avis éclairés. En effet, je ne suis pas un spécialiste de Docker et de Gilab-ci (même si je me suis tapé une grosse partie de la doc) et certaines de mes questions pourront vous paraître un peu naïves :wink:

Le script Python de la wotmap est lancé par CRON toutes les 24h pour :

  1. stopper le noeud duniter qui se trouve sur le même serveur que la wotmap
  2. l’interroger pour générer le JSON utilisé par SigmaJS
  3. Relancer le noeud Duniter

Quelle architecture utiliseriez-vous ? En effet, j’imagine que si je déploie une image Docker avec la wotmap à l’intérieur, le script Python ne pourra pas interroger le noeud qui se trouve sur la machine hôte. J’ai pensé aussi à déployer un docker-compose en suivant cette approche mais je galère. Je vois qu’@Elois utilise cette technique dans duniter-rs-ci mais je ne suis pas sûr de maîtriser tous les concepts induits par Docker et Gitlab-ci…

Je cherche donc des ressources (en français de préférence sinon en anglais) qui pourraient m’être utiles sinon quelqu’un pour m’aider à maîtriser ces concepts. Je suis prêt à faire un don ou à payer en monnaie libre car je pense que ça serait vraiment une valeur ajoutée dans mes compétences.

En vous remerciant par avance.

#2

La partie déploiement continue du site statique via un job GitLab est faisable.
C’est semblable à un GitLab Pages.

Par contre, la génération des données avec le script Python à partir d’un nœud Duniter synchronisé, ça c’est autre chose. Il faudrait avoir un nœud Duniter dans une instance Docker.

Je sais pas si réinstaller, synchroniser un nœud et lancer le script Python dans une instance Docker toutes les 24 heures soit la manière la plus élégante de faire les choses.

C’est un peu prendre un bazooka pour tuer un moustique. Tu as pas d’autres moyens d’avoir ces données générées d’une autre manière ?

Voilà des pistes, je te laisse réfléchir.

#3

Sinon, tu pourrais rendre disponible ces données accessibles sur le net qui serait mis à jour avant que le CD soit lancé.
Les téléchargées via cette URL depuis l’instance Docker et hop, c’est dans la boîte !

Par contre, je sais pas si c’est faisable de déployer automatiquement à telle heure comme un cron job.

Ça pourra être déclenché par une modification de ton code. Mais pour que ça soit déclenché toutes les 24h après que ton script ait mis à jour les données, faut lire la doc.

Cf la doc de .gitlab-ci.yml.

#4

En fait, ça n’a pas besoin de passer par une instance Docker, cf le site web de silkaj.

#5

Oui je crois que ça j’ai compris comment faire via une image Docker Apache ou Nginx.

C’est ce que j’en avais conclu en effet. Du coup, j’ai 2 questions : Peut-on monter un volume entre deux containers avec docker-compose, de manière à ce que le script python de la wotmap puisse interroger les data ? Et pour générer le JSON avec le script Python, celui-ci doit stopper le nœud, c’est possible qu’une instance Docker lance des commandes dans une autre ?

L’idée est bonne. Même sans les télécharger, cela devrait fonctionner puisque SigmaJS charge le JSON à partir d’une URL.

Dans ce cas, il faudrait que je découpe le projet en deux parties : la partie web et la partie python. Le script python serait sur la machine hôte avec le nœud duniter (ou dans une instance Docker de Duniter). De cette manière, la machine hôte (ou l’instance Docker de Duniter) pourrait servir le JSON sur sur une URL, comme c’est déjà le cas. Et la partie web (HTML, CSS et JS) serait déployée via CI/CD dans une autre instance Docker. Est-ce que cela vous semble pertinent ?

#6

J’ai du mal à comprendre ton .gitlab-ci.yml… Pourquoi deux jobs qui font exactement la même chose ? Et pourquoi juste un ls ? Quelle est son utilité ?

#7

Oui, bien vu, il fait deux fois la même chose.
Et le ls est a supprimé.
C’était pour comprendre où il se trouvait.

#8

@Pierre_Jean_CHANCELL qu’entend tu précisement par “interroger” le noeud duniter. Pourquoi a tu besoin de stopper le noeud duniter pour l’interroger ? Tu pioche directement dans la base de donnée sqlite ou leveldb ?

Si il pourra, il suffit de partager un volume avec le conteneur. Tu peut faire ça avec docker-compose :slight_smile:

Le lien que tu donne permet juste de créer une image docker contenant docker-compose pour pouvoir l’utiliser dans la Ci, ce n’est que la 1ère étape.
C’est drôle car vais justement avoir besoin d’une image docker avec docker-compose dedans, donc je pourra t’aider a le faire. Par contre ça te donne juste la possibilité d’utiliser la commande docker-compsoe dans tes job de CI/CD, toute la CI/CD reste a faire :stuck_out_tongue:
(nb: la solution que je te propose plus bas ne nécessite pas docker-compose car je pense que tu n’en a pas besoin en fait, comme dit moul c’est un peu prendre un semi-remorque pour aller chercher le pain).

En fait duniter-rs-ci est juste une image docker contenant tout ce qu’il faut pour éxécuter certains jobs de la CI/CD de durs, notamment la compilation et les tests. C’est donc juste la partie CI et pas la partie CD.

Tu peut ordonnacer une CI/CD gitlab : https://docs.gitlab.com/ce/user/project/pipelines/schedules.html
A ta place je ferai un job gitlab-page qui :

  • lance une sync duniter sans start le noeud
  • lance le script python
  • récupère le jspon
  • publie le site statique wotmap avec le bon json

Il te faudra exécuter ce job dans une image docker a toi qui contiendra tout les ingrédients nécessaires : duniter et python.
Le mieux est de basé ton image sur l’image docker de duniter déjà existante : https://hub.docker.com/r/fabwice/docker-duniter-ts

#9

Le script Python interroge la base leveldb de Duniter, c’est pour ça que le script stoppe le nœud avant d’en extraire les données.

Merci. Ça me prouve que j’avais bien compris le fonctionnement de Docker et docker-compose :slight_smile:

Tu me confortes encore une fois sur le fait que j’avais bien compris :slight_smile:

OK, je vais me renseigner sur le job gitlab-page que je ne connais pas et je ferai des essais.

Encore une fois, grâce à toi, je suis sûr d’avoir compris ! :slight_smile: Je ne savais pas quelle image de base prendre, voilà chose faite. Dès que j’aurai du temps, je pourrai tenter cette approche. Un grand merci @elois :wink:

#10

Encore une ou deux questions :

  • J’ai désactivé tous les runners pour le projet wotmap et j’ai activé le Runner que j’ai installé sur mon serveur. C’est bien ça qu’il faut faire pour que le déploiement se fasse sur mon serveur ?
    image
  • Je pense qu’une fois que mon image Docker sera construite, le mieux est de l’héberger sur le registry.duniter.org ?
#11

Non ton job peut s’éxécuter sur un runner situé sur n’importequel serveur, pas besoin que ce soit sur le serveur cible du déploiement :slight_smile:

Par contre concernant gitlab-page il me semble qu’il y a des limitations et que les sites statiques déployés par gitlab-pages sont hébergé sur le même serveur que le gitlal. En tout cas c’est comme ça que @1000i100 a configuré gitlab-pages sur notre gitlab, peut etre qu’il y a moyen de déployer sur un serveur distant mais ça je en sais pas du tout, c’est une partie que je n’ai encore jamais exploré.

Oui tout a fait. Si c’est une image seulement dédiée a ta CI/CD (ce qui est le cas concernant la solution que je t’ai proposé) ça n’est pas utile de pousser l’image sur d’autres registry.

#12

@Pierre_Jean_CHANCELL il te faudra reset l’ENTRYPOINT car tu n’en a pas besoin dans une image déstinée a un runner de CI/CD : https://github.com/moby/moby/issues/3465#issuecomment-47598629

#13

Je ne sais pas non-plus, je pense que ça doit être possible en bataillant un peu, et je pense qu’on y gagnerais beaucoup en disponibilité des sites déployé via gitlab-pages.

Je rajoute dans un coin de mon backlog personnel d’y regarder, mais je ne sais pas quand ça montera suffisamment haut dans les priorité pour que je m’en occupe, je n’en prendrais aucun ombrage si quelqu’un y regarde avant moi :wink: