‫Cette section sera consacrée aux registres d'images de conteneurs.
‫Il y a beaucoup de
‫chemin à parcourir, nous allons donc commencer par dire en gros que vous avez besoin d'un registre d'images dans votre plan.
‫Ce n'est pas vraiment une partie optionnelle de l'écosystème des conteneurs. Docker et d’autres outils ont été conçus de manière
‫à ce qu’ils aient besoin d’un emplacement, situé hors de vos serveurs et de vos postes de travail pour développeurs, pour
‫stocker vos images.
‫Techniquement, il peut s'agir de fichiers zip et vous pouvez les exporter et les importer, mais la situation est
‫vraiment ardue.
‫Donc, vous voulez vraiment planifier un registre, que ce soit sur Internet ou privé.
‫Nous allons en fait passer en revue certaines choses et différentes conférences ici où nous
‫parlerons des détails de Docker Hub et de certaines des options de construction automatique.
‫Nous allons nous concentrer sur le magasin Docker pour une conférence et expliquer en quoi cela diffère réellement de Hub.
‫Ensuite, l'option Docker Cloud, qui est également différente de Hub, mais constitue également un complément au jeu d'outils
‫Docker. Elle
‫pourrait peut-être vous aider à faciliter le déploiement de serveurs et de vos données dans le cloud.
‫Nous avons également la nouvelle fonctionnalité Swarms dans Docker Cloud, sur laquelle j’aurai une conférence spécifique.
‫Et ensuite, vous allez apprendre à créer votre propre registre et à le déployer sur votre ordinateur local ou
‫sur un Docker Swarm à utiliser comme registre privé.
‫C'est en fait open-source. Et ensuite, nous mentionnerons certaines des options de registre
‫tierces au cas où vous ne voudriez pas utiliser Docker Hub ou le registre Docker à code source ouvert.
‫Dans cette conférence, nous allons aborder certains des sujets avancés de Docker Hub.
‫Il s’agit du registre d’images le plus populaire au monde pour les conteneurs, mais ce n’est pas le seul.
‫Voyons ce qu'il fait en plus
‫de ce que nous avons déjà discuté jusqu'à présent. En résumé, Hub est un registre, mais il contient également une image de construction.
‫Cela ne fait normalement pas partie, par exemple, du
‫registre à code source ouvert. Il contient donc quelques éléments supplémentaires qui vous permettent de créer
‫des images à la volée.
‫Nous allons passer à certaines de ces fonctionnalités ici.
‫Et ensuite, discutez également de la liaison de vos comptes GitHub et BitBucket au concentrateur et de la vérification de
‫certaines des fonctionnalités de construction automatique permettant de créer vos images sur la base des commits.
‫Et ensuite, nous allons montrer quelques fonctionnalités autour de l'enchaînement de la construction d'images afin que vous puissiez plus
‫facilement vous assurer que vos images sont toujours à jour.
‫Nous avons déjà traité un peu de Docker Hub
‫lorsque nous avons découvert les images plus tôt dans ce cours. Mais je voulais passer en revue certaines des
‫fonctionnalités dont nous n’avons peut-être pas discuté, puis les comparer à Docker Store, puis parler de
‫ce que Docker Cloud pourrait faire pour nous avant que nous ne passions à d’autres options de registre. .
‫De toute évidence, Docker Hub est un registre.
‫C'est ce que nous avons parlé de tout ce cours.
‫C'est la façon dont nous tirons toutes nos images, et c'est le registre par défaut de Docker. Mais ce n'est pas le seul
‫de loin.
‫Parlons de ce qu'il peut faire en plus de ce que nous avons déjà fait.
‫Nous pouvons voir que j'ai des dépôts ici, évidemment. Vous pouvez dire que j'ai en fait au moins
‫un privé ici. Les privés, vous
‫en obtenez un gratuitement, et le reste, vous devez payer.
‫Vous configurez un compte de facturation comme d'habitude et vous payez pour cela. Lorsque vous créez des référentiels, et sur chacune de vos
‫images, qu'elles soient publiques ou privées, vous pouvez choisir d'accorder des autorisations à des personnes.
‫Voici à quoi ressemblerait mon point de vue pour un référentiel que je possède.
‫Cela se trouve être un public.
‫Si je suis allé dans les paramètres, vous pouvez voir que je peux basculer entre rendre privé
‫et public.
‫Je peux le supprimer. Je peux créer des Webhooks, et ceux-ci sont très pratiques lorsque vos
‫images sont construites et insérées dans Docker Hub.
‫Vous pouvez le faire envoyer un lien Web à un autre service, comme Jenkins ou Codeship, ou Travis
‫CI, ou quelque chose du genre, pour que les versions automatisées se poursuivent.
‫Ces Webhooks sont là pour vous aider à automatiser le processus d'obtention de votre code de Git ou GitHub
‫à Docker et jusqu'aux serveurs sur lesquels vous souhaitez les exécuter. Collaborateurs est la zone d'autorisations dans laquelle
‫vous pouvez définir des autorisations permettant à d'autres personnes de manipuler
‫votre image.
‫Et puis nous avons aussi des organisations. Ainsi, vous disposez de vos propres autorisations pour vos propres référentiels et vous
‫pouvez ensuite donner d'autres autorisations à vos référentiels. Mais si vous souhaitez créer des organisations, vous pouvez également
‫le faire.
‫Ils sont totalement gratuits.
‫Par exemple, sous cette organisation, je peux voir toutes leurs mises en pension. Et puis, parce que j'ai les autorisations
‫pour chacun, je peux réellement y aller et changer tous leurs paramètres.
‫Vous pouvez voir que je peux contrôler la composition de l'équipe.
‫Je peux contrôler la facturation comme vous le feriez normalement pour les images privées.
‫Cela ressemble beaucoup à GitHub, si vous avez déjà utilisé GitHub, ou si vous avez déjà payé pour quoi que ce soit sur GitHub.
‫C'est très similaire lorsque tout ce qui est open-source est gratuit et que tout ce que vous voulez
‫être privé doit payer pour des plans en groupe. Et les organisations fonctionnent de la même manière que GitHub.
‫Il n'y a pas beaucoup d'autre chose.
‫Je veux juste vous montrer quelques éléments clés que vous devez savoir si vous souhaitez commencer à les utiliser.
‫Premièrement, si vous utilisez un GitHub ou BitBucket pour stocker votre code, ne cliquez pas sur ce bouton pour
‫créer votre référentiel.
‫En outre, n'effectuez pas de push Docker avant de le créer car vous voulez vraiment monter
‫ici pour créer et créer une construction automatisée. La génération automatisée permet à Docker Hub de créer ce
‫chemin de CI qui générera automatiquement votre image en fonction des validations de code.
‫C'est comme le webhook inversé.
‫Les Webhooks que nous avons examinés il y a quelques instants permettent à Docker Hub de notifier à quelque chose d'autre que
‫l'image est terminée.
‫Mais ce processus permet à Docker Hub d'être averti lorsque quelque chose d'autre se produit.
‫Je le configure toujours pour la construction automatique de mes propres référentiels.
‫Dans ce cas, par exemple, je viens de choisir un référentiel auquel j'ai accès et GitHub.
‫Et puis, je lui donne une courte description qui me permet de créer un référentiel.
‫Mais, dans ce cas, il sait que cela vient de GitHub.
‫Chaque fois qu'il y a une validation basée sur certaines exigences, ou certaines branches, cela construira réellement mon
‫image à la volée.
‫Ensuite, je reçois un joli petit e-mail disant que c'est réussi ou pas.
‫C'est pourquoi vous voyez sur beaucoup d'images qu'il s'agit de constructions automatisées.
‫Ce n’est qu’un signe de qualité, car il montre que cette image est probablement toujours à
‫jour, où que se trouve le code source. Vous verrez ici, comme le serveur Jekyll que
‫nous avons utilisé précédemment dans ce cours, que j'ai certaines de ces options automatisées que je n'avais pas dans le référentiel précédent
‫et qui n'étaient pas configurées pour l'automatisation.
‫Donc ici, j'ai les détails de construction, les paramètres de construction. Vous pouvez voir que chaque fois que c'est construit,
‫c'est réussi dans l'histoire. Et puis, dans les paramètres de construction, je peux choisir les branches que je veux construire. Quelque chose que je recommande
‫fortement est que, sous les liens de référentiel, si vous construisez
‫des images sur Docker Hub et que vous utilisez une instruction from que vous extrayez d'une
‫autre image, vous souhaitez configurer les liens de référentiel ici, afin que chaque fois que le logiciel change votre
‫image est reconstruite.
‫Et c'est un gros problème car, avec le temps, votre image va avoir des dépendances, et devra être mise à jour lorsque celles-ci
‫seront mises à jour elles-mêmes, peut-être sur la
‫base d'exigences de sécurité ou de nouvelles corrections de bugs. Et donc, sur le mien, parce que Ruby et
‫Jekyll se trouvent dans mon image et que le fichier Docker contient le nom de Jekyll,
‫je les mets ici de sorte que chaque fois que ces images sont reconstruites, les miennes le sont ensuite.
‫Si vous souhaitez également créer un déclencheur de construction ... un déclencheur de construction est un autre moyen entrant pour
‫que vous ayez automatiquement une image, et vous avez peut-être un autre logiciel que GitHub que vous voulez
‫lancer lorsque vous avez des problèmes.
‫Vous pouvez donc créer ces URL de publication uniques ici.