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, ...), en shell (s'apparente à du SSH), ...
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.
# à propos du gitlab-runner, tâches, container
Posté par Marc Quinton . En réponse au message Fonctionnement des Gitlab runner et pipeline. É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.