Esta es una transcripción del discurso. и .
Esta es la historia de un proyecto que utilizó un sistema de gestión de configuración autoescrito y por qué el cambio a Ansible tomó 18 meses.
Día No. -ХХХ: Antes del comienzo
Inicialmente, la infraestructura constaba de muchos hosts separados que ejecutaban Hyper-V. Crear una máquina virtual requirió muchos pasos: colocar los discos en el lugar correcto, registrar DNS, reservar DHCP, poner la configuración de la VM en el repositorio de git. Este proceso estaba parcialmente mecanizado, pero, por ejemplo, las máquinas virtuales se distribuían manualmente entre los hosts. Pero, por ejemplo, los desarrolladores podrían corregir la configuración de la VM en git y aplicarla reiniciando la VM.
Solución de gestión de configuración personalizada
Sospecho que la idea original fue concebida como IaC: muchas máquinas virtuales sin estado que restablecen su estado a cero cuando se reinician. ¿Qué era la gestión de la configuración de VM? Esquemáticamente parece simple:
- Se configuró una MAC estática para la VM.
- Se conectó una ISO con CoreOS y un disco de arranque a la VM.
- CoreOS inicia el script de personalización descargándolo del servidor WEB según su IP.
- El script descarga la configuración de la VM a través de SCP según la dirección IP.
- Se inician la plantilla de los archivos de la unidad systemd y la plantilla de los scripts bash.
Esta solución tenía muchos problemas obvios:
- CoreOS ISO ha quedado obsoleto.
- Muchas acciones automatizadas complejas y magia al migrar/crear máquinas virtuales.
- Dificultad para actualizar y cuándo se necesita una determinada versión de software. Aún más divertido con los módulos del kernel.
- Las máquinas virtuales no se obtuvieron sin datos, es decir. Las máquinas virtuales aparecieron con un disco con datos de usuario adicionales montados.
- Alguien constantemente arruinaba las dependencias de la unidad systemd y CoreOS se congelaba al reiniciar. Fue difícil detectar esto usando las herramientas disponibles en CoreOS.
- Gestión de secretos.
- No hubo CM. Había configuraciones bash y YML para CoreOS.
Para aplicar la configuración de la VM, debe reiniciarla, pero es posible que no se reinicie. Parece un problema obvio, pero no hay discos persistentes; no hay ningún lugar donde guardar los registros. Bueno, está bien, intentemos agregar la opción de carga del kernel para que se envíen los registros. Pero no, qué complicado es todo.
Día #0: Reconocer el problema
Era la infraestructura de desarrollo habitual: jenkins, entornos de prueba, seguimiento, registro. CoreOS fue diseñado para alojar clústeres k8s, es decir. el problema era cómo se usaba CoreOS. El primer paso fue elegir una pila. Nos decidimos por:
- CentOS como distribución base, porque Esta es la distribución más cercana a los entornos de producción.
- Ansible para la gestión de la configuración, porque hubo un examen exhaustivo al respecto.
- Jenkins como marco para la automatización de procesos existentes, porque ya se ha utilizado activamente para procesos de desarrollo
- Hyper-V como plataforma de virtualización. Hay una serie de razones que van más allá del alcance de la historia, pero en resumen: no podemos usar las nubes, debemos usar nuestro propio hardware.
Día No. 30: Arreglando acuerdos existentes - Acuerdos como Código
Cuando la pila estuvo libre, comenzaron los preparativos para la mudanza. Arreglando los acuerdos existentes en forma de código (Acuerdos como código!). Transición labor manual -> mecanización -> automatización.
1. Configurar máquinas virtuales
Ansible hace un gran trabajo al respecto. Con un mínimo de movimientos corporales puedes tomar el control de las configuraciones de VM:
- Crea un repositorio git.
- Ponemos la lista de VM en inventario, configuraciones en playbooks y roles.
- Estamos configurando un esclavo jenkins especial desde el cual puedes ejecutar Ansible.
- Creamos un trabajo y configuramos Jenkins.
El primer proceso está listo. Los acuerdos son fijos.
2. Cree una nueva máquina virtual
Aquí no todo fue muy conveniente. No es muy conveniente crear máquinas virtuales en Hyper-V desde Linux. Uno de los intentos de mecanizar este proceso fue:
- Ansbile se conecta a través de WinRM al host de Windows.
- Ansible ejecuta un script de PowerShell.
- El script de Powershell crea una nueva máquina virtual.
- Al utilizar Hyper-V/ScVMM, al crear una máquina virtual en el sistema operativo invitado, se configura el nombre de host.
- Al actualizar la concesión de DHCP, la VM envía su nombre de host.
- La integración estándar de ddns y dhcp en el lado del controlador de dominio configura el registro DNS.
- Puede agregar una VM a su inventario y configurarla con Ansible.
3.Crear plantilla de VM
Aquí no inventaron nada, se llevaron un empacador.
- Agregue el empaquetador y kickstart config al repositorio de git.
- Configurando un esclavo jenkins especial con hyper-v y Packer.
- Creamos un trabajo y configuramos Jenkins.
Cómo funciona este enlace:
- Packer crea una VM vacía y recoge el ISO.
- La VM arranca, Packer ingresa el comando en el gestor de arranque para usar nuestro archivo kickstart desde un disquete o http.
- Anaconda se inicia con nuestra configuración y se realiza la configuración inicial del sistema operativo.
- Packer espera a que la VM esté disponible.
- Packer dentro de la VM ejecuta ansible en modo local.
- Ansible utiliza exactamente los mismos roles que utiliza en el paso 1.
- Packer exporta la plantilla de VM.
Día #75: Refactorizar el acuerdo sin romper = Prueba ansible + Testkitchen
Es posible que capturar las convenciones en el código no sea suficiente. Después de todo, si en los entresijos del proceso quieres cambiar algo, puedes romper algo. Por tanto, en el caso de la infraestructura, aparece la prueba de esta misma infraestructura. Para sincronizar el conocimiento dentro del equipo, comenzamos a probar los roles de Ansible. No voy a profundizar porque... Hay un artículo que describe los acontecimientos en ese momento. (spoiler esta no fue la versión final y después todo se complicó más ).
Día #130: ¿Quizás CentOS+ansible no sea necesario? tal vez openshift?
Debemos entender que el proceso de introducción de infraestructura no fue el único y hubo subproyectos paralelos. Por ejemplo, llegó una solicitud para iniciar nuestra aplicación en openshift y esto resultó en una investigación durante más de una semana. lo que ralentizó el proceso de mudanza. El resultado fue que openshift no cubre todas las necesidades; se necesita hardware real, o al menos la capacidad de jugar con el kernel.
Día #170: Openshift no es adecuado, ¿arriesguémonos con Windows Azure Pack?
Hyper-V no es muy amigable, SCVMM no lo mejora mucho. Pero existe el Windows Azure Pack, que es un complemento de SCVMM e imita a Azure. Pero en realidad, el producto parece abandonado: la documentación tiene enlaces rotos y es muy escasa. Pero como parte del estudio de opciones para simplificar la vida de nuestra nube, también la examinaron.
Día #250: El paquete Windows Azure no es muy bueno. Seguimos en SCVMM
Windows Azure Pack parecía prometedor, pero se decidió no incorporar WAP con sus complejidades al sistema por el bien de funciones innecesarias y se quedó con SCVMM.
Día #360: Comiéndose el elefante pieza a pieza
Sólo un año después la plataforma para la mudanza estuvo lista y comenzó el proceso de mudanza. Para ello se planteó una tarea SMART. Revisamos todas las máquinas virtuales y comenzamos a descubrir la configuración una por una, a describirla en Ansible y a cubrirla con pruebas.
Día #450: ¿Qué tipo de sistema obtuviste?
El proceso en sí no es interesante. Es rutinario, se puede notar que la mayoría de las configuraciones fueron relativamente simples o isomorfas y según el principio de Pareto, el 80% de las configuraciones de VM requirieron el 20% del tiempo. Siguiendo el mismo principio, el 80% del tiempo se dedicó a preparar la mudanza y sólo el 20% a la mudanza en sí.
Día #540: Final
¿Qué pasó en 18 meses?
- Los acuerdos se convirtieron en un código.
- Labor manual -> Mecanización -> Automatización.
Enlaces
Fuente: habr.com