Diffusion continue de votre solution InterSystems à l'aide de GitLab - Partie V : Pourquoi 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 les 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 cet article, nous parlerons des conteneurs et de la manière dont ils peuvent être utilisés (et pour quelles raisons).

Cet article est basé sur une connaissance des concepts de docker et de conteneur. Consultez les articles suivants de  @Luca Ravazzolo si vous voulez en savoir plus sur les conteneurs et sur les images.

Les avantages

L'utilisation de conteneurs présente de nombreux avantages :

• Portabilité
• Efficacité
• Isolement
• Poids léger
• Immuabilité

Examinons-les en détail.

Portabilité

Un conteneur contient une application avec tous les éléments dont elle a besoin pour fonctionner, comme les fichiers de configuration et les dépendances. Cela vous permet d'exécuter facilement et de manière fiable des applications dans différents environnements tels que votre bureau local, des serveurs physiques, des serveurs virtuels, des environnements de test, d'essai, de production et des nuages publics ou privés.

Un autre aspect de la portabilité réside dans le fait qu'une fois que vous avez construit votre image Docker et vérifié qu'elle fonctionne correctement, elle peut fonctionner partout où Docker fonctionne, c'est-à-dire sur les serveurs Windows, Linux et MacOS actuels.

Efficacité

En fait, vous n'avez besoin que votre processus d'application fera pas fonctionner tous les logiciels du système, etc. C'est exactement ce que permettent les conteneurs : ils n'exécutent que les processus dont vous avez explicitement besoin, et rien d'autre. Puisque les conteneurs ne nécessitent pas de système d'exploitation distinct, ils utilisent moins de ressources. Alors que les VM mesurent souvent jusqu'à plusieurs gigaoctets, les conteneurs ne mesurent normalement que quelques centaines de mégaoctets, ce qui permet de faire fonctionner beaucoup plus de conteneurs que de VM sur un seul serveur. Comme les conteneurs ont un niveau d'utilisation plus élevé en ce qui concerne le matériel sous-jacent, vous avez besoin de moins de matériel, ce qui entraîne une réduction des coûts du métal nu (bare metal) ainsi que des coûts du centre de données.

Isolement

Les conteneurs isolent votre application de tout le reste, et si plusieurs conteneurs peuvent fonctionner sur le même serveur, ils peuvent être complètement indépendants les uns des autres. Toute interaction entre les conteneurs doit être explicitement déclarée en tant que telle. Si un conteneur tombe en panne, il n'affecte pas les autres et peut être redémarré rapidement. Cette isolation est également bénéfique pour la sécurité. Par exemple, la vulnérabilité d'un serveur web exploité sur "bare metal" peut potentiellement permettre à un hacker d'accéder à l'ensemble du serveur, mais dans le cas des conteneurs, le hacker n'aura accès qu'au conteneur du serveur web.

Poids léger

Puisque les conteneurs ne nécessitent pas d'OS séparé, ils peuvent être démarrés, arrêtés ou redémarrés en quelques secondes, ce qui accélère tous les processus de développement associés et le temps de mise en production. Vous pouvez commencer à travailler immédiatement et ne pas perdre de temps à la configuration. 

Immuabilité

L'infrastructure immuable est constituée de composants immuables qui sont remplacés à chaque déploiement, au lieu d'être mis à jour sur place. Ces composants sont lancés à partir d'une image commune qui est créée une fois par déploiement et qui peut être testée et validée. L'immuabilité réduit les incohérences et permet de répliquer et de passer facilement d'un état à l'autre de votre application. Ces composants sont lancés à partir d'une image commune qui est créée une fois par déploiement et qui peut être testée et validée. L'immuabilité réduit les incohérences et permet de répliquer et de passer facilement d'un état à l'autre de votre application. Plus d'informations sur l' immuabilité.

Nouvelles possibilités

Tous ces avantages nous permettent de gérer notre infrastructure et notre flux de travail d'une manière entièrement nouvelle.

Orchestration

Les environnements "bare metal" ou "VM" posent un problème : ils sont individualisés , ce qui entraîne de nombreuses surprises, généralement désagréables, à l'avenir. La réponse à cette question est Infrastructure as Code (Infrastructure en tant que code) - gestion de l'infrastructure dans un modèle descriptif, en utilisant les mêmes versions que celles utilisées par l'équipe DevOps pour le code source.

Avec "Infrastructure as Code", une commande de déploiement place toujours l'environnement cible dans la même configuration, quel que soit l'état de départ de l'environnement. Pour ce faire, il faut soit configurer automatiquement une cible existante, soit supprimer la cible existante et recréer un nouvel environnement.

Ainsi, avec l'"Infrastructure as Code", les équipes apportent des modifications à la description de l'environnement et à la version du modèle de configuration, qui se présente généralement sous la forme d'un code bien documenté, tel que JSON. Le pipeline de mise en production exécute le modèle pour configurer les environnements cibles. Si l'équipe doit apporter des modifications, elle modifie la source, pas la cible.

Avec les conteneurs, tout cela est possible et beaucoup plus facile à réaliser. L'arrêt d'un conteneur et le démarrage d'un autre prennent quelques secondes, tandis que la fourniture d'une nouvelle machine virtuelle prend quelques minutes. Et je ne parle même pas du retour d'un serveur à un état propre.

Mise à l'échelle

D'après ce qui précède, on peut penser que l'infrastructure en tant que code ("infrastructure as code") est statique par nature. Ce n'est pas le cas, car les outils d'orchestration peuvent également assurer une mise à l'échelle horizontale (provisionnement d'une plus grande quantité de données identiques) sur la base de la charge de travail actuelle. Il ne faut exécuter que ce qui est actuellement nécessaire et faire évoluer l'application en conséquence. Cela peut également réduire les coûts.

Conclusion

Les conteneurs peuvent optimiser votre pipeline de développement. L'élimination des incohérences entre les environnements facilite les tests et le débogage. L'orchestration vous permet de créer des applications évolutives.  Le déploiement ou le rollback à n'importe quel point de l'historique immuable est possible et facile.

Les organisations veulent travailler à un niveau plus élevé où tous les problèmes énumérés ci-dessus sont déjà résolus et où nous trouvons des planificateurs et des orchestrateurs qui gèrent plus de choses de manière automatisée pour nous.