En todos los cambios, parte del contenido permanece igual. Estas preguntas son cómo podemos implementar el código en producción con una carga de trabajo mínima y sin interrupciones. En segundo lugar, ¿cómo sabemos si el servicio se está ejecutando con normalidad, si está ejecutándose o cerrado, y si lo configuramos correctamente, el servicio se comportará como se esperaba?
Aquí hay cuatro cosas simples que se pueden hacer en cualquier entorno para ayudar a mejorar el proceso de implementación. Estos le brindarán mejores conocimientos y confianza para que su aplicación se ejecute y configure correctamente.
- Verificación de estado de la aplicación
- Notas del evento
- Pod: minimiza el impacto
- Despliegue azul-verde
Verificación de estado de la aplicación
El primer paso para mejorar la implementación y la administración de la aplicación es comprender si su aplicación está funcionando correctamente (se está ejecutando y puede realizar las tareas esperadas), puede comunicarse con los servicios posteriores y ejecutar la versión correcta. Obviamente, el monitoreo es crucial, pero nuestro método de monitoreo es la clave para usarlo en la implementación automatizada. En todos los lugares en los que he trabajado, hemos realizado algún tipo de monitoreo de aplicaciones y bases de datos, pero no todos han realizado verificaciones de estado de las aplicaciones.
Recientemente, en Kountable, hemos establecido el punto / public / health en todas las aplicaciones . Esta verificación de estado nos informará sobre la aplicación. Primero, si la aplicación se está ejecutando normalmente (iniciada y lista). En segundo lugar, qué versión del código ( confirmación ) está ejecutando la aplicación . En tercer lugar, el tiempo de actividad de la aplicación y, finalmente, el estado de conexión . El connnection_status nos dice si la aplicación puede conectarse a la base de datos o servicios derivados. Si no es así, podemos comprobar si se trata de un problema de red, un problema de contraseña o un problema fuera de línea del servicio de bajada. Esto ayuda a reducir el tiempo y el foco de las fallas de la aplicación. Este es un ejemplo de salida de verificación de estado .
{
"healthy": true,
"commit": "1e98e46",
"uptime": "05:22:47:21",
"connection_status": true
}Esta verificación de estado puede usarse no solo para monitorear servicios, sino también como parte del proceso de implementación. Las comprobaciones de estado se pueden utilizar para verificar la versión instalada ( confirmación ), así como el estado de salud y conexión durante una implementación azul-verde . Si todos estos pasan, además de otras pruebas completas, podemos actualizar automáticamente la implementación a producción.
En los primeros días de esta configuración, implementamos servicios que fallaban en las comprobaciones de estado en AWS ECS. El ID de envío no coincide con el ID que se implementará. Si ya tiene un servicio de ECS en ejecución, sabe que AWS puede hacer bien su trabajo, lo que le permite implementar nuevas versiones de las tareas de ECS de una manera que tenga el menor impacto en el servicio que se está ejecutando actualmente. ECS iniciará una nueva tarea, verificará el punto final de verificación de estado configurado en el grupo de destino y, solo cuando pase, agotará la tarea anterior y habilitará el nuevo servicio. En el pasado, he visto muchas nuevas tareas de ECS implementadas, y luego siempre están en un ciclo de inicio y falla. No hay ningún error de AWS en la implementación de tareas. La única opción es ver los registros de CloudWatch y verá que su servicio se inicia y se detiene cada minuto. Puede tomar algo de tiempo
A través de la verificación de estado de la aplicación con el ID de envío o la versión, y la implementación azul-verde, podemos detectar fallas de implementación. La herramienta de implementación verifica el ID de envío que se implementará y el ID de envío de verificación de estado. Cuando no coincidan, la implementación se detendrá. Esta configuración simple ahorra más de 30 minutos de tiempo para identificar el problema y evita que el problema se ponga en producción.
Notas del evento
Una tendencia que he visto una y otra vez es que cuando no hay cambios en el sistema, la aplicación o el entorno, apenas hay problemas o interrupciones. Cuando trabajaba en Apigee, al principio, nuestros clientes crecían rápidamente y el código se publicaba continuamente. Durante este período de rápido desarrollo y despliegue continuo, encontraremos muchos problemas en las aplicaciones de producción. En tiempos tranquilos, cuando no hay despliegue de producción, el problema casi desaparecerá o casi no.
En un entorno en constante cambio, es difícil realizar un seguimiento de todos los cambios. Cuando se producen cambios, se necesita algún tiempo para reducir el alcance, especialmente cuando los cambios se implementan a lo largo del tiempo y a nivel mundial. Una cosa que encuentro fácil de implementar y muy útil es registrar el evento de cambio y agregarlo a su sistema de monitoreo. Esto se puede hacer fácilmente con herramientas de implementación para actualizar el sistema de monitoreo con eventos de implementación.
Este es un ejemplo en el que recientemente implementamos la aplicación y el tiempo de respuesta aumentó de inmediato. La anotación de Grafana marca el tiempo de implementación y luego verá el pico de tiempo de respuesta.
Además de ayudar a determinar rápidamente la causa, también encontré eventos registrados para cualquier proceso de implementación u otro proceso automatizado que sea fácil de implementar. Creo que todos los cambios en el entorno (ejecutados desde herramientas de administración de configuración, parches, copias de seguridad e incluso cambios no automáticos) deben cambiarse.
Descubrí que agregar eventos de respaldo ayuda al superponer la ventana de respaldo al uso de recursos del sistema (CPU, memoria, etc.). Esta es una forma rápida y fácil de ver si el proceso de copia de seguridad es el culpable de los picos de memoria y CPU.
Pod: minimiza el impacto
Hay muchas iteraciones diferentes del concepto de Pods, desde el diseño del centro de datos, VMware Pods hasta Kubernetes Pods . Hay muchas formas de usar o diseñar Pods. La clave es diseñar aplicaciones e infraestructura para reducir el impacto de cualquier falla en algunos componentes, clientes o servicios.
Cuando diseñamos la aplicación y la infraestructura juntas en Apigee, nos dimos cuenta de este concepto. Trabajando con Engineering en términos de operación, diseñamos una aplicación de múltiples inquilinos para ejecutar clientes en 2 o más pods de aplicaciones. Para nosotros, un Pod es un conjunto de servicios de aplicaciones, en el que se asignan de 1 a X clientes a un Pod específico. Por ejemplo, puede tener un Pod para aplicaciones principales y otro Pod para análisis o registro. En la configuración de AWS, puede tener pods de aplicaciones por región de AWS y, luego, puede asignar clientes a pods en todas o varias regiones del mundo.
Si hay un problema con el Pod en un área específica debido a fallas en la nube, problemas de implementación u otros factores. El impacto de este problema solo se aislará a los clientes del Pod en el área. Generalmente, después de implementar clientes en múltiples regiones, nunca notarán el problema.
Al diseñar la aplicación y la infraestructura juntas, cuanto mayor sea la posibilidad de reducir el impacto del problema / radio de explosión, mejor será el resultado final.
Despliegue azul-verde
La implementación azul-verde le permite ejecutar dos versiones diferentes de la aplicación, mientras que una ejecuta tráfico en tiempo real. Puede configurarlo de varias formas diferentes. En el pasado, he ejecutado dos versiones de aplicaciones en ECS, y ambas apuntan a la misma base de datos.
Su aplicación y base de datos deben ser compatibles con versiones anteriores y posteriores. La clave de la compatibilidad son los cambios en el esquema de su base de datos. Debe asegurarse de aplazar la eliminación de la columna hasta que ninguna de las versiones lo requiera.
Para cambiar entre v1.0.3 o v1.0.5, AWS ALB establece dos reglas, una para el azul y la otra para el verde. El ALB cambia la regla de escucha de azul a verde y luego agota todas las conexiones antiguas (azules).
sobre nosotros
Zeyang, ingeniero certificado en Jenkins, practicante de campo de DevOps. Centrarse en el intercambio de prácticas de tecnología de operación y mantenimiento de DevOps a nivel empresarial, centrándose principalmente en la nueva tecnología de operación y mantenimiento de Linux y cursos de tecnología de DevOps. Rica experiencia práctica de primera línea, la búsqueda de la practicidad en el curso ha sido reconocida por la mayoría de los estudiantes. El contenido del curso proviene de aplicaciones empresariales, donde no solo puede aprender tecnología sino también adquirir habilidades populares, ¡es bienvenido!
Enlace de clase: https://edu.51cto.com/lecturer/11054706.html