🥇Πρακτικές Συνεχούς Παράδοσης με Docker (κριτική και βίντεο)

Θα ξεκινήσουμε το blog μας με δημοσιεύσεις βασισμένες στις τελευταίες ομιλίες του τεχνικού μας διευθυντή αποστολ (Ντιμίτρι Στολιάροφ). Όλα έλαβαν χώρα το 2016 σε διάφορες επαγγελματικές εκδηλώσεις και ήταν αφιερωμένα στο θέμα DevOps και Docker. Έχουμε ήδη ένα βίντεο από τη συνάντηση του Docker Moscow στο γραφείο του Badoo δημοσίευσε Σε σύνδεση. Τα νέα θα συνοδεύονται από άρθρα που θα μεταφέρουν την ουσία των εκθέσεων. Ετσι…

31 Μαΐου στο συνέδριο RootConf 2016, που πραγματοποιήθηκε στο πλαίσιο του φεστιβάλ «Ρωσικές Τεχνολογίες Διαδικτύου» (RIT++ 2016), η ενότητα «Συνεχής ανάπτυξη και ανάπτυξη» άνοιξε με την έκθεση «Βέλτιστες πρακτικές συνεχούς παράδοσης με το Docker». Συνόψισε και συστηματοποίησε τις βέλτιστες πρακτικές για τη δημιουργία μιας διαδικασίας Συνεχούς Παράδοσης (CD) χρησιμοποιώντας το Docker και άλλα προϊόντα ανοιχτού κώδικα. Εργαζόμαστε με αυτές τις λύσεις στην παραγωγή, γεγονός που μας επιτρέπει να βασιζόμαστε στην πρακτική εμπειρία.

Αν έχετε την ευκαιρία να αφιερώσετε μια ώρα βίντεο της έκθεσης, συνιστούμε να το παρακολουθήσετε πλήρως. Διαφορετικά, παρακάτω είναι η κύρια περίληψη σε μορφή κειμένου.

Συνεχής παράδοση με Docker

Κάτω από Συνεχής Παράδοση κατανοούμε την αλυσίδα των γεγονότων ως αποτέλεσμα των οποίων ο κώδικας εφαρμογής από το αποθετήριο Git έρχεται πρώτα στην παραγωγή και στη συνέχεια καταλήγει στο αρχείο. Μοιάζει με αυτό: Git → Build → Test → Release → Operate.

Το μεγαλύτερο μέρος της αναφοράς είναι αφιερωμένο στο στάδιο της κατασκευής (συναρμολόγηση εφαρμογής) και τα θέματα έκδοσης και λειτουργίας θίγονται εν συντομία. Θα μιλήσουμε για προβλήματα και μοτίβα που σας επιτρέπουν να τα λύσετε και οι συγκεκριμένες υλοποιήσεις αυτών των μοτίβων μπορεί να είναι διαφορετικές.

Γιατί χρειάζεται καθόλου το Docker εδώ; Δεν είναι τυχαίο που αποφασίσαμε να μιλήσουμε για πρακτικές συνεχούς παράδοσης στο πλαίσιο αυτού του εργαλείου ανοιχτού κώδικα. Παρόλο που ολόκληρη η αναφορά είναι αφιερωμένη στη χρήση της, αποκαλύπτονται πολλοί λόγοι όταν εξετάζεται το κύριο μοτίβο διάθεσης κώδικα εφαρμογής.

Κύριο μοτίβο διάθεσης

Έτσι, όταν κυκλοφορούμε νέες εκδόσεις της εφαρμογής, σίγουρα αντιμετωπίζουμε πρόβλημα διακοπής λειτουργίας, που δημιουργήθηκε κατά την εναλλαγή του διακομιστή παραγωγής. Η επισκεψιμότητα από την παλιά έκδοση της εφαρμογής στη νέα δεν μπορεί να αλλάξει αμέσως: πρώτα πρέπει να βεβαιωθούμε ότι η νέα έκδοση όχι μόνο έχει ληφθεί με επιτυχία, αλλά και «ζεσταίνεται» (δηλαδή, είναι εντελώς έτοιμη να εξυπηρετήσει αιτήματα).

Έτσι, για κάποιο χρονικό διάστημα και οι δύο εκδόσεις της εφαρμογής (παλιά και νέα) θα λειτουργούν ταυτόχρονα. Το οποίο οδηγεί αυτόματα σε σύγκρουση κοινόχρηστων πόρων: δίκτυο, σύστημα αρχείων, IPC, κ.λπ. Με το Docker, αυτό το πρόβλημα επιλύεται εύκολα με την εκτέλεση διαφορετικών εκδόσεων της εφαρμογής σε ξεχωριστά κοντέινερ, για τα οποία η απομόνωση πόρων είναι εγγυημένη στον ίδιο κεντρικό υπολογιστή (διακομιστής/εικονική μηχανή). Φυσικά, μπορείτε να τα βγάλετε πέρα με μερικά κόλπα χωρίς καθόλου μόνωση, αλλά αν υπάρχει ένα έτοιμο και βολικό εργαλείο, τότε υπάρχει και ο αντίθετος λόγος - να μην το αμελήσετε.

Η μεταφορά εμπορευματοκιβωτίων παρέχει πολλά άλλα οφέλη όταν αναπτύσσεται. Οποιαδήποτε εφαρμογή εξαρτάται από συγκεκριμένη έκδοση (ή εύρος εκδόσεων) διερμηνέας, διαθεσιμότητα modules/extensions κ.λπ., καθώς και των εκδόσεων τους. Και αυτό ισχύει όχι μόνο για το άμεσο εκτελέσιμο περιβάλλον, αλλά και για ολόκληρο το περιβάλλον, συμπεριλαμβανομένου λογισμικό συστήματος και την έκδοσή του (μέχρι τη διανομή Linux που χρησιμοποιείται). Λόγω του γεγονότος ότι τα κοντέινερ περιέχουν όχι μόνο κώδικα εφαρμογής, αλλά και προεγκατεστημένο σύστημα και λογισμικό εφαρμογής των απαιτούμενων εκδόσεων, μπορείτε να ξεχάσετε προβλήματα με εξαρτήσεις.

Ας συνοψίσουμε κύριο μοτίβο διάθεσης νέες εκδόσεις λαμβάνοντας υπόψη τους ακόλουθους παράγοντες:

Αρχικά, η παλιά έκδοση της εφαρμογής εκτελείται στο πρώτο κοντέινερ.
Στη συνέχεια, η νέα έκδοση ξετυλίγεται και «θερμαίνεται» σε ένα δεύτερο δοχείο. Αξίζει να σημειωθεί ότι αυτή η ίδια η νέα έκδοση μπορεί να φέρει όχι μόνο ενημερωμένο κώδικα εφαρμογής, αλλά και οποιαδήποτε από τις εξαρτήσεις της, καθώς και στοιχεία συστήματος (για παράδειγμα, μια νέα έκδοση του OpenSSL ή ολόκληρη τη διανομή).
Όταν η νέα έκδοση είναι πλήρως έτοιμη να εξυπηρετήσει αιτήματα, η κυκλοφορία αλλάζει από το πρώτο κοντέινερ στο δεύτερο.
Η παλιά έκδοση μπορεί πλέον να διακοπεί.

Αυτή η προσέγγιση της ανάπτυξης διαφορετικών εκδόσεων της εφαρμογής σε ξεχωριστά κοντέινερ παρέχει μια άλλη ευκολία - γρήγορη επαναφορά στην παλιά έκδοση (εξάλλου, αρκεί να αλλάξετε την κυκλοφορία στο επιθυμητό κοντέινερ).

Η τελευταία πρώτη σύσταση ακούγεται σαν κάτι που ούτε ο καπετάνιος δεν μπορούσε να βρει λάθος:[κατά την οργάνωση της Συνεχούς Παράδοσης με το Docker] Χρησιμοποιήστε το Docker [και καταλάβετε τι δίνει]" Θυμηθείτε, αυτό δεν είναι μια ασημένια σφαίρα που θα λύσει κάθε πρόβλημα, αλλά ένα εργαλείο που παρέχει μια υπέροχη βάση.

Αναπαραγωγιμότητα

Με τον όρο «αναπαραγωγιμότητα» εννοούμε ένα γενικευμένο σύνολο προβλημάτων που αντιμετωπίζονται κατά τη λειτουργία εφαρμογών. Μιλάμε για τέτοιες περιπτώσεις:

Τα σενάρια που ελέγχονται από το τμήμα ποιότητας για σκηνοθεσία πρέπει να αναπαράγονται με ακρίβεια στην παραγωγή.
Οι εφαρμογές δημοσιεύονται σε διακομιστές που μπορούν να λαμβάνουν πακέτα από διαφορετικούς καθρέφτες αποθετηρίου (με την πάροδο του χρόνου ενημερώνονται και μαζί τους οι εκδόσεις των εγκατεστημένων εφαρμογών).
“Τα πάντα λειτουργούν για μένα τοπικά!” (...και δεν επιτρέπεται στους προγραμματιστές η παραγωγή.)
Πρέπει να ελέγξετε κάτι στην παλιά (αρχειοθετημένη) έκδοση.
...

Η γενική τους ουσία συνοψίζεται στο γεγονός ότι είναι απαραίτητη η πλήρης συμμόρφωση των περιβαλλόντων που χρησιμοποιούνται (καθώς και η απουσία του ανθρώπινου παράγοντα). Πώς μπορούμε να εγγυηθούμε την αναπαραγωγιμότητα; Δημιουργήστε εικόνες Docker βασίζονται σε κώδικα από το Git και στη συνέχεια χρησιμοποιήστε τα για οποιαδήποτε εργασία: σε δοκιμαστικές τοποθεσίες, στην παραγωγή, σε τοπικές μηχανές προγραμματιστών... Ταυτόχρονα, είναι σημαντικό να ελαχιστοποιήσετε τις ενέργειες που εκτελούνται μετά συναρμολόγηση της εικόνας: όσο πιο απλή είναι, τόσο λιγότερο πιθανό είναι να υπάρχουν σφάλματα.

Η υποδομή είναι κώδικας

Εάν οι απαιτήσεις υποδομής (διαθεσιμότητα λογισμικού διακομιστή, η έκδοσή του, κ.λπ.) δεν επισημοποιηθούν και δεν «προγραμματιστούν», τότε η διάθεση οποιασδήποτε ενημέρωσης εφαρμογής μπορεί να έχει καταστροφικές συνέπειες. Για παράδειγμα, στο staging έχετε ήδη μεταβεί στην PHP 7.0 και έχετε ξαναγράψει τον κώδικα ανάλογα - τότε η εμφάνισή του στην παραγωγή με κάποια παλιά PHP (5.5) σίγουρα θα εκπλήξει κάποιον. Μπορεί να μην ξεχάσετε μια σημαντική αλλαγή στην έκδοση του διερμηνέα, αλλά «ο διάβολος είναι στις λεπτομέρειες»: η έκπληξη μπορεί να είναι σε μια μικρή ενημέρωση οποιασδήποτε εξάρτησης.

Μια προσέγγιση για την επίλυση αυτού του προβλήματος είναι γνωστή ως IaC (Υποδομή ως κώδικας, «υποδομή ως κώδικας») και περιλαμβάνει την αποθήκευση απαιτήσεων υποδομής μαζί με τον κωδικό εφαρμογής. Χρησιμοποιώντας το, οι προγραμματιστές και οι ειδικοί του DevOps μπορούν να εργαστούν με το ίδιο αποθετήριο εφαρμογών Git, αλλά σε διαφορετικά μέρη του. Από αυτόν τον κώδικα δημιουργείται μια εικόνα Docker στο Git, στην οποία αναπτύσσεται η εφαρμογή λαμβάνοντας υπόψη όλες τις ιδιαιτερότητες της υποδομής. Με απλά λόγια, τα σενάρια (κανόνες) για τη συναρμολόγηση εικόνων θα πρέπει να βρίσκονται στο ίδιο αποθετήριο με τον πηγαίο κώδικα και να συγχωνεύονται μεταξύ τους.

Στην περίπτωση μιας αρχιτεκτονικής εφαρμογής πολλαπλών επιπέδων - για παράδειγμα, υπάρχει το nginx, το οποίο βρίσκεται μπροστά από μια εφαρμογή που εκτελείται ήδη μέσα σε ένα κοντέινερ Docker - Οι εικόνες Docker πρέπει να δημιουργούνται από κώδικα στο Git για κάθε επίπεδο. Στη συνέχεια, η πρώτη εικόνα θα περιέχει μια εφαρμογή με έναν διερμηνέα και άλλες «στενές» εξαρτήσεις και η δεύτερη εικόνα θα περιέχει το upstream nginx.

Εικόνες Docker, επικοινωνία με το Git

Χωρίζουμε όλες τις εικόνες Docker που συλλέγονται από το Git σε δύο κατηγορίες: προσωρινές και απελευθερωμένες. Προσωρινές εικόνες επισημαίνονται με το όνομα του κλάδου στο Git, μπορούν να αντικατασταθούν από την επόμενη δέσμευση και διατίθενται μόνο για προεπισκόπηση (όχι για παραγωγή). Αυτή είναι η βασική διαφορά τους από αυτά που κυκλοφορούν: ποτέ δεν ξέρεις ποιο συγκεκριμένο commit περιλαμβάνει.

Είναι λογικό να συλλέγονται σε προσωρινές εικόνες: το κύριο υποκατάστημα (μπορείτε να το προωθήσετε αυτόματα σε ξεχωριστό ιστότοπο για να βλέπετε συνεχώς την τρέχουσα έκδοση του master), κλάδους με εκδόσεις, κλάδους συγκεκριμένων καινοτομιών.

Αφού η προεπισκόπηση των προσωρινών εικόνων έρθει στην ανάγκη για μετάφραση στην παραγωγή, οι προγραμματιστές βάζουν μια συγκεκριμένη ετικέτα. Συλλέγεται αυτόματα ανά ετικέτα εικόνα απελευθέρωσης (η ετικέτα του αντιστοιχεί στην ετικέτα από το Git) και ανοίγει στη φάση. Εάν επαληθευτεί με επιτυχία από το τμήμα ποιότητας, πηγαίνει στην παραγωγή.

dapp

Όλα όσα περιγράφονται (κυκλοφορία, συναρμολόγηση εικόνας, επακόλουθη συντήρηση) μπορούν να υλοποιηθούν ανεξάρτητα χρησιμοποιώντας σενάρια Bash και άλλα «αυτοσχέδια» εργαλεία. Αλλά αν το κάνετε αυτό, τότε κάποια στιγμή η υλοποίηση θα οδηγήσει σε μεγάλη πολυπλοκότητα και κακή δυνατότητα ελέγχου. Κατανοώντας αυτό, καταλήξαμε να δημιουργήσουμε το δικό μας εξειδικευμένο βοηθητικό πρόγραμμα Workflow για την κατασκευή CI/CD - dapp.

Ο πηγαίος κώδικας του είναι γραμμένος σε Ruby, ανοιχτού κώδικα και δημοσιεύεται στο GitHub. Δυστυχώς, η τεκμηρίωση είναι αυτή τη στιγμή το πιο αδύναμο σημείο του εργαλείου, αλλά εργαζόμαστε πάνω σε αυτό. Και θα γράψουμε και θα μιλήσουμε για το dapp περισσότερες από μία φορές, γιατί... Ειλικρινά ανυπομονούμε να μοιραστούμε τις δυνατότητές του με ολόκληρη την ενδιαφερόμενη κοινότητα, αλλά στο μεταξύ, στείλτε τα προβλήματά σας και τραβήξτε αιτήματα ή/και παρακολουθήστε την ανάπτυξη του έργου στο GitHub.

Ενημερώθηκε 13 Αυγούστου 2019: επί του παρόντος ένα έργο dapp μετονομάστηκε σε werf, ο κώδικάς του έχει ξαναγραφεί πλήρως στο Go και η τεκμηρίωσή του έχει βελτιωθεί σημαντικά.

Kubernetes

Ένα άλλο έτοιμο εργαλείο Ανοιχτού Κώδικα που έχει ήδη λάβει σημαντική αναγνώριση στο επαγγελματικό περιβάλλον είναι Kubernetes,ένα σύμπλεγμα διαχείρισης Docker. Το θέμα της χρήσης του στη λειτουργία έργων που έχουν δημιουργηθεί στο Docker ξεφεύγει από το πεδίο εφαρμογής της έκθεσης, επομένως η παρουσίαση περιορίζεται σε μια επισκόπηση ορισμένων ενδιαφερόντων χαρακτηριστικών.

Για διάθεση, η Kubernetes προσφέρει:

ανιχνευτής ετοιμότητας — έλεγχος της ετοιμότητας μιας νέας έκδοσης της εφαρμογής (για εναλλαγή της κυκλοφορίας σε αυτήν).
κυλιόμενη ενημέρωση - διαδοχική ενημέρωση εικόνας σε ένα σύμπλεγμα κοντέινερ (απενεργοποίηση, ενημέρωση, προετοιμασία για εκκίνηση, εναλλαγή κυκλοφορίας).
σύγχρονη ενημέρωση - ενημέρωση μιας εικόνας σε ένα σύμπλεγμα με διαφορετική προσέγγιση: πρώτα στα μισά κοντέινερ και μετά στα υπόλοιπα.
απελευθερώσεις καναρινιών - λανσάροντας μια νέα εικόνα σε περιορισμένο (μικρό) αριθμό δοχείων για την παρακολούθηση ανωμαλιών.

Δεδομένου ότι το Continuous Delivery δεν είναι μόνο η κυκλοφορία μιας νέας έκδοσης, το Kubernetes έχει μια σειρά από δυνατότητες για μετέπειτα συντήρηση της υποδομής: ενσωματωμένη παρακολούθηση και καταγραφή για όλα τα κοντέινερ, αυτόματη κλιμάκωση κ.λπ. Όλα αυτά λειτουργούν ήδη και απλώς περιμένουν τη σωστή εφαρμογή στις διαδικασίες σας.

Τελικές συστάσεις

Χρησιμοποιήστε το Docker.
Δημιουργήστε εικόνες Docker εφαρμογών για όλες τις ανάγκες σας.
Ακολουθήστε την αρχή «Η υποδομή είναι κώδικας».
Συνδέστε το Git με το Docker.
Ρυθμίστε τη σειρά διάθεσης.
Χρησιμοποιήστε μια έτοιμη πλατφόρμα (Kubernetes ή άλλη).

Βίντεο και διαφάνειες

Βίντεο από την παράσταση (περίπου μία ώρα) δημοσιεύτηκε στο YouTube (το ίδιο το ρεπορτάζ ξεκινά από το 5ο λεπτό - ακολουθήστε τον σύνδεσμο για να παίξετε από αυτή τη στιγμή).

Παρουσίαση της έκθεσης:

PS

Άλλες αναφορές για το θέμα στο ιστολόγιό μας:

«werf - το εργαλείο μας για CI / CD στο Kubernetes (επισκόπηση και αναφορά βίντεο)» (Dmitry Stolyarov; 27 Μαΐου 2019 στο DevOpsConf);
«Βάσεις δεδομένων και Kubernetes» (Dmitry Stolyarov, 8 Νοεμβρίου 2018 στο HighLoad++);
«Βέλτιστες πρακτικές CI/CD με Kubernetes και GitLab» (Dmitry Stolyarov, 7 Νοεμβρίου 2017 στο HighLoad++);
«Η εμπειρία μας με την Kubernetes σε μικρά έργα» (Dmitry Stolyarov, 6 Ιουνίου 2017 στο RootConf).

Πηγή: www.habr.com

Πρακτικές συνεχούς παράδοσης με το Docker (κριτική και βίντεο)