Vous ne pouvez pas faire GitOps tant que vous navez pas` git add `

(3 février 2020)

Cet article explique comment jai résolu quelques problèmes liés à lobtention de mon environnement initial et de mes configurations dans Git – les premiers pas vers GitOps.

Je voulais adopter GitOps depuis un certain temps, mais cest toujours délicat pour savoir par où commencer. Dois-je utiliser Jenkins Jobs – Je connais bien Jenkins? Cest un peu vieille école, peut-être que je devrais utiliser Ansible Tower. J’ai entendu des choses sur ArgoCD et bien d’autres. La vérité est que je ne peux rien faire tant que mon environnement et ma configuration ne sont pas stockés dans Git.

À la fin de cet article, Jespère que vous prendrez quelques-uns de mes conseils pour commencer.

Que vais-je obtenir en utilisant Git pour les configurations de serveur?

  1. Toutes les modifications sont enregistrées & suivies. Qui a fait cela changement? Quand? etc.
  2. Toutes les modifications sont versionnées. Oups, le changement le plus récent a cassé quelque chose. Facile à restaurer.
  3. Sauvegarde gratuite. Il suffit de cloner le référentiel à plusieurs emplacements.
  4. Des configurations faciles à réutiliser. Je viens dinstaller un nouveau serveur et je souhaite utiliser 90\% dune configuration Apache commune. Clonez simplement le dépôt et copiez le fichier.

Créez un dépôt Git – privé, mais accessible

Mon intention est de stocker tous mes fichiers de configuration pour dnsmasq, httpd, et ainsi de suite, le tout dans Git. La configuration est sensible, y compris les noms dutilisateur et les mots de passe, et il est donc évident quun dépôt public GitHub nest pas la meilleure idée. Si vous êtes prêt à payer pour un dépôt privé, allez-y. Jai choisi de créer un référentiel sur un serveur dédié que jai sur Internet public, afin que tous les autres serveurs puissent lobtenir.

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

Noms de répertoire basés sur DNS – faciles à parcourir

Je veux faciliter le tri et la structure de ma configuration. Jai décidé dutiliser les noms DNS du serveur pour les répertoires . Je lai fait sur mes serveurs domestiques;

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

Pourquoi le stocker dans /opt? Jutilise généralement ce répertoire pour les fichiers stockés sur un serveur qui lui sont spécifiques. Il a lavantage dêtre le plus souvent le même système de fichiers que / – ce qui facilite la liaison de fichiers en dur. Au point suivant:

Les configurations de service de liaison fixe dans votre dépôt Git

Vous pourriez avoir un dépôt Git séparé par serveur, ou même par service, mais cela deviendra très vite ingérable. Au contraire, ce référentiel «ServerConfiguration» pour lensemble de votre environnement peut facilement stocker la configuration de nombreux services différents.

Comment pouvons-nous alors faire en sorte quApache, dnsmasq et tous ces autres services lutilisent? Les liens durs sont la voie à suivre. La syntaxe est ln

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

Pourquoi pas des liens symboliques, dites-vous? Eh bien, jai commencé par utiliser des liens symboliques, mais jai trouvé que les politiques SELinux pour des choses comme dnsmasq se plaignaient vraiment de lutilisation dun fichier de configuration en dehors dun répertoire attendu. Il semble que SELinux autorise deux liens physiques distincts à avoir deux contextes SELinux distincts.

Liaison vers une configuration de service commune

Jai un tas de serveurs qui partagent tous les mêmes fichiers de configuration. Un répertoire common avec des liens symboliques relatifs fonctionne bien ici.

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
...

Get Committed

Une fois dans lequel vous avez associé vos fichiers de configuration, noubliez pas de git add et git commit votre progression.

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

Prenez lhabitude de modifier les configurations, puis dajouter, de valider les modifications. Poussez périodiquement ces modifications sur votre serveur dorigine et tirez / mettez à jour si nécessaire. Je trouve que cest contagieux, et quand je trouve un serveur qui nest pas sous le contrôle de version de Git config, jajoute rapidement les configurations nécessaires dans le référentiel.

Ce sera la base de GitOps plus sophistiqués plus tard dans le ligne. Mais pour linstant, ce processus présente déjà de nombreux avantages.

Si vous cherchez un tutoriel pour démarrer avec Git, je vous recommande vivement le Git Book .

Où puis-je aller à partir dici?!

  1. Store production, test et configuration dans différentes branches, et fusionnez entre elles.
  2. Faites code reviews lorsque les gens soumettent – qui a besoin dun comité consultatif de changement?!
  3. Explorez les différentes options pour appliquer automatiquement cette configuration lors de lenregistrement – Jenkins Jobs, Ansible Tower, ArgoCD, etc.

Photo de Yancy Min sur Unsplash