Finalmente se rindió a merced de los contenedores y descubrió que resuelven muchos problemas y tiene muchas ventajas:
- Los contenedores son inmutables: SO, bibliotecas, carpetas y aplicaciones: dado que todo esto se almacena directamente en el contenedor, está 100% seguro de que la imagen que se probó en QA siempre irá a producción. Y funcionará exactamente de la misma manera.
- Contenedores livianos: un contenedor no desperdicia memoria. En lugar de cientos de megabytes y gigabytes, un contenedor solo necesita memoria para el proceso principal.
- Los contenedores son rápidos: un contenedor se inicia tan rápido como un proceso normal de Linux. No minutos, sino literalmente segundos.
Sin embargo, muchos todavía creen que los contenedores son máquinas virtuales, y se olvidan de su propiedad más importante ...
Contenedores efímeros
La disponibilidad es la razón por la que debe cambiar su enfoque sobre cómo manejar los contenedores.
Y esto es lo que en ningún caso debe hacerse para no perder las ventajas de los contenedores:1. No es necesario almacenar datos dentro del contenedor. Durante el ciclo de vida, los contenedores se pueden suspender, destruir, reemplazar. Si la aplicación se ejecuta en un contenedor, la versión 1.0 de esta aplicación debería cambiar fácilmente a la versión 1.1 sin pérdida de datos y otros problemas. Por lo tanto, si desea guardar datos, deben escribirse en eso. Sin embargo, debe tener cuidado de que los dos contenedores no escriban en el mismo lugar para no dañar los datos. Por lo tanto, verifique que las aplicaciones escriban correctamente los datos en el almacenamiento compartido.
2. No es necesario dividir la entrega de la aplicación. Algunas personas piensan que un contenedor es la misma máquina virtual. Y la mayoría de ellos creen que las aplicaciones deberían implementarse en contenedores existentes. De hecho, esto también es posible, especialmente en la fase de desarrollo, cuando hay una depuración y una implementación constantes. Pero deben ingresar el CD-ROM de entrega continua para transferirlo al departamento de control de calidad o producción solo como parte de su propia imagen. Recuerde: los contenedores son inquebrantables.
3. No es necesario crear imágenes grandes. Una imagen grande es más difícil de distribuir. Por lo tanto, la imagen debe incluir solo aquellos archivos y bibliotecas que realmente se necesitan para iniciar el proceso de solicitud. No es necesario instalar paquetes innecesarios o ejecutar actualizaciones (yum update), que crean una nueva capa en la imagen y le escriben muchos archivos.
4. No use recipientes de una sola capa. Para utilizar eficazmente los sistemas de archivos multicapa (multinivel), cree siempre capas separadas para el sistema operativo, para la definición del nombre de usuario, para la configuración y, finalmente, para la aplicación misma. Por lo tanto, será más fácil recrear, mantener y distribuir imágenes.
5. No es necesario crear imágenes a partir de contenedores en ejecución. En otras palabras, no use el comando docker commit para crear una imagen, ya que dichas imágenes no serán reproducibles. En su lugar, use siempre un Dockerfile u otras herramientas S2I (fuente a imagen) que proporcionen reproducibilidad. Además, en Dockerfile, puede rastrear fácilmente los cambios si lo almacena en el repositorio de origen (git).
6. No es necesario usar solo la última etiqueta. Esta etiqueta es algo así como INSTANTÁNEA para los usuarios de Maven. Debido a la naturaleza de varias capas del sistema de archivos contenedor, las etiquetas son muy útiles. Sin embargo, puede esperar una sorpresa desagradable cuando, por ejemplo, después de un descanso de meses, decide recopilar una imagen y de repente descubre que la aplicación ya no se inicia porque la capa principal (FROM en el lenguaje Dockerfile) ha sido reemplazada por una nueva versión que no admite compatibilidad con versiones anteriores. O porque se recuperó la versión incorrecta del caché de compilación que estaba esperando. Además, la última etiqueta también debe evitarse al implementar contenedores en producción, ya que no podrá rastrear qué versión de la imagen se está iniciando.
7. No es necesario ejecutar más de un proceso en un contenedor. Los contenedores son ideales para un solo proceso (http daemon daemon, servidor de aplicaciones, DBMS). De lo contrario, puede encontrar todo tipo de problemas, como profundizar en los registros o actualizar los procesos por separado.
8. No es necesario almacenar credenciales en una imagen; utilice variables de entorno para esto. No prescriba ningún inicio de sesión y contraseña en la imagen. En su lugar, utilice variables de entorno para extraer datos relevantes de fuentes externas al contenedor. La imagen de Postgres es un gran ejemplo de cómo hacer esto correctamente.
9. No es necesario ejecutar procesos como root. “De manera predeterminada, los contenedores Docker se ejecutan como root. (...) Sin embargo, a medida que la tecnología evoluciona, pueden aparecer otras opciones de inicio predeterminadas más seguras. En las condiciones actuales, el requisito de raíz puede considerarse una amenaza y puede no proporcionarse en todos los entornos. Para especificar un usuario que no sea root, en nombre del cual se lanzará el contenedor, se usa la directiva USER ”(Extracto de la guía para los autores de imágenes de Docker)
10. No es necesario confiar en las direcciones IP. Cada contenedor tiene su propia dirección IP interna, que puede cambiar después de reiniciar el contenedor. Si la aplicación o el microservicio necesita comunicarse con otro contenedor, use variables de entorno para transferir el nombre de host deseado al número de puerto de un contenedor a otro.
¿Te acuerdas? Ahora puedes usarlo con seguridad. Y puede encontrar consejos prácticos para usar contenedores en nuestro blog.