Présentation Docker

Nous allons tout le long de la présentation travailler dans un cotexte d'un système Linux Ubuntu 20.04.
Pour les besoins d'accès aux droits administrateur nous utiliserons VirtualBox. (Nous pourrions aussi utiliser Docker à partir de Windows 10 professionnel ou MacOs Hieght Serra)

Donc l'environnement une machine virtuelle Linux Ubuntu 20.04 LTS dans VirtualBox, ceci nous montrera par la même occasion la différence, concrètement, entre VM et Conteneur

Avant d'envisager l'installation de Docker, commençons par comprendre les problèmes que la technologie Docker vise à résoudre.

Le problème du développeur : 'ça marche sur ma machine' mais 'en production j'ai un soucis'

Ceci est dû à plusieurs facteurs:

• L'environnement système de développement n'est pas identique à celui de production

• Les versions des outils, logiciels de bases, intergiciels, les librairies dynamiques, etc.. peuvent être différents

• Les permissions des fichiers

• Les adresses réseaux, les conflits de ports

• etc....

• 
  

Tout cela arrive à son paroxysme lorsqu'il est temps pour un développeur de déployer son code sur l'hôte, et cela ne fonctionne pas. Alors, l'environnement de production doit-il être configuré pour correspondre à la machine du développeur, ou les développeurs ne doivent-ils faire leur travail que dans des environnements qui correspondent à ceux utilisés en production ?

Dans un monde idéal, tout devrait être cohérent, de l'ordinateur portable du développeur jusqu'à vos serveurs de production ; cependant, cette utopie a traditionnellement été difficile à réaliser. Chacun a sa façon de travailler et ses propres préférences personnelles. Il est déjà assez difficile d'assurer la cohérence entre plusieurs plates-formes lorsqu'un seul ingénieur travaille sur les systèmes, sans parler d'une équipe d'ingénieurs travaillant avec une équipe de centaines de développeurs.

La solution Docker (développeur)

Pour les développeur

En utilisant Docker pour Mac, Docker pour Windows ou pour Linux, un développeur peut rapidement encapsuler son code dans un conteneur qu'il a lui-même défini ou créé en tant que Dockerfile pour représenter un environnement complet cohérent identique partout. Le développeur aura toutefois besoin de compétences d'un administrateur système ou d'une équipe d'exploitation, nous y reviendrons.

Ainsi les programmeurs peuvent continuer à utiliser l'environnement de développement intégré (IDE) de leur choix et maintenir leurs flux de travail lorsqu'ils travaillent avec le code. Comme nous le verrons dans les prochaines pages, installer et utiliser Docker n'est pas difficile ; Considérant à quel point il était difficile de maintenir des environnements cohérents, même avec l'automatisation, Docker semble un peu trop facile!.

Le problème pour les opérationnels

Supposons que vous vous occupez de cinq serveurs : trois serveurs Web à charge équilibrée et deux serveurs de base de données qui sont dans une configuration maître ou esclave dédiée à l'exécution de l'application A1 Vous utilisez un outil système adapté, pour gérer automatiquement la pile logiciel et configuration sur vos cinq serveurs.

Tout se passe bien jusqu'à ce qu'on vous dise que nous devons déployer l'application A2 sur les mêmes serveurs qui exécutent l'application A1. À première vue, ce n'est pas un problème - vous pouvez modifier votre configuration avec votre outil système pour ajouter de nouveaux utilisateurs, ajoutez des hôtes virtuels, extraire la dernière version du code, etc. Cependant, vous remarquez que l'application A2 nécessite une version du logiciel plus récente que celle que vous utilisez pour l'application A1.

Pour aggraver les choses, vous savez déjà que l'application A1 refuse catégoriquement de fonctionner avec la nouvelle pile logicielle et que l'application A2 n'est pas rétro compatible.

Traditionnellement, cela vous laisse quelques choix, qui ne font qu'aggraver le problème d'une manière ou d'une autre :

• Demander plus de serveurs ? Bien que cette tradition soit probablement la solution technique la plus sûre, cela ne signifie pas automatiquement qu'il y aura un budget pour des ressources supplémentaires.

• Réarchitecturer la solution ? Retirer l'un des serveurs Web et de base de données de l'équilibreur de charge ou de la réplication et le redéployer avec la pile logicielle pour l'application A2 peut sembler la prochaine option la plus simple d'un point de vue technique. Cependant, vous introduisez des points de défaillance uniques pour l'application A2 et réduisez également la redondance pour l'application A1 : il y avait probablement une raison pour laquelle vous exécutiez trois serveurs Web et deux serveurs de base de données en premier lieu.

• Vous essayez d'installer la nouvelle pile logicielle côte à côte sur vos serveurs ? Eh bien, cela est certainement possible et peut sembler être un bon plan à court terme pour sortir le projet, mais cela pourrait vous laisser avec un château de cartes qui pourrait s'effondrer lorsque le premier correctif de sécurité critique est nécessaire pour l'un ou l'autre pile logicielle.

La solution Docker (Operations)

C'est là que Docker commence à prendre tout son sens. Si l'application A1 s'exécute sur vos trois serveurs Web dans des conteneurs, vous exécutez peut-être plus de trois conteneurs ; en fait, vous pourriez déjà en exécuter six, en doublant les conteneurs, ce qui vous permet d'exécuter des déploiements progressifs de votre application sans réduire la disponibilité de l'application A1.

Le déploiement de l'application A2 dans cet environnement est aussi simple que de simplement lancer plus de conteneurs sur vos trois hôtes, puis de les acheminer vers l'application nouvellement déployée à l'aide de votre équilibreur de charge. Comme vous ne faites que déployer des conteneurs, vous n'avez pas à vous soucier de la logistique du déploiement, de la configuration et de la gestion de deux versions de la même pile logicielle sur le même serveur.

Dans cette présentation nous allons travailler sur des exemples concret...

Problème pour l'entreprise

Les entreprises souffrent des mêmes problèmes rencontrés par les développeurs et les opérateurs, car elles emploient les deux types de professions ; cependant, ils ont ces deux entités à une échelle beaucoup plus grande, et il y a aussi beaucoup plus de risques impliqués.

Le problème

En raison du risque ainsi que du fait que tout temps d'arrêt pourrait causer un arr6et de production, coûter des ventes ou avoir un impact sur la réputation, les entreprises doivent tester chaque déploiement avant qu'il ne soit publié. Cela signifie que les nouvelles fonctionnalités et correctifs sont bloqués dans un schéma d'attente pendant que les événements suivants se produisent :

• Les environnements de test sont lancés et configurés.

• Les applications sont déployées dans les environnements nouvellement lancés.

• Les plans de test sont exécutés, et l'application et la configuration sont modifiées jusqu'à ce que les tests réussissent.

• Les demandes de modification sont écrites, soumises et discutées pour que l'application mise à jour soit déployée en production.

Ce processus peut prendre de quelques jours à quelques semaines, voire des mois, selon la complexité de l'application et le risque introduit par le changement. Bien que le processus soit nécessaire pour assurer la continuité et la disponibilité de l'entreprise au niveau technologique, il ajoute potentiellement un risque au niveau de l'entreprise. Que se passe-t-il si vous avez une nouvelle fonctionnalité bloquée dans ce schéma d'attente et qu'un concurrent publie une fonctionnalité similaire, ou pire encore, la même, avant vous ?

Ce scénario pourrait être tout aussi préjudiciable que le temps d'arrêt contre lequel le processus a été mis en place pour vous protéger en premier lieu.