‫Eh bien, bonjour?
‫Ou devrais-je dire bienvenue dans le futur de la gestion logicielle avec Docker et les outils de conteneur ?
‫Cette vidéo concerne spécifiquement Docker.
‫Il a eu beaucoup d'outils au fil des ans, mais cette vidéo concerne les trois innovations
‫majeures qui ont lancé toute l'évolution du logiciel Docker en 2013.
‫Il s'agit principalement de trois éléments : l'image Docker, le registre Docker, puis le conteneur Docker.
‫La plupart d'entre nous, quand on pense à Docker, on pense au conteneur.
‫Mais ces trois innovations vont ensemble comme du pain et du beurre, et elles s'appellent Add, Docker, build,
‫ship run.
‫Ce sont les trois étapes pour prendre un logiciel d'identification auparavant non conteneurisé, le transformer en une image docker, le placer sur un registre, le placer là
‫où vous en avez besoin pour l'exécuter, puis enfin créer un conteneur à partir de celui-ci.
‫En fait, la Ciencia for the Cloud Native Computing Foundation, dont de nombreux outils parleront dans toutes mes
‫vidéos, ces produits, outils et flux de travail supposent dans la plupart des cas que vous utilisez un
‫flux de travail de conteneur, une exécution de navire de construction .
‫Alors décomposons-les et quels sont exactement les trois.
‫Tout d'abord, l'image du conteneur et j'aime la considérer comme un packageur d'applications universel et nous avons eu beaucoup de gestionnaires de
‫packages au fil des ans.
‫En fait, j'ai perdu le compte et j'ai été dans tous les gestionnaires de paquets pendant un certain temps, mais
‫je ne me souviens jamais de quoi que ce soit qui ait été multi-OS multiplateforme et indépendant du langage d'application, ce qui signifie qu'il fonctionnera
‫partout et il fonctionne sur n'importe quoi tant qu'il exécute Linux ou Windows.
‫Jetons maintenant un coup d'œil rapide à un fichier Docker, qui est la recette ou l'ensemble d'instructions pour créer une image de conteneur, une
‫image docker et une image de conteneur sont le même terme pour la même chose.
‫En fait, la spécification d'image Docker était si populaire qu'elle est maintenant une norme connue sous le nom de norme d'image
‫OCI.
‫Vous voyez donc un ensemble d'instructions et chaque fichier Docker a besoin d'un point de départ.
‫On peut partir de l'image de quelqu'un d'autre.
‫Nous pouvons avoir de nombreuses images de, beaucoup de.
‫Nous aborderons donc toute cette complexité plus tard.
‫Mais nous commençons avec un python ici et nous progressons vers le bas.
‫En fait, nous commençons avec ces calques.
‫Chacune de ces commandes dans le fichier Docker s'appelle parfois une strophe avec des lettres majuscules, y compris
‫l'origine, puis l'exécution et leur chemin vers le bas, car elle les traite de haut en bas
‫créera des couches qui seront déplacées autour des serveurs sous forme d'archives.
‫Et à l'intérieur de ces couches se trouvent des fichiers, des répertoires et des autorisations de fichiers et parfois des métadonnées que nous aborderons
‫plus tard.
‫Lorsque je commence à créer cette image, elle démarre cette première ligne et recherche l'image Python à partir de Docker Hub ou de
‫l'endroit où je lui ai dit d'obtenir l'image.
‫Et cela inclut uniquement Python, ses binaires et ses bibliothèques.
‫Il ne contient pas de pilotes hôtes ou le noyau Linux ou quoi que ce soit en dehors de ce dont Python a besoin pour fonctionner.
‫Si Python a besoin d'un SSL ouvert, cela est inclus dans cette couche de l'image.
‫Ensuite, nous pouvons passer à la ligne suivante du fichier Docker.
‫C'est une commande PIP pour un programme d'installation de dépendances Python et il installe flask.
‫Cela va donc démarrer une nouvelle couche qui ajoute un flacon comme vous le feriez avec une commande pip install normale.
‫En fait, ce qui se passe en arrière-plan consiste à exécuter de petits conteneurs rapides pour chacune de ces couches, à
‫exécuter les commandes ou à faire tout ce que vous devez faire à l'intérieur de ces couches,
‫puis à les stocker dans leur propre emplacement distinct sur l'hôte Linux qui construit ceci.
‫Nous empilons donc les calques ici, puis nous passons à la ligne suivante, la commande de copie, le travail.
‫Il y a juste un changement de métadonnées.
‫Cela change simplement les emplacements dans le système de fichiers, ce n'est pas grave.
‫La commande de copie copie notre code source de l'hôte sur lequel nous construisons dans sa propre couche empilée au-dessus
‫des autres.
‫Ceux-ci forment ensemble une image à l'aide de la commande docker build.
‫C'est l'une de ces choses à propos de Docker qui est devenue si facile à utiliser parce que nous n'avions
‫besoin que de cette simple commande de construction Docker pour prendre un tas de choses complexes dans le fichier Docker et le transformer en
‫une seule image.
‫C'est juste notre application et seulement les dépendances dont elle a besoin et rien d'autre.
‫C'est la première partie de l'exécution du navire de construction en cours de construction par Docker.
‫Ensuite, parlons du registre.
‫Le registre Docker est destiné à la distribution des applications.
‫Chaque système de conditionnement d'applications a un moyen de faire circuler ces packages et le registre Docker n'est plus
‫différent maintenant.
‫Il s'agit simplement de la spécification de distribution OCI ou de la spécification de registre OCI.
‫C'est donc à nouveau une norme dans toute l'industrie pour savoir comment déplacer les images de conteneurs.
‫Et c'est partout.
‫Chaque nuage en a un.
‫Le hub Docker est le hub par défaut et probablement le plus populaire.
‫GitHub a un Bitbucket GitLab.
‫Ils ont tous leurs propres registres d'images et vous pouvez gérer le vôtre.
‫Il existe probablement au moins une douzaine de projets de logiciels gratuits, open source et payants qui vous
‫permettent d'y stocker vos images Docker.
‫Alors décomposons comment cela fonctionne.
‫Tout d'abord, nous avons notre image que nous venons de créer, et cette image a un hachage sha unique qui identifie toutes ces
‫couches ensemble d'une manière que nous pouvons garantir que si nous regardons le hachage sur deux systèmes différents, nous pouvons
‫être certains que c'est exactement les mêmes fichiers, exactement les mêmes métadonnées que nous venons de créer.
‫Ces couches d'images vont ensemble et se répartissent.
‫Nous pouvons utiliser quelque chose comme Docker Push pour prendre ces couches d'images et les pousser vers un registre.
‫Vous pouvez utiliser l'un des nombreux registres, comme je l'ai mentionné, mais une fois qu'il est là, vous
‫pouvez alors aller sur une autre machine et faire un Docker pull, qui tirera une copie identique de cette image sur cette machine, tout comme nous
‫l'avions construit sur le premier appareil.
‫Et c'est l'un des principes fondamentaux de Docker, c'est que nous sommes capables de prendre le logiciel
‫que nous avons créé sur une machine avec toutes ses dépendances et de l'exécuter exactement de la même manière sur un
‫autre système qui pourrait être des distributions complètement différentes de Linux ou Windows.
‫Si vous êtes sous Linux et que vous créez une image Linux qui doit s'exécuter sous Linux car elle exécute des binaires Linux.
‫Si vous l'avez construit sur CentOS et que vous l'avez exécuté sur un Bonita, ce serait exactement la même application et les mêmes dépendances
‫quelle que soit cette distribution.
‫Enfin, nous arrivons au conteneur Docker lui-même.
‫Une fois que nous avons effectué toutes ces étapes de création de l'image, de mise en place dans un emplacement, nous
‫pouvons y accéder depuis nos serveurs, puis la télécharger sur nos serveurs.
‫Nous pouvons l'exécuter.
‫Imaginons que nous ayons un serveur exécutant Linux.
‫Il exécute peut-être Windows, mais dans ce cas, nous nous concentrerons uniquement sur Linux.
‫Docker fonctionnera en arrière-plan, connu sous le nom de moteur Docker.
‫Et le moteur de cette machine unique orchestrera ou gérera toutes les différentes choses qui
‫doivent se produire pour télécharger des images, vérifiera qu'il s'agit exactement de la chose qui devait être téléchargée,
‫puis les exécutera finalement.
‫Ensuite, nous obtenons l'image que nous venons de télécharger avec un sondage Docker, puis nous allons exécuter une commande.
‫Il n'est pas encore vraiment important que vous appreniez les commandes, mais c'est une commande d'exécution de Docker.
‫C'est la partie run de build ship run.
‫Et dans ce cas, nous exécutons cette application Python dans son propre conteneur.
‫Ce conteneur est appelé espace de noms.
‫C'est cette fonctionnalité Linux qui empêche l'application exécutée dans ce conteneur de voir le reste
‫du système d'exploitation.
‫Il obtient son propre système de fichiers vierge, et il n'inclura que les fichiers qui se trouvaient dans cette image que nous venons de
‫créer.
‫Il obtiendra sa propre adresse IP et sa propre carte réseau virtuelle et sa propre liste de processus et ressemble fondamentalement à
‫son propre système à l'intérieur.
‫Ensuite, si nous exécutons à nouveau cette commande d'exécution Docker avec notre nom d'image ou notre hachage d'image, nous obtenons un
‫conteneur identique fonctionnant côte à côte.
‫Or, ces deux processus sont isolés l'un de l'autre.
‫Ainsi, l'application Python, un conteneur on ne peut pas voir l'application Python et le conteneur deux.
‫Et si vous changez un fichier du conteneur en conteneur un, vous ne verrez pas ce fichier par défaut.
‫Si nous ajoutions un deuxième serveur avec une deuxième instance du moteur Docker en cours d'exécution et faisions la même chose,
‫nous pourrions avoir une configuration hautement disponible avec notre application, s'exécutant plusieurs fois pour la redondance ou de meilleures
‫performances ou quelle que soit notre raison d'exécuter plus que l'un d'eux.
‫Ils seront identiques du point de vue du système de fichiers, des permissions et des métadonnées.
‫Maintenant, nous pouvons en apprendre beaucoup plus sur ce sujet, c'est pourquoi le cours que j'ai est
‫si long maintenant.
‫Mais ce sont toujours les trois choses qui n'ont pas changé après Docker.
‫Les a d'abord conceptualisés.
‫L'idée de build ship run est l'un des principes fondamentaux du conteneur et de la barre Kubernetes.
‫Vous nommez le projet dans l'écosystème cloud natif et cela suppose probablement que vous disposez de ce type
‫de flux de travail typique pour faire passer vos applications des mains de vos développeurs aux systèmes de test, puis enfin aux
‫serveurs de production.
‫Ce sont ces mêmes trois étapes, alors j'espère que cela commence à comprendre un peu que vous comprenez pourquoi ce
‫sont les trois éléments clés.
‫Même aujourd'hui, de très nombreuses années après que tout cela ait été inventé, découvrons la suite.