Gestión de configuración para 'administradores múltiples de servidor único'

Hemos configurado un servidor que ejecuta la infraestructura para una pequeña asociación. Hasta ahora, hemos tratado de administrar la configuración con Ansible, pero eso no ha sido un gran éxito. Quizás lo estamos haciendo mal.

En principio, la idea es que este servidor se quede solo la mayor parte del tiempo, con personas agregando o cambiando cosas una vez en una luna azul. Esto hace que sea crucial que todo lo que se configure y ejecute en el servidor esté bien documentado y sea claro, ya que las personas que no administran el sistema con frecuencia seguramente perderán información general (y mucho menos recordar los detalles). Además, con el tiempo, la composición del grupo de personas que administrará este servidor cambiará (a medida que las personas se vayan y se unan al 'comité').

Comenzamos con una instalación limpia, agregando roles en ansible siempre que quisiéramos configurar algo (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Tal vez debido a nuestra inexperiencia, por supuesto, nunca podemos escribir un conjunto de tareas ansibles exactamente de la manera en que las necesitamos, también porque la configuración es un proceso de prueba y error. Eso significa que, en la práctica, normalmente primero configuraremos cualquier servicio que queramos ejecutar en el servidor y luego lo traduzcamos a tareas de respuesta. Puedes ver a dónde va esto. Las personas se olvidan de probar la tarea, o tienen miedo de hacerlo a riesgo de romper cosas o, lo que es peor: olvidamos o descuidamos agregar cosas a lo que se puede responder.

Hoy, tenemos muy poca confianza en que la configuración ansible realmente refleje lo que está configurado en el servidor.

Actualmente veo tres problemas principales:

• Es difícil (lea: no tenemos una buena manera de) probar tareas ansibles sin arriesgarse a romper cosas.
• Agrega trabajo extra para descubrir primero la configuración deseada y luego descubrir cómo traducir esto a tareas ansibles.
• (Idealmente), no lo usamos con la frecuencia suficiente para construir familiaridad y rutina.

Una consideración importante aquí es que, sea lo que sea que terminemos haciendo, debería ser fácil para los recién llegados aprender las cuerdas sin mucha práctica.

¿Existe una alternativa viable que aún brinde algunas garantías y comprobaciones (comparables a la combinación de archivos Ansible para algunos master) que "no puede configurar las cosas y anotar lo que hizo"?

EDITAR: hemos considerado comprometernos /etccon git. ¿Hay alguna manera razonable de proteger los secretos (claves privadas, etc.) de esa manera, pero aún así tener el repositorio de configuración disponible fuera del servidor de alguna manera?

Simplemente active una máquina virtual de prueba / preparación que pueda usar para validar sus cambios. Su método actual de realizar cambios manualmente primero se rompe irremediablemente y está condenado al fracaso. Usted y su equipo deben comprometerse a usar CM correctamente y parte de eso es tener un sistema de prueba disponible. Incluso una máquina virtual local vagabunda sería suficiente.

Esto no solo ayudará a probar nuevos cambios, sino que también servirá como un banco de pruebas para que los nuevos empleados (o empleados mayores que no hayan usado el sistema por un tiempo) se familiaricen con su configuración ansible.

En cuanto a mantener / etc / en git: no, no hagas esto. Ese directorio es solo una pequeña porción de lo que ansible está cambiando, y tener git en su lugar solo alentará a las personas a realizar cambios locales.

Mantenga sus libros de jugadas ansibles en git. Considere restringir los permisos de modo que solo usted pueda aplicar cambios ansibles al servidor en vivo. Otros pueden enviar solicitudes de extracción con sus cambios, que puede revisar y fusionar en maestro si corresponde.

Tal vez debido a nuestra inexperiencia, por supuesto, nunca podemos escribir un conjunto de tareas ansibles exactamente de la manera en que las necesitamos, también porque la configuración es un proceso de prueba y error. Eso significa que, en la práctica, normalmente primero configuraremos cualquier servicio que queramos ejecutar en el servidor y luego lo traduzcamos a tareas de respuesta.

Mientras que hay otras cuestiones (como no tener un entorno de pruebas), se puede tener una gran mejora por no hacer esto .

Uno de los objetivos principales de diseño de Ansible es ser idempotente , lo que significa que ejecutar su libro de jugadas varias veces no debería cambiar nada (a menos que haya cambiado las jugadas). Por lo tanto, cuando configuro un nuevo software, mis pasos son:

1. Realizar cambios en las tareas de Ansible.
2. Ejecute el libro de jugadas.
3. Examine el sistema y, si no es correcto, vuelva al paso 1.
4. Cometer mis cambios.

Si no cree que va a escribir lo correcto la primera vez en Ansible, escríbalo de todos modos e itere hasta que esté correcto, como cualquier otro código. Esto reduce en gran medida la posibilidad de olvidar Ansiblize algunos cambios que realizó, ya que cada cambio que realizó ya estaba en Ansible en algún momento durante su proceso de desarrollo.

Ansible tiene un tiempo de aceleración antes de que exceda su nivel anterior de productividad, pero una vez que lo hace, su estado del sistema es fácil de asegurar. Sus prácticas parecen estar fuera de sincronía con sus objetivos finales. Puede ser productivo con un conjunto de herramientas CM, manteniendo prácticas sólidas de ingeniería, pero lleva tiempo estructurarlo correctamente. Básicamente, se trata de eficiencia comercial y de fácil implementación, para lograr estabilidad y escalabilidad empresarial. De la misma manera que un programador profesional experimentado no escribe hacks feos, las consecuencias siempre superan los beneficios.

Para empezar, es posible que tenga demasiados cocineros, sin una clara propiedad, si es así, espere una tragedia de los bienes comunes. Cada prioridad comercial prevalecerá sobre las preocupaciones de ingeniería del sistema en todo momento, a menos que esté ampliamente desactivado y lo que quede se refleje directamente en el ingeniero responsable.

Un conjunto de herramientas CM no puede ser diseñado por administradores, esto es lo que acabo de darme cuenta. Pueden reutilizar el trabajo existente, o POSIBLEMENTE extenderse sobre una base sólida, pero aun así requeriría una gran cantidad de prácticas de aplicación. Lo que puede hacer un ingeniero, simplemente NO es lo que puede hacer un administrador. Muchos conceptos en Ansible son casi los mismos que en una base de código, ¿puede enseñar un Python de administración y esperar resultados competentes? No, ciertamente no, esperaría un trabajo de pirateo, por lo que debe hacer la tarea lo suficientemente estructurada para que un trabajo de pirateo sea soportable.

Por lo tanto, debe configurar las cosas para el éxito, diseñar soluciones para puntos de administración innecesaria. Cambie la complejidad de los sistemas de bajo nivel por cosas que un administrador realmente podría hacer con éxito. Un conjunto de herramientas CM NO lo salvará de desajustes arquitectónicos o de diseño.

Por lo tanto, el orden está sujeto a modificaciones, obviamente porque la implementación depende de la ruta que sea menos perjudicial para su estado actual.

1. Mueva cualquier trabajo del sistema relacionado con el flujo de trabajo relacionado con el negocio a una plataforma de ejecución dedicada.

2. Divida las tareas en el cuadro, puede tener dos o más cuadros en uno en este momento.

3. Vuelva a implementar su CM de una manera más estructurada, y siga mejores prácticas, libros de jugadas que representen objetos, NO funciones o roles. Cada sistema debe describirse en una jugada.