Diffusion continue de votre solution InterSystems à l'aide de GitLab - Partie VI : Infrastructure des conteneurs

Dans cette série d'articles, j'aimerais présenter et discuter de plusieurs approches possibles pour le développement de logiciels avec les technologies d'InterSystems et GitLab. J'aborderai des sujets tels que:

• Git 101
• Flux Git (processus de développement)
• Installation de GitLab
• Flux de travail GitLab
• Diffusion continue
• Installation et configuration de GitLab
• GitLab CI/CD
• Pourquoi des conteneurs?
• Infrastructure de conteneurs
• GitLab CI/CD utilisant des conteneurs

Dans le premier article, nous avons évoqué les notions de base de Git, les raisons pour lesquelles une compréhension approfondie des concepts de Git est importante pour le développement de logiciels modernes et la manière dont Git peut être utilisé pour développer des logiciels.

Dans le deuxième article, nous avons évoqué le flux de travail GitLab - un processus complet du cycle de vie du logiciel ainsi que Diffusion continue.

Dans le troisième article, nous avons évoqué l'installation et la configuration de GitLab et la connexion de vos environnements à GitLab

Dans le quatrième article, nous avons écrit une configuration de CD.

Dans le cinquième article, nous avons parlé des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

Dans cet article, nous allons discuter des principaux composants dont vous aurez besoin pour exécuter un pipeline de diffusion continue avec des conteneurs et de la façon dont ils fonctionnent tous ensemble.

Notre configuration se présente comme suit :

On voit ici la répartition des trois étapes principales :

• Construction
• Expédition
• Exécution

Build

Dans les parties précédentes, la construction (build) était souvent incrémentale - nous calculions la différence entre l'environnement actuel et la base de code actuelle et modifiions notre environnement pour qu'il corresponde à la base de code. Avec les conteneurs, chaque build est un build complet. Le résultat du build est une image qui peut être exécutée n'importe où, sans dépendances.

Expédition

Une fois que notre image est construite et qu'elle a passé les tests, elle est téléchargée dans le registre - serveur spécialisé pour héberger les images docker. Elle peut alors remplacer l'image précédente ayant la même balise. Par exemple, suite à un nouveau commit dans la branche master, nous avons construit la nouvelle image (projet/version:master) et si les tests sont positifs, nous pouvons remplacer l'image dans le registre par une nouvelle sous la même balise, de sorte que tous ceux qui extraient le projet/version:master obtiendront une nouvelle version.

Exécution

Les images sont enfin déployées. Bien qu'une solution de CI telle que GitLab puisse contrôler ou un orchestrateur spécialisé, l'objectif est le même : certaines images sont exécutées, leur état est vérifié périodiquement et elles sont mises à jour si une nouvelle version de l'image est disponible.

Consultez le webinar de docker expliquant ces différentes étapes.

Ou encore, du point de vue du commit :

Dans notre configuration de diffusion, nous allons:

• Introduire le code dans le référentiel GitLab
• Construire l'image docker
• Tester cette image
• Publier l'image dans notre registre docker
• Remplacer l'ancien conteneur par la nouvelle version à partir du registre

P

• Docker
• Registre Docker
• Domaine enregistré (facultatif mais préférable)
• Outils graphique GUI (facultatif)

 

Docker

Tout d'abord, il faut lancer docker quelque part. Je recommanderais de commencer par un serveur équipé d'une version plus courante de Linux, comme Ubuntu, RHEL ou Suse. N'utilisez pas de distributions orientées cloud comme CoreOS, RancherOS, etc. - elles ne sont pas adaptées aux débutants. N'oubliez pas de remplacer le pilote de stockage par devicemapper. 

Si nous parlons de déploiements importants, l'utilisation d'outils d'orchestration de conteneurs comme Kubernetes, Rancher ou Swarm peut automatiser la plupart des tâches, mais nous n'allons pas en discuter (du moins dans cette partie).

 

Registre Docker

Il s'agit d'un premier conteneur que nous devons exécuter, et c'est une application côté serveur évolutive sans état qui stocke les images Docker et vous permet de les distribuer.
Vous devriez utiliser le Registre si vous voulez :

•  contrôler rigoureusement l'endroit où vos images sont stockées
•  être pleinement propriétaire de son pipeline de distribution d'images
•  intégrer rigoureusement le stockage et la distribution d'images dans votre flux de travail de développement interne

Voici la Documentation de Registre.

Connexion du registre et de GitLab

Remarque: GitLab contient un registre intégré. Vous pouvez l'exécuter à la place du registre externe. Lisez les documents GitLab liés dans ce paragraphe.

Pour connecter votre registre à GitLab, il vous faudra exécuter votre registre avec le support HTTPS  - j'utilise Let's Encrypt pour obtenir des certificats, et j'ai suivi ce Gist pour obtenir des certificats et les introduire dans un conteneur. Après avoir vérifié que le registre est disponible en HTTPS (vous pouvez le vérifier depuis votre navigateur), suivez ces instructions pour connecter le registre à GitLab.  Ces instructions varient en fonction de vos besoins et de votre installation de GitLab, dans mon cas la configuration consistait à ajouter le certificat et la clé du registre (correctement nommés et avec les permissions correctes) à /etc/gitlab/ssl, et ces lignes à /etc/gitlab/gitlab.rb:

registry_external_url 'https://docker.domain.com'
gitlab_rails['registry_api_url'] = "https://docker.domain.com"

Après la reconfiguration de GitLab, j'ai pu voir un nouvel onglet Registry dans lequel se trouvent les informations sur la manière de marquer correctement les images nouvellement construites, de sorte qu'elles apparaissent ici.

 

Domaine

Dans notre configuration de diffusion continue, nous construirons automatiquement une image par branche et si l'image passe les tests alors nous la publierons dans le registre et l'exécuterons automatiquement, ainsi notre application sera automatiquement disponible dans tous les " états ", par exemple, auxquels nous pouvons accéder :

• Plusieurs branches de fonctionnalités disponibles à <featureName>.docker.domain.com
• Version test disponible à master.docker.domain.com
• Version préprod disponible à preprod.docker.domain.com
• Version prod disponible à prod.docker.domain.com

Pour ce faire, il nous faut disposer d'un nom de domaine et ajouter un enregistrement DNS de type wildcard qui renvoie *.docker.domain.com vers l'adresse IP de docker.domain.com. Or vous pouvez utiliser des ports différents.

Proxy Nginx

Comme nous avons plusieurs branches de fonctionnalités, nous devons rediriger automatiquement les sous-domaines vers le conteneur approprié. Pour ce faire, nous pouvons utiliser Nginx comme un proxy inverse. Voici un guide.

Outils graphique GUI

Pour commencer l'utilisation des conteneurs, vous pouvez utiliser la ligne de commande ou l'une des interfaces graphiques GUI. Il en existe de nombreux, par exemple :

• Rancher
• MicroBadger
• Portainer
• Simple Docker UI
• ...

Ils vous permettent de créer des conteneurs et de les gérer à partir de l'interface graphique GUI  au lieu de l'interface de commande (CLI). Voici à quoi ressemble Rancher :

 

Système d'exécution de GitLab

Comme précédemment, pour exécuter des scripts sur d'autres serveurs, nous devons installer le système d'exécution de GitLab. J'en ai parlé dans le troisième article.

Notez que vous devrez utiliser l'exécuteur Shell au lieu de l'exécuteur Docker. L'exécuteur Docker est utilisé lorsque vous avez besoin de quelque chose à l'intérieur de l'image, par exemple vous construisez une application Android dans un conteneur Java et vous n'avez besoin que d'une apk. Dans notre cas, il nous faut un conteneur complet et pour cela nous avons besoin de l'exécuteur Shell.

 

Conclusion

Il est facile de commencer à utiliser des conteneurs et il existe de nombreux outils à choisir.

La diffusion continue utilisant des conteneurs diffère de la configuration habituelle de la diffusion continue à plusieurs égards :

• Les dépendances sont satisfaites au moment de la construction et une fois l'image construite, il n'est plus nécessaire de se soucier des dépendances.
• Reproductibilité - vous pouvez reproduire facilement un environnement existant en utilisant localement le même conteneur.
• Rapidité - comme les conteneurs ne contiennent rien d'autre que ce que vous avez explicitement ajouté, ils peuvent être construits plus rapidement et, surtout, ils sont construits une seule fois et utilisés à tout moment.
• Efficacité - comme ci-dessus, les conteneurs génèrent moins de frais généraux par rapport, par exemple, aux VMs.
• Évolutivité - grâce aux outils d'orchestration, vous pouvez automatiquement adapter votre application à la charge de travail et ne consommer que les ressources dont vous avez besoin dans l'immédiat.