Geekly articles weekly

Conteneurs pour adultes (partie 01): un guide pratique de la terminologie

Vous vous demandez peut-être pourquoi traiter avec la terminologie si le concept de conteneurs semble assez simple et direct? Cependant, bien souvent, l'utilisation incorrecte des termes crée des obstacles au développement de conteneurs. Par exemple, les gens pensent souvent que les termes «conteneurs» et «images» sont utilisés de manière interchangeable, bien qu'il existe en fait d'importantes différences conceptuelles entre eux. Autre exemple: dans le monde des conteneurs, un «référentiel» ne signifie pas ce que vous pensez. De plus, la technologie des conteneurs est bien plus qu'un simple docker.



Ainsi, sans connaître la terminologie, il sera difficile de comprendre en quoi docker diffère de CRI-O, rkt ou lxc / lxd; ou évaluer le rôle de l'Open Container Initiative dans la normalisation des technologies de conteneurs.

Présentation


Commencer avec les conteneurs Linux est très simple, mais il s'avère rapidement que cette simplicité est trompeuse. Cela se produit généralement comme ceci: après avoir passé quelques minutes à installer un docker ou un autre moteur de conteneur, vous entrez déjà vos premières commandes. Juste quelques minutes - et vous avez déjà créé votre première image du conteneur et l'avez placée dans le domaine public. Ensuite, vous passez habituellement à l'architecture de l'environnement de production, puis soudain vous vous rendez compte que pour cela, vous devez d'abord faire face à la masse des termes et des technologies qui sont derrière tout cela. Pire encore, bon nombre des termes énumérés ci-dessous sont utilisés de manière interchangeable, ce qui crée beaucoup de confusion pour les débutants.

  • Conteneur
  • Image
  • Image du conteneur
  • Couche d'image
  • Registre
  • Dépôt
  • Tag
  • Image de base
  • Image de la plateforme
  • Couche

Après avoir maîtrisé la terminologie présentée dans ce document, vous comprendrez mieux la base technologique des conteneurs. De plus, cela vous aidera, vous et vos collègues, à parler le même langage, ainsi qu'à concevoir consciemment et délibérément l'architecture des environnements de conteneurs en fonction des spécificités des tâches à résoudre. À son tour, du point de vue de la communauté informatique et de l'industrie dans son ensemble, une augmentation générale de la compréhension des technologies de conteneurs contribue à l'émergence de nouvelles architectures et solutions. Notez que cet article est destiné à un lecteur qui a déjà une idée de la façon d'exécuter des conteneurs.

Conteneurs: notions de base


Avant de passer à la terminologie des conteneurs, nous déterminerons ce qu'est en fait le conteneur lui-même. Le terme «conteneur» signifie deux choses à la fois. Comme un programme Linux classique, un conteneur peut être dans l'un des deux états: fonctionnel et non fonctionnel. À l'état inactif, le conteneur est un fichier ou un ensemble de fichiers stockés sur le disque. C'est à cet état que se réfèrent les termes Container Image et Container Repository. Lorsque vous entrez la commande de lancement de conteneur, le moteur de conteneur décompresse les fichiers et les métadonnées nécessaires et les transfère au noyau Linux. Le démarrage d'un conteneur est très similaire au démarrage d'un processus Linux normal et nécessite un appel d'API au noyau Linux. Cet appel d'API lance généralement une isolation supplémentaire et monte une copie des fichiers qui se trouvent dans l'image du conteneur. Une fois le conteneur lancé, il ne s'agit que d'un processus Linux. La procédure de lancement des conteneurs, ainsi que le format des images des conteneurs stockés sur disque, sont définis et réglementés par des normes.

Il existe plusieurs formats pour les images de conteneurs ( Docker , Appc , LXD ), mais l'industrie évolue progressivement vers une seule norme Open Container Initiative , parfois appelée Open Containers ou simplement OCI. Cette norme définit la spécification du format d'image de conteneur , qui définit le format de disque pour le stockage des images de conteneur, ainsi que les métadonnées, qui, à leur tour, définissent des éléments tels que l'architecture matérielle et le système d'exploitation (Linux, Windows, etc.). Un format d'image standard unique est la clé pour créer un écosystème logiciel qui permet aux développeurs, aux projets Open Source et aux éditeurs de logiciels de créer des images compatibles et divers outils, tels que la signature électronique, la numérisation, l'assemblage, le lancement, le déplacement et la gestion des images de conteneurs.

En outre, il existe plusieurs moteurs de conteneurs, tels que Docker , CRI-O , Railcar , RKT , LXC . Le moteur de conteneur prend une image du conteneur et le transforme en conteneur (c'est-à-dire un processus en cours d'exécution). Le processus de conversion est également défini par la norme OCI, qui comprend une spécification d'exécution de conteneur et une implémentation de référence d'exécution appelée RunC, qui est un modèle open source réglementé par la communauté de développement appropriée. De nombreux moteurs de conteneur utilisent ce modèle pour interagir avec le noyau hôte lors de la création de conteneurs.

Les outils qui prennent en charge les spécifications du format d'image de conteneur et l'environnement d'exécution de conteneur de la norme OCI offrent une portabilité au sein de l'écosystème de diverses plates-formes de conteneurs, moteurs de conteneurs et outils de support sur diverses plates-formes cloud et architectures locales. Comprendre la terminologie, les normes et l'architecture des systèmes de conteneurs vous permettra de communiquer avec d'autres spécialistes et de concevoir des applications et des environnements conteneurisés évolutifs et pris en charge qui garantissent l'utilisation efficace des conteneurs pour les années à venir.

Vocabulaire de base


Image du conteneur


Dans sa définition la plus simple, une image de conteneur est un fichier téléchargé à partir du serveur de registre et utilisé localement comme point de montage au démarrage du conteneur. Bien que le terme «image de conteneur» soit utilisé assez souvent, il peut signifier différentes choses. Le fait est que bien que Docker, RKT et même LXD fonctionnent selon le principe qui vient d'être décrit - c'est-à-dire qu'ils téléchargent les fichiers supprimés et les exécutent en tant que conteneurs - chacune de ces technologies interprète l'image du conteneur à sa manière. LXD fonctionne avec des images monolithiques (monocouche), tandis que docker et RKT utilisent des images OCI, qui peuvent contenir plusieurs couches.

À strictement parler, une image de conteneur sur un serveur de registre est loin d'être un seul fichier. Lorsque les gens utilisent le terme «image de conteneur», ils désignent souvent le référentiel et un ensemble de plusieurs couches de l'image de conteneur, ainsi que des métadonnées qui contiennent des informations supplémentaires sur ces couches.

De plus, le concept d'image conteneur implique implicitement l'existence d'un format pour une telle image.

Format d'image du conteneur


Initialement, chaque moteur de conteneur, y compris LXD, RKT et Docker, avait son propre format d'image. Certains de ces formats n'autorisent qu'une seule couche, tandis que d'autres prennent en charge une arborescence de plusieurs couches. Aujourd'hui, presque tous les principaux outils et moteurs de conteneur sont passés au format OCI , qui détermine comment les couches et les métadonnées doivent être organisées dans l'image du conteneur. En substance, le format OCI définit une image de conteneur qui se compose de fichiers tar séparés pour chaque couche et d'un fichier manifest.json commun contenant des métadonnées.

La norme Open Container Initiative (OCI) , qui était à l'origine basée sur le format d'image Docker V2 , a réussi à combiner un vaste écosystème de moteurs de conteneurs, de plates-formes cloud et d'outils (scanners de sécurité, outils de signature, création et déplacement de conteneurs) et vous permet de protéger votre investissement dans les connaissances et des outils.

Moteur de conteneur


Le moteur de conteneur est la partie du logiciel qui accepte les demandes des utilisateurs, y compris les paramètres de ligne de commande, télécharge les images et, du point de vue de l'utilisateur final, lance les conteneurs. Il existe de nombreux moteurs de conteneurs, dont Docker, RKT, CRI-O et LXD. En outre, de nombreuses plates-formes cloud, services PaaS et plates-formes de conteneurs ont leurs propres moteurs qui comprennent les images au format Docker ou OCI. Le fait d'avoir une norme industrielle pour le format d'image garantit l'interopérabilité de toutes ces plateformes.

En descendant d'un niveau, nous pouvons dire que la plupart des moteurs de conteneur ne démarrent pas réellement les conteneurs eux-mêmes, mais via un runtime compatible OCI, comme runc. En règle générale, un runtime de conteneur effectue les opérations suivantes:

  • Gère les paramètres, entrée utilisateur
  • Gère les paramètres transmis via l'API (le plus souvent le système d'orchestration de conteneurs)
  • Télécharger des images de conteneur depuis le serveur de registre
  • Décompresse et enregistre l'image du conteneur sur le disque à l'aide du pilote graphique (bloc ou fichier, selon le pilote)
  • Prépare un point de montage pour le conteneur, généralement dans un stockage de copie sur écriture (à nouveau, bloc ou fichier, selon le pilote)
  • Prépare les métadonnées qui seront transmises au runtime pour exécuter correctement le conteneur en utilisant:
    • Paramètres par défaut spécifiques implicites pour l'image du conteneur (par exemple, ArchX86 )
    • Entrée utilisateur pour remplacer les valeurs par défaut contenues dans l'image du conteneur (par exemple, CMD, ENTRYPOINT)
    • Paramètres par défaut spécifiés par l'image du conteneur (par exemple, règles SECCOM )
  • Appelle l'exécution du conteneur

Conteneur


Les conteneurs existent dans les systèmes d'exploitation depuis un certain temps, car il ne s'agit en fait que d'une instance en cours d'exécution d'une image de conteneur. Un conteneur est un processus Linux standard qui est généralement créé à l'aide de l'appel système clone () au lieu de fork () ou exec (). De plus, des mesures d'isolement supplémentaires sont souvent appliquées aux conteneurs à l'aide de cgroups , SELinux ou AppArmor .

Hôte de conteneur


Un hôte de conteneur est un système sur lequel s'exécutent des processus conteneurisés, souvent appelés conteneurs pour plus de simplicité. Il peut s'agir, par exemple, d'une machine virtuelle RHEL Atomic Host située dans un cloud public ou exécutée sur du métal nu dans un centre de données d'entreprise. Lorsque l'image de conteneur (en d'autres termes, le référentiel) du serveur de registre est téléchargée sur l'hôte de conteneur local, ils disent qu'elle tombe dans le cache local.

Vous pouvez déterminer quels référentiels sont synchronisés avec le cache local à l'aide de la commande suivante:

  [root @ rhel7 ~] # images docker -a

 ID D'IMAGE D'ÉTIQUETTE DE RÉFÉRENTIEL FORMAT VIRTUEL CRÉÉ
 registry.access.redhat.com/rhel7 dernière 6883d5422f4e il y a 3 semaines 201,7 Mo

Serveur de registre


Un serveur de registre est essentiellement un serveur de fichiers utilisé pour stocker des référentiels Docker. En règle générale, le serveur de registre est spécifié par le nom DNS et, éventuellement, le numéro de port. La plupart des avantages de l'écosystème Docker sont dus à la possibilité de télécharger et de télécharger des référentiels sur des serveurs de registre.

Si le démon docker ne trouve pas de copie du référentiel dans le cache local, il la télécharge automatiquement à partir du serveur de registre. Sur la plupart des distributions Linux, le démon docker utilisera le site docker.io pour cela, mais sur certaines distributions, il peut être configuré à sa manière. Par exemple, Red Hat Enterprise Linux essaie d'abord de télécharger à partir de registry.access.redhat.com, puis seulement à partir de docker.io (Docker Hub).

Il faut souligner ici que le serveur de registre est implicitement considéré comme fiable. Par conséquent, vous devez décider dans quelle mesure vous faites confiance au contenu d'un registre et, respectivement, l'autoriser ou le refuser. Outre la sécurité, d'autres aspects doivent être traités à l'avance, par exemple les problèmes de licence logicielle ou la surveillance de la conformité. La simplicité avec laquelle Docker permet aux utilisateurs de télécharger des logiciels rend la question de la confiance extrêmement importante.

Red Hat Enterprise Linux vous permet de configurer le registre Docker par défaut. De plus, RHEL7 et RHEL7 Atomic vous permettent d'ajouter ou de verrouiller des serveurs de registre via le fichier de configuration :

  vi / etc / sysconfig / docker

RHEL7 et RHEL 7 Atomic utilisent le serveur de registre Red Hat par défaut:

  ADD_REGISTRY = '- add-registry registry.access.redhat.com'

Dans certains cas, pour des raisons de sécurité, il est logique de bloquer les registres de docker publics, tels que DockerHub:

  # BLOCK_REGISTRY = '- bloc-registre'

Red Hat propose également son serveur de registre intégré dans le cadre de la plate - forme de conteneur OpenShift , ainsi que le serveur de registre d'entreprise autonome Quay Enterprise et le cloud, les référentiels privés et publics Quay.io.

Orchestration de conteneurs


Les gens commencent généralement par installer un hôte de conteneur et téléchargent d'abord les images de conteneur dont ils ont besoin. Ensuite, ils procèdent à la création de leurs propres images et les téléchargent sur le serveur de registre pour les mettre à la disposition du reste de l'équipe. Après un certain temps, il est nécessaire de combiner plusieurs conteneurs afin qu'ils puissent être déployés en une seule unité. Et enfin, à un moment donné, ces unités doivent faire partie du convoyeur de production (développement-QA-production). C'est ainsi que les gens réalisent généralement qu'ils ont besoin d'un système d'orchestration.

Le système d'orchestration de conteneurs n'implémente que deux choses:

  1. Répartir dynamiquement les chargements de conteneurs sur les ordinateurs du cluster (ce que l'on appelle souvent «informatique distribuée»)
  2. Fournit un fichier de description d'application standard (kube yaml, docker compose, etc.)

Ces deux choses offrent en fait une gamme d'avantages:

  1. La possibilité de gérer les conteneurs qui composent l'application, indépendamment les uns des autres, ce qui vous permet de résoudre efficacement les tâches suivantes:
    • Élimination des grands clusters hôtes de conteneurs
    • Défaillance au niveau des conteneurs individuels (processus ne répondant plus, épuisement de la mémoire)
    • Basculement au niveau de l'hôte du conteneur (lecteurs, réseau, redémarrage)
    • Basculement au niveau du moteur du conteneur (avarie, redémarrage)
    • Mise à l'échelle individuelle des conteneurs de haut en bas
  2. Déploiement facile de nouvelles instances de la même application dans de nouveaux environnements, à la fois cloud et traditionnels, par exemple:
    • Sur les machines de développement contrôlées par un système d'orchestration
    • Dans un environnement de développement partagé dans un espace de noms privé
    • Dans un environnement de développement commun dans un espace de noms public interne pour garantir la visibilité et les performances des tests
    • Dans l'environnement interne de QA
    • Dans un environnement de charge de test fourni dynamiquement et révoqué dans le cloud
    • Dans un environnement de référence pour vérifier la compatibilité avec l'environnement de production
    • En environnement de production
    • Dans un environnement de reprise après sinistre
    • Dans un nouvel environnement de production contenant des hôtes de conteneurs, des moteurs de conteneurs ou des outils d'orchestration mis à jour
    • Dans le nouvel environnement de production, qui n'est pas différent du principal, mais situé dans une région différente

Les communautés Open Source et les éditeurs de logiciels proposent de nombreux outils d'orchestration différents. Au départ, les trois grands de ces outils incluaient Swarm , Mesos et Kubernetes , mais aujourd'hui Kubernetes est devenu la norme de l'industrie, car même Docker et Mesosphere ont annoncé leur soutien, sans parler de presque tous les principaux fournisseurs de services. Cependant, si vous recherchez un système d'orchestration d'entreprise, nous vous recommandons de regarder de plus près Red Hat OpenShift .

Dictionnaire avancé


Exécution du conteneur


Le runtime du conteneur est un composant de bas niveau qui est généralement utilisé dans le cadre d'un moteur de conteneur, mais peut également être utilisé manuellement pour tester les conteneurs. La norme OCI définit une implémentation de référence du runtime connue sous le nom de runc . Il s'agit de l'implémentation la plus utilisée, mais il existe d'autres temps d'exécution compatibles OCI tels que les conteneurs Crun , Railcar et katacontainers . Docker, CRI-O et de nombreux autres moteurs de conteneurs utilisent runc.

Le runtime du conteneur est responsable des éléments suivants:

  • Obtient le point de montage du conteneur fourni par le moteur de conteneur (pour les tests, il pourrait simplement s'agir d'un répertoire)
  • Obtient les métadonnées de conteneur fournies par le moteur de conteneur (pendant les tests, il peut s'agir d'un fichier config.json assemblé manuellement)
  • Communique avec le noyau du système d'exploitation pour lancer des processus conteneurisés (via l'appel système clone)
  • Configure les groupes de contrôle
  • Configure la politique SELinux
  • Configure les règles d'armure d'application

Petite parenthèse historique: lorsque le moteur Docker est apparu pour la première fois, il utilisait le LXC comme environnement d'exécution. Les développeurs Docker ont ensuite écrit leur propre bibliothèque pour exécuter des conteneurs appelés libcontainer. Il a été écrit dans la langue Golang et est devenu une partie du moteur Docker. Après la création de l'organisation OCI, Docker a introduit le code source libcontainer dans ce projet et a publié cette bibliothèque en tant qu'utilitaire distinct appelé runc, qui est ensuite devenu l'implémentation de référence du runtime du conteneur dans la norme OCI et est utilisé dans d'autres moteurs de conteneur, tels que CRI-O . Runc est un utilitaire très simple qui n'attend qu'un point de montage (répertoire) et des métadonnées (config.json) pour lui être transmis. Vous trouverez plus d'informations sur runc ici .

Pour une compréhension plus approfondie, voir Présentation des normes de conteneur et de l' exécution du conteneur .

Couches d'images


Les référentiels sont souvent appelés images ou images de conteneurs, bien qu'en réalité les référentiels se composent d'une ou plusieurs couches. Les couches d'image du référentiel sont interconnectées par les relations parent-enfant, et chaque couche d'image contient des différences par rapport à la couche parent.

Examinons les couches de référentiel sur l'hôte de conteneur local. Depuis le démarrage de la version 1.7, Docker ne dispose d'aucun outil intégré pour afficher les couches d'images dans le référentiel local (mais il existe des outils pour les registres en ligne), nous utiliserons l'utilitaire Dockviz . Notez que chaque couche a une balise et un identifiant unique universel (UUID) . Pour afficher les UUID abrégés qui sont généralement uniques au sein de la même machine, nous utilisons la commande suivante (si vous avez besoin d'un UUID complet, utilisez la même commande avec l'option -no-trunc):

docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock nate / dockviz images -t

  ├─2332d8973c93 Taille virtuelle: 187,7 Mo
  Virtual └─ea358092da77 Taille virtuelle: 187,9 Mo
  Virtual └─a467a7c6794f Taille virtuelle: 187,9 Mo
  │ └─ca4d7b1b9a51 Taille virtuelle: 187,9 Mo
  Virtual └─4084976dd96d Taille virtuelle: 384,2 Mo
  Virtual └─943128b20e28 Taille virtuelle: 386,7 Mo
  │ └─db20cc018f56 Taille virtuelle: 386,7 Mo
  │ └─45b3c59b9130 Taille virtuelle: 398,2 Mo
  Virtual └─91275de1a5d7 Taille virtuelle: 422,8 Mo
  Virtual └─e7a97058d51f Taille virtuelle: 422,8 Mo
  │ └─d5c963edfcb2 Taille virtuelle: 422,8 Mo
  │ └─5cfc0ce98e02 Taille virtuelle: 422,8 Mo
  Virtual └─7728f71a4bcd Taille virtuelle: 422,8 Mo
  │ └─0542f67da01b Taille virtuelle: 422,8 Mo Tags: docker.io/registry:latest

Comme vous pouvez le voir, le référentiel docker.io/registry se compose en fait de plusieurs couches. Cependant, plus important encore, l'utilisateur peut, en principe, «démarrer» le conteneur à partir de n'importe quelle étape de cette échelle, par exemple, en entrant la commande ci-dessous (c'est tout à fait correct, mais personne ne peut garantir qu'il a été testé ou fonctionnera correctement). En règle générale, le collecteur d'images marque (crée des noms) les couches qui doivent être utilisées comme point de départ:

  docker run -it 45b3c59b9130 bash

Les référentiels sont organisés de la même manière car chaque fois que le collecteur crée une nouvelle image, les différences sont enregistrées sous un autre calque. Il existe deux façons principales de créer de nouvelles couches dans le référentiel. Tout d'abord, lors de la création manuelle d'une image, chaque confirmation de modification crée un nouveau calque. Si le collecteur crée une image à l'aide d'un fichier Docker, chaque directive du fichier crée un nouveau calque. Par conséquent, il est toujours utile de pouvoir voir ce qui a changé dans le référentiel entre les couches.

Balises


Bien que l'utilisateur lui-même puisse spécifier la couche de départ pour le montage et le démarrage du conteneur dans le référentiel, il n'a pas du tout à le faire. Lorsque le collecteur d'images crée un nouveau référentiel, ils marquent généralement les calques les plus appropriés pour ce rôle. Ces marqueurs sont appelés balises et représentent un outil avec lequel le collecteur d'images peut indiquer au consommateur d'images quelles couches sont les mieux utilisées. En règle générale, les balises sont utilisées pour indiquer les versions logicielles dans un référentiel.Cependant, ni OCI, ni aucune autre norme ne réglemente l'utilisation des balises, ce qui ouvre un champ illimité de confusion pendant la collaboration. Par conséquent, nous vous recommandons de documenter soigneusement les balises si elles sont utilisées non seulement pour marquer les versions logicielles.

De plus, il existe une balise spéciale - latest, qui pointe généralement vers une couche contenant les derniers logiciels dans le référentiel. Cette balise pointe simplement vers la couche d'image, comme toute autre balise, et peut donc également être utilisée de manière incorrecte.

Pour afficher à distance les balises disponibles dans le référentiel, exécutez la commande suivante (l' utilitaire jq rend la sortie beaucoup plus lisible):

curl -s registry.access.redhat.com/v1/repositories/rhel7/tags | jq
  {
 "7.0-21": "e1f5733f050b2488a17b7630cb038bfbea8b7bdfa9bdfb99e63a33117e28d02f",
 "7.0-23": "bef54b8f8a2fdd221734f1da404d4c0a7d07ee9169b1443a338ab54236c8c91a",
 "7.0-27": "8e6704f39a3d4a0c82ec7262ad683a9d1d9a281e3c1ebbb64c045b9af39b3940",
 "7.1-11": "d0a516b529ab1adda28429cae5985cab9db93bfd8d301b3a94d22299af72914b",
 "7.1-12": "275be1d3d0709a06ff1ae38d0d5402bc8f0eeac44812e5ec1df4a9e99214eb9a",
 "7.1-16": "82ad5fa11820c2889c60f7f748d67aab04400700c581843db0d1e68735327443",
 "7.1-24": "c4f590bbcbe329a77c00fea33a3a960063072041489012061ec3a134baba50d6",
 "7.1-4": "10acc31def5d6f249b548e01e8ffbaccfd61af0240c17315a7ad393d022c5ca2",
 "7.1-6": "65de4a13fc7cf28b4376e65efa31c5c3805e18da4eb01ad0c8b8801f4a10bc16",
 "7.1-9": "e3c92c6cff3543d19d0c9a24c72cd3840f8ba3ee00357f997b786e8939efef2f",
 "7.2": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "7.2-2": "58958c7fafb7e1a71650bc7bdbb9f5fd634f3545b00ec7d390b2075db511327d",
 "7.2-35": "6883d5422f4ec2810e1312c0e3e5a902142e2a8185cd3a1124b459a7c38dc55b",
 "7.2-38": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "latest": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e"
  }


docker , . , «rhel7» – .

 docker pull rhel7

:

 docker pull registry.access.redhat.com/rhel7:latest

, . , , , docker images. , , , «» (manifest.json):

 docker images

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
 registry.access.redhat.com/rhel7 latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel6 latest 05c3d56ba777 4 weeks ago 166.1 MB
 registry.access.redhat.com/rhel6/rhel latest 05c3d56ba777 4 weeks ago 166.1 MB
  ...

, . docker ( , ) , «rhel7» .

, docker URL. , , URL .



, :

 REGISTRY/NAMESPACE/REPOSITORY[:TAG]

Une URL complète se compose d'un nom de serveur, d'un espace de noms et éventuellement d'une balise. En fait, il y a beaucoup de nuances lors de la spécification d'une URL, et en explorant l'écosystème des dockers, vous verrez que beaucoup de choses sont facultatives. En particulier, regardez les commandes ci-dessous: toutes sont correctes et conduisent au même résultat:

 docker pull registry.access.redhat.com/rhel7/rhel:latest
 docker pull registry.access.redhat.com/rhel7/rhel
 docker pull registry.access.redhat.com/rhel7
 docker pull rhel7 / rhel: dernier

Espaces de noms


– . DockerHub , , .

Red Hat , Red Hat Federated Registry . registry.access.redhat.com . , . , Red Hat , - :

 registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/openshift3/mongodb-24-rhel7
registry.access.redhat.com/rhscl/mongodb-26-rhel7
registry.access.redhat.com/rhscl_beta/mongodb-26-rhel7
Registry-mariadbcorp.rhcloud.com/rhel7/mariadb-enterprise-server:10.0

Veuillez noter que parfois l'URL complète peut ne pas être spécifiée. Dans l'exemple ci-dessus, pour chaque espace de noms, il existe un référentiel par défaut. Si l'utilisateur spécifie uniquement l'espace de noms fedora, le référentiel avec la dernière balise est téléchargé sur le serveur local. Par conséquent, les commandes ci-dessous conduisent au même résultat:

 docker pull fedora
docker pull docker.io/fedora
docker pull docker.io/library/fedora:latest

Espaces de noms du noyau


, , . , , , , , . , , , . .

Bash Enter, Bash Linux- exec() . , , docker, docker , clone() . clone () , , , , , ..

, Linux - , clone ().


…

Source: https://habr.com/ru/post/fr416169/

More articles:


All Articles