Découvrez la registry
OK, avant d’aller plus loin, faisons un état des lieux. Vous savez maintenant comment construire une image grâce à un Dockerfile et démarrer un conteneur en partant de cette image.
Comment je fais maintenant pour vous envoyer l’image que j’ai construite sur mon poste de travail ? Si j’ai bien compris, elle n’existe pour l’instant que sur mon poste.
Effectivement, l’image construite n’existe pour l’instant que sur la machine ayant servi à construire cette image. Lors du déploiement d’une application, il est nécessaire de mettre à disposition publiquement cette image afin de la déployer sur plusieurs machines, et dans plusieurs contextes, que ce soit un déploiement au sein d’un datacenter privé, mais aussi dans le cas du déploiement dans le cloud. C’est là qu'intervient la registry.
Ok, super ! Mais pourquoi utiliser une registry ?
La registry est là où sont stockées toutes les images des applications. C’est un point central unique qui stocke toutes les images. Avant l'utilisation d’un registre d’images, il existait un problème récurrent : la gestion des différentes versions de son application web complexe. Chaque déploiement s'accompagnait d'une multitude de fichiers à suivre, de dépendances à jongler et de configurations à ajuster manuellement, un processus fastidieux et sujet aux erreurs.
Registre d’images public et registre d’images privé
Il existe deux types de registres d’images, un public et un privé.
Dans le cas d’un type public, les images sont accessibles à tous et permettent de partager des images de conteneurs librement. Des plateformes populaires comme Docker Hub et Quay.io proposent des registries publiques.
Dans le cas d’un type privé, les images sont hébergées sur des serveurs privés et ne sont accessibles qu'aux utilisateurs autorisés. Elles offrent un meilleur contrôle sur la sécurité et la confidentialité des images de conteneurs. Par exemple, il est possible d’autoriser les accès à des images confidentielles uniquement aux personnes habilitées.
Comment choisir mon type de registre ?
Alice vous explique que le choix entre un registre d’images publiques et un registre d’images privées dépend de plusieurs facteurs, comme un besoin en matière de sécurité.
Si les images de conteneurs contiennent des informations sensibles, il est préférable d'utiliser un registre d’images privé. Si vous avez besoin de partager des images de conteneurs avec d'autres personnes, un registre d’images publiques peut être une bonne option.
Un registre d’images privées vous donne un contrôle total sur les images de conteneurs qui y sont stockées.
Un registre d’image est nécessaire dans le cas d’un déploiement sur plusieurs machines. C’est un endroit central qui permet de stocker toutes les images de conteneurs d'un projet en un seul endroit, ce qui facilite leur accès et leur gestion. Avoir un endroit central contenant toutes les images d’un projet permet le partage d'images publiquement ou privées, permettant aux développeurs de collaborer facilement et de réutiliser le travail des autres.
Ces registres peuvent être soit publiques et déployés dans un cloud par exemple, soit privés et uniquement déployés dans le réseau de l’entreprise.
Si je comprends bien, ces registries stockent toutes les versions des images du site e-commerce ?
Exactement ! Toutes les différentes versions des images que vous pouvez construire du site e-commerce seront stockées dans le registre d’image. Ces registres servent aussi à partager plus facilement les images du site avec les autres personas de l’équipe, notamment les Ops qui déploieront le site.
Et tout le monde a accès à toutes les images disponibles ?
Oui et non. Il existe plusieurs niveaux de partage d’images dans les entreprises. Par exemple, les Ops peuvent mettre à disposition des images propres à l’entreprise contenant déjà les outils nécessaires de monitoring et d’observabilité afin de permettre le maintien en condition opérationnel des applications. Ces images ont été aussi durcies par la sécurité pour assurer une sécurité maximale des applications.
Les applications se basent alors sur ces images afin de construire leurs propres images applicatives. Cela permet aussi d’avoir un endroit central pour mettre à jour les frameworks permettant de faire tourner ces applications.
Ok j’ai compris ! Et du coup, toutes les versions des images sont dans la registry ?
Exactement ! Comme toutes les versions sont disponibles, en cas de problème, le retour en arrière est facilité. Vous pouvez alors choisir la version d’images que vous souhaitez conserver et supprimez celles dont vous n’avez plus besoin.
Ces registres d’images peuvent être intégrés aux pipelines de CI/CD, permettant d'automatiser le déploiement d'images de conteneurs sur différents environnements.
Mais c’est génial ! Cela veut dire que tout le monde peut participer à la création de ces images ?
Comme vous avez pu le voir, les développeurs, les Ops et les DevOps participent au workflow de création de ces images. Mais comme les images sont immuables, construites avant le déploiement et stockées de manière centralisée, il est possible d’activer sur certains registres d’images des scans de vulnérabilité de vos images. La sécurité peut alors aussi voir les différentes failles présentes dans l’image.
Pour le site e-commerce, le développeur crée alors le Dockerfile du site, qui est ensuite intégré et construit dans le pipeline de CI/CD. Une fois cette image construite, la sécurité peut alors voir les différentes failles de sécurité et demander aux Ops de déployer une version ne contenant aucune faille.
Activez la registry dans minikube
Afin de partager les images que vous avez précédemment créées, minikube vient avec un addon pratique activant un registre d’images.
Débutez l’activation
Pour l’activer, il suffit simplement d’activer l’addon par la commande suivante :
minikube addons enable registry
Cette commande va alors démarrer un pod contenant un registre d’images. Vous pouvez vérifier que le pod est bien démarré en lançant la commande suivante :
minikube kubectl -- get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-7db6d8ff4d-6zxp4 1/1 Running 0 15m kube-system etcd-minikube 1/1 Running 0 15m kube-system kube-apiserver-minikube 1/1 Running 0 15m kube-system kube-controller-manager-minikube 1/1 Running 0 15m kube-system kube-proxy-gvmkp 1/1 Running 0 15m kube-system kube-scheduler-minikube 1/1 Running 0 15m kube-system registry-gfvxg 1/1 Running 0 15m kube-system registry-proxy-zj4tg 1/1 Running 0 15m kube-system storage-provisioner 1/1 Running 0 15mVous devriez alors voir deux lignes apparaître avec le nom registry dedans.
Poussez une image Docker dans la registry
Afin de pousser votre image dans la registry, il est d’abord nécessaire de reconstruire votre image avec le nom de la registry inclus dans le nom de l'image. Par défaut, s’il n’y a aucun nom de registre d’image, l’image va être poussée sur le Docker hub, dans le catalogue central. Or, vous n’avez aucun droit sur ce catalogue, donc l’action ne va pas fonctionner.
Rendez accessible votre registry
Avant de pouvoir pousser votre image, une petite manipulation devra être faite. Par défaut, la registry écoute sur le port 80 de la machine de minikube, sans être exposé à l’extérieur.
Il est donc nécessaire d’exposer la registry publiquement sur le port 5000 de la machine. Par convention, le port utilisé pour une registry est le port 5000. La commande suivante doit être lancée dans une autre fenêtre :
minikube kubectl -- port-forward --namespace kube-system service/registry 5000:80 Forwarding from 127.0.0.1:5000 -> 5000 Forwarding from [::1]:5000 -> 5000
Une fois la commande lancée, la registry est en écoute sur le port 5000. Vous devez laisser cette fenêtre ouverte sinon l’upload de l’image ne fonctionnera pas.
Vous pouvez vérifier que la commande précédente fonctionne avec la commande :
curl http://localhost:5000/v2/_catalog
{"repositories":[""]}Le registre d’images devrait vous répondre avec la liste d’images qu’il a en stock. Ici, il n’y a pour l’instant aucune image.
Taguez votre image
Ensuite, vous devez taguer votre image avec le nom de la registry afin de pouvoir l’uploader dans votre registry.
Dans le répertoire contenant votre Dockerfile, tapez la commande suivante :
docker build . --tag localhost:5000/ma_premiere_image docker push localhost:5000/ma_premiere_image
L’upload de l’image devrait se faire. Enfin, pour vérifier que l’image est bien présente dans la registry, tapez la commande suivante :
curl http://localhost:5000/v2/_catalog
{"repositories":["ma_premiere_image"]}
Votre image devrait être présente dans la registry.
Dans ce screencast, vous avez :
Activé la registry de minikube
Tagué l’image avec le nom de la registry
Poussé l’image dans le catalogue
À vous de jouer
Contexte
Après avoir envoyé un mail à Alice lui faisant part de la réussite de la création de votre image, vous recevez un nouveau mail de sa part :
Super nouvelle ! Par contre, ton image n’est disponible que sur ta machine et ne peut donc pas être partagée avec le reste de l’équipe.
Peux-tu la pousser sur la registry de l’équipe ?
Je te rappelle les informations:
URL de la registry : registry.livecorp.com:5000
Nom de ton image : website-ecommerce
Tag : v2.0
Dis-moi quand l’image est dispo sur la registry !
Consignes
Retaguez l’image avec les informations fournies par Alice ;
Vérifiez que l’image est bien disponible dans la registry.
En résumé
Un registre d’image conserve de manière centralisée les images de vos applications.
Il existe des registres d’images publiques ou privés.
Un registre d’image inclut des mécanismes de sécurité et d’autorisation.
Il est nécessaire de taguer votre image avec le nom de votre registre d’image privé.
Dans le prochain chapitre, vous allez pouvoir déployer votre application et mettre en place votre premier pod !
Pour l’activer, il suffit simplement d’activer l’addon par la commande suivante :
```bash
minikube addons enable registry
```
Cette commande va alors démarrer un pod contenant un registre d’images. Vous pouvez vérifier que le pod est bien démarré en lançant la commande suivante:
```bash
minikube kubectl -- get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-7db6d8ff4d-6zxp4 1/1 Running 0 15m
kube-system etcd-minikube 1/1 Running 0 15m
kube-system kube-apiserver-minikube 1/1 Running 0 15m
kube-system kube-controller-manager-minikube 1/1 Running 0 15m
kube-system kube-proxy-gvmkp 1/1 Running 0 15m
kube-system kube-scheduler-minikube 1/1 Running 0 15m
kube-system registry-gfvxg 1/1 Running 0 15m
kube-system registry-proxy-zj4tg 1/1 Running 0 15m
kube-system storage-provisioner 1/1 Running 0 15m
```
Vous devriez alors voir deux lignes apparaître avec le nom registry dedans.
//info Si vous avez le moindre soucis de connexion, vous pouvez vous rérérer à cette page pour diagnostiquer vos problèmes : https://minikube.sigs.k8s.io/docs/handbook/registry/
Poussez une image Docker dans la registry
Afin de pouvoir pousser votre image dans la registry, il est d’abord nécessaire de reconstruire votre image avec le nom de la registry inclus dans le nom de l'image. Par défaut, s’il n’y a aucun nom de registre d’image, l’image va être poussée sur le Docker hub, dans le catalogue central. Or, vous n’avez aucun droit sur ce catalogue, donc l’action ne va pas fonctionner.
Rendez accessible votre registry
Avant de pouvoir pousser votre image, une petite manipulation devra être faite. Par défaut, la registry écoute sur le port 80 de la machine de minikube, sans être exposé à l’extérieur.
Il est donc nécessaire d’exposer publiquement la registry publiquement sur le port 5000 de la machine. Par convention, le port utilisé pour une registry est le port 5000. La commande suivante doit être lancé dans une autre fenêtre:
```bash
minikube kubectl -- port-forward --namespace kube-system service/registry 5000:80
Forwarding from 127.0.0.1:5000 -> 5000
Forwarding from [::1]:5000 -> 5000
```
Une fois la commande lancée, la registry est en écoute sur le port 5000. Vous devez laisser cette fenêtre ouverte sinon l’upload de l’image ne fonctionnera pas.
Vous pouvez vérifier que la commande précédente fonctionne avec la commande :
```bash
curl http://localhost:5000/v2/_catalog
{"repositories":[""]}
```
Le registre d’images devrait vous répondre avec la liste d’images qu’il a en stock. Ici, il n’y a pour l’instant aucune image.
Taguez votre image
Ensuite, vous devez taguer votre image avec le nom de la registry afin de pouvoir l’uploader dans votre registry.
Dans le répertoire contenant votre Dockerfile, tapez la commande suivante:
```bash
docker build . --tag localhost:5000/ma_premiere_image
docker push localhost:5000/ma_premiere_image
```
L’upload de l’image devrait se faire. Enfin, pour vérifier que l’image est bien présente dans la registry, tapez la commande suivante:
```bash
curl http://localhost:5000/v2/_catalog
{"repositories":["ma_premiere_image"]}
```
Votre image devrait être présente dans la registry.
#Screencast 8395236-1c4-sc1 - livré |
Dans ce screencast, vous avez :
Activé la registry de minikube
Tagué l’image avec le nom de la registry
Poussé l’image dans le catalogue
A vous de jouer
Contexte
Après avoir envoyé un mail à Alice lui faisant part de la réussite de la création de votre image, vous recevez un nouveau mail de sa part.
Super nouvelle ! Par contre, ton image n’est disponible que sur ta machine et ne peut donc pas être partagée avec le reste de l’équipe.
Peux-tu la pousser sur la registry de l’équipe ?
Je te rappelle les informations:
URL de la registry : registry.livecorp.com:5000
Nom de ton image : website-ecommerce
Tag : v2.0
Dis moi quand l’image est dispo sur la registry !
Consignes
Retagguer l’image avec les informations fournis par Diane
Vérifier que l’image est bien disponible dans la registry
Vérifiez votre travail à l’aide cet exemple de corrigé
Une fois l’image poussé dans la registry, vous devriez la voir apparaître avec la commande suivante :
```bash
curl http://localhost:5000/v2/_catalog
{
repositories: [ website-ecommerce ]
}
```
En résumé
Un registre d’image conserve de manière centralisé les images de vos applications
Il existe des registre d’images publique ou privé
Un registre d’image inclut des mécanismes de sécurité et d’autorisation
Il est nécessaire de tagger votre image avec le nom de votre registre d’image privé
Dans le prochain chapitre, vous allez pouvoir déployer votre application et mettre en place votre premier pod !
