Blog  //  Marzo 2017  //  ¿Qué versión de Docker necesito?

¿Qué versión de Docker necesito?



El pasado 2 de marzo, prácticamente coincidiendo con el cuarto aniversario de Docker, se anunció un nuevo modelo de nomenclatura para sus productos, homogeneizando nombres y simplificando su estructura. A partir de ahora Docker se divide en dos plataformas:
  • El conocido como Docker Engine pasa a llamarse Docker Community Edition (CE).
  • Docker Datacenter /Docker engine CS (Commercial Supported) pasa a llamarse Docker Enterprise Edition (EE). Además se simplifica creando 3 niveles de soporte.
Junto con esto presentaron un nuevo modelo de liberación de versiones y de mantenimiento de estas. En primer lugar se abandona el versionado numeral tal como se estaba usando hasta ahora y se convierte a una basada en el año y mes de lanzamiento, similar al utilizado por Canonical en Ubuntu. De esta forma después de Docker v1.13 aparece la versión v17.03. Más allá de un cambio meramente estético esto lleva asociado un cambio en el modelo de soporte y mantenimiento. La versión de la API queda fuera de este nomenclatura y se mantendrá como hasta ahora, intentando mantener la compatibilidad siempre con las versiones anteriores. La versión CE ahora tendrá dos variantes:
  • Edge: De liberación mensual y en la que solo se proporcionará soporte a bugs y fallos de seguridad durante el mes en curso.
  • Stable: De liberación trimestral con cuatro meses de soporte.
Por su parte Docker EE lleva el mismo ritmo de liberación que la versión Stable pero el soporte se garantiza durante un año.


Docker EE

Hasta la llegada de esta versión el soporte estaba muy segmentado en función de las funcionalidades que quisiésemos contratar y los productos que incluyese este soporte. Además no estaba demasiado claro qué infraestructura estaba certificada y quién era el encargado de dar este soporte (el proveedor en la nube, el desarrollador del sistema operativo o el fabricante, por ejemplo). Entendamos que esta versión está dirigida a aplicaciones críticas en la que necesitemos una garantía de soporte.

Para simplificar todo esto se han acometido tres planes:
  1. Reducción de los planes de soporte a 3: Básico, estándar o avanzado.
  2. Creación de un programa de certificación a nivel de infraestructuras y plugins.
  3. Centralización de toda la oferta e información en Docker store, con todos los planes de precio, información y elementos certificados. Incluye además contenedores certificados validados por la propia Docker Inc.


Los planes

En la siguiente imagen podemos ver la matriz de planes con las características incluidas en cada uno.



La licencia es por nodo (máquina física o virtual) y tiene un coste mensual. En el caso de los proveedores de cloud como Azure o AWS el coste es por hora de uso y los planes se reducen agrupándolos. Todos los precios se pueden obtener en Docker store.
 


Programa de certificación

Para poder acceder a la versión EE es necesario que nuestra infraestructura esté dentro de las certificadas. Para ello se ha creado un programa de certificación y homologación en la que Docker garantiza que sus herramientas funcionaran sin problema y que existe una vía directa de comunicación entre proveedor y fabricante para agilizar la resolución de incidencias y compartir información.

De partida podemos contratar esta versión para Azure, AWS, Red hat linux, Oracle linux, SUSE, Ubuntu, CentOS y Windows server 2016 y pronto se unirá Google Cloud.



Por la parte de plugins y contenedores certificados podemos encontrar productos de empresas como netapp, nexenta, weaveworks, sysdig, nutanix o Microsoft.


Docker store

Sin abandonar el repositorio público conocido como Docker Hub, la empresa se ha lanzado a crear un marketplace donde centralizar los contenedores, plugins y versiones de sus herramientas dando un enfoque más corporativo y facilitando la búsqueda con filtros donde se describe el origen y el soporte del que goza cada recurso.


Además ha añadido repositorios con los paquetes e instrucciones de la versión CE para las SO más populares como MacOS, Windows 10 o Debian y la posibilidad de contratar el soporte directamente desde este sitio. Por ejemplo, en las versiones de AWS y Azure accederemos a una plantilla donde se nos desplegará la infraestructura automáticamente y el coste de la licencia se aplicará a nuestro factura de ese proveedor (en el caso de Azure hay disponible un periodo de prueba de 30 días para evaluar el producto).

Finalmente, si también es posible contratar soporte para entornos menos críticos donde no necesitamos una atención inmediata a nuestras incidencias, pero para ello necesitamos ponernos en contacto directamente con la empresa.
 

¿Este es el principio del fin de Docker como lo conocíamos?

Todos los cambios producen miedos y gustan más a unos grupos que a otros. Por una parte está noticia ha sido muy bien acogida por la gente que necesita un proveedor fuerte para dar el salto y poner en producción arquitecturas basadas en contenedores. Los miedos sobre quien ofrecería el soporte y la fortaleza del proyecto se deben disipar al ver que si se desea se puede contratar un soporte refrendado por grandes de la industria tecnológica y una garantía de soporte clara y bien documentada.

Para los amantes de los productos open source y la gente que necesita un producto en evolución continua el anuncio de que la versión EE se apoye en la versión CE Stable, que el ritmo de liberación sea más rápido en la variante Edge y que no haya habido ningún cambio en las licencias junto el anuncio de que otra de las bases de Docker como es containerd haya sido donado a CNCF (como ya fue donado hace año y medio runC a OCP) debería ser motivo de alegría por el triunfo de otro producto nacido de un modelo de software libre. 

Por suerte Docker sigue siendo modular y nos permite adaptar el stack tecnológico a nuestras necesidades. Este modelo de soporte no nos impone el uso de orquestadores y gestores de clusters y a los que no les convenza Docker Datacenter pueden usar alternativas como kubernetes, rancher o Mesos/marathon, openshift, etc... Cada proyecto tiene unas necesidades y, al menos por ahora, Docker Inc te sigue sin obligar a utilizar únicamente sus herramientas.
 
Comentarios:
Ángel Luis Mula
Buenos dias Santiago,

La respuesta corta seria:

Para consolidar los datos de un contenedor en una imagen que puedas compartir debes hacer un docker container commit (siempre que los datos no estén montado en un volumen externo).

Después si quieres compartir esta imagen mediante el repositorio publico de docker (hub.docker.com) tienes que renombrar la imagen con el formato UsuaroDockerHub/NombreImagen:Version. Esto lo puedes hacer en el mismo paso de docker commit o a posteriori con docker tag. Finalmente tienes que subir la imagen al repositorio haciendo un docker push <imagen>. Todo esto lo puedes encontrar mejor explicado en https://docs.docker.com/engine/getstarted/step_six/

Por ejemplo si nuestro contenedor se llama "mongo", nuestro usuario de docker hub es santiago y la imagen nueva queremos que se llame "custommongo" haríamos:

docker container commit mongo santiago/custommongo:v0.1
docker login -u santiago
docker image push santiago/custommongo:v0.1

Tu amigo podría descargarse la imagen con:

docker image pull santiago/custommongo:v0.1

(O directamente con docker container run ...)

Otra opción para compartirlo sin usar un repositorio es usar docker image save y docker image load compartiendo entre ambos el fichero .tar generado.

Pero para responderte de una manera más seria es necesario primero definir un escenario de buenas practicas en docker y explicar el funcionamiento ideal en el que nos va a resultar más util esta tecnología.

Lo primero hay que tener claro la diferencia entre imagen y contenedor, el ciclo de vida de un contenedor y donde residen los datos de este. Por convenio se intenta que los contenedores sean stateless, es decir que no tengan estado. Simplificandolo mucho basicamente los datos no deberían residir dentro del contenedor (aunque podemos hacerlo). Para ello lo normal es que usemos volúmenes (los tienes de muchos tipos, desde data container, directorios locales, algunos plugins de almacenamiento distribuido, amazon EFS, etc...). También se recomienda que los contenedores sean efímeros, es decir deberíamos poder parar y destruir un contenedor para que sea sustituido por otro con la mínima configuración posible. Esto nos habilita usar metodologías como 12-factor apps o infraestructura inmutable.

Siguiendo con las simplificaciones pensemos en un contenedor como una imagen que ponemos en ejecución dotándole de unos recursos (RAM, CPU, red, etc...). Estos recursos solo perduran mientras el contenedor no se destruya. Podemos usar docker commit para incorporar los datos a una imagen pero perderemos una de las grandes ventajas que nos proporciona docker y es la de definir nuestra infraestructura mediante código. Idealmente nuestras imágenes deberían estar construidas a partir de un fichero de texto de definición conocido como Dockerfile.

Las ventajas que esto nos proporciona son muy grandes:
- Un fichero de texto puede ser controlado por software de gestión de versiones (ej: git).
- Es entendible por humanos.
- Es un formato estándar.
- Podemos usar software de integración continua.
- Nos permite usar variables de entorno para la construcción de nuestras imágenes.
- Nos asegura que la creación de nuestra imagen es reproducible.

NOTA: En la versión 1.13 / 17.03 se ha reorganizado las opciones del CLI de docker. He usado para los ejemplos la sintaxis nueva (recomendada)

Sobre la organización de cursos o meetup, por ahora no tenemos fechas definidas pero estamos organizando el calendario y muy pronto habrá noticias
29/03/2017 12:37:36

Santiago
Hola Ángel Luis Mula,
soy desde hace menos de una semana un nuevo un babeliano y me están encantando tus post de Docker, estoy trabajando en una app personal y tengo "dockerizado" el mongo en una imagen con la versión mongo:3.4.2, pero no se como hacer un push de la imagen para que otro amigo mio la pueda descargar y así usar la misma base de datos, cuando se la descarga existe pero la imagen esta vacía. Tengo un montón de preguntas que me gustaría resolver y quisiera saber si vas a dar algún curso o meetup de formación de docker ya sea interna o externa, para apuntarme y aprender mas de esta herramienta tan interesante y chula.
¡ Muchas gracias por los post, me encantan !
27/03/2017 17:19:02

 Security code