official images
1.0.0
Las imágenes oficiales de Docker son imágenes seleccionadas alojadas en Docker Hub. Los principios principales son:
Centrarse en el software gratuito y de código abierto
Admite múltiples arquitecturas
Ejemplifique las mejores prácticas Dockerfile
Reconstrucción activa para actualizaciones y correcciones de seguridad
Siga las recomendaciones anteriores
Agregue un comportamiento mínimo de calidad de vida para el entorno del contenedor donde encaje
Consulte la documentación de Docker para obtener una buena descripción general de alto nivel del programa.
En esencia, nos esforzamos por seguir las recomendaciones de upstream sobre cómo pretenden que se consuma su software. Muchas imágenes se mantienen en colaboración con el proyecto anterior relevante si no las mantienen directamente ellos. Además, nuestro objetivo es ejemplificar las mejores prácticas para que Dockerfiles sirva como referencia al crear o derivar sus propias imágenes a partir de ellos.
(Si es representante de una empresa para la cual existe una imagen y le gustaría participar, consulte la sección Mantenimiento a continuación).
Algunas imágenes se han adaptado a otras arquitecturas y muchas de ellas cuentan con soporte oficial (en diversos grados).
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/ A partir del 12 de septiembre de 2017, estas otras arquitecturas se incluyen en las imágenes sin prefijo a través de "listas de manifiestos" (también conocidas como "índices" en la especificación de imágenes OCI), de modo que, por ejemplo, docker run hello-world debería Ejecútelo tal cual en todas las plataformas compatibles.
Si tiene curiosidad acerca de cómo se construyen, diríjase a https://doi-janky.infosiftr.net/job/multiarch/ para ver el andamiaje de compilación.
Consulte la sección de múltiples arcos a continuación para obtener recomendaciones sobre cómo agregar más arquitecturas a una imagen oficial.
¡Sí! Contamos con un repositorio de preguntas frecuentes dedicado donde intentamos recopilar otras preguntas comunes (tanto sobre el programa como sobre nuestras prácticas).
¡Gracias por su interés en el proyecto de imágenes oficiales de Docker! Nos esforzamos por hacer que estas instrucciones sean lo más simples y directas posible, pero si se siente perdido, no dude en buscarnos en Libera.Chat IRC en el canal #docker-library o creando una incidencia en GitHub aquí.
Asegúrese de familiarizarse con los repositorios oficiales en Docker Hub y las mejores prácticas para escribir Dockerfiles en la documentación de Docker. Estas serán la base del proceso de revisión realizado por los mantenedores oficiales de imágenes. Si desea que el proceso de revisión sea más fluido, asegúrese de que sus Dockerfile cumplan con todos los puntos mencionados allí, así como a continuación, antes de enviar una solicitud de extracción.
Además, las descripciones del Hub para estas imágenes se almacenan actualmente por separado en el repositorio docker-library/docs , cuyo archivo README.md explica más sobre cómo está estructurado y cómo contribuir a él. Esté preparado para enviar un PR allí también, pendiente de la aceptación de su imagen aquí.
Debido a que las imágenes oficiales están destinadas a ser herramientas de aprendizaje para aquellos nuevos en Docker, así como las imágenes base para que los usuarios avanzados creen sus versiones de producción, revisamos cada Dockerfile propuesto para asegurarnos de que cumpla con un estándar mínimo de calidad y mantenibilidad. Si bien parte de ese estándar es difícil de definir (debido a la subjetividad), aquí se define tanto como sea posible, al mismo tiempo que se adhiere a las "Mejores prácticas" cuando corresponda.
Puede encontrar una lista de verificación que los mantenedores pueden utilizar durante la revisión en NEW-IMAGE-CHECKLIST.md .
Los cambios de versión y las correcciones de seguridad deben solucionarse de manera oportuna.
Si no representa a upstream y upstream se interesa en mantener la imagen, se deben tomar medidas para garantizar una transición fluida del mantenimiento de la imagen a upstream.
Para las empresas interesadas en hacerse cargo del mantenimiento de un repositorio existente, el primer paso es involucrarse en el repositorio existente. Hacer comentarios sobre problemas, proponer cambios y darse a conocer dentro de la "comunidad de imágenes" (incluso si esa "comunidad" es solo el mantenedor actual) son lugares importantes para comenzar a garantizar que la transición no sorprenda a los contribuyentes y usuarios existentes.
Al hacerse cargo de un repositorio existente, asegúrese de que todo el historial de Git del repositorio original se mantenga en el nuevo repositorio mantenido anteriormente para asegurarse de que el proceso de revisión no se detenga durante la transición. Esto se logra más fácilmente bifurcando lo nuevo del repositorio existente, pero también se puede lograr obteniendo las confirmaciones directamente del original y empujándolas al nuevo repositorio (es decir, git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). En GitHub, una alternativa es transferir la propiedad del repositorio de git. Esto se puede lograr sin darle a ninguno de los grupos acceso de administrador al repositorio del otro propietario:
La reconstrucción del mismo Dockerfile debería dar como resultado que se empaquete la misma versión de la imagen, incluso si la segunda compilación ocurre varias versiones después, o la compilación debería fallar por completo, de modo que una reconstrucción inadvertida de un Dockerfile etiquetado como 0.1.0 no termine. hasta que contiene 0.2.3 . Por ejemplo, si usa apt para instalar el programa principal de la imagen, asegúrese de fijarlo a una versión específica (por ejemplo: ... apt-get install -y my-package=0.1.0 ... ). Para los paquetes dependientes instalados por apt , generalmente no es necesario fijarlos a una versión.
Ninguna imagen oficial puede derivarse de imágenes no oficiales ni depender de ellas (lo que permite el scratch sin imágenes y las excepciones intencionalmente limitadas fijadas en .external-pins ; consulte también .external-pins/list.sh ).
Todas las imágenes oficiales deben proporcionar una interfaz coherente. Un usuario principiante debería poder docker run official-image bash (o sh ) en Docker sin necesidad de aprender sobre --entrypoint . También es bueno que los usuarios avanzados aprovechen el punto de entrada, de modo que puedan docker run official-image --arg1 --arg2 sin tener que especificar el binario a ejecutar.
Si el proceso de inicio no necesita argumentos, simplemente use CMD :
CMD [ "irb" ] Si es necesario realizar una inicialización al inicio, como crear la base de datos inicial, use un ENTRYPOINT junto con CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Asegúrese de que docker run official-image bash (o sh ) también funcione. La forma más sencilla es comprobar el comando esperado y, si es otra cosa, simplemente exec "$@" (ejecutar lo que se pasó, manteniendo correctamente los argumentos en formato de escape).
#! /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 la imagen solo contiene el ejecutable principal y sus bibliotecas vinculadas (es decir, sin shell), entonces está bien usar el ejecutable como ENTRYPOINT , ya que es lo único que se puede ejecutar:
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] El indicador más común de si esto es apropiado es que la imagen Dockerfile comienza desde scratch ( FROM scratch ).
Intente que el Dockerfile sea fácil de entender/leer. Puede resultar tentador, en aras de la brevedad, poner detalles de inicialización complicados en un script independiente y simplemente agregar un comando RUN en el Dockerfile . Sin embargo, esto hace que el Dockerfile resultante sea demasiado opaco y es poco probable que dichos Dockerfile pasen la revisión. En su lugar, se recomienda colocar todos los comandos para la inicialización en el Dockerfile como combinaciones apropiadas de comandos RUN o ENV . Para encontrar buenos ejemplos, mire las imágenes oficiales actuales.
Algunos ejemplos al momento de escribir este artículo:
Siguiendo las pautas de Docker, se recomienda encarecidamente que la imagen resultante sea solo una preocupación por contenedor; Básicamente, esto significa solo un proceso por contenedor, por lo que no hay necesidad de un sistema de inicio completo. Hay dos situaciones en las que un proceso similar a init sería útil para el contenedor. El primero es el manejo de señales. Si el proceso iniciado no maneja SIGTERM al salir, no se eliminará ya que es PID 1 en el contenedor (consulte la "NOTA" al final de la sección Primer plano en los documentos de la ventana acoplable). La segunda situación sería la cosecha de zombis. Si el proceso genera procesos secundarios y no los cosecha adecuadamente, generará una tabla de procesos completa, lo que puede impedir que todo el sistema genere nuevos procesos. Para ambas inquietudes recomendamos tini. Es increíblemente pequeño, tiene dependencias externas mínimas, cumple cada una de estas funciones y solo realiza las partes necesarias de cosecha y reenvío de señales.
Asegúrese de usar tini en CMD o ENTRYPOINT según corresponda.
Es mejor instalar tini desde un paquete proporcionado por la distribución (por ejemplo, apt-get install tini ). Si tini no está disponible en su distribución o es demasiado antiguo, aquí hay un fragmento de un Dockerfile para agregar en 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 --versionEste es un lugar donde la experiencia termina superando a la documentación en el camino hacia la iluminación, pero los siguientes consejos pueden ayudar:
Evite COPY / ADD siempre que sea posible, pero cuando sea necesario, sea lo más específico posible (es decir, COPY one-file.sh /somewhere/ en lugar de COPY . /somewhere ).
La razón de esto es que el caché para las instrucciones COPY considera que los cambios mtime del archivo son una falla de caché, lo que puede hacer que el comportamiento del caché de COPY sea impredecible a veces, especialmente cuando .git es parte de lo que se debe editar COPY (por ejemplo).
Asegúrese de que las líneas que tienen menos probabilidades de cambiar aparezcan antes de las líneas que tienen más probabilidades de cambiar (con la advertencia de que cada línea debe generar una imagen que aún se ejecute correctamente sin suposiciones de líneas posteriores).
Por ejemplo, la línea que contiene el número de versión del software ( ENV MYSOFTWARE_VERSION 4.2 ) debe aparecer después de una línea que configura el archivo .list del repositorio APT ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
El Dockerfile debe escribirse para ayudar a mitigar los ataques de interceptación durante la compilación. Nuestros requisitos se centran en tres objetivos principales: verificar la fuente, verificar el autor y verificar el contenido; estos se logran respectivamente de la siguiente manera: usando https cuando sea posible; importar claves PGP con la huella digital completa en Dockerfile para verificar firmas; incrustar sumas de verificación directamente en el Dockerfile . Los tres deben usarse cuando sea posible. Solo se puede utilizar https y suma de comprobación incrustada cuando no se publica ninguna firma. Como último recurso, solo es aceptable una suma de verificación integrada si el sitio no tiene https disponible ni firma.
El propósito de recomendar el uso de https para descargar los artefactos necesarios es garantizar que la descarga provenga de una fuente confiable, lo que también dificulta mucho la interceptación.
El propósito de recomendar la verificación de la firma PGP es garantizar que solo un usuario autorizado publique el artefacto determinado. Al importar claves PGP, utilice el servicio keys.openpgp.org cuando sea posible (de lo contrario, prefiera keyserver.ubuntu.com ). Consulte también la sección de preguntas frecuentes sobre claves y verificación.
El propósito de recomendar la verificación de la suma de verificación es verificar que el artefacto sea el esperado. Esto garantiza que cuando el contenido remoto cambie, el Dockerfile también cambiará y proporcionará una interrupción natural de la caché docker build . Como beneficio adicional, esto también evita la descarga accidental de artefactos más nuevos de lo esperado en archivos con versiones deficientes.
A continuación se muestran algunos ejemplos:
Preferido : descarga a través de https, clave PGP, importación completa de huellas dactilares y verificación asc , suma de verificación integrada verificada.
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;
# installAlternativa : huella digital de clave completa importada a apt, que verificará las firmas y las sumas de verificación cuando se descarguen e instalen los paquetes.
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/*;
# ... (Como nota al margen, rm -rf /var/lib/apt/lists/* es más o menos lo opuesto a apt-get update : garantiza que la capa no incluya los ~8 MB adicionales de datos de la lista de paquetes APT, y impone el uso apropiado apt-get update .)
Alternativa menos segura : incruste la suma de comprobación en el 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;
# installNota: el uso de SHA1 o MD5 debe considerarse una "suma de comprobación de último recurso", ya que ambos se consideran generalmente inseguros:
Inaceptable : descargue el archivo a través de http(s) sin verificación.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install De forma predeterminada, los contenedores Docker se ejecutan con privilegios reducidos: capacidades de Linux incluidas en la lista blanca, grupos de control y un perfil Seccomp predeterminado (1.10+ con soporte de host). El software que se ejecuta en un contenedor puede requerir privilegios adicionales para funcionar correctamente y existen varias opciones de línea de comandos para personalizar la ejecución del contenedor. Consulte docker run Reference y Seccomp for Docker como referencia.
Los repositorios oficiales que requieren privilegios adicionales deben especificar el conjunto mínimo de opciones de línea de comando para que el software funcione, y aun así pueden ser rechazados si esto introduce problemas importantes de portabilidad o seguridad. En general, no se permite --privileged , pero una combinación de las opciones --cap-add y --device puede ser aceptable. Además, --volume puede ser complicado ya que hay muchas ubicaciones del sistema de archivos del host que introducen problemas de portabilidad/seguridad (por ejemplo, socket X11).
Para las actualizaciones de imágenes que constituyen una solución de seguridad, hay algunas cosas que recomendamos para ayudar a garantizar que su actualización se combine, cree y publique lo más rápido posible:
[email protected] con unos días (hábiles) de anticipación para avisarnos y estimar el tiempo (para que podamos programar el tiempo adecuado para la actualización entrante).[security] en el título de su solicitud de extracción (por ejemplo, [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). Cada repositorio puede especificar múltiples arquitecturas para todas y cada una de las etiquetas. Si no se especifica ninguna arquitectura, las imágenes se crean en Linux en amd64 (también conocido como x86-64). Para especificar más o diferentes arquitecturas, utilice el campo Architectures (lista delimitada por comas, los espacios en blanco recortados). Las arquitecturas válidas se encuentran en el archivo oci-platform.go de Bashbrew:
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 Las Architectures de cualquier etiqueta determinada deben ser un subconjunto estricto de las Architectures de la etiqueta de la que FROM .
Las imágenes deben tener un único Dockerfile por entrada en el archivo de la biblioteca que pueda usarse para múltiples arquitecturas. Esto significa que cada arquitectura soportada tendrá la misma línea FROM (por ejemplo, FROM debian:bookworm ). Consulte golang , docker , haproxy y php para ver ejemplos de archivos de biblioteca que usan un Dockerfile por entrada y vea sus respectivos repositorios de git, por ejemplo, Dockerfile s.
Si diferentes partes del Dockerfile solo ocurren en una arquitectura u otra, use el flujo de control (por ejemplo, if / case ) junto con dpkg --print-architecture o apk -print-arch para detectar la arquitectura del espacio de usuario. Utilice uname únicamente para la detección de arquitectura cuando no se puedan instalar herramientas más precisas. Consulte golang para ver un ejemplo en el que algunas arquitecturas requieren la creación de archivos binarios a partir de los paquetes fuente ascendentes y otras simplemente descargan la versión binaria.
Para imágenes base como debian será necesario tener un Dockerfile diferente y un contexto de compilación para ADD binarios específicos de la arquitectura y esta es una excepción válida a lo anterior. Dado que estas imágenes usan las mismas Tags , deben estar en la misma entrada. Utilice los campos específicos de la arquitectura para GitRepo , GitFetch , GitCommit y Directory , que son la arquitectura concatenada con un guión ( - ) y el campo (por ejemplo, arm32v7-GitCommit ). Cualquier arquitectura que no tenga un campo específico de arquitectura usará el campo predeterminado (por ejemplo, si no hay arm32v7-Directory significa que se usará Directory para arm32v7 ). Consulte los archivos debian o ubuntu en la biblioteca para ver ejemplos. El siguiente es un ejemplo de 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
Consulte la sección de formato de instrucciones para obtener más información sobre el formato del archivo de la biblioteca.
Proponer una nueva imagen oficial no debe tomarse a la ligera. Esperamos y exigimos un compromiso para mantener su imagen (incluidas y especialmente actualizaciones oportunas según corresponda, como se indicó anteriormente).
Los archivos de definición de la biblioteca son archivos de texto sin formato que se encuentran en el directorio library/ del repositorio official-images . Cada archivo de biblioteca controla el conjunto actual de etiquetas de imagen "compatibles" que aparecen en la descripción de Docker Hub. Las etiquetas que se eliminan de un archivo de biblioteca no se eliminan de Docker Hub, por lo que las versiones antiguas pueden seguir estando disponibles para su uso, pero no son mantenidas por el desarrollador ni por el mantenedor de la imagen oficial. Las etiquetas en el archivo de biblioteca sólo se crean a través de una actualización de ese archivo de biblioteca o como resultado de la actualización de su imagen base (es decir, una imagen FROM debian:bookworm se reconstruirá cuando se cree debian:bookworm ). Solo se reconstruirá lo que esté en el archivo de la biblioteca cuando una base tenga actualizaciones.
Dada esta política, vale la pena aclarar algunos casos: versiones reabastecidas, versiones candidatas y compilaciones de integración continua. Cuando se propone un nuevo repositorio, es común incluir algunas versiones anteriores no compatibles en la solicitud de extracción inicial con el acuerdo de eliminarlas inmediatamente después de la aceptación. No confunda esto con un archivo histórico completo, que no es la intención. Otro caso común en el que el término "compatible" se amplía un poco es con los candidatos a lanzamiento. Una versión candidata es en realidad solo una convención de nomenclatura para lo que se espera que sean versiones de menor duración, por lo que son totalmente aceptables y recomendables. A diferencia de un candidato de lanzamiento, las compilaciones de integración continua que tienen un ciclo de lanzamiento totalmente automatizado basado en confirmaciones de código o un cronograma regular no son apropiadas.
Se recomienda encarecidamente que explore algunos de los contenidos library/ archivo existente (y el historial para tener una idea de cómo cambian con el tiempo) antes de crear uno nuevo para familiarizarse con las convenciones predominantes y ayudar a agilizar el proceso de revisión (de modo que que podemos centrarnos en el contenido en lugar del formato esotérico o el uso/nombramiento de etiquetas).
El nombre de archivo de un archivo de definición determinará el nombre del repositorio de imágenes que crea en Docker Hub. Por ejemplo, el archivo library/ubuntu creará etiquetas en el repositorio ubuntu .
Las etiquetas de un repositorio deben reflejar las versiones o variaciones anteriores. Por ejemplo, Ubuntu 14.04 también se conoce como Ubuntu Trusty Tahr, pero a menudo simplemente como Ubuntu Trusty (especialmente en uso), por lo que ubuntu:14.04 (número de versión) y ubuntu:trusty (nombre de versión) son alias apropiados para el mismo contenido de imagen. En Docker, la latest etiqueta es un caso especial, pero es un nombre un poco inapropiado; latest es realmente la etiqueta "predeterminada". Cuando uno hace docker run xyz , Docker interpreta que eso significa docker run xyz:latest . Teniendo en cuenta estos antecedentes, ninguna otra etiqueta contiene la cadena latest , ya que no es algo que se espera o se anima a los usuarios a escribir (es decir, xyz:latest realmente debería usarse simplemente como xyz ). Dicho de otra manera, tener un alias para la "versión más alta de la serie 2.2 de XYZ" debería ser xyz:2.2 , no xyz:2.2-latest . De manera similar, si hay una variante alpina de xyz:latest , debe tener el alias xyz:alpine , no xyz:alpine-latest o xyz:latest-alpine .
Se recomienda encarecidamente que las etiquetas de número de versión reciban alias que faciliten al usuario permanecer en la versión "más reciente" de una serie en particular. Por ejemplo, dadas las versiones 2.3.7 y 2.2.4 del software XYZ actualmente compatibles, los alias sugeridos serían Tags: 2.3.7, 2.3, 2, latest y Tags: 2.2.4, 2.2 , respectivamente. En este ejemplo, el usuario puede usar xyz:2.2 para usar fácilmente la versión de parche más reciente de la serie 2.2, o xyz:2 si se necesita menos granularidad (Python es un buen ejemplo de dónde es más obviamente útil: python:2 y python:3 son muy diferentes y pueden considerarse como la etiqueta latest para cada una de las principales pistas de lanzamiento de Python).
Como se describió anteriormente, latest es realmente "predeterminada", por lo que la imagen de la que es un alias debe reflejar qué versión o variación del software deben usar los usuarios si no saben o no les importa qué versión usan. Usando Ubuntu como ejemplo, ubuntu:latest apunta a la versión LTS más reciente, dado que es lo que la mayoría de los usuarios deberían usar si saben que quieren Ubuntu pero no saben ni les importa qué versión (especialmente considerando que será la última). versión más "estable" y con mejor soporte en un momento dado).
El formato del archivo de manifiesto se basa oficialmente en RFC 2822 y, como tal, debería resultar familiar para las personas que ya están familiarizadas con los "encabezados" de muchos protocolos/formatos de Internet populares, como HTTP o correo electrónico.
Las adiciones principales están inspiradas en la forma en que Debian usa comúnmente 2822, es decir, las líneas que comienzan con # se ignoran y las "entradas" están separadas por una línea en blanco.
La primera entrada son los metadatos "globales" de la imagen. El único campo obligatorio en la entrada global es Maintainers , cuyo valor está separado por comas en el formato de Name <email> (@github) o Name (@github) . Cualquier campo especificado en la entrada global será el predeterminado para el resto de las entradas y se puede anular en una entrada individual.
# 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 obtendrá el código del repositorio de Git ( GitRepo ) en la confirmación especificada ( GitCommit ). Si la confirmación a la que se hace referencia no está disponible al recuperar master del GitRepo asociado, es necesario proporcionar un valor para GitFetch para indicarle a Bashbrew qué referencia buscar para obtener la confirmación necesaria.
La imagen creada se etiquetará como <manifest-filename>:<tag> (es decir, library/golang con un valor de Tags de 1.6, 1, latest creará etiquetas de golang:1.6 , golang:1 y golang:latest ).
Opcionalmente, si Directory está presente, Bashbrew buscará el Dockerfile dentro del subdirectorio especificado en lugar de en la raíz (y Directory se usará como "contexto" para la compilación en lugar del nivel superior del repositorio). Si File está presente, se utilizará el nombre de archivo especificado en lugar de Dockerfile .
Consulte la sección de múltiples arcos para obtener detalles sobre cómo especificar un GitRepo , GitFetch , GitCommit o Directory diferente para una arquitectura específica.
library/ carpeta. Su nombre será el nombre de su repositorio en el Hub. Bashbrew ( bashbrew ) es una herramienta para clonar, crear, etiquetar y enviar imágenes oficiales de Docker. Consulte el README de Bashbrew para obtener más información.
