run - Dockerfile o registro? ¿Cuál es la estrategia preferida para la distribución?

docker tag example (4)

Si está haciendo un servicio con un Dockerfile, es preferible que cree una imagen con el Dockerfile y la introduzca en el registro, en lugar de distribuir el Dockerfile (y repo) para que la gente construya sus imágenes.

¿Qué casos de uso favorecen la distribución repo de Dockerfile y qué caso de uso favorecen la distribución del Registro?

Creo que depende un poco de su aplicación, pero preferiría el archivo Docker :

Un Dockerfile ...

... en la raíz de un proyecto hace que sea muy fácil de construir y ejecutar, es solo un comando.
... puede ser cambiado por un desarrollador si es necesario.
... es documentación sobre cómo construir tu proyecto
... es muy pequeño en comparación con una imagen que podría ser útil para personas con una conexión de internet lenta
... está en la misma ubicación que el código, por lo que cuando la gente compruebe el código, lo encontrará.

Una imagen en un registro ...

... ya está construido y listo!
... Debe ser mantenido. Si confirma un nuevo código o actualiza su aplicación, también debe actualizar la imagen.
... debe ser elaborado cuidadosamente: ¿Se puede cambiar la configuración? ¿Cómo manejas los registros? ¿Como es de grande? ¿Empaquetan un NGINX dentro de la imagen o es esta parte del mundo exterior? Como dijo @Mark O''Connor, congelarás cierta configuración, pero tal vez esa no sea la configuración que alguien más quiera usar.

Es por eso que preferiría el archivo Docker. Es lo mismo con un Vagrantfile: preferiría el Vagrantfile en lugar de la imagen de la máquina virtual. Y es lo mismo con un script ANT o Maven: preferiría el script de compilación en lugar del artefacto empaquetado (al menos si quiero contribuir con código al proyecto).

En DevTable inicialmente estábamos usando un Dockerfile que se ejecutó cuando implementamos nuestros servidores para generar nuestras imágenes de Docker. A medida que nuestra imagen acoplable se hacía más compleja y tenía más dependencias, se tardaba más y más en generar la imagen desde el Dockerfile. Lo que realmente necesitábamos era una forma de generar la imagen una vez y luego llevar el producto terminado a nuestros servidores.

Normalmente, uno podría lograr esto al enviar su imagen a index.docker.io , sin embargo, tenemos un código de propietario que no pudimos publicar en el mundo. También puede terminar en una situación así si planea construir un producto alojado alrededor de Docker.

Para abordar esta necesidad en la comunidad, construimos Quay , que pretende ser las imágenes de Github of Docker. Compruébelo y déjenos saber si soluciona una necesidad para usted.

Los repositorios privados en su propio servidor también son una opción.

Para ejecutar el servidor, clone el https://github.com/dotcloud/docker-registry en su propio servidor.

Para usar su propio servidor, prefija la etiqueta con la dirección del host del registro. Por ejemplo:

# Tag to create a repository with the full registry location. # The location (e.g. localhost.localdomain:5000) becomes # a permanent part of the repository name $ sudo docker tag 0u812deadbeef your_server.example.com:5000/repo_name # Push the new repository to its home location on your server $ sudo docker push your_server.example.com:5000/repo_name

(vea http://docs.docker.io.s3-website-us-west-2.amazonaws.com/use/workingwithrepository/#private-registry )

Me imagino que la misma pregunta podría aplicarse al código fuente en comparación con las instalaciones de paquetes binarios.

Al ingresar a un registro central compartido, puede congelar y certificar una configuración particular y luego ponerla a disposición de otros miembros de su organización.