official images
1.0.0
Les images officielles Docker sont des images organisées hébergées sur Docker Hub. Les principes principaux sont :
Focus sur les logiciels libres et open source
Prise en charge de plusieurs architectures
Illustrer les meilleures pratiques Dockerfile
Reconstruire activement pour les mises à jour et les correctifs de sécurité
Adhérer aux recommandations en amont
Ajoutez un comportement de qualité de vie minimal pour l'environnement du conteneur, le cas échéant
Consultez la documentation de Docker pour un bon aperçu de haut niveau du programme.
Essentiellement, nous nous efforçons de tenir compte des recommandations formulées en amont sur la manière dont ils envisagent d'utiliser leurs logiciels. De nombreuses images sont conservées en collaboration avec le projet en amont concerné si elles ne sont pas gérées directement par eux. De plus, nous visons à illustrer les meilleures pratiques pour les Dockerfiles afin de servir de référence lors de la création ou de la dérivation de vos propres images.
(Si vous êtes le représentant d'un amont pour lequel il existe une image et que vous souhaitez vous impliquer, veuillez consulter la section Maintien ci-dessous !)
Certaines images ont été portées pour d'autres architectures, et beaucoup d'entre elles sont officiellement prises en charge (à des degrés divers).
arm32v6 ) : https://hub.docker.com/u/arm32v6/arm32v7 ) : https://hub.docker.com/u/arm32v7/arm64v8 ) : https://hub.docker.com/u/arm64v8/amd64 ) : https://hub.docker.com/u/amd64/windows-amd64 ) : https://hub.docker.com/u/winamd64/arm32v5 ) : https://hub.docker.com/u/arm32v5/ppc64le ) : https://hub.docker.com/u/ppc64le/s390x ) : https://hub.docker.com/u/s390x/mips64le ) : https://hub.docker.com/u/mips64le/riscv64 ) : https://hub.docker.com/u/riscv64/i386 ) : https://hub.docker.com/u/i386/ Depuis le 12/09/2017, ces autres architectures sont incluses sous les images non préfixées via des « listes de manifestes » (également appelées « index » dans la spécification d'image OCI), de sorte que, par exemple, docker run hello-world devrait s'exécute tel quel sur toutes les plates-formes prises en charge.
Si vous êtes curieux de savoir comment ceux-ci sont construits, rendez-vous sur https://doi-janky.infosiftr.net/job/multiarch/ pour voir l'échafaudage de construction.
Consultez la section multi-arch ci-dessous pour obtenir des recommandations sur l'ajout de plus d'architectures à une image officielle.
Oui! Nous disposons d'un référentiel FAQ dédié dans lequel nous essayons de collecter d'autres questions courantes (à la fois sur le programme et sur nos pratiques).
Merci de votre intérêt pour le projet d'images officielles Docker ! Nous nous efforçons de rendre ces instructions aussi simples et directes que possible, mais si vous vous trouvez perdu, n'hésitez pas à nous contacter sur Libera.Chat IRC dans le canal #docker-library ou en créant un problème GitHub ici.
Assurez-vous de vous familiariser avec les référentiels officiels sur Docker Hub et les meilleures pratiques d'écriture de fichiers Docker dans la documentation Docker. Celles-ci constitueront la base du processus de révision effectué par les responsables officiels des images. Si vous souhaitez que le processus de révision se déroule plus facilement, veuillez vous assurer que vos Dockerfile respectent tous les points mentionnés ici, ainsi que ci-dessous, avant de soumettre une pull request.
De plus, les descriptions Hub de ces images sont actuellement stockées séparément dans le référentiel docker-library/docs , dont le fichier README.md explique plus en détail comment il est structuré et comment y contribuer. Soyez prêt à y soumettre également un PR, en attendant l'acceptation de votre image ici.
Étant donné que les images officielles sont destinées à être des outils d'apprentissage pour ceux qui découvrent Docker ainsi que des images de base pour les utilisateurs avancés pour créer leurs versions de production, nous examinons chaque Dockerfile proposé pour nous assurer qu'il répond à une norme minimale de qualité et de maintenabilité. Bien qu'une partie de cette norme soit difficile à définir (en raison de la subjectivité), autant que possible est définie ici, tout en adhérant aux « meilleures pratiques », le cas échéant.
Une liste de contrôle qui peut être utilisée par les responsables lors de la révision peut être trouvée dans NEW-IMAGE-CHECKLIST.md .
Les changements de version et les correctifs de sécurité doivent être traités en temps opportun.
Si vous ne représentez pas l'amont et que l'amont s'intéresse à la maintenance de l'image, des mesures doivent être prises pour assurer une transition en douceur de la maintenance de l'image vers l'amont.
Pour les responsables en amont souhaitant prendre en charge la maintenance d'un référentiel existant, la première étape consiste à s'impliquer dans le référentiel existant. Faire des commentaires sur les problèmes, proposer des changements et se faire connaître au sein de la « communauté d'images » (même si cette « communauté » n'est que le responsable actuel) sont autant de points de départ importants pour garantir que la transition ne soit pas surprenante pour les contributeurs et les utilisateurs existants.
Lors de la reprise d'un référentiel existant, assurez-vous que l'intégralité de l'historique Git du référentiel d'origine est conservée dans le nouveau référentiel maintenu en amont pour vous assurer que le processus de révision n'est pas bloqué pendant la transition. Ceci est plus facilement accompli en créant le nouveau à partir du référentiel existant, mais peut également être accompli en récupérant les commits directement à partir de l'original et en les poussant dans le nouveau dépôt (c'est-à-dire, git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). Sur GitHub, une alternative consiste à déplacer la propriété du référentiel git. Cela peut être accompli sans donner à l'un ou l'autre des groupes l'accès administrateur au référentiel de l'autre propriétaire :
La reconstruction du même Dockerfile devrait entraîner la même version de l'image étant empaquetée, même si la deuxième build se produit plusieurs versions plus tard, ou la build devrait échouer complètement, de sorte qu'une reconstruction par inadvertance d'un Dockerfile marqué comme 0.1.0 ne se termine pas contenant 0.2.3 . Par exemple, si vous utilisez apt pour installer le programme principal de l'image, assurez-vous de l'épingler sur une version spécifique (ex : ... apt-get install -y my-package=0.1.0 ... ). Pour les packages dépendants installés par apt il n'est généralement pas nécessaire de les épingler sur une version.
Aucune image officielle ne peut être dérivée ou dépendre d'images non officielles (autorisant les scratch non liées à l'image et les exceptions intentionnellement limitées épinglées dans .external-pins -- voir aussi .external-pins/list.sh ).
Toutes les images officielles doivent fournir une interface cohérente. Un utilisateur débutant devrait être capable d' docker run official-image bash (ou sh ) sans avoir besoin de se renseigner sur --entrypoint . Il est également intéressant pour les utilisateurs avancés de profiter du point d'entrée, afin de pouvoir docker run official-image --arg1 --arg2 sans avoir à spécifier le binaire à exécuter.
Si le processus de démarrage n'a pas besoin d'arguments, utilisez simplement CMD :
CMD [ "irb" ] Si une initialisation doit être effectuée au démarrage, comme la création de la base de données initiale, utilisez un ENTRYPOINT avec CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Assurez-vous que docker run official-image bash (ou sh ) fonctionne également. Le moyen le plus simple est de vérifier la commande attendue et s'il s'agit d'autre chose, exec "$@" (exécutez tout ce qui a été passé, en gardant correctement les arguments échappés).
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ " Si l'image ne contient que l'exécutable principal et ses bibliothèques liées (c'est-à-dire pas de shell), alors vous pouvez utiliser l'exécutable comme ENTRYPOINT , puisque c'est la seule chose qui peut s'exécuter :
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] L'indicateur le plus courant permettant de savoir si cela est approprié est que l'image Dockerfile commence par scratch ( FROM scratch ).
Essayez de rendre le Dockerfile facile à comprendre/lire. Il peut être tentant, par souci de concision, de regrouper les détails d'initialisation compliqués dans un script autonome et d'ajouter simplement une commande RUN dans le Dockerfile . Cependant, cela rend le Dockerfile résultant trop opaque et il est peu probable que de tels Dockerfile soient examinés. Au lieu de cela, il est recommandé de placer toutes les commandes d'initialisation dans le Dockerfile en tant que combinaisons de commandes RUN ou ENV appropriées. Pour trouver de bons exemples, regardez les images officielles actuelles.
Quelques exemples au moment de la rédaction :
Conformément aux directives Docker, il est fortement recommandé que l'image résultante ne représente qu'une seule préoccupation par conteneur ; cela signifie principalement un seul processus par conteneur, il n'est donc pas nécessaire d'avoir un système d'initialisation complet. Il existe deux situations dans lesquelles un processus de type init serait utile pour le conteneur. Le premier étant la gestion du signal. Si le processus lancé ne gère pas SIGTERM en quittant, il ne sera pas tué puisqu'il s'agit du PID 1 dans le conteneur (voir "REMARQUE" à la fin de la section Premier plan dans la documentation du docker). La deuxième situation serait la récolte de zombies. Si le processus génère des processus enfants et ne les récupère pas correctement, cela conduira à une table de processus complète, ce qui peut empêcher l'ensemble du système de générer de nouveaux processus. Pour ces deux problèmes, nous recommandons tini. Il est incroyablement petit, a des dépendances externes minimes, remplit chacun de ces rôles et ne fait que les parties nécessaires de récolte et de transmission du signal.
Assurez-vous d'utiliser tini dans CMD ou ENTRYPOINT selon le cas.
Il est préférable d'installer tini à partir d'un package fourni par la distribution (ex. apt-get install tini ). Si tini n'est pas disponible dans votre distribution ou est trop ancien, voici un extrait de Dockerfile à ajouter dans tini :
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --versionC’est un domaine où l’expérience finit par l’emporter sur la documentation sur le chemin vers l’illumination, mais les conseils suivants peuvent aider :
Évitez COPY / ADD autant que possible, mais si nécessaire, soyez aussi précis que possible (c'est-à-dire COPY one-file.sh /somewhere/ au lieu de COPY . /somewhere ).
La raison en est que le cache des instructions COPY considère les modifications mtime au fichier comme un buste de cache, ce qui peut parfois rendre le comportement du cache de COPY imprévisible, en particulier lorsque .git fait partie de ce qui doit être COPY (par exemple).
Assurez-vous que les lignes les moins susceptibles de changer arrivent avant les lignes les plus susceptibles de changer (avec la mise en garde que chaque ligne doit générer une image qui s'exécute toujours avec succès sans hypothèses sur les lignes ultérieures).
Par exemple, la ligne qui contient le numéro de version du logiciel ( ENV MYSOFTWARE_VERSION 4.2 ) doit suivre une ligne qui configure le fichier .list du référentiel APT ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
Le Dockerfile doit être écrit pour aider à atténuer les attaques d'interception pendant la construction. Nos exigences se concentrent sur trois objectifs principaux : vérifier la source, vérifier l'auteur et vérifier le contenu ; ceux-ci sont respectivement accomplis de la manière suivante : en utilisant https lorsque cela est possible ; importer des clés PGP avec l'empreinte digitale complète dans le Dockerfile pour vérifier les signatures ; intégrer les sommes de contrôle directement dans le Dockerfile . Les trois doivent être utilisés lorsque cela est possible. Seuls https et la somme de contrôle intégrée peuvent être utilisés lorsqu'aucune signature n'est publiée. En dernier recours, seule une somme de contrôle intégrée est acceptable si le site ne dispose pas de https ni de signature.
Le but de recommander l'utilisation de https pour télécharger les artefacts nécessaires est de garantir que le téléchargement provient d'une source fiable, ce qui rend également l'interception beaucoup plus difficile.
L'objectif de la recommandation de la vérification de la signature PGP est de garantir que seul un utilisateur autorisé a publié l'artefact donné. Lors de l'importation de clés PGP, veuillez utiliser le service keys.openpgp.org lorsque cela est possible (en préférant keyserver.ubuntu.com sinon). Voir également la section FAQ sur les clés et la vérification.
Le but de la recommandation de la vérification de la somme de contrôle est de vérifier que l'artefact est comme prévu. Cela garantit que lorsque le contenu distant change, le Dockerfile changera également et fournira un buste naturel du cache docker build . En prime, cela évite également le téléchargement accidentel d’artefacts plus récents que prévu sur des fichiers mal versionnés.
Voici quelques exemples :
Préféré : téléchargement via https, importation complète des empreintes digitales de la clé PGP et vérification asc , somme de contrôle intégrée vérifiée.
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# installAlternative : empreinte digitale complète importée dans apt qui vérifiera les signatures et les sommes de contrôle lorsque les packages seront téléchargés et installés.
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (En remarque, rm -rf /var/lib/apt/lists/* est à peu près le contraire de apt-get update -- il garantit que la couche n'inclut pas les ~ 8 Mo supplémentaires de données de liste de packages APT, et applique une utilisation appropriée apt-get update .)
Alternative moins sécurisée : intégrez la somme de contrôle dans le Dockerfile .
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# installRemarque : l'utilisation de SHA1 ou de MD5 doit être considérée comme une « somme de contrôle de dernier recours », car les deux sont considérés comme généralement dangereux :
Inacceptable : téléchargez le fichier via http(s) sans vérification.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install Par défaut, les conteneurs Docker sont exécutés avec des privilèges réduits : fonctionnalités Linux sur liste blanche, groupes de contrôle et profil Seccomp par défaut (1.10+ avec prise en charge de l'hôte). Les logiciels exécutés dans un conteneur peuvent nécessiter des privilèges supplémentaires pour fonctionner correctement, et il existe un certain nombre d'options de ligne de commande pour personnaliser l'exécution du conteneur. Voir docker run Reference et Seccomp pour Docker pour référence.
Les référentiels officiels qui nécessitent des privilèges supplémentaires doivent spécifier l'ensemble minimal d'options de ligne de commande pour que le logiciel fonctionne, et peuvent toujours être rejetés si cela introduit des problèmes de portabilité ou de sécurité importants. En général, --privileged n'est pas autorisé, mais une combinaison des options --cap-add et --device peut être acceptable. De plus, --volume peut être délicat car il existe de nombreux emplacements du système de fichiers hôte qui introduisent des problèmes de portabilité/sécurité (par exemple, le socket X11).
Pour les mises à jour d'images qui constituent un correctif de sécurité, nous recommandons quelques éléments pour garantir que votre mise à jour est fusionnée, créée et publiée le plus rapidement possible :
[email protected] quelques jours (ouvrés) à l'avance pour nous donner une information et une estimation du calendrier (afin que nous puissions planifier l'heure de la mise à jour entrante de manière appropriée).[security] dans le titre de votre pull request (par exemple, [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). Chaque référentiel peut spécifier plusieurs architectures pour toutes les balises. Si aucune architecture n'est spécifiée, les images sont construites sous Linux sur amd64 (alias x86-64). Pour spécifier des architectures supplémentaires ou différentes, utilisez le champ Architectures (liste délimitée par des virgules, les espaces sont coupés). Les architectures valides se trouvent dans le fichier oci-platform.go de Bashbrew :
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 Les Architectures d'une balise donnée doivent être un sous-ensemble strict des Architectures de la balise dont elle est FROM .
Les images doivent avoir un seul Dockerfile par entrée dans le fichier de bibliothèque qui peut être utilisé pour plusieurs architectures. Cela signifie que chaque architecture prise en charge aura la même ligne FROM (par exemple FROM debian:bookworm ). Voir golang , docker , haproxy et php pour des exemples de fichiers de bibliothèque utilisant un Dockerfile par entrée et consultez leurs dépôts git respectifs par exemple Dockerfile s.
Si différentes parties du Dockerfile n'apparaissent que dans une architecture ou une autre, utilisez le flux de contrôle (par exemple if / case ) avec dpkg --print-architecture ou apk -print-arch pour détecter l'architecture de l'espace utilisateur. Utilisez uniquement uname pour la détection de l'architecture lorsque des outils plus précis ne peuvent pas être installés. Voir golang pour un exemple où certaines architectures nécessitent la création de binaires à partir des packages sources en amont et d'autres téléchargent simplement la version binaire.
Pour les images de base comme debian il sera nécessaire d'avoir un Dockerfile et un contexte de construction différents afin d' ADD des binaires spécifiques à l'architecture et il s'agit d'une exception valable à ce qui précède. Étant donné que ces images utilisent les mêmes Tags , elles doivent figurer dans la même entrée. Utilisez les champs spécifiques à l'architecture pour GitRepo , GitFetch , GitCommit et Directory , qui sont l'architecture concaténée avec un trait d'union ( - ) et le champ (par exemple arm32v7-GitCommit ). Toute architecture qui n'a pas de champ spécifique à l'architecture utilisera le champ par défaut (par exemple, aucun arm32v7-Directory signifie que Directory sera utilisé pour arm32v7 ). Voir les fichiers debian ou ubuntu dans la bibliothèque pour des exemples. Ce qui suit est un exemple pour hello-world :
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
Voir la section format d'instruction pour plus d'informations sur le format du fichier de bibliothèque.
Proposer une nouvelle image officielle ne doit pas être entrepris à la légère. Nous attendons et exigeons un engagement à maintenir votre image (y compris et en particulier des mises à jour en temps opportun, le cas échéant, comme indiqué ci-dessus).
Les fichiers de définition de bibliothèque sont des fichiers de texte brut trouvés dans le répertoire library/ du référentiel official-images . Chaque fichier de bibliothèque contrôle l'ensemble actuel de balises d'image « pris en charge » qui apparaissent dans la description de Docker Hub. Les balises supprimées d'un fichier de bibliothèque ne sont pas supprimées de Docker Hub, de sorte que les anciennes versions peuvent continuer à être utilisées, mais ne sont pas gérées par l'amont ou par le responsable de l'image officielle. Les balises dans le fichier de bibliothèque ne sont construites que via une mise à jour de ce fichier de bibliothèque ou à la suite de la mise à jour de son image de base (c'est-à-dire qu'une image FROM debian:bookworm serait reconstruite lors de la construction debian:bookworm ). Seul ce qui se trouve dans le fichier de bibliothèque sera reconstruit lorsqu'une base aura des mises à jour.
Compte tenu de cette politique, il convient de clarifier quelques cas : les versions remplies, les versions candidates et les versions d'intégration continue. Lorsqu'un nouveau référentiel est proposé, il est courant d'inclure certaines anciennes versions non prises en charge dans la demande d'extraction initiale avec l'accord de les supprimer juste après acceptation. Ne confondez pas cela avec des archives historiques complètes, ce qui n'est pas l'intention. Un autre cas courant où le terme « pris en charge » est un peu étendu est celui des versions candidates. Une version candidate n'est en réalité qu'une convention de dénomination pour ce qui devrait être des versions de plus courte durée, elles sont donc totalement acceptables et encouragées. Contrairement à une version candidate, les versions d'intégration continue qui ont un cycle de publication entièrement automatisé basé sur des validations de code ou un calendrier régulier ne sont pas appropriées.
Il est fortement recommandé de parcourir certains contenus de library/ fichiers existants (et l'historique pour avoir une idée de la façon dont ils évoluent au fil du temps) avant d'en créer un nouveau pour vous familiariser avec les conventions en vigueur et contribuer à rationaliser davantage le processus de révision (ainsi que nous pouvons nous concentrer sur le contenu plutôt que sur le formatage ésotérique ou l'utilisation/la dénomination des balises).
Le nom de fichier d'un fichier de définition déterminera le nom du référentiel d'images qu'il crée sur le Docker Hub. Par exemple, le fichier library/ubuntu créera des balises dans le référentiel ubuntu .
Les balises d'un référentiel doivent refléter les versions ou variantes en amont. Par exemple, Ubuntu 14.04 est également connu sous le nom d'Ubuntu Trusty Tahr, mais souvent simplement sous le nom d'Ubuntu Trusty (en particulier lors de son utilisation), donc ubuntu:14.04 (numéro de version) et ubuntu:trusty (nom de la version) sont des alias appropriés pour le même contenu d'image. Dans Docker, la latest balise est un cas particulier, mais c'est un terme un peu abusif ; latest est vraiment la balise "par défaut". Quand on fait docker run xyz , Docker interprète cela comme signifiant docker run xyz:latest . Dans ce contexte, aucune autre balise ne contient jamais la chaîne latest , car ce n'est pas quelque chose que les utilisateurs sont censés ou encouragés à saisir (c'est-à-dire que xyz:latest devrait en réalité être utilisé simplement comme xyz ). En d'autres termes, avoir un alias pour la "version la plus élevée de la série 2.2 de XYZ" devrait être xyz:2.2 , et non xyz:2.2-latest . De même, s'il existe une variante alpine de xyz:latest , elle doit être alias xyz:alpine , et non xyz:alpine-latest ou xyz:latest-alpine .
Il est fortement recommandé que les balises de numéro de version reçoivent des alias qui permettent à l'utilisateur de rester facilement sur la version "la plus récente" d'une série particulière. Par exemple, étant donné les versions 2.3.7 et 2.2.4 du logiciel XYZ actuellement prises en charge, les alias suggérés seraient respectivement Tags: 2.3.7, 2.3, 2, latest et Tags: 2.2.4, 2.2 . Dans cet exemple, l'utilisateur peut utiliser xyz:2.2 pour utiliser facilement la version de correctif la plus récente de la série 2.2, ou xyz:2 si moins de granularité est nécessaire (Python est un bon exemple de cas où cela est évidemment le plus utile - python:2 et python:3 sont très différents et peuvent être considérés comme la latest balise de chacune des versions majeures de Python).
Comme décrit ci-dessus, latest est vraiment "par défaut", donc l'image pour laquelle il s'agit d'un alias doit refléter la version ou la variante du logiciel que les utilisateurs doivent utiliser s'ils ne savent pas ou ne se soucient pas de la version qu'ils utilisent. En utilisant Ubuntu comme exemple, ubuntu:latest pointe vers la version LTS la plus récente, étant donné que c'est ce que la majorité des utilisateurs devraient utiliser s'ils savent qu'ils veulent Ubuntu mais ne savent pas quelle version ou ne se soucient pas de quelle version (d'autant plus qu'il s'agira de la version la plus récente). version la plus « stable » et la mieux prise en charge à un moment donné).
Le format de fichier manifeste est officiellement basé sur la RFC 2822 et, en tant que tel, devrait être familier aux personnes déjà familiarisées avec les « en-têtes » de nombreux protocoles/formats Internet populaires tels que HTTP ou le courrier électronique.
Les principaux ajouts sont inspirés de la manière dont Debian utilise couramment 2822 : les lignes commençant par # sont ignorées et les « entrées » sont séparées par une ligne vide.
La première entrée concerne les métadonnées « globales » de l’image. Le seul champ obligatoire dans l'entrée globale est Maintainers , dont la valeur est séparée par des virgules au format Name <email> (@github) ou Name (@github) . Tout champ spécifié dans l'entrée globale sera celui par défaut pour le reste des entrées et pourra être remplacé dans une entrée individuelle.
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew récupérera le code du référentiel Git ( GitRepo ) au commit spécifié ( GitCommit ). Si le commit référencé n'est pas disponible en récupérant le master du GitRepo associé, il devient nécessaire de fournir une valeur pour GitFetch afin d'indiquer à Bashbrew quelle référence récupérer afin d'obtenir le commit nécessaire.
L'image construite sera étiquetée comme <manifest-filename>:<tag> (c'est-à-dire, library/golang avec une valeur Tags de 1.6, 1, latest créera des balises de golang:1.6 , golang:1 et golang:latest ).
Facultativement, si Directory est présent, Bashbrew recherchera le Dockerfile dans le sous-répertoire spécifié plutôt qu'à la racine (et Directory sera utilisé comme "contexte" pour la construction au lieu du niveau supérieur du référentiel). Si File est présent, le nom de fichier spécifié au lieu de Dockerfile sera utilisé.
Consultez la section multi-arch pour plus de détails sur la façon de spécifier un GitRepo , GitFetch , GitCommit ou Directory différent pour une architecture spécifique.
library/ . Son nom sera le nom de votre référentiel sur le Hub. Bashbrew ( bashbrew ) est un outil permettant de cloner, de créer, de marquer et de diffuser les images officielles de Docker. Consultez le README de Bashbrew pour plus d'informations.
