Este artículo describe la capacidad / idea / concepto de cambiar la configuración global en los servidores de comandos locales en una gran infraestructura utilizando Gitlab CI y Ansible.
Digamos que tiene 20 equipos de desarrollo y 1 equipo de administración / DevOps. ¿Cómo cambiar las contraseñas de administrador en todos los servidores? ¿Cómo agregar el certificado raíz de Enterprise a todos los servidores? Etc.
¿Qué problema resuelve?
Situación tipica:
Hay administradores globales / DevOps.
Hay configuraciones globales (NTP, DNS, Proxy, etc.)
Hay equipos de desarrollo local: TeamA, TeamB, TeamC, TeamD, etc.
Hay desarrolladores que solo pueden ir a los servidores de su equipo.
¿Cómo agregar / actualizar administradores globales, configuraciones globales?
La tarea se complica por el hecho de que la configuración global se almacena por separado de la configuración de comandos locales en repositorios privados.
Si tiene pocos servidores en toda la empresa, puede iniciar Ansible en un modo simple: comience a actualizar los administradores globales y la configuración global en todos los servidores a la vez.
Para grandes instalaciones, las empresas suelen utilizar Puppet, Chef.
Concepto
Para cambiar la configuración global en los servidores de comandos locales en una gran infraestructura, propongo un mecanismo de submódulo git.
El repositorio con configuraciones locales usa submódulos git con configuraciones globales.
A continuación se muestra un diagrama esquemático de la conexión de un repositorio privado con configuraciones globales a repositorios de comandos locales.
Puede usar el concepto de actualizar la configuración global utilizando el submódulo git en la infraestructura con Puppet, Chef, Salt, pero el artículo proporciona un ejemplo con Ansible.
Por ejemplo, instale tomcat, mysql, nginx y aplique configuraciones globales en un equipo llamado team.
Hay un grupo común en gitlab que contiene configuraciones generales.
En el grupo común hay un proyecto base-bootstrap que contiene administradores, configuraciones de sysctl, etc.
Por lo general, en una empresa hay varios departamentos de desarrollo, más a menudo se denominan equipos.
En gitlab, cree un grupo de equipo (tendrá su propio nombre de equipo).
En el grupo de equipo creamos proyectos: aplicación, base de datos, equilibrador de carga.
Captura de pantalla de base-bootstrap, aplicación, base de datos, equilibrador de carga:
El repositorio base-bootstrap se incluye como un submódulo git en la aplicación, base de datos, repositorio de loadbalancer.
Cada vez que la aplicación, la base de datos, el equilibrador de carga en el repositorio comienzan a actualizar el submódulo base-bootstrap.
Después de eso, ansible-playbook de base-bootstrap y ansible-playbook de base-bootstrap se aplican a servidores de aplicaciones, bases de datos y cargadores de carga.
Es decir, si agrega un nuevo administrador a base-bootstrap o cambia la configuración del sistema en base-bootstrap, entonces con la aplicación, base de datos, loadbalancer, la nueva configuración de base-bootstrap se aplica a la aplicación, base de datos, loadbalancer.
Preparación
Debe leer artículos sobre Ansible para principiantes:
# Ansible por dónde empezar
# Guía de respuestas
Debe tener gitlab y gitlab-runner implementados con docker instalado.
El ejecutor de Docker se usa como ejemplo aquí: puede usar el ejecutor de Shell.
Cómo implementar gitlab y gitlab-runner:
# Artículo de Southbridge Gitlab-CI
# Integración continua y despliegue de Docker en GitLab CI
Debe tener 3 servidores (por ejemplo, en ubuntu): aplicación, base de datos, equilibrador de carga.
Aplicación, base de datos, equilibrador de carga son nombres comunes.
Todos los ejemplos pueden ampliarse, mejorarse, utilizarse por otro software: el artículo muestra el principio general.
Cómo implementar
Los repositorios y todo el código para la prueba se pueden tomar desde aquí: https://github.com/patsevanton/ansible-gitlab-habr
Si va al servidor con el nombre de usuario / contraseña, en el grupo deseado (en este caso el equipo) cree la variable de contraseña de usuario (cuando cambie, también debe cambiar la variable en el código) y especifique la contraseña allí (la contraseña de contraseña se usa en el código)
No olvide crear el usuario necesario con los derechos de sudo en los servidores finales (el código de usuario se usa en el código).
Para aquellos que van al servidor utilizando claves SSH, debe crear la variable SSH_PRIVATE_KEY en el grupo del equipo y agregarle la clave privada del usuario que se conectará al servidor.
Este es un ejemplo simple de conexión a servidores, por lo que los problemas de seguridad no están cubiertos en este artículo.
En cada repositorio (aplicación, base de datos, equilibrador de carga) cree un submódulo git:
git submodule add git@gitlab.example.com:common/base-bootstrap.git git submodule add git@gitlab.example.com:team/team-users.git
Se necesita un submódulo para acceder al repositorio privado compartido.
En nuestro caso, este es el repositorio con la configuración general de base-bootstrap y el repositorio de usuarios del equipo de usuarios del equipo.
Donde gitlab.example.com es su servidor de gitlab.
Luego, en .gitmodules, cambiamos la ruta al repositorio a relativa
Un ejemplo:
[submodule "team-users"] path = team-users url = ../team-users.git [submodule "base-bootstrap"] path = base-bootstrap url = ../../common/base-bootstrap.git
En cada repositorio en los hosts cambiamos la IP a la nuestra, en ansible.cfg cambiamos el remote_user a nuestro usuario.
Si no ha tenido ninguna confirmación en las últimas horas / días, y necesita implementar nuevos cambios generales en los servidores (por ejemplo, necesita agregar un nuevo administrador), para tales situaciones hay un tirón ansible.
Configure ansible-pull para descargar el repositorio common / base-bootstrap.
Para hacer esto, agregue el repositorio de tokens de implementación.
Vaya al repositorio common / base-bootstrap y luego vaya a settings / repository / Deploy Tokens.
Crea una ficha. El nombre de usuario y la contraseña resultantes se registran en base-bootstrap / vars / cron.yml.
Después de comprobar que todo funciona correctamente, creo que vale la pena cambiar el tiempo de inicio de ansible-pull de "cada 2 minutos" al que más le convenga.
Si ansible-pull ha caído, significa que el CI de este servicio caerá, lo que comienza cada vez que se compromete con este repositorio de servicios (digamos que el servicio se llama aplicación)
Cheque
Crea un nuevo administrador.
Intente agregar un nuevo administrador en https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/users.yml
Cambio de sistema
Intente agregar / cambiar la configuración de sysctl en https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/sysctl.yml
Agregar entradas a cron
Intente agregar entradas cron a https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/cron.yml
Extender o instalar sus aplicaciones
Primero necesita encontrar un rol para instalar sus aplicaciones.
Vaya a https://galaxy.ansible.com/ y encuentre la función para instalar su aplicación.
Intente instalar su aplicación usando el rol de la consola en sus servidores. Por lo general, todos los roles tienen instrucciones en las descripciones.
Por ejemplo, intente instalar java junto a tomcat. Primero instale el rol geerlingguy.java
ansible-galaxy install geerlingguy.java
Cree el ansible.cfg estándar igual que los repositorios.
Crea un inventario:
[java] java ansible_host=IP-
Crear un libro de jugadas java.yml
- hosts: java become: yes vars_files: - vars/main.yml roles: - { role: geerlingguy.java }
Ejecute ansible-playbook java.yml
Si todo salió con éxito, agréguelo al proyecto deseado (en este caso, la aplicación)
El rol de geerlingguy.java se agrega después del rol de robertdebock.tomcat https://github.com/patsevanton/ansible-gitlab-habr/blob/master/team/application/tomcat-app.yml#L11
Lo mismo ocurre con todas las demás aplicaciones que necesita instalar en el servidor.
Prueba de libro de jugadas y seguridad
Para simplificar el artículo, no se aborda el problema del almacenamiento y las pruebas de contraseña.
Hay artículos sobre cómo probar el libro de jugadas:
# Ansible: prueba de libros de jugadas (parte 1)
# Pruebas e integración continua para roles Ansible con Molecule y Jenkins
Respuestas a preguntas
1) Mentat: ¿Y por qué, después de todo, no es así como está escrito en el muelle ansible, con los entornos? Desde la primera lectura, parece un intento de reinventarlo nuevamente. Ahí es bastante conveniente aplicar todo esto como ansible-playbook -i env / teamA personalAPlaybook.yml
Respuesta: Este esquema hace posible cambiar la configuración global. Lo que se describe en la pregunta es cambiar la configuración local de los comandos.
PD: Quizás la misma funcionalidad se implementa en Ansible Tower. Pero no puedo decir nada sobre esto: no trabajé con Ansible Tower.