Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:docker:general:mise_en_place_d_un_registry_docker [2020/10/07 19:53] qduchemitechnique:docker:general:mise_en_place_d_un_registry_docker [2022/05/24 20:50] (Version actuelle) ppom
Ligne 1: Ligne 1:
 {{indexmenu_n>40}} {{indexmenu_n>40}}
-======Mise en place d'un registry Docker====== +# Registre Docker pour stocker les images 
-Lorsque l'on utilise Docker, il y a différentes possibilités pour utiliser nos propres images.  + 
-====Build manuel==== +À partir d'un `Dockerfile`, on peut construire une image. L'intérêt d'une image est d'être ré-utilisable. 
-La première solution sans doute la plus simple consiste à mettre le `Dockerfile` sur les machines qui nous intéresse et à builder cette image localement à l'aide de la commande:+ 
 +<bootnote question>Comment permettre à d'autres personnes de ré-utiliser mon image ?</bootnote> 
 + 
 +## Partager le Dockerfile 
 + 
 +La première solution sans doute la plus simple consiste à mettre le `Dockerfile` sur les machines qui nous intéressent et à construire cette image localement à l'aide de la commande :
  
 <code bash> <code bash>
Ligne 9: Ligne 14:
 </code> </code>
  
-Cette solution fonctionnemais est longue. En cas de changement sur l'imageil faut rebuilder toute l'image ce qui peut prendre quelques minutes+Similairementje peux partager mon `Dockerfile` avec d'autres personneset les laisser la construire.
  
-====Docker Hub==== +Cette solution fonctionne, mais présente plusieurs problèmes :
-La seconde solution est d'utiliser un registry mis en place par docker. Il permet de stocker ses images de manière centralisée. En cas de modification, on ne rebuild qu'une seule fois l'image. On la pousse ensuite sur le registry et il suffit de tirer la dernière version sur nos machines pour mettre à jour nos images.  +
-Cette solution fonctionne bien, mais impose d'exposer publiquement ses images sur le Hub. À cela, on ne sait pas comment sont stockées ni même où sont stockées nos images. +
  
-====Registry privé==== +* Un `Dockerfile` n'assure pas forcément un build **reproductible** : à partir du même `Dockerfile`, on pourra obtenir deux images différentes dans le temps 
-La solution du registry privé permet d'avoir les avantages des deux solutions précédentesUn registry privé est un entrepôt qui permet d'héberger des images Docker et qui est auto hébergé. Cela permet de savoir exactement où sont nos images et de centraliser celles-ci à un seul endroit+* Construire une image peut être long (téléchargement de paquets, compilation...) : c'est très consommateur de ressource.
  
-=====Mise en place=====+Une solution idéale serait de pouvoir partager directement ses images, une fois construites.
  
-On utilise les fichiers présents sur le dépôt `dockerfiles`, et les instructions associées : https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-registry+## Docker Hub
  
-Maintenant que le registry est prêt, on peut builder et lui pousser des images:+C'est ce que propose le [Docker Hub](https://hub.docker.com/) : un espace où n'importe peut téléverser ses images et télécharger les images des autres. Ainsi, à chaque utilisation de l'image, il n'y a qu'à la télécharger, et on a l'assurance que ça sera la même image partout où on la télécharge. 
 + 
 +À chaque modification du `Dockerfile`, il n'y a besoin de reconstruire l'image qu'une seule fois puis de la tirer partout où c'est nécessaire. 
 + 
 +Cette solution fonctionne bien, mais impose d'exposer publiquement ses images sur le Hub. 
 + 
 +<bootnote important>Il y a d'autres problèmes plus importants. Le Docker Hub est complètement centralisé, ce qui nous rend dépendant à une entité qu'on ne maîtrise pas et qui change régulièrement ses conditions générales d'utilisation (en particulier autour de la période de rétention des images). Le jour où Docker décide par exemple de faire payer son service, nous ne pourrons pas nous y opposer.</bootnote> 
 + 
 +## Registre privé 
 + 
 +La solution retenue consiste à utiliser un registre privé pour stocker nos images. En opposition, le Docker Hub est un registre public. 
 + 
 +<bootnote>Un registre Docker est simplement un logiciel qui permet de téléverser et de télécharger des images Docker.</bootnote> 
 + 
 +Ainsi, on est pas obligé de reconstruire les images chaque fois que l'on veut les utiliser, on peut les partager avec qui on veut, et on maîtrise l'infrastructure de bout en bout. 
 + 
 +## Utilisation 
 + 
 +<bootnote web>Notre registre privé est déployé avec les fichiers présents sur le dépôt [registry](https://gitlab.utc.fr/picasoft/projets/services/registry) (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]).</bootnote> 
 + 
 +On peut alors pousser des images sur le registre comme suit :
  
 <code bash> <code bash>
 +# Exemple de construction d'image
 $ docker build -t monimage . $ docker build -t monimage .
 $ docker tag monimage registry.picasoft.net/monimage:v1 $ docker tag monimage registry.picasoft.net/monimage:v1
 +# Pourrait être
 +$ docker-compose build
 +# Pousser l'image sur le registre privé
 $ docker push registry.picasoft.net/monimage:v1 $ docker push registry.picasoft.net/monimage:v1
 </code> </code>
  
-<bootnote warning>Sur les clientil faut au préalable se connecter au registre de production. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass)</bootnote>+Sur une autre machinela récupération de l'image est symétrique :
  
 +<code bash>
 +$ docker pull registry.picasoft.net/monimage:v1
 +</code>
 +
 +<bootnote warning>Sur les client, il faut au préalable se connecter au registre de production. Les identifiants sont les mêmes que sur les machines, le wiki, le Cloud...
 <code bash> <code bash>
 $ docker login registry.picasoft.net $ docker login registry.picasoft.net
-Username (pica)pica+Username: <ton login>
 Password: Password:
 Login Succeeded Login Succeeded
 </code> </code>
- 
- 
-=====Archi Picasoft===== 
-Picasoft possède son propre registry privé. Celui-ci se trouve sur la machine ''monitoring''. 
  • technique/docker/general/mise_en_place_d_un_registry_docker.1602093234.txt.gz
  • de qduchemi