Redujimos el tiempo de implementación en múltiples entornos en una décima parte gracias al despliegue con Docker, lo que también nos permitió ahorrar dos puestos de operación y mantenimiento para un equipo de diez personas.

El mes pasado, nuestro pequeño equipo de SaaS de comercio electrónico en Singapur estuvo a punto de colapsar: justo antes de una gran promoción, actualizamos la función de sincronización de inventario para 3 sitios en el sudeste asiático. Todo funcionaba bien durante las pruebas locales, pero cuando lo implementamos en los servidores en la nube de Indonesia, aparecieron errores de dependencias. Dos servidores backend y un equipo de operaciones tuvieron que trabajar durante 18 horas para resolver el problema, lo que retrasó el plan de realizar pruebas de carga previas en 3 días.

Primero, entendamos qué es exactamente la implementación con Docker.

En otras palabras, se trata de empacar todo tu código de aplicación, las bibliotecas dependientes, los archivos de configuración e incluso los parámetros del kernel del sistema operativo en una imagen de contenedor estándar. Así, tal y como funciona en tu entorno local, funcionará sin problemas en cualquier servidor que cuente con el motor Docker instalado.20MB se puede realizar en un solo espejo con un tiempo mínimo de inicio de 1 segundo.。

Utilizamos los ingresos reales de 3 meses.

Lo primero que se ha resuelto de manera definitiva es el problema de la incoherencia del entorno. Antes, solo asignar diferentes versiones de Node.js y controladores de bases de datos a cada sitio web llevaba más de medio día. Ahora, las imágenes empaquetadas se transfieren directamente al repositorio de imágenes, y se pueden descargar y iniciar los tres sitios con un solo clic. El tiempo de despliegue se ha reducido de un promedio de 4 horas a 24 minutos, y ya no es necesario pasar toda la noche actualizando las versiones antes de las promociones importantes.

En segundo lugar, la tasa de utilización de los recursos del servidor se ha duplicado. Antes, cada sitio alquilaba por separado un servidor en la nube con 2 núcleos (4G), y el uso del CPU en tiempos de inactividad era inferior al 10%. Ahora, utilizando Docker, hemos reunido las aplicaciones, cachés y tareas programadas de los tres sitios en un solo servidor con 4 núcleos (8G), y los recursos son justamente suficientes.El costo mensual del servidor se ahorra directamente 620 dólares.No es una cantidad pequeña para un equipo pequeño de menos de 10 personas.

Finalmente, la velocidad de expansión es completamente capaz de mantenerse al día con el tráfico repentino. El año pasado, durante el Black Friday, nos llevó casi 2 horas agregar servidores de manera temporal para configurar el entorno adecuadamente. Este año, en los 10 minutos previos al pico, creamos 12 réplicas de contenedores que soportaron tres veces el tráfico habitual, y no volvimos a tener casos de solicitudes que se demoraran.

No te apresures a subir al coche, ya hemos pasado por esos baches por ti.

El primer problema fue que la imagen resultante era demasiado grande y compleja. Al principio, utilizábamos directamente la imagen completa de Node.js oficial para empaquetar nuestras aplicaciones, lo que hacía que la imagen tuviera un tamaño considerable (1.2G). El proceso de transferencia a los repositorios de imágenes internacionales tardaba más de 20 minutos. Más tarde, cambiamos a usar una imagen base Alpine, eliminando todas las dependencias innecesarias, y el tamaño de la imagen se redujo significativamente (90MB), lo que aumentó la velocidad de transferencia en más de 10 veces.

El segundo problema es que los datos se encuentran dentro de un contenedor. Al principio no nos dimos cuenta y almacenamos las imágenes de los productos subidas por los usuarios directamente en la carpeta local del contenedor. Más tarde, cuando el contenedor se reinició, todas las imágenes desaparecieron, y tardamos un día en recuperarlas desde la copia de seguridad. Desde entonces, todos los datos persistentes se han montado en la carpeta local del servidor o en el almacenamiento de objetos, y no hemos tenido más problemas.

El tercer problema es la falta de restricciones de recursos. Al principio, no se establecieron límites de CPU y memoria para los contenedores. Una vez, un error en una tarea programada de un sitio ocupó toda la CPU del servidor, lo que causó el cierre de los otros dos sitios. Más tarde, se establecieron límites de recursos para cada contenedor, de modo que incluso si un servicio tiene un problema, no afectará al sistema en su conjunto.

¿Deberíamos usar Docker o no? Nuestro criterio para tomar la decisión es muy simple.

Circunstancias en las que se debe utilizar: Necesitas desplegar la misma aplicación en múltiples servidores, cambias frecuentemente entre entornos de desarrollo/prueba/produccción, y tu equipo tiene más de 3 personas, cada una con un entorno de desarrollo diferente. Utilizar Docker solo mejorará la eficiencia.

Circunstancias en las que no deberías usarlo: Si solo tienes un pequeño blog, lo ejecutas en un solo servidor y actualizas el código solo una vez cada seis meses, realmente no hay necesidad de gastar tiempo aprendiendo Docker. Es más sencillo utilizar Baota o realizar la implementación de forma manual.

Tres consejos específicos para quienes empiezan por primera vez

• Las 3 primeras veces que compiles una imagen, busca directamente los mejores modelos de prácticas oficiales; no escribas tu propio Dockerfile al azar. De esta manera, podrás evitar el 80% de los problemas de sobredimensión de la imagen y errores de permisos.
• Al principio, no es necesario utilizar herramientas de configuración complejas como K8s; simplemente usa Docker Compose para gestionar hasta 3 servicios, lo cual es más que suficiente.
• Para el repositorio de imágenes, utiliza los nodos internacionales del proveedor de servicios en la nube; no lo configures tú mismo, el tiempo que ahorrarás te permitirá desarrollar varias funciones más.

Respuestas unificadas a problemas comunes

Pregunta: ¿Consumirá Docker una cantidad adicional de rendimiento del servidor? Hemos realizado pruebas y el deterioro del rendimiento es inferior al 5%, lo que es completamente imperceptible para la gran mayoría de los equipos pequeños y medianos.

Pregunta: ¿Se puede migrar la antigua aplicación a Docker? Por supuesto que sí. Tenemos un proyecto PHP antiguo que ha estado en funcionamiento durante 3 años y tardamos solo 2 días en crear la imagen y realizar la migración, lo cual es mucho más rápido que configurar todo de nuevo.