GitOps: Διαχείριση ρυθμίσεων Server

Η διατήρηση ιστορικού αλλαγών και ρυθμίσεων του server και των υπηρεσιών του αλλά και η δυνατότητα εντοπισμού μίας προβληματικής ρύθμισης και επαναφοράς εκατοντάδων αρχείων ρυθμίσεων μπορεί να επιτευχθεί με τις GitOps πρακτικές.

Ένας ή εκατό servers, που μπορεί να περιλαμβάνουν άλλα τόσα VPS, Docker containers, LXC/LXD conteiners, απαιτούν αρχεία ρυθμίσεων που μπορούν να μετακινηθούν άμεσα, να εντοπιστούν τυχών προβληματικές ρυθμίσεις και να επαναφερθούν σε μια συγκεκριμένη λειτουργική στιγμή.

Μια από τις πολλές διαθέσιμες λύσεις είναι και οι πρακτικές GitOps. Είχαμε δει ένα αντίστοιχο παράδειγμα αλλά για το desktop μας (βλέπε : Dotfiles σε Git Bare για εύκολη μεταφορά ρυθμίσεων).

Τι στο καλό είναι το GitOps;

To GitOps είναι μια σειρά από πρακτικές που βασίζονται στην παραδοχή ότι:

Το Git είναι η μόνη πηγή της αλήθειας !

αμήν…

Το GitOps απαιτεί να αποθηκεύεται η επιθυμητή κατάσταση του συστήματος version control (git), έτσι ώστε ο καθένας να μπορεί να επιθεωρήσει ολόκληρη τη διαδρομή των αλλαγών. Με αυτόν τον τρόπο όλες οι αλλαγές θα είναι διαφανείς και θα παρέχουν πληροφόρηση για το ποιος, το τι και πότε έκανε την αλλαγή σε κάποια ρύθμιση.

Αυτό σημαίνει ότι τόσο η εφαρμογή όσο και η υποδομή είναι τώρα version controlled αντικείμενα και μπορούν να ελεγχθούν χρησιμοποιώντας τις ίδιες αρχές με τις οποίες γίνεται η διαχείριση εκδόσεων στην ανάπτυξη λογισμικού. Με άλλα λόγια η υποδομή μετατρέπεται σε «Infrastracture as Code«.

Σε μια εποχή που τα containers (Docker και LXC/LXD) παρέχουν την δυνατότητα σε δευτερόλεπτα, οι διαχειριστές να κάνουν deploy πολλές υπηρεσίες, αντιλαμβάνεστε το πόσο σημαντικό είναι να υπάρχει η επιθεώρηση των ρυθμίσεων. Όταν δε, οι επιχειρήσεις πρέπει να κλιμακώσουν αυτά τα containers και να στραφούν σε Docker Swarm ή Kubernetes οι πρακτικές GitOps θα παίξουν σημαντικό ρόλο στην επιτυχία του εγχειρήματος.

Τι κερδίζουμε με το Git για τα server configs

Ότι κερδίζει ένας developer στην χρήση του git για τον κώδικά του τα ίδια κερδίζει και ο SysOp. Συγκεκριμένα:

• Όλες οι αλλαγές καταγράφονται και ανιχνεύονται – Ποιος έκανε την αλλαγή, πότε, κτλ;
• Όλες οι αλλαγές είναι εκδόσεις – Εάν η πιο πρόσφατη αλλαγή έσπασε κάτι, είναι εύκολο να επαναφέρετε μια προηγούμενη.
• Δωρεάν αντίγραφο ασφαλείας – Απλά κλωνοποιήστε τον αποθετήριο σε όσες τοποθεσίες (backup servers κλπ) θέλετε.
• Εύκολη επαναχρησιμοποίηση των configs – Κάνατε μια νέα εγκατάσταση διακομιστή και θέλετε να χρησιμοποιήσετε μια κοινή διαμόρφωση Apache/nginx κλπ; Απλά κλωνοποιήστε το repo και αντιγράψτε το αρχείο.

Τα παραπάνω φυσικά προϋποθέτουν ότι γνωρίζεται και έχετε:

• Βασικές γνώσεις Git
• Έχετε κάποιο private repository σε Github, Gitlab, Bitbucket κλπ

Δημιουργήστε ένα αποθετήριο Git – ιδιωτικό, αλλά προσβάσιμο

Θα πρέπει να δημιουργήσετε ένα private αποθετήριο και να ξεκινήσετε με Git bare (τι είναι το git bare). Στο παράδειγμά μου θέλω να αποθηκεύσω όλα τα αρχεία ρυθμίσεων Centos για το dnsmasq, httpd κλπ σε Git. Η διαμόρφωση θα περιλαμβάνει ονόματα χρηστών και των κωδικών πρόσβασης, οπότε προφανώς δεν είναι η καλύτερη ιδέα ένα δημόσιο repo του GitHub.

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

Επίσης θέλω ευκολία στην ταξινόμηση και τη δομή της διαμόρφωσης μου. οπότε χρησιμοποιήσω τα ονόματα διακομιστή DNS για τους φακέλους ρυθμίσεων στο git.

sudo git clone ssh://user@example.com/opt/ServerConfiguration.git
cd ServerConfiguration
sudo mkdir -p example.com/server1/{httpd,dnsqmasq}

Γιατί το αποθηκεύω στο /opt (βλέπε : Τι είναι όλοι αυτοί οι φάκελοι στο Linux); Έχει το πλεονέκτημα ότι είναι συχνά διαμορφωμένο με το ίδιο σύστημα αρχείων με το / (σε αντίθεση ίσως με το /home, /var που μπορεί να είναι σε άλλο δίσκο), καθιστώντας το εύκολο να δημιουργώ hard-links στα των αρχείων.

Πώς λοιπόν, όλες αυτές τις ρυθμίσεις από υπηρεσίες και τα χρησιμοποιούμε σε νέα εγκατάσταση; Συνήθως η λύση είναι τα hard-links το οποίο ακολουθεί την σύνταξη ln [υπάρχον αρχείο] [νέος σύνδεσμος]. Π.χ.:

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

Γιατί όχι symlinks θα μου πείτε… Όσοι έχετε δουλέψει με CenOS θα διαπιστώσετε ότι οι πολιτικές του SELinux για πράγματα όπως το dnsmasq θα χτυπήσουν συναγερμό όταν γίνεται χρήση ενός αρχείου ρυθμίσεων έξω από έναν αναμενόμενο από το SELinux κατάλογο. Φαίνεται ότι το SELinux επιτρέπει δύο διαφορετικά hard-links να έχουν δύο χωριστά SELinux contexts.

Σε κάποιες περιπτώσεις όμως μερικοί servers μπορούν να μοιράζονται τα ίδια αρχεία ρυθμίσεων. Ένας κοινός κατάλογος με σχετικούς symlinks είναι μια χαρά :

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

Git add, commit, push και όλα καλά !

Αφού κάναμε τα απαραίτητα links για τα αρχεία ρυθμίσεων, μην ξεχάσετε να τα προσθέσετε και να push’αρετε:

cd /opt/ServerConfiguration
sudo git add -A
sudo git commit 'Αλλαγή τελευταίας στιγμής!.'
sudo git push

Από εδώ και πέρα θα πρέπει απλά να αποκτήσετε τη συνήθεια μόλις επεξεργάζεστε configs να κάνετε add, commit, push.

Επίλογος

Τα παραπάνω είναι ούτε η κορυφή του παγόβουνου σε ότι αφορά τις πρακτικές όσων αφορά το GitOps αλλά είναι μια επιφανειακή εισαγωγή σε μια απαραίτητη συνήθεια που θα είναι χρήσιμη για όσους θα ασχοληθούν με Kubernetes, Docker, LXC/LXD containers, Ansible, Travis κλπ.