No puedes hacer GitOps hasta que` git add` `

(3 de febrero de 2020)

Este artículo explica cómo resolví un par de desafíos para obtener mi entorno y configuraciones iniciales en Git: los primeros pasos para GitOps.

He querido adoptar GitOps durante bastante tiempo, pero siempre es complicado para saber por dónde empezar. ¿Utilizo Jenkins Jobs? ¿Conozco bien a Jenkins? Sin embargo, es un poco de la vieja escuela, tal vez debería usar Ansible Tower. Escuché cosas sobre ArgoCD y muchos otros. La verdad es que no puedo hacer nada hasta que tenga mi entorno y mi configuración almacenados en Git.

Al final de este artículo, Espero que aprendas algunos de mis consejos para comenzar.

¿Qué obtendré al usar Git para las configuraciones del servidor?

  1. Todos los cambios son registrados & rastreados. Quién hizo eso ¿cambio? ¿Cuando? etc.
  2. Todos los cambios están versionados. Vaya, el cambio más reciente rompió algo. Fácil de revertir.
  3. Copia de seguridad gratuita. Simplemente clone el repositorio en varias ubicaciones.
  4. Configuraciones fáciles de reutilizar. Acabo de instalar un nuevo servidor y desea utilizar el 90\% de una configuración común de Apache. Simplemente clone el repositorio y copie el archivo.

Cree un repositorio Git: privado, pero accesible

Mi intención es almacenar todos mis archivos de configuración para dnsmasq, httpd, y así sucesivamente, todo en Git. La configuración es sensible, incluidos los nombres de usuario y las contraseñas, por lo que, obviamente, un repositorio público de GitHub no es la mejor idea. Si está dispuesto a pagar por un repositorio privado, hágalo. Opté por crear un repositorio en un servidor dedicado que tengo en la Internet pública, para que todos los demás servidores puedan obtenerlo.

cd /opt/ 
git init --bare ServerConfiguration.git

Nombres de directorio basados ​​en DNS: fácil de navegar

Quiero que sea fácil ordenar y estructurar mi configuración. Decidí usar los nombres DNS del servidor para los directorios . Yo en mis servidores domésticos, lo hice;

git clone ssh://[email protected]/opt/ServerConfiguration.git
cd ServerConfiguration.git
mkdir -p example.com/server1/{httpd,dnsqmasq}

¿Por qué almacenarlo en /opt? Generalmente uso este directorio para archivos almacenados en un servidor que son específicos para él. Tiene la ventaja de ser el mismo sistema de archivos que /, lo que facilita la vinculación de archivos. Pasando al siguiente punto;

Configuraciones de servicio de enlace duro en su repositorio de Git

Podría tener un repositorio de Git separado por servidor, o incluso por servicio, pero esto rápidamente se volverá inmanejable. Más bien, este repositorio «ServerConfiguration» para todo su entorno puede almacenar fácilmente la configuración de muchos servicios diferentes.

¿Cómo, entonces, conseguimos que Apache, dnsmasq y todos esos otros servicios lo usen? Hardlinks es el camino a seguir. La sintaxis es ln

ln /opt/ServerConfiguration/example.com/server1/httpd.conf /etc/httpd/conf/httpd.conf

¿Por qué no los enlaces simbólicos, dices? Bueno, comencé usando enlaces simbólicos, pero descubrí que las políticas de SELinux para cosas como dnsmasq realmente se quejaban de usar un archivo de configuración fuera de un directorio esperado. Parece que SELinux permite que dos enlaces duros separados tengan dos contextos SELinux separados.

Enlace simbólico a la configuración de servicio común

Tengo un montón de servidores que comparten los mismos archivos de configuración. Un directorio common con enlaces simbólicos relativos funciona bien aquí.

cd /opt/ServerConfiguration 
mkdir -p example.com/common
cp /etc/httpd/conf/httpd.conf common/httpd.conf
ln -s "../common/httpd.conf" server1/httpd.conf
ln -s "../common/httpd.conf" server2/httpd.conf
...

Comprométete

Una vez ha vinculado sus archivos de configuración, no olvide git add y git commit su progreso.

cd /opt/ServerConfiguration
git add -A
git commit "Made some changes..."
git push

Entra en el hábito de editar configuraciones, y luego agregar, confirmando los cambios. Envíe esos cambios a su servidor de origen periódicamente y extraiga / actualice cuando sea necesario. Encuentro que es infeccioso, y cuando encuentro un servidor que no está bajo el control de la versión de configuración de Git, rápidamente agrego las configuraciones necesarias al repositorio.

Esta será la base para algunos GitOps más sofisticados más adelante en el línea. Pero por ahora, este proceso ya tiene muchos beneficios.

Si está buscando un tutorial para comenzar con Git, le recomiendo el Git Book .

¿A dónde puedo ir desde aquí?

  1. Tienda production, test y configuration en diferentes ramas y fusionarlas.
  2. Haz code reviews cuando las personas envían: ¿quién necesita una Junta Asesora de Cambios?
  3. Explore las diversas opciones para aplicar automáticamente esa configuración al registrarse: Jenkins Jobs, Ansible Tower, ArgoCD, etc.

Foto de Yancy Min en Unsplash