Muy buenas, me llamo Luis y para hoy les traigo otro post.
Índice
Defina y controle la forma en que envÃa aplicaciones de software a producción
La estabilidad y la gobernanza se encuentran entre los temas más candentes que deben tratarse en cualquier proceso de desarrollo de software.
Ambos temas deben abordarse desde la etapa de desarrollo hasta la implementación y las etapas de ejecución en el entorno de producción.
Uno de los procesos o técnicas que pueden ayudar a dominar el desarrollo, la implementación y la ejecución de los servicios de software es el proceso de preparación de producción.
Este proceso es un conjunto de tareas y verificación de elementos que deben verificarse durante el proceso de desarrollo de software para garantizar que los servicios:
- Tener la documentación adecuada.
- Están preparados para funcionar en entornos de producción.
- Cumplen con todos los estándares adoptados y caracterÃsticas no funcionales.
Tener la información anterior verificada para cada uno de los servicios desarrollados ayudará a:
- Proporcionar información transparente sobre los aspectos internos del servicio.
- El traspaso fluido entre los equipos de desarrollo y SRE / implementación.
- Dar confianza a los equipos de implementación / SRE para ejecutar y respaldar los servicios en producción.
En este artÃculo, ilustraré cómo definir un proceso básico de preparación de producción y explicaré cada uno de los elementos que debe abordar este proceso.
El proceso / lista de verificación de preparación para la producción consta de dos secciones principales:
- Descripción del servicio: estos son los elementos que describirán el servicio y proporcionarán la identidad del servicio. La mayorÃa de estos elementos se consideran documentación de servicio y siempre deben actualizarse, en caso de cambios.
- Estándares: estos son los elementos que deben implementarse para que el servicio cumpla con los estándares adoptados y las caracterÃsticas no funcionales admitidas.
Elementos de descripción del servicio
A continuación se muestra una lista y una breve descripción de los elementos que se pueden incluir en la sección de descripción del servicio:
Propietarios
Enumere los propietarios y contribuyentes del servicio (ingenieros, propietarios de empresas) con sus funciones y responsabilidades.
Esta información puede resultar de gran ayuda cuando es necesario tomar una decisión sobre el servicio o en caso de incidencias en el entorno de producción.
Lógica empresarial
Describa el caso de uso del servicio y la lógica empresarial. Esto ayudará a otros equipos a aprender cómo funciona el servicio internamente y facilitará el traspaso entre equipos.
Responsabilidades
Describir las principales responsabilidades y caracterÃsticas del servicio para poder comprender el rol y la necesidad del servicio.
Componentes y sistemas
Describa la arquitectura del servicio y los componentes o servicios internos.
Especificaciones técnicas
Proporcionar el servicio especificaciones técnicas y requisitos tales como:
- Requisitos de hardware y software de infraestructura (SO, RAM, CPU).
- TecnologÃas utilizadas (lenguaje de programación, bibliotecas, herramientas de terceros).
Flujos y diagramas de secuencia
Describe todas las dependencias del servicio y explica los flujos y comunicaciones entre el servicio y otros microservicios.
Esta información es muy útil, especialmente cuando ocurren incidentes y es necesario investigar el problema. Estos diagramas deben cubrir al menos los dos casos siguientes.
- Dependencias del servicio de terceros.
- Comunicaciones de servicio con otros servicios en la pila.
Descripción de la configuración
Proporcione y describa todas las posibles configuraciones del servicio que se necesitan para instalarlo y desplegarlo en un entorno. El conjunto de configuraciones admitidas puede pertenecer a una o más de las siguientes categorÃas de configuración:
- Configuraciones de tiempo de creación: configuraciones que se proporcionan al crear el paquete de servicios, por ejemplo, sistemas operativos compatibles.
- Configuraciones de tiempo de implementación: estas son las configuraciones que se pueden pasar al proceso de servicio en el momento de la implementación como variables de entorno. Un ejemplo de dicha configuración es la cadena de conexión de la base de datos.
- Configuraciones de tiempo de ejecución: estas son las configuraciones que se conservan y se pueden cargar y cambiar mientras el servicio se está ejecutando (es decir, no es necesario reiniciar el servicio), por ejemplo, el idioma principal admitido por el servicio.
- Secretos: se trata de información confidencial que no debe almacenarse ni compartirse en texto plano, como contraseñas de bases de datos, claves privadas y secretos de API de terceros.
Instalación
Describa los pasos necesarios para la instalación e implementación del servicio. Esto debe describirse en detalle y cubrir todas las áreas y pasos necesarios para implementar el servicio y solucionar problemas de las instancias en ejecución, en caso de problemas.
Automatización E2E
Describa los casos de uso de prueba de un extremo a otro influenciados por el servicio.
Especificaciones de API
Defina y documente la especificación de API en caso de que el servicio proporcione una API que deba ser consumida por otros servicios.
Estándares y caracterÃsticas no funcionales
Estilo de código
El servicio debe ser compatible con el estilo de código adoptado. Hay varias herramientas que se pueden integrar con las canalizaciones de CI / CD para garantizar que el código integrado sea compatible con el estilo del código.
Por ejemplo, para aplicaciones Ruby, Rubocop se puede utilizar para realizar esta tarea fácilmente.
Seguridad
La seguridad del servicio es uno de los temas más importantes y sensibles. Por lo tanto, el código fuente del servicio, las imágenes de Docker y otros paquetes deben escanearse y verificarse frente a vulnerabilidades conocidas.
- Utilice bibliotecas de análisis estático como Guardafrenos para aplicaciones Ruby.
- Escanee las imágenes de Docker en busca de vulnerabilidades del sistema operativo.
Registro de aplicaciones
Los servicios de producción deben admitir una forma coherente de registros de producción por servicios. A continuación se presentan algunos puntos recomendados que se deben tener en cuenta al definir el sistema y el método de registro.
- El nivel de registro se puede configurar mediante una variable de entorno. (En producción, el nivel debe ser INFO).
- Acepta registros de una sola lÃnea (solo un logline para cada solicitud web o evento).
- Admite formato de registro JSON / clave-valor. Esto hará que sea más fácil analizar y enviar los registros.
Integraciones de terminales de verificación de estado
Cada servicio implementado en entornos de producción debe admitir puntos finales de verificación de estado para poder verificar el estado y la salud del servicio.
Estos puntos finales pueden ser utilizados por los sistemas de monitoreo o por las soluciones de orquestador de contenedores (Swarm o Kubernetes).
Los puntos finales de verificación de estado son un requisito para admitir una implementación de alta disponibilidad y sin tiempo de inactividad.
Solicitar seguimiento sobre múltiples servicios
En caso de que el software siga una arquitectura de microservicio y atender una solicitud pueda resultar en múltiples llamadas a varios servicios, debemos asegurarnos de que los registros de estos servicios estén correlacionados y puedan identificarse como una sola solicitud.
Esta colección de registros debe aplicarse no sólo a las comunicaciones sÃncronas entre servicios, sino también a la comunicación asincrónica, como trabajos en segundo plano, suscriptores de RabbitMQ, consumidores de Kafka y otros.
Soporte de Docker y soporte de Kubernetes
El alojamiento de aplicaciones en contenedores en las instalaciones o en la nube es una necesidad para poder admitir una implementación portátil mejor, más fluida y una escalabilidad sencilla.
Por lo tanto, es necesario asegurarse de que el servicio se pueda ejecutar en estos sistemas.
Es una buena idea proporcionar algunos estándares y documentación para que los equipos de desarrollo puedan dockerizar los servicios en la etapa inicial del desarrollo. A continuación se muestran algunas de las áreas que deben cubrirse para este tema.
- Dockerize el servicio y cree archivos de Docker.
- Construya Makefile para crear una interfaz unificada para crear imágenes de Docker.
- Cree recursos de Kubernetes.
- Construya un gráfico de Helm para el servicio.
- Cree una canalización de Jenkins para crear las imágenes de Docker.
Pruebas de rendimiento
Es necesario implementar pruebas de rendimiento para poder verificar y comprender el rendimiento y los lÃmites del nuevo servicio y la pila completa.
CI / CD
Asegúrese de que todas las canalizaciones de CI / CD necesarias estén implementadas y creadas en Jenkins.
- Ejecutar pruebas unitarias.
- Cree imágenes de Docker.
- Construya gráficos de Helm.
- Implementar en todos los env.
- etc.
La lista de elementos anterior es solo un ejemplo de los elementos que se pueden incluir en la lista de verificación de preparación para la producción.
Los elementos dependen de la naturaleza del servicio, el lenguaje de programación y la arquitectura de software para la que se creará la lista de verificación de elementos.
Por ejemplo, en el caso de tener aplicaciones Rails, es posible que deba agregar un elemento para controlar y recopilar registros de la consola Rails.
Por otro lado, en el caso de las aplicaciones móviles, algunos de los elementos de la lista anterior no se aplican en absoluto y es necesario considerar nuevos elementos, como:
- Cumplimiento de los T&C de las tiendas de aplicaciones y los programas para desarrolladores de Google y Apple.
- Forzar actualización.
- Banderas de funciones remotas.
- Versiones y dispositivos compatibles.
- Otros …
Conclusión
El proceso de preparación de producción es una gran idea para comenzar a controlar el proceso de desarrollo y mantener la estabilidad del servicio en los sistemas de producción.
También ayuda a ganar confianza para ejecutar y respaldar los servicios en producción. El proceso presentado en el artÃculo no es piedra sólida.
De hecho, es muy recomendable personalizar y crear un proceso que se adapte a las necesidades del proyecto y los servicios de software.
Gracias por leer este post.
Añadir comentario