Μάθε για το Ανοιχτό Λογισμικό και βοήθησε!
by: Cerebrux
Η διατήρηση ιστορικού αλλαγών και ρυθμίσεων του 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.
| 12 | cd /opt/sudo git init --bare ServerConfiguration.git |
Επίσης θέλω ευκολία στην ταξινόμηση και τη δομή της διαμόρφωσης μου. οπότε χρησιμοποιήσω τα ονόματα διακομιστή DNS για τους φακέλους ρυθμίσεων στο git.
| 123 | sudo git clone ssh://user@example.com/opt/ServerConfiguration.gitcd ServerConfigurationsudo mkdir -p example.com/server1/{httpd,dnsqmasq} |
Γιατί το αποθηκεύω στο /opt (βλέπε : Τι είναι όλοι αυτοί οι φάκελοι στο Linux); Έχει το πλεονέκτημα ότι είναι συχνά διαμορφωμένο με το ίδιο σύστημα αρχείων με το / (σε αντίθεση ίσως με το /home, /var που μπορεί να είναι σε άλλο δίσκο), καθιστώντας το εύκολο να δημιουργώ hard-links στα των αρχείων.
Πώς λοιπόν, όλες αυτές τις ρυθμίσεις από υπηρεσίες και τα
χρησιμοποιούμε σε νέα εγκατάσταση; Συνήθως η λύση είναι τα hard-links το
οποίο ακολουθεί την σύνταξη ln [υπάρχον αρχείο] [νέος σύνδεσμος]. Π.χ.:
| 1 | 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 είναι μια χαρά :
| 12345 | cd /opt/ServerConfigurationsudo mkdir -p example.com/commonsudo cp /etc/httpd/conf/httpd.conf common/httpd.confsudo ln -s "../common/httpd.conf" server1/httpd.confsudo ln -s "../common/httpd.conf" server2/httpd.conf |
Git add, commit, push και όλα καλά !
Αφού κάναμε τα απαραίτητα links για τα αρχεία ρυθμίσεων, μην ξεχάσετε να τα προσθέσετε και να push’αρετε:
| 1234 | cd /opt/ServerConfigurationsudo git add -Asudo git commit 'Αλλαγή τελευταίας στιγμής!.'sudo git push |
Από εδώ και πέρα θα πρέπει απλά να αποκτήσετε τη συνήθεια μόλις επεξεργάζεστε configs να κάνετε add, commit, push.
Επίλογος
Τα παραπάνω είναι ούτε η κορυφή του παγόβουνου σε ότι αφορά τις πρακτικές όσων αφορά το GitOps αλλά είναι μια επιφανειακή εισαγωγή σε μια απαραίτητη συνήθεια που θα είναι χρήσιμη για όσους θα ασχοληθούν με Kubernetes, Docker, LXC/LXD containers, Ansible, Travis κλπ.
—
Πηγή άρθρου: https://planet.ellak.gr/ & https://cerebrux.net/