Hello,
J'ai lu plusieurs tuto en francais et regardé plusieurs video et malgré tout ca il y a des choses que je ne comprends pas sur le fonctionnement de Git en général, des gitlab runner et des pipelines.
1) Déjà est-ce que le runner c'est un container Docker ou est-ce juste l'agent installé sur le serveur (par exemple le serveur web qui va recevoir une nouvelle livraison) et qui scrute le repo git (donc l'origine) en l'attente d'un push ?
Si c'est un container Docker où s'excute t'il ? Chez gitlab.com ou sur le serveur qui va recevoir la livraison ?
2) J'ai lu que le "script" ou les stages contenu dans le .gitlab-ci.yml s'éxécutent à chaque commit de code. Est-ce que ça veut dire que Gitlab indique à la machine d'où est partie le commit d’exécuter le contenu du .gitlab-ci.yml ?
3) Qu'est-ce qu'on appelle pipeline ? Est-ce un Job ? Un ensemble de Job strictement défini ? L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml ?
4) Si j'ai bien compris il ne peut y avoir qu'un seul .gitlab-ci-yml par branche git ?
Donc si j'ai 5 environnements différents (par ex LOCAL, TEST, DEV, STAGING, PROD) et que je veux un déploiement entièrement automatique et changer quelques détails en fonctione de l'environnement jusqu'en STAGING il faut que j'organise mon projet en 5 branches différentes avec chacune un fichier .gitlab-ci-yml ?
5) Qu'est-ce qui se passe à l'issue d'une merge request si par exemple je veux merger la branche STAGING vers la branche PROD ?
Est-ce que ma branche STAGING continue d'exister et son .gitlab-ci-yml reste inchangé? Ou disparait elle ? En d'autre termes est-ce qu'une MR c'est seulement le remplacement du contenu de ma branche PROD par celui de la branche STAGING par une sorte de rm -rf prod/
et cp -R STAGING/ PROD/ ?
Bon comme vous le voyez jj'ai pas tout compris et c'est un sacré sac de noeud dans ma tête donc svp n'hesitez pas à détailler vos explications.
Si y 'en a qui ont des schémas, des blogs ou des videos qui résument tout ça je suis preneur.
Merci de votre aide.
# Pioufff
Posté par MrBidon . Évalué à 1. Dernière modification le 21 février 2020 à 15:33.
Je ne suis pas expert pipeline gitlab mais on utilise ça depuis 2 ans dans l'équipe je peux déjà te donner des billes. Mais le mieux c'est qe tu te monte une VM et un projet de test type hello world pour voir si tu arrives à faire ce que tu veux, ça se fait assez vite.
non le runner n'est pas un container, j'ai pas trop testé ce mode, moi je l'utilise en mode shell dans ce cas ton process est éxécuté sur la machine où le runner est installé. ca me convient bien.
Non c'est l'inverse c'est gitlab qui déclanche l'utilisation du runner, par exemple, chez nous c'est configurer pour ne généré une release qu'à chaque tag.
oui
L'ensemble des jobs/tasks contenus dans le .gitlab-ci.yml en gros tu as une étape build / test / preprod / prod il y a même possibilité d'avoir un bouton pour basculer d'une étape à l'autre
Non, il faut que ton .gitlab-ci-yml gère toutes ces étapes les unes après les autres
C'est plutôt un comprégension de git qu'il te faut et non de gitlab, on a discuté d'un sujet similaire, il y a pas longtemps ici : https://linuxfr.org/forums/programmation-php/posts/branches-git
Bon courage :)
[^] # Re: Pioufff
Posté par Orwell . Évalué à 1.
Merci pour ta réponse.
Mais alors le runner est installé sur gitlab ? Sinon comment Gitlab peut il déclencher un traitement sur mon serveur s'il n'y a pas un agent sur le dit serveur qui est connecté en permanence à gitlab en attente d'instruction ?
D'accord mais dans ce cas y a t'il un instruction dans le .gitlab-ci-yml qui me permet dire que pour le step/stage PROD je veux approuver manuellement/explicitement le déploiement en PROD ?
Et d'ailleurs comment ce pipeline (.gitlab-ci-yml) a t'il connaissance de l'environnement sur lequel il s’exécute?
Est-ce que il s'exécute sur tous les serveurs quelques soit l'env et qu'il vérifie sur ces serveurs la valeur d'une variable et n'effectue réellement le traitement que si le test de la variable est vrai?
Un exemple de fichier .gitlab-ci-yml avec plusieurs env m'aiderait peut être à comprendre.
[^] # Re: Pioufff
Posté par MrBidon . Évalué à 1.
Le runner est enregistré dans gitlab, ainsi gitlab peut lancer les builds. Le plus simple pour comprendre est d'installer tout ça il s'agit de deux "deb". Je n'ai pas d'exemple à te donner pour l'instant, on est dans un mode très simple, au début j'avais mis en place le bouton de basculement d'un stade à l'autre. ca doit être expliquer dans la doc.
# à propos du gitlab-runner, tâches, container
Posté par Marc Quinton . Évalué à 2.
bonjour,
il est possible d'installer un gitlab-runner à peu prêt n'importe ou : réseau local, réseau public, … ; la seule contrainte que le gitlab-runner puisse se connecter à son serveur maitre : un serveur gitlab.
Dans la procédure d'installation, on créé un lien (avec des URL et des clés) entre un serveur Gitlab (public ou privé) et différentes instances de gitlab-runner. Suite a cette installation, tous les gitlab-runner sont esclaves et au service du serveur Gitlab. Ils sont en attente de tâches à exécuter. Il est possible d'associer des TAGs à un gitlab-runner ; le choix est totalement libre et dépend de ce qu'on veut faire :
builder, docker, shell, interne, public, shared, install.Pour ce qui concerne les tâches, elles sont décrites dans le format (gitlab-ci.yml)[https://docs.gitlab.com/ee/ci/yaml/]. C'est le fichier .gitlab-ci.yml placé à la racine du projet qui porte ces tâches. Ces fichiers décrivent des tâches composées d'actions (commandes bash). Via des TAGS, il est possible de faire un lien entre une tache et un gitlab-runner. On pourra par exemple sélectionner un gitlab-runner pour la partie compilation, test, création des binaires (Artifacts dans la terminologie Gitlab). Un gitlab-runner spécifique sera chargé de l'installation configuration des applications dans un environnement spécifique et en zone privée non accessible par le gitlab-runner principal.
Environnement d’exécution : il est possible au moment de l'installation du gitlab-runner de choisir le mode d'exécution : en container (
Docker, Virtualbox, …), enshell(s'apparente à duSSH), …L'avantage de l'environnement Docker est de pouvoir créer une instance de fabrication vierge qui n'aura d'existence que le temps de l’exécution des tâches liées au gitlab-ci.yml ; on peut choisir librement l'environnement d’exécution (basé sur Linux) :
debian (buster, stretch, ...), centos, archlinux… on peut aussi fabriquer des containers docker sur mesure ayant les caractéristiques voulue et les télécharger directement plutôt que de tout refabriquer systématiquement à chaque build. Cela permet de gagner du temps (machine) et bande passante (internet, réseau local).l’exécution en SHELL ne devrait être utilisé que pour des cas spécifiques : risque de scories suite à l’exécution d'une précédente tache.
[^] # Re: à propos du gitlab-runner, tâches, container
Posté par Orwell . Évalué à 1.
Merci Marc,
Là c'est un peu plus clair.
Ce que tu appelles le gitlab-runner principal c'est l'instance gitlab (giltlab server ou gitlab.com) qui contrôle les gitlab runner esclave n'est-ce pas ?
[^] # Re: à propos du gitlab-runner, tâches, container
Posté par Marc Quinton . Évalué à 2.
dans une entreprise, il peut y avoir plusieurs gitlab-runners :
- le principal, chargé du build et des taches les plus lourdes avec des capacités importantes pour gérer cette charge
- des runners secondaires plutot dédiés à la mise en place des applications sur des réseaux privés : dans ce cas, pas besoin de performances sur ces runners sauf si runner et applications tournent sur la meme machine, ce qui n'est pas une obligation.
[^] # Re: à propos du gitlab-runner, tâches, container
Posté par Orwell . Évalué à 1.
ok merci.
Dans ce cas comment indique t-on à un runner qu'il est le principal ou un secondaire ?
[^] # Re: à propos du gitlab-runner, tâches, container
Posté par NeoX . Évalué à 2. Dernière modification le 25 février 2020 à 13:21.
il l'a dit
il n'y a pas de runner maitre, c'est ton serveur/depot gitlab qui est maitre
et qui demande à un runner ou à un autre de travailler.
[^] # Re: à propos du gitlab-runner, tâches, container
Posté par Orwell . Évalué à 1.
Ok merci.
Désormais c'est tout à fait clair.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.