‫Maintenant, vous vous demandez peut-être encore, même après avoir appris certaines des fonctionnalités clés de Docker.
‫Pourquoi Docker doit-il exister ?
‫Évidemment, nous emballons des logiciels depuis des décennies avec des tonnes d'autres gestionnaires de paquets déployant des logiciels sur des
‫serveurs.
‫Alors parlons-en.
‫Cette vidéo va se concentrer sur trois choses autour de pourquoi Docker et pourquoi maintenant ?
‫Et au moment de sa création, il y avait des frictions.
‫Il y avait des choses qui nous ont empêchés de passer au niveau supérieur de vitesse et de facilité d'utilisation du cycle de vie du logiciel, en particulier en ce qui
‫concerne l'empaquetage, la distribution et l'exécution de tous les logiciels que nous créons.
‫Et j'aime les listes de trois, je suppose.
‫Donc, cette liste principale d'environnements d'isolement et de vitesse.
‫Ces trois domaines sont ce dont je veux parler en tant que trois raisons générales.
‫J'ai l'impression que les conteneurs eux-mêmes devaient exister et pourquoi ils sont si populaires aujourd'hui.
‫Tout d'abord, le problème de l'isolement.
‫Et si nous revenons au début de ma carrière dans les années 90, nous pouvons commencer à parler
‫de ce qu'étaient les serveurs avant d'avoir des conteneurs.
‫Si nous remontons encore plus loin qu'en 2013, avant la création de Docker et que nous parlons du début des années 2000 dans
‫les années 90, lorsque nous sommes passés du mainframe au PC, cela pourrait être à quoi ressemblerait un administrateur typique.
‫J'avais quelques serveurs par entreprise.
‫Vous savez, on ne pourrait pas vraiment gérer 100 serveurs par personne.
‫Encore une fois, c'était comme, vous savez, 2000.
‫Et donc on aurait ces gros serveurs très chers dont il était rare de consommer toutes leurs ressources avec une
‫seule appli.
‫Alors, vous vous retrouveriez avec toutes ces applications toutes bricolées sur le même serveur.
‫Et le serveur est devenu cassant.
‫C'est devenu difficile à gérer car vous pourriez avoir besoin de changer une chose pour une application, puis une autre application avait besoin
‫d'une chose différente.
‫Et puis vous deviez gérer leurs différentes versions de Python ou vos différentes versions d'Apache sur différents serveurs
‫juste pour équilibrer le tout en même temps, vous vouliez mettre de plus en plus de choses sur chaque
‫serveur.
‫Mais rien n'était isolé, donc toutes ces applications partageaient le même système de fichiers.
‫Il ne pouvait généralement pas y avoir plusieurs versions de cette application sans beaucoup de piratage compliqué.
‫Et c'était un gros problème.
‫Puis vinrent les VM.
‫Ainsi, une fois que les machines virtuelles sont devenues vraiment populaires, même avant le cloud, nous avons pu faire abstraction de
‫toutes nos applications et commencer à mettre moins d'applications sur des machines virtuelles plus petites, toutes écrivant sur le même grand hôte.
‫Cela pourrait donc ressembler à ceci et nous pourrions commencer par Chef ou Puppet comme moyen
‫de gérer tous ces nombres croissants de serveurs.
‫En fait, nous aurions alors tellement de serveurs au début des 20 premières dizaines avant la création de Dockers qu'il devenait
‫très difficile de les gérer tous à la fois.
‫Vous étiez un seul administrateur, essayant peut-être de gérer des dizaines, voire des centaines de serveurs, même avec le cloud
‫nous aidant à faire tourner les machines plus rapidement, les démontant plus rapidement.
‫C'était beaucoup.
‫C'était tellement difficile à gérer que c'en est devenu trop pour beaucoup d'entre nous.
‫Et le cloud, je pense, l'a rendu meilleur, mais aussi pire parce qu'il a rendu beaucoup plus facile d'en faire
‫tourner beaucoup plus.
‫Alors, comment Docker peut-il vous aider ?
‫Comment peut-il nous aider à réduire la quantité d'infrastructure à gérer tout en assurant l'isolation de nos charges de travail afin que les
‫choses ne deviennent pas fragiles ou difficiles à gérer ?
‫Eh bien, si c'était notre configuration il y a 20 ans, au lieu de répartir toutes ces machines virtuelles avec un
‫nombre inutile d'OS.
‫Ce que font les conteneurs, c'est qu'ils nous isolent comme une machine virtuelle.
‫Ce n'est pas tout à fait la même chose, mais nous allons simplement dire pour l'instant qu'il s'agit d'une couche d'isolation où ils obtiennent leur
‫propre adresse IP, ils obtiennent leur propre système de fichiers, ils obtiennent leur propre espace de processus.
‫Et donc cela ressemble presque à une machine virtuelle complète, mais vous n'avez pas besoin de tous les différents systèmes d'exploitation pour
‫que nous puissions réduire notre système d'exploitation, compter notre nombre d'hôtes physiques.
‫Vous n'avez plus besoin d'utiliser les machines virtuelles comme couche d'isolation, et cela pourrait ressembler à ceci.
‫Au lieu d'utiliser S-H, vous utiliseriez un Docker.
‫Seelye Ou si vous passez à Kubernetes, vous pouvez utiliser l'IA du sceau Kubernetes et vos applications
‫sont toutes isolées dans leurs propres conteneurs.
‫Cela vous offre de nombreux avantages, notamment l'exécution de plusieurs versions de la même application sur le même
‫système sans aucun conflit.
‫Vient ensuite le problème des environnements.
‫Et évidemment, nous faisions tourner des tonnes de systèmes d'exploitation comme je l'ai dit, mais le nombre de
‫types d'environnements différents augmentait également.
‫Avez-vous déjà entendu parler de travaux sur ma Machine ?
‫Il a été en quelque sorte rendu célèbre comme une blague par Jeff Atwood, l'un des fondateurs de StackOverflow, et un
‫article de blog célèbre depuis longtemps.
‫Mais cela fonctionne sur ma machine, l'idée était un peu sarcastique, mais la plaisanterie était que c'est souvent le
‫travail du développeur de s'assurer que l'application fonctionne correctement.
‫Mais ils ne disposent pas de tous les environnements nécessaires à l'exécution de cette application.
‫Alors ils l'exécutent simplement sur leur machine, ils testent sur leur machine, puis quand ça ne marche
‫pas ailleurs, ils disent que ça marche sur ma machine.
‫C'est vraiment difficile quand nous avons tous ces différents systèmes d'exploitation et que Docker a inventé cette matrice
‫de l'enfer, ce qui signifie essentiellement pour chaque partie de votre application, qui est au-dessus de
‫moi, puis pour chaque type d'environnement ici de ce côté, vous avez un configuration différente.
‫Peut-être que vous devez installer les dépendances d'une manière différente.
‫Peut-être que les dépendances sont légèrement différentes car l'une a une version différente dans l'autre.
‫Vous avez tous ces différents types d'environnements et vous avez probablement dû lire ou écrire de la documentation sur la façon
‫dont l'application que le développeur utilise sur Mac doit être installée différemment sur Windows, qui doit être installée
‫différemment sur un serveur Linux et sur et ainsi de suite.
‫Désormais, l'image du conteneur et le conteneur lui-même sont devenus un fondement.
‫Mental, abstrait ou un contrat entre l'endroit où il est exécuté et ce qui est exécuté à l'intérieur, un peu comme des conteneurs physiques dans le
‫monde réel qui nous permettent d'expédier des marchandises partout dans le monde depuis une conception d'il y a
‫près de cent ans.
‫L'objectif était que les personnes qui livraient les conteneurs physiques n'aient pas à savoir ce qu'il y avait à l'intérieur,
‫et les personnes qui mettaient leurs affaires à l'intérieur du conteneur n'avaient pas à savoir ou à se soucier de la façon dont
‫le conteneur arrivait physiquement à destination.
‫C'était une abstraction des proportions désormais épiques de millions de conteneurs expédiés dans le monde entier.
‫Et à peu près tout dans votre maison a probablement été dans un conteneur au cours de sa vie.
‫La même chose est vraie pour les images dans les conteneurs Docker maintenant.
‫Il s'agit d'un format standard cohérent connu maintenant sous le nom de normes OCI.
‫Ceux-ci garantissent que partout où vous exécutez le conteneur, il sera exécuté de la même manière cohérente avec les mêmes dépendances exactes
‫avec lesquelles il a été construit.
‫Ensuite, le problème de la vitesse.
‫Maintenant, je ne parle pas nécessairement ici de la vitesse du processeur ou de la vitesse de la mémoire.
‫Ces choses deviennent naturellement plus rapides avec le temps.
‫Mais je parle vraiment de la rapidité des affaires.
‫Et quand on parle de moi. T et les logiciels et le cycle
‫de vie des logiciels, nous parlons vraiment de la capacité des entreprises et des organisations à concrétiser leurs idées, à livrer leurs
‫idées logicielles au client aussi rapidement que possible.
‫Et cela fait partie du cycle de vie du logiciel.
‫Eh bien, il s'avère que l'industrie a modifié l'infrastructure et l'architecture depuis l'aube
‫de l'informatique.
‫Pour cette raison précise, j'ai réalisé ce joli petit graphique car vous pouvez commencer par le haut.
‫Il y a bien longtemps dans les années 90, lorsque j'ai fait mes débuts et que nous avions des mainframes migrés vers
‫des PC dans une architecture distribuée qui concernait en grande partie la vitesse de déploiement du changement.
‫Vous pouviez désormais installer DOS sur une seule machine sans avoir à attendre que l'ordinateur central soit mis
‫à jour vers la prochaine version d'Unix.
‫Nous ne pouvions plus bouger tous à la fois.
‫Nous avions besoin que différentes parties de notre organisation évoluent dans des directions différentes à des vitesses
‫différentes, d'où l'aube de l'informatique distribuée.
‫Puis nous sommes passés du bare metal, du virtuel, car nous en avions marre d'attendre la commande de matériel et d'attendre qu'il
‫soit implémenté dans un centre de données.
‫Nous voulions accélérer les choses et mieux utiliser nos ressources.
‫La virtualisation et les machines virtuelles sont devenues extrêmement populaires pour ces raisons.
‫Ensuite, le centre de données vers le cloud était la prochaine étape, car nous devions maintenant déployer des idées encore plus rapidement que ne
‫le permettaient nos propres matériels et centres de données.
‫Nous voulions exécuter des serveurs que nous n'avions pas actuellement en quelques minutes, pas en jours ou en semaines, et
‫le cloud nous a donné accès à des ressources quasi instantanées, ce qui est évidemment la raison pour laquelle le cloud est si énorme aujourd'hui.
‫Et puis finalement, nous sommes sur la prochaine étape de ce voyage, passant de l'expansion massive de l'hôte que nous avons eue où
‫nous avions trop d'hôtes, de noyaux et de systèmes d'exploitation.
‫Et maintenant, nous allons pouvoir en réduire le nombre, car nous sommes désormais en mesure d'isoler les charges de travail
‫qu'elles contiennent et de les exécuter ensemble en toute sécurité sur le même noyau.
‫J'inclus ici le sans serveur, au fait, car si vous creusez vraiment dans la plupart des plates-formes sans serveur,
‫elles ne font qu'exécuter des conteneurs en arrière-plan.
‫Il peut s'agir d'un conteneur que vous avez expédié en tant qu'image ou simplement d'un conteneur dans lequel ils
‫exécutent votre fonction, mais ils s'exécutent toujours dans un conteneur.
‫Et c'est pourquoi j'aime parler de plus vite, plus vite, plus vite.
‫Essentiellement, ce que Containers et Docker vous offrent, c'est la possibilité de développer plus rapidement, de créer vos applications plus
‫rapidement, de les tester plus rapidement et de les déployer plus rapidement sur vos serveurs.
‫Maintenant, es-tu toujours avec moi ?
‫J'ai toujours votre attention.
‫Récapitulons cela très rapidement.
‫Donc, la raison pour laquelle les conteneurs existent est trois raisons principales, à mon avis, la meilleure isolation à l'intérieur d'un seul système d'exploitation
‫économise du temps et de la gestion du système d'exploitation et des dépendances, mais nous donne également l'isolation dont nous avons
‫besoin pour protéger nos applications.
‫Ensuite, nous avons réduit les variances environnementales.
‫Ainsi, la différence entre chaque environnement qu'il exécute est très minime.
‫Encore une fois, généralement juste vos paramètres de connexion pour les bases de données, peut-être des chemins d'URL, des trucs comme ça,
‫des ports, et puis le reste est exactement le même que vous l'avez construit et testé.
‫Et enfin, augmenter notre vitesse de changement, non seulement pour le logiciel lui-même, mais pour l'entreprise qui souhaite
‫mettre en œuvre ce logiciel.
‫Nous sommes maintenant en mesure de développer plus rapidement, de le construire plus rapidement, de le déployer sur des serveurs plus rapidement et
‫de le tester plus rapidement, tout cela parce que ces images de conteneurs et les conteneurs eux-mêmes sont si faciles à créer, déployer, redéployer et
‫réexécuter et tout ça.
‫J'espère donc que cela a du sens.
‫Je vous verrai dans la prochaine vidéo.