Duniter indexer CI

C’est un souci de conf du noyau qui ne permet pas de faire tourner des binaires d’architectures différentes via qemu.

Je n’ai pas la main sur mmicro. Nous dépendons de nos hégerdeurs.

Les runners sont tagués pour une bonne raison. Le runner podman est tagué podman. Les runners basés sur Docker devraient être tagués docker. Si la CI de l’indexer nécessite un runner Docker elle doit le spécifier dans son fichier .gitlab-ci.yaml.

La période actuelle n’est pas celle où je suis le plus disponible. Je ne décroche pas, j’ai juste moins de temps pour geeker.

EDIT : En regardant la liste des jobs de la CI duniter-indexer je constate que tous les jobs récents (réussis ou en échec) ont tourné sur un runner tagué dind. Je ne vois donc pas de rapport avec le runner podman que j’ai mis en place.

plait-il ? :joy:

Message SMS de Pedrito :

Bonjour Hugo
Je suis assez peu dispo ces temps ci.
L’infra est maintenue par moi même et Cid. Par contre l’admin sys est faite par Pini et / ou Poka.
Je vais répondre au post que tu viens de faire d’ici ce soir.

Ma sollicitation première allait dans le sens de l’infra mais pas seulement.
En effet, j’étais en contact avec Poka et plus du tout de réponse. Sais tu s’il va bien? Si je peux faire qqch pour lui?

L’admin sys ne peut pas être faite par quelqu’un qui n’est pas au courant et n’a pas la main, ça ne marchera pas :confused:
@poka ne répond plus, il n’a pas la forme en ce moment, mais il ne semble pas que l’on puisse y faire grand chose. Il faudrait quand même qu’on sache qui s’occupe de quel runner et quels runners ne sont pas administrés. C’était le but du recensement Infrastructure de l'écosytème Duniter mais il n’est pas fini.

Pas de rapport avec le runner podman ici (il est utile pour duniter-v2s mais pas pour duniter-indexer pour l’instant). Il s’agit du runner axiom-team-ci-privileged-dind, c’est, je pense, celui indiqué dans le recensement :

2 Likes

@HugoTrentesaux : Ça y est j’ai un peu de temps pour jeter un oeil. As-tu un job sous la main que je pourrais relancer plusieurs fois afin de comprendre ce qu’il se passe ?

J’ai compris ce qu’il se passe : le runner n’a pas les droits pour lancer Docker en mode privileged:

gitlab-runner@runner-ci:~$ docker run --rm -it debian
root@f84c69a21960:/# 
exit
gitlab-runner@runner-ci:~$ docker run --rm -it --privileged debian
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to apply caps: operation not permitted: unknown.
ERRO[0000] error waiting for container: context canceled 

@Cid_Ragarock : voici ce que j’ai trouvé sur le sujet : Docker inside LXC starting container process caused "apply caps: operation not permitted" - Server Fault.

EDIT : J’ai désactivé le runner axiom-team-ci-privileged-dind en attendant que ce soit résolu.

1 Like

@HugoTrentesaux

L’admin sys ne peut pas être faite par quelqu’un qui n’est pas au courant et n’a pas la main, ça ne marchera pas :confused:

Je ne suis pas sur de comprendre. Que veux tu donc dire stp?
Il est prévu depuis le début que nous mettions à disposition la partie infra nécessaire à Axiom. Nous apportons notre concours en maintenant cette infra.
Nous ne sommes pas à même de maintenir les services afférents, cela me semblait être clair.
“La main” avait été donné à @poka? @Pini veux tu prendre le relai?

@Pini

J’ai compris ce qu’il se passe : le runner n’a pas les droits pour lancer Docker en mode privileged:

Nous avions lors de la bascule des services avec @poka adapté les droits mais cela rejoint ce que demandais @Cid_Ragarock plus haut. Il y a encore un peu d’adaptation à faire à ce niveau, sachant que nous voudrions éviter les failles de sécurité.

2 Likes

Oui je veux bien. Merci.

2 Likes

OK pour moi.
On s’organise sur Element.

1 Like

On a fait quelques tests avec @Pedrito, non concluants jusque là : il n’est toujours pas possible de lancer un docker en mode privileged sur notre VM runner-ci hébergée sur la machine mmicro.

De mon côté j’ai testé le build de duniter-indexer avec podman, et ça semble passer modulo quelques changements au fichier .gitlab-ci.yaml. En revanche ces modifications ne sont pas compatibles avec Docker. Donc la CI peut fonctionner soit sur runner docker, soit sur runner podman, mais pas sur les deux.

1 Like

Maintenant que j’ai la main sur la VM de test je viens de configurer un nouveau runner.

Quelqu’un peut-il tester ? Je ne promets pas que ça marche du premier coup.

1 Like

J’avais pas eu le temps de tester ton nouveau runner, mais je vais avoir besoin de publier une nouvelle image pour l’indexeur, donc c’est le bon moment pour tester !

[edit] la pipeline fonctionne sur le nouveau runner : deploy_docker_duniter_indexer (#120186) · Jobs · nodes / duniter-indexer · GitLab
mais comment récupérer l’image docker ? On pourrait utiliser le registry GitLab comme proposait @Moul
Ou alors il faut activer la publication sur https://hub.docker.com/r/duniter/duniter-indexer, est-ce qu’il suffit de dé-commenter les lignes commentées @Pini ?

Ce runner est obsolète. Utilise kepler-pipglr à la place.

Désolé pas très réactif ces temps ci car je suis bien occupé à migrer les services de mon assoce vers une autre machine suite à un disuqe dur défaillant.

@HugoTrentesaux, si tu as une idée de priorisation sur ce dont tu as besoin et qui dépends de moi, n’hésite pas à me pinguer en direct.

1 Like

Ok, merci pour l’info du runner. Prend ton temps pour ton assoce (de musique ?), si tu veux je peux te maintenir une liste des tâches prioritaires qui pourraient te convenir :slight_smile:

Oui.

C’est bien à un truc de ce genre que je pensais. Mais en direct car si c’est dispersé dans plusieurs fils de discussion c’est compliqué à retrouver.

1 Like

Ou plutôt à un seul endroit, parce que en direct les autres ne seront pas forcément au courant et nous risquons de nous marcher sur les pieds.

Et faisons le lien avec cet autre fil : Démarrez votre indexeur (tutoriel) - #6 by cgeek, car j’y mentionne le ticket #144 et le fait qu’un build arm64 serait aussi le bienvenu.

2 Likes

J’avais compris que tu utilisais un runner que j’avais mis en place sur une VM de test de l’infra mmicro. Ce runner est hors ligne depuis 2 mois, et je n’arrive plus à accéder à la VM de test ni à l’infra proxmox de mmicro.

Mais en fait tu utilises bien kepler-pipglr. Et tu as cherry-picked pour ça mes commits sur la branche pini-test.

Ce mystère étant résolu, j’imagine qu’il reste à :

  • Mettre ça au propre
  • Ajouter un job de publication d’image
  • Permettre un build multi plateformes amd64 + arm64

D’autres choses ?

Ce serait chouette d’expliquer ce que font les 12 runners visibles par les admins gitlab sur https://git.duniter.org/admin/runners dans le sujet Infrastructure de l'écosytème Duniter. Ça permettrait de visibiliser ces contributions en public.

  • mettre au propre → oui, vu l’historique de galère de elois et manu lors du hackathon de Bordeaux j’ai l’impression que ça pourrait faire un grand bien !
  • ajouter un job de publication d’image → il me semble qu’il y en avait déjà un déclenché sur master, j’avais juste publié une image sur ma branche comme version de travail
  • build multiplateforme → oui, c’est ce que demandait cgeek et ça servira aux gens qui feront tourner sous arm

Avec ça, ça me semble bon. Au moins ça permettrait d’avoir plus d’instances de l’indexeur en attendant qu’on décide ce qu’on fait par rapport à squid (pour l’instant ça me bien mieux d’avoir les deux).

A post was merged into an existing topic: Gitlab-runner CI

J’ai mis à jour ma branche pinit-test. Il ne m’est pas possible de tester l’upload de l’image puisqu’il faut pour ça être sur la branche master.

Je ne crois pas que ça gêne beaucoup si on teste cette étape en direct sur master après avoir mergé.
=> MR !18 .

1 Like

C’est bon :tada: ! Les utilisateurs de l’indexeur vont pouvoir utiliser l’image docker sur le dockerhub de duniter : https://hub.docker.com/r/duniter/duniter-indexer/tags.

2 Likes