Descripción del proyecto
TraducidoEjecutamos una aplicación web de producción en un solo VPS, y esta configuración se ha convertido en una fuente constante de problemas. Cualquier lanzamiento significa acceder por SSH, actualizar manualmente el código, reiniciar servicios a mano y esperar que nada se rompa; no hay aislamiento de la aplicación de las dependencias, no hay forma de escalar bajo carga, y un solo reinicio apaga todo el servicio. Queremos hacer esto de la manera correcta. La tarea es contenerizar la aplicación existente usando Docker, luego migrar la carga de trabajo a un clúster de Kubernetes para que finalmente obtengamos compilaciones reproducibles, escalado horizontal, auto-reparación y despliegues donde no tengamos que desvelarnos.
El trabajo comienza escribiendo Dockerfiles limpios y listos para producción para cada servicio, con compilaciones de múltiples etapas para que las imágenes se mantengan ligeras y sin herramientas innecesarias. A continuación, necesitamos enmarcar el despliegue como un conjunto de gráficos de Helm que cubran la aplicación en sí, su configuración, secretos y servicios de soporte, con archivos de valores separados para cada entorno. En el lado del clúster, necesitamos reglas de Horizontal Pod Autoscaler basadas en CPU y memoria, solicitudes y límites razonables, y sondas de vivacidad y preparación correctas para que Kubernetes reinicie los pods no saludables y dirija el tráfico solo a instancias realmente listas. Los datos persistentes y la configuración deben ir a volúmenes, mapas de configuración y secretos, no integrados en imágenes.
Finalmente, todo esto debe integrarse en un pipeline de CI/CD automatizado que construya imágenes, las envíe a un registro y despliegue en el clúster al fusionar. El lanzamiento de producción en sí debe realizarse sin tiempo de inactividad, utilizando una estrategia de rolling o blue-green con un camino de reversión documentado. Por favor, proporcione experiencia relevante en Kubernetes y un breve plan antes de comenzar.
— Dockerfile para todos los servicios con compilaciones de múltiples etapas
— Gráficos de Helm con valores de entorno, mapas de configuración y secretos
— Escalado automático HPA, más solicitudes, límites, sondas de vivacidad/preparación
— Pipeline de CI/CD que construye, envía y despliega imágenes automáticamente
— Despliegue sin tiempo de inactividad (rolling o blue-green) con plan de reversión
— Breve manual de migración y entrega de documentación
El trabajo comienza escribiendo Dockerfiles limpios y listos para producción para cada servicio, con compilaciones de múltiples etapas para que las imágenes se mantengan ligeras y sin herramientas innecesarias. A continuación, necesitamos enmarcar el despliegue como un conjunto de gráficos de Helm que cubran la aplicación en sí, su configuración, secretos y servicios de soporte, con archivos de valores separados para cada entorno. En el lado del clúster, necesitamos reglas de Horizontal Pod Autoscaler basadas en CPU y memoria, solicitudes y límites razonables, y sondas de vivacidad y preparación correctas para que Kubernetes reinicie los pods no saludables y dirija el tráfico solo a instancias realmente listas. Los datos persistentes y la configuración deben ir a volúmenes, mapas de configuración y secretos, no integrados en imágenes.
Finalmente, todo esto debe integrarse en un pipeline de CI/CD automatizado que construya imágenes, las envíe a un registro y despliegue en el clúster al fusionar. El lanzamiento de producción en sí debe realizarse sin tiempo de inactividad, utilizando una estrategia de rolling o blue-green con un camino de reversión documentado. Por favor, proporcione experiencia relevante en Kubernetes y un breve plan antes de comenzar.
— Dockerfile para todos los servicios con compilaciones de múltiples etapas
— Gráficos de Helm con valores de entorno, mapas de configuración y secretos
— Escalado automático HPA, más solicitudes, límites, sondas de vivacidad/preparación
— Pipeline de CI/CD que construye, envía y despliega imágenes automáticamente
— Despliegue sin tiempo de inactividad (rolling o blue-green) con plan de reversión
— Breve manual de migración y entrega de documentación
Administración Efectivo, Transferencia bancaria
