Por fin luego de tanto trabajar ya hallamos el arreglo de esta contrariedad que ciertos lectores de nuestro sitio han presentado. Si deseas aportar algún detalle no dudes en dejar tu comentario.
Solución:
Docker no da ningún significado semántico a los valores de las etiquetas. Una etiqueta puede ser cualquiera string valor en absoluto, y las etiquetas se pueden reutilizar. El único valor de etiqueta especial es que si solo dice imagename en un docker pull o docker run comando, se interpreta automáticamente como imagename:latest.
Mecánicamente, puede asignar varias etiquetas a la misma imagen, pero es necesario docker push todos ellos. La parte más cara del impulso es el contenido de la capa, por lo que en su mayoría solo empujará el hecho de la etiqueta alternativa en una imagen existente. Del mismo modo, extraer una etiqueta de imagen, si es un duplicado de una imagen que ya tiene, es casi gratis, pero no hay una manera fácil de encontrar todas las etiquetas de una imagen determinada.
Yo recomendaria:
- Dar cada construya un identificador único, algo así como un ID de confirmación de control de fuente o una marca de tiempo.
- Si hace lanzamientos oficiales, también etiquete las compilaciones de ese lanzamiento con el número de lanzamiento. (De manera más general, si la confirmación de control de fuente actual está etiquetada, etiquete la imagen de Docker con la etiqueta de control de fuente).
- Si es útil para su flujo de trabajo de desarrollo, etiquete también las compilaciones que son las puntas de las ramas con su nombre.
- Dada su importancia, probablemente sea útil etiquetar algo como
latest(quizás el lanzamiento más reciente). - Evitar el uso de
latesty otras etiquetas que espera cambiar al hacer referencia a imágenes creadas (endocker runcomandos, DockerfileFROMlíneas, especificaciones de pod de Kubernetes, …).
Esta combinación de cosas podría significar que la misma imagen está etiquetada. imagename:g1234567, :1.2.3, :master, y :latest, y su sistema de CI necesitaría hacer cuatro docker pushes. Probablemente esperaría que las dos primeras imágenes fueran bastante constantes, pero las dos últimas cambiarían de forma rutinaria. Entonces podrías ejecutar algo como imagename:1.2.3 con algo de confianza.
(El único caso especial que me viene a la mente es un paquete de software que cambia con poca frecuencia y, por lo tanto, es posible que deba reconstruirse si hay correcciones ascendentes o actualizaciones de seguridad. Parece típico reutilizar la misma etiqueta para esto: por ejemplo, ubuntu:18.04 se actualiza cada semana o dos).
Las imágenes en la ventana acoplable se denominan mediante una referencia, siendo las más comunes un repositorio de imágenes y una etiqueta. Y esa etiqueta es relativamente libre string que apunta a una imagen específica. Es mejor considerar las etiquetas como un puntero mutable, se puede cambiar, puede tener varios punteros apuntando a la misma imagen y se puede eliminar mientras la imagen subyacente puede permanecer intacta.
Dado que la ventana acoplable no impone mucha estructura en las etiquetas (aparte de verificar que contiene caracteres válidos y no excede un límite de longitud), hacer cumplir esto es un ejercicio que se deja a cada responsable del repositorio, y se han obtenido muchas soluciones diferentes.
Para los mantenedores de repositorios, aquí hay algunas implementaciones comunes:
Opcion A: Idealmente, los encargados del mantenimiento del repositorio siguen algún tipo de semver. Este número de versión debe correlacionarse con la versión del software empaquetado, a menudo con un número de parche adicional para la revisión de la imagen. Es importante destacar que las imágenes etiquetadas de esta manera deben incluir etiquetas no solo para la versión 1.2.3-1, sino también 1.2.3, 1.2 y 1, cada una de las cuales se actualiza a la última versión dentro de su respectiva jerarquía. Esto permite a los usuarios intermedios depender de 1.2 y obtener automáticamente las actualizaciones para 1.2.4, 1.2.5, etc., a medida que surgen las correcciones de errores y las actualizaciones de seguridad.
Opcion B: De manera similar a la opción semver anterior, muchos proyectos incluyen otros metadatos importantes con sus etiquetas, por ejemplo, qué arquitectura o imagen base se usó para esa compilación. Esto se ve comúnmente con imágenes alpine vs debian / slim, o código compilado arm vs amd. Estos a menudo se combinarán con semver, por lo que es posible que vea etiquetas como alpine-1.5, además de alpine-1 y alpine etiquetas.
Opción C: Algunos proyectos siguen una versión más continua que no ofrece promesas de compatibilidad con versiones anteriores. Esto a menudo se hace con números de compilación o una fecha. stringy, de hecho, el propio Docker lo usa, aunque con un proceso para desaprobar funciones y evitar cambios importantes. He visto bastantes proyectos internos con empresas que utilizan esta estrategia para versionar sus imágenes, basándose en el número de compilación de un servidor CI.
Opción D: Soy menos fanático de poner hash de revisión de Git como etiquetas de imagen, ya que no transmiten detalles sin hacer referencia al repositorio de Git. No todos los usuarios pueden tener este acceso o habilidad para comprender esta referencia. Y al mirar dos hashes diferentes, no tengo idea de cuál es más nuevo o compatible con mi aplicación sin una verificación externa. También asumen que el único número de versión importante es de Git e ignoran que la misma revisión de Git se puede usar para crear múltiples imágenes, desde diferentes imágenes principales, diferentes arquitecturas o solo múltiples Dockerfiles / destinos de múltiples etapas dentro del mismo repositorio de Git. En su lugar, me gusta usar el esquema de etiqueta y, finalmente, las anotaciones de especificaciones de imagen una vez que tengamos herramientas en torno a las anotaciones de imagen, para rastrear detalles como las revisiones de Git. Esto coloca la revisión de Git en metadatos que puede consultar para verificar una imagen, mientras deja que la etiqueta sea informativa para el usuario.
Para los usuarios de imágenes, si tiene el requisito de evitar cambios inesperados desde el principio, hay dos opciones que conozco.
La primera es ejecutar su propio servidor de registro y llevar sus dependencias externas a un servidor local. Docker incluye una imagen para un registro independiente que puede instalar, y la API está abierta, lo que ha permitido que muchos proveedores de repositorios de artefactos admitan el registro de Docker. Tenga cuidado de actualizar regularmente este registro e incluya una forma de volver a versiones anteriores si una actualización daña su entorno.
La segunda opción es dejar de depender de las etiquetas mutables. En su lugar, puede usar la fijación de imágenes que se refiere a la referencia única sha256 del registro al manifiesto que no se puede cambiar. Puede encontrar este valor en RepoDigests cuando inspecciona una imagen extraída de un servidor de registro:
$ docker inspect -f 'json .RepoDigests' debian:latest
["[email protected]:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f"]
$ docker run -it --rm [email protected]:de3eac83cd481c04c5d6c7344cd7327625a1d8b2540e82a8231b5675cef0ae5f /bin/bash
[email protected]:/#
El mayor riesgo de vincularse a una imagen específica como esta es la falta de actualizaciones de seguridad y correcciones de errores importantes. Si elige esta opción, asegúrese de tener un procedimiento para actualizar periódicamente estas imágenes.
Independientemente de la solución que siga para extraer imágenes, el uso de la última solo es útil para una prueba rápida de desarrollador, no para ningún caso de uso de producción. El comportamiento de la última depende completamente del mantenedor del repositorio, algunos siempre lo actualizan a la última versión, algunos lo convierten en la última versión estable y algunos se olvidan de actualizarlo en absoluto. Si depende de lo último, es probable que experimente una interrupción cuando las imágenes ascendentes cambien de una versión como 1.5 a 2.0, con cambios incompatibles con versiones anteriores. Su próxima implementación incluirá inadvertidamente estos cambios a menos que dependa explícitamente de una etiqueta que ofrezca la promesa de correcciones de errores y parches de seguridad sin cambios importantes.
Para mí, se trata de saber qué versión de (mi) software se incluyó en la imagen de Docker. Mi recomendación es usar algo como el de git ID de versión corta. Yo no uso latest ya que no tiene un contexto útil.
Cree la imagen de Docker con la versión de Git como etiqueta. los stable-package-name a continuación se muestra solo el nombre de su aplicación, como “HelloWorld” o cualquier cosa que desee:
REV_TAG=$(git log -1 --pretty=format:%h)
docker build -t :$REV_TAG .
Más tarde, envío lo que etiqueté al repositorio remoto:
# nominate the tagged image for deployment
docker tag :$REV_TAG :$REV_TAG
# push docker image to remote repository
docker push
Reseñas y calificaciones
Recuerda que puedes comunicar esta reseña si te ayudó.