Προτείνω να διαβάσετε τη μεταγραφή της αναφοράς του Alexander Sigachev από την Inventos "Διαδικασία ανάπτυξης και δοκιμής με το Docker + Gitlab CI"
Όσοι μόλις αρχίζουν να εφαρμόζουν τη διαδικασία ανάπτυξης και δοκιμών που βασίζεται στο Docker + Gitlab CI κάνουν συχνά βασικές ερωτήσεις. Από πού να ξεκινήσω; Πώς να οργανωθεί; Πώς να δοκιμάσετε;
Αυτή η αναφορά είναι καλή επειδή μιλά με δομημένο τρόπο για τη διαδικασία ανάπτυξης και δοκιμής χρησιμοποιώντας το Docker και το Gitlab CI. Η ίδια η έκθεση είναι του 2017. Νομίζω ότι από αυτή την έκθεση μπορείτε να μάθετε τα βασικά, τη μεθοδολογία, την ιδέα, την εμπειρία χρήσης.
Ποιος νοιάζεται, παρακαλώ κάτω από τη γάτα.
Ονομάζομαι Alexander Sigachev. Δουλεύω για την Inventos. Θα σας πω για την εμπειρία μου από τη χρήση του Docker και πώς το υλοποιούμε σταδιακά σε έργα της εταιρείας.
Θέμα παρουσίασης: Διαδικασία ανάπτυξης με χρήση Docker και Gitlab CI.
Αυτή είναι η δεύτερη ομιλία μου για το Docker. Κατά τη στιγμή της πρώτης αναφοράς, χρησιμοποιούσαμε μόνο το Docker στην ανάπτυξη σε μηχανήματα προγραμματιστών. Ο αριθμός των εργαζομένων που χρησιμοποίησαν το Docker ήταν περίπου 2-3 άτομα. Σταδιακά αποκτήθηκε εμπειρία και προχωρήσαμε λίγο πιο πέρα. Σύνδεσμος με το δικό μας .
Τι θα περιλαμβάνει αυτή η έκθεση; Θα μοιραστούμε την εμπειρία μας για το τι γκανιότα έχουμε μαζέψει, τι προβλήματα έχουμε λύσει. Όχι παντού ήταν όμορφο, αλλά επέτρεπε να προχωρήσει.
Το σύνθημά μας είναι: αγκυροβολήστε ό,τι μπορούμε να πάρουμε στα χέρια μας.
Τι προβλήματα λύνουμε;
Όταν υπάρχουν πολλές ομάδες σε μια εταιρεία, ο προγραμματιστής είναι ένας κοινός πόρος. Υπάρχουν στάδια όπου ένας προγραμματιστής αποσύρεται από ένα έργο και δίνεται για κάποιο χρονικό διάστημα σε ένα άλλο έργο.
Για να καταλάβει γρήγορα ο προγραμματιστής, πρέπει να κατεβάσει τον πηγαίο κώδικα του έργου και να εκκινήσει το περιβάλλον το συντομότερο δυνατό, κάτι που θα του επιτρέψει να προχωρήσει περαιτέρω στην επίλυση των προβλημάτων αυτού του έργου.
Συνήθως, αν ξεκινήσετε από το μηδέν, τότε υπάρχει μικρή τεκμηρίωση στο έργο. Πληροφορίες σχετικά με τον τρόπο ρύθμισης είναι διαθέσιμες μόνο σε παλιούς. Οι εργαζόμενοι στήνουν μόνοι τους τον χώρο εργασίας τους σε μία ή δύο ημέρες. Για να το επιταχύνουμε αυτό, χρησιμοποιήσαμε το Docker.
Ο επόμενος λόγος είναι η τυποποίηση των ρυθμίσεων στο Development. Από την εμπειρία μου, οι προγραμματιστές αναλαμβάνουν πάντα την πρωτοβουλία. Σε κάθε πέμπτη περίπτωση, εισάγεται ένας προσαρμοσμένος τομέας, για παράδειγμα, vasya.dev. Δίπλα του κάθεται ο γείτονάς του Petya, του οποίου ο τομέας είναι petya.dev. Αναπτύσσουν έναν ιστότοπο ή κάποιο στοιχείο του συστήματος χρησιμοποιώντας αυτό το όνομα τομέα.
Όταν το σύστημα μεγαλώνει και αυτά τα ονόματα τομέα αρχίζουν να μπαίνουν σε διαμορφώσεις, προκύπτει μια διένεξη περιβάλλοντος ανάπτυξης και η διαδρομή τοποθεσίας ξαναγράφεται.
Το ίδιο συμβαίνει και με τις ρυθμίσεις της βάσης δεδομένων. Κάποιος δεν ασχολείται με την ασφάλεια και λειτουργεί με κενό κωδικό πρόσβασης root. Στο στάδιο της εγκατάστασης, η MySQL ζήτησε από κάποιον κωδικό πρόσβασης και ο κωδικός αποδείχθηκε 123. Συμβαίνει συχνά η διαμόρφωση της βάσης δεδομένων να αλλάζει συνεχώς ανάλογα με την δέσμευση του προγραμματιστή. Κάποιος διόρθωσε, κάποιος δεν διόρθωσε τη διαμόρφωση. Υπήρχαν κόλπα όταν βγάλαμε κάποιο είδος δοκιμαστικής διαμόρφωσης .gitignore και κάθε προγραμματιστής έπρεπε να εγκαταστήσει τη βάση δεδομένων. Αυτό δυσκόλεψε το ξεκίνημα. Είναι απαραίτητο, μεταξύ άλλων, να θυμόμαστε τη βάση δεδομένων. Η βάση δεδομένων πρέπει να προετοιμαστεί, να εισαχθεί ένας κωδικός πρόσβασης, να εγγραφεί ένας χρήστης, να δημιουργηθεί ένας πίνακας κ.λπ.
Ένα άλλο πρόβλημα είναι οι διαφορετικές εκδόσεις των βιβλιοθηκών. Συμβαίνει συχνά ένας προγραμματιστής να εργάζεται με διαφορετικά έργα. Υπάρχει ένα έργο Legacy που ξεκίνησε πριν από πέντε χρόνια (από το 2017 - σημ. εκδ.). Κατά τη στιγμή της κυκλοφορίας, ξεκινήσαμε με τη MySQL 5.5. Υπάρχουν επίσης σύγχρονα έργα όπου προσπαθούμε να εφαρμόσουμε πιο σύγχρονες εκδόσεις της MySQL, για παράδειγμα, 5.7 ή παλαιότερες (το 2017 - σημείωση έκδοσης)
Όποιος εργάζεται με MySQL γνωρίζει ότι αυτές οι βιβλιοθήκες φέρουν εξαρτήσεις μαζί τους. Είναι μάλλον προβληματικό να τρέχεις 2 βάσεις μαζί. Τουλάχιστον, οι παλιοί πελάτες είναι δύσκολο να συνδεθούν στη νέα βάση δεδομένων. Αυτό με τη σειρά του δημιουργεί αρκετά προβλήματα.
Το επόμενο πρόβλημα είναι όταν ένας προγραμματιστής εργάζεται σε τοπικό μηχάνημα, χρησιμοποιεί τοπικούς πόρους, τοπικά αρχεία, τοπική μνήμη RAM. Όλη η αλληλεπίδραση κατά τη στιγμή της ανάπτυξης μιας λύσης σε προβλήματα πραγματοποιείται στο πλαίσιο του γεγονότος ότι λειτουργεί σε ένα μηχάνημα. Ένα παράδειγμα είναι όταν έχουμε διακομιστές υποστήριξης στο Production 3, και ο προγραμματιστής αποθηκεύει αρχεία στον ριζικό κατάλογο και από εκεί το nginx παίρνει αρχεία για να απαντήσει στο αίτημα. Όταν ένας τέτοιος κώδικας μπαίνει στο Production, αποδεικνύεται ότι το αρχείο υπάρχει σε έναν από τους 3 διακομιστές.
Η κατεύθυνση των μικροϋπηρεσιών αναπτύσσεται τώρα. Όταν χωρίζουμε τις μεγάλες εφαρμογές μας σε μερικά μικρά στοιχεία που αλληλεπιδρούν μεταξύ τους. Αυτό σας επιτρέπει να επιλέξετε τεχνολογίες για μια συγκεκριμένη στοίβα εργασιών. Σας επιτρέπει επίσης να μοιράζεστε εργασία και ευθύνες μεταξύ προγραμματιστών.
Ο Frondend-developer, που αναπτύσσεται στο JS, δεν έχει σχεδόν καμία επιρροή στο Backend. Ο προγραμματιστής του backend, με τη σειρά του, αναπτύσσει, στην περίπτωσή μας, το Ruby on Rails και δεν παρεμβαίνει στο Frondend. Η αλληλεπίδραση πραγματοποιείται χρησιμοποιώντας το API.
Ως μπόνους, με τη βοήθεια του Docker, μπορέσαμε να ανακυκλώσουμε πόρους στο Staging. Κάθε έργο, λόγω των ιδιαιτεροτήτων του, απαιτούσε ορισμένες ρυθμίσεις. Από φυσικής πλευράς, ήταν απαραίτητο να εκχωρηθεί είτε ένας εικονικός διακομιστής και να ρυθμιστούν ξεχωριστά, είτε να μοιραστούν κάποιο είδος μεταβλητού περιβάλλοντος και τα έργα μπορούσαν, ανάλογα με την έκδοση των βιβλιοθηκών, να επηρεάσουν το ένα το άλλο.
Εργαλεία. Τι χρησιμοποιούμε;
- Ο ίδιος ο Docker. Το Dockerfile περιγράφει τις εξαρτήσεις μιας μεμονωμένης εφαρμογής.
- Το Docker-compose είναι ένα πακέτο που συγκεντρώνει μερικές από τις εφαρμογές μας Docker.
- Χρησιμοποιούμε το GitLab για να αποθηκεύσουμε τον πηγαίο κώδικα.
- Χρησιμοποιούμε το GitLab-CI για την ενοποίηση συστήματος.
Η έκθεση αποτελείται από δύο μέρη.
Το πρώτο μέρος θα μιλήσει για τον τρόπο λειτουργίας του Docker σε μηχανές προγραμματιστών.
Το δεύτερο μέρος θα μιλήσει για τον τρόπο αλληλεπίδρασης με το GitLab, τον τρόπο εκτέλεσης των δοκιμών και τον τρόπο εισαγωγής στο Staging.
Το Docker είναι μια τεχνολογία που επιτρέπει (χρησιμοποιώντας μια δηλωτική προσέγγιση) να περιγράψει τα απαραίτητα στοιχεία. Αυτό είναι ένα παράδειγμα Dockerfile. Εδώ δηλώνουμε ότι κληρονομούμε από την επίσημη εικόνα Ruby:2.3.0 Docker. Περιέχει εγκατεστημένη την έκδοση Ruby 2.3. Εγκαθιστούμε τις απαιτούμενες βιβλιοθήκες build και το NodeJS. Περιγράφουμε ότι δημιουργούμε έναν κατάλογο /app. Ορίστε τον κατάλογο της εφαρμογής ως κατάλογο εργασίας. Σε αυτόν τον κατάλογο τοποθετούμε το απαιτούμενο ελάχιστο Gemfile και Gemfile.lock. Στη συνέχεια, χτίζουμε τα έργα που εγκαθιστούν αυτήν την εικόνα εξάρτησης. Υποδεικνύουμε ότι το κοντέινερ θα είναι έτοιμο για ακρόαση στην εξωτερική θύρα 3000. Η τελευταία εντολή είναι η εντολή που εκκινεί απευθείας την εφαρμογή μας. Εάν εκτελέσουμε την εντολή έναρξης έργου, η εφαρμογή θα προσπαθήσει να εκτελέσει και να εκτελέσει την καθορισμένη εντολή.
Αυτό είναι ένα ελάχιστο παράδειγμα αρχείου docker-compose. Σε αυτή την περίπτωση, δείχνουμε ότι υπάρχει σύνδεση μεταξύ δύο δοχείων. Αυτό είναι απευθείας στην υπηρεσία βάσης δεδομένων και την υπηρεσία Ιστού. Οι διαδικτυακές εφαρμογές μας στις περισσότερες περιπτώσεις απαιτούν κάποιο είδος βάσης δεδομένων ως backend για την αποθήκευση δεδομένων. Εφόσον χρησιμοποιούμε MySQL, το παράδειγμα είναι με τη MySQL - αλλά τίποτα δεν μας εμποδίζει να χρησιμοποιήσουμε κάποια άλλη βάση δεδομένων (PostgreSQL, Redis).
Παίρνουμε από την επίσημη πηγή από το Docker hub την εικόνα της MySQL 5.7.14 χωρίς αλλαγές. Συλλέγουμε την εικόνα που είναι υπεύθυνη για την εφαρμογή web μας από τον τρέχοντα κατάλογο. Συλλέγει μια εικόνα για εμάς κατά την πρώτη εκτόξευση. Στη συνέχεια, εκτελεί την εντολή που εκτελούμε εδώ. Αν πάμε πίσω, θα δούμε ότι έχει οριστεί η εντολή εκκίνησης μέσω Puma. Η Puma είναι μια υπηρεσία γραμμένη σε Ruby. Στη δεύτερη περίπτωση, παρακάμπτουμε. Αυτή η εντολή μπορεί να είναι αυθαίρετη ανάλογα με τις ανάγκες ή τις εργασίες μας.
Περιγράφουμε επίσης ότι πρέπει να προωθήσουμε μια θύρα στον κεντρικό υπολογιστή προγραμματιστή μας από 3000 σε 3000 στη θύρα κοντέινερ. Αυτό γίνεται αυτόματα χρησιμοποιώντας το iptables και τον μηχανισμό του, ο οποίος είναι απευθείας ενσωματωμένος στο Docker.
Ο προγραμματιστής μπορεί επίσης, όπως και πριν, να έχει πρόσβαση σε οποιαδήποτε διαθέσιμη διεύθυνση IP, για παράδειγμα, το 127.0.0.1 είναι η τοπική ή εξωτερική διεύθυνση IP του μηχανήματος.
Η τελευταία γραμμή λέει ότι το κοντέινερ Ιστού εξαρτάται από το κοντέινερ db. Όταν καλούμε την έναρξη του κοντέινερ Ιστού, το docker-compose θα ξεκινήσει πρώτα τη βάση δεδομένων για εμάς. Ήδη στην αρχή της βάσης δεδομένων (στην πραγματικότητα, μετά την εκκίνηση του κοντέινερ! Αυτό δεν εγγυάται την ετοιμότητα της βάσης δεδομένων) θα ξεκινήσει η εφαρμογή, το backend μας.
Αυτό αποφεύγει σφάλματα όταν η βάση δεδομένων δεν είναι ανοιχτή και εξοικονομεί πόρους όταν σταματάμε το κοντέινερ της βάσης δεδομένων, ελευθερώνοντας έτσι πόρους για άλλα έργα.
Τι μας δίνει τη χρήση της σύνδεσης βάσης δεδομένων στο έργο. Διορθώνουμε την έκδοση της MySQL για όλους τους προγραμματιστές. Αυτό αποφεύγει ορισμένα σφάλματα που μπορεί να προκύψουν όταν οι εκδόσεις αποκλίνουν, όταν αλλάζουν η σύνταξη, η διαμόρφωση, οι προεπιλεγμένες ρυθμίσεις. Αυτό σας επιτρέπει να καθορίσετε ένα κοινό όνομα κεντρικού υπολογιστή για τη βάση δεδομένων, σύνδεση, κωδικό πρόσβασης. Απομακρυνόμαστε από τον ζωολογικό κήπο των ονομάτων και των διενέξεων στα αρχεία ρυθμίσεων που είχαμε νωρίτερα.
Έχουμε την ευκαιρία να χρησιμοποιήσουμε μια πιο βέλτιστη διαμόρφωση για το περιβάλλον ανάπτυξης, η οποία θα διαφέρει από την προεπιλογή. Η MySQL έχει ρυθμιστεί για αδύναμα μηχανήματα από προεπιλογή και η απόδοσή της εκτός κουτιού είναι πολύ κακή.
Το Docker σάς επιτρέπει να χρησιμοποιείτε τον διερμηνέα Python, Ruby, NodeJS, PHP της επιθυμητής έκδοσης. Απαλλαγούμε από την ανάγκη χρήσης κάποιου είδους διαχείρισης εκδόσεων. Προηγουμένως, η Ruby χρησιμοποιούσε ένα πακέτο rpm που σας επέτρεπε να αλλάξετε την έκδοση ανάλογα με το έργο. Επιτρέπει επίσης, χάρη στο κοντέινερ Docker, την ομαλή μετεγκατάσταση του κώδικα και την έκδοση του μαζί με τις εξαρτήσεις. Δεν έχουμε κανένα πρόβλημα να κατανοήσουμε την έκδοση τόσο του διερμηνέα όσο και του κώδικα. Για να ενημερώσετε την έκδοση, χαμηλώστε το παλιό κοντέινερ και σηκώστε το νέο κοντέινερ. Αν κάτι πήγε στραβά, μπορούμε να κατεβάσουμε το νέο δοχείο, να σηκώσουμε το παλιό δοχείο.
Μετά τη δημιουργία της εικόνας, τα κοντέινερ τόσο στην Ανάπτυξη όσο και στην Παραγωγή θα είναι τα ίδια. Αυτό ισχύει ιδιαίτερα για μεγάλες εγκαταστάσεις.
Στο Frontend χρησιμοποιούμε JavaScipt και NodeJS.
Τώρα έχουμε το τελευταίο έργο στο ReacJS. Ο προγραμματιστής έτρεξε τα πάντα στο κοντέινερ και αναπτύχθηκε χρησιμοποιώντας επανάληψη φόρτωσης.
Στη συνέχεια, εκκινείται η εργασία συναρμολόγησης JavaScipt και ο κώδικας που μεταγλωττίζεται σε στατικά δίνεται μέσω πόρων εξοικονόμησης nginx.
Εδώ έχω δώσει το σχήμα του τελευταίου μας έργου.
Ποιες εργασίες επιλύθηκαν; Είχαμε την ανάγκη να δημιουργήσουμε ένα σύστημα με το οποίο αλληλεπιδρούν οι κινητές συσκευές. Λαμβάνουν δεδομένα. Μια δυνατότητα είναι η αποστολή ειδοποιήσεων push σε αυτήν τη συσκευή.
Τι έχουμε κάνει για αυτό;
Χωρίσαμε στην εφαρμογή στοιχεία όπως: το τμήμα διαχείρισης στο JS, το backend, το οποίο λειτουργεί μέσω της διεπαφής REST στο Ruby on Rails. Το backend αλληλεπιδρά με τη βάση δεδομένων. Το αποτέλεσμα που δημιουργείται δίνεται στον πελάτη. Ο πίνακας διαχείρισης αλληλεπιδρά με το backend και τη βάση δεδομένων μέσω της διεπαφής REST.
Είχαμε επίσης την ανάγκη να στείλουμε ειδοποιήσεις push. Πριν από αυτό, είχαμε ένα έργο που εφάρμοσε έναν μηχανισμό που είναι υπεύθυνος για την παράδοση ειδοποιήσεων σε πλατφόρμες για κινητές συσκευές.
Έχουμε αναπτύξει το ακόλουθο σχήμα: ένας χειριστής από το πρόγραμμα περιήγησης αλληλεπιδρά με τον πίνακα διαχείρισης, ο πίνακας διαχείρισης αλληλεπιδρά με το backend, η αποστολή είναι η αποστολή ειδοποιήσεων Push.
Οι ειδοποιήσεις push αλληλεπιδρούν με ένα άλλο στοιχείο που υλοποιείται στο NodeJS.
Δημιουργούνται ουρές και στη συνέχεια αποστέλλονται ειδοποιήσεις σύμφωνα με τον μηχανισμό τους.
Εδώ σχεδιάζονται δύο βάσεις δεδομένων. Προς το παρόν, με τη βοήθεια του Docker, χρησιμοποιούμε 2 ανεξάρτητες βάσεις δεδομένων που δεν έχουν καμία σχέση μεταξύ τους. Επιπλέον, έχουν ένα κοινό εικονικό δίκτυο και τα φυσικά δεδομένα αποθηκεύονται σε διαφορετικούς καταλόγους στον υπολογιστή του προγραμματιστή.
Το ίδιο αλλά σε αριθμούς. Εδώ είναι σημαντική η επαναχρησιμοποίηση του κώδικα.
Αν προηγουμένως μιλήσαμε για επαναχρησιμοποίηση κώδικα με τη μορφή βιβλιοθηκών, τότε σε αυτό το παράδειγμα, η υπηρεσία μας που ανταποκρίνεται στις ειδοποιήσεις Push επαναχρησιμοποιείται ως πλήρης διακομιστής. Παρέχει ένα API. Και η νέα μας ανάπτυξη αλληλεπιδρά ήδη με αυτήν.
Εκείνη την εποχή, χρησιμοποιούσαμε την έκδοση 4 του NodeJS. Τώρα (το 2017 - σημείωση έκδοσης) στις πρόσφατες εξελίξεις χρησιμοποιούμε την έκδοση 7 του NodeJS. Δεν υπάρχει πρόβλημα στα νέα στοιχεία για τη συμμετοχή νέων εκδόσεων βιβλιοθηκών.
Εάν είναι απαραίτητο, μπορείτε να αναδιαμορφώσετε και να αυξήσετε την έκδοση NodeJS από την υπηρεσία ειδοποιήσεων Push.
Και αν μπορέσουμε να διατηρήσουμε τη συμβατότητα API, τότε θα είναι δυνατή η αντικατάστασή του με άλλα έργα που χρησιμοποιήθηκαν στο παρελθόν.
Τι χρειάζεστε για να προσθέσετε το Docker; Προσθέτουμε ένα Dockerfile στο αποθετήριο μας, το οποίο περιγράφει τις απαραίτητες εξαρτήσεις. Σε αυτό το παράδειγμα, τα στοιχεία αναλύονται λογικά. Αυτό είναι το ελάχιστο σύνολο ενός προγραμματιστή υποστήριξης.
Κατά τη δημιουργία ενός νέου έργου, δημιουργούμε ένα Dockerfile, περιγράφουμε το επιθυμητό οικοσύστημα (Python, Ruby, NodeJS). Στο docker-compose, περιγράφει την απαραίτητη εξάρτηση - τη βάση δεδομένων. Περιγράφουμε ότι χρειαζόμαστε μια βάση δεδομένων με τέτοια έκδοση, αποθήκευση δεδομένων εκεί και εκεί.
Χρησιμοποιούμε ένα ξεχωριστό τρίτο δοχείο με nginx για να σερβίρουμε στατικό. Υπάρχει δυνατότητα αποστολής εικόνων. Το Backend τα βάζει σε έναν προπαρασκευασμένο τόμο, ο οποίος είναι επίσης τοποθετημένος σε ένα δοχείο με nginx, που δίνει το στατικό.
Για να αποθηκεύσουμε τη διαμόρφωση nginx, mysql, προσθέσαμε έναν φάκελο Docker στον οποίο αποθηκεύουμε τις απαραίτητες ρυθμίσεις. Όταν ένας προγραμματιστής κάνει έναν κλώνο git ενός αποθετηρίου στον υπολογιστή του, έχει ήδη ένα έργο έτοιμο για τοπική ανάπτυξη. Δεν υπάρχει αμφιβολία ποια θύρα ή ποιες ρυθμίσεις να εφαρμόσετε.
Στη συνέχεια, έχουμε πολλά στοιχεία: admin, inform-API, push notifications.
Για να ξεκινήσουμε όλα αυτά, δημιουργήσαμε ένα άλλο αποθετήριο, το οποίο ονομάσαμε dockerized-app. Αυτή τη στιγμή χρησιμοποιούμε πολλά αποθετήρια πριν από κάθε στοιχείο. Απλώς διαφέρουν λογικά - στο GitLab μοιάζει με φάκελο, αλλά στο μηχάνημα του προγραμματιστή, ένας φάκελος για ένα συγκεκριμένο έργο. Ένα επίπεδο πιο κάτω είναι τα συστατικά που θα συνδυαστούν.
Αυτό είναι ένα παράδειγμα μόνο του περιεχομένου της εφαρμογής dockerized. Φέρνουμε επίσης τον κατάλογο Docker εδώ, στον οποίο συμπληρώνουμε τις διαμορφώσεις που απαιτούνται για τις αλληλεπιδράσεις όλων των στοιχείων. Υπάρχει ένα README.md που περιγράφει εν συντομία τον τρόπο εκτέλεσης του έργου.
Εδώ έχουμε εφαρμόσει δύο αρχεία docker-compose. Αυτό γίνεται για να μπορείτε να τρέξετε σε βήματα. Όταν ένας προγραμματιστής εργάζεται με τον πυρήνα, δεν χρειάζεται ειδοποιήσεις push, απλώς εκκινεί ένα αρχείο docker-compose και, κατά συνέπεια, ο πόρος αποθηκεύεται.
Εάν υπάρχει ανάγκη ενσωμάτωσης με ειδοποιήσεις push, τότε εκκινούνται το docker-compose.yaml και το docker-compose-push.yaml.
Εφόσον το docker-compose.yaml και το docker-compose-push.yaml βρίσκονται σε έναν φάκελο, δημιουργείται αυτόματα ένα ενιαίο εικονικό δίκτυο.
Περιγραφή εξαρτημάτων. Αυτό είναι ένα πιο προηγμένο αρχείο που είναι υπεύθυνο για τη συλλογή στοιχείων. Τι είναι αξιοσημείωτο εδώ; Εδώ εισάγουμε το εξισορροπητικό στοιχείο.
Αυτή είναι μια έτοιμη εικόνα Docker που εκτελεί το nginx και μια εφαρμογή που ακούει στην υποδοχή Docker. Δυναμικό, καθώς τα κοντέινερ ενεργοποιούνται και απενεργοποιούνται, αναγεννά τη διαμόρφωση nginx. Διανέμουμε τον χειρισμό στοιχείων με ονόματα τομέα τρίτου επιπέδου.
Για το περιβάλλον Ανάπτυξης, χρησιμοποιούμε τον τομέα .dev - api.informer.dev. Οι εφαρμογές με τομέα .dev είναι διαθέσιμες στον τοπικό υπολογιστή του προγραμματιστή.
Επιπλέον, οι ρυθμίσεις παραμέτρων μεταφέρονται σε κάθε έργο και όλα τα έργα ξεκινούν ταυτόχρονα.
Γραφικά, αποδεικνύεται ότι ο πελάτης είναι το πρόγραμμα περιήγησής μας ή κάποιο εργαλείο με το οποίο κάνουμε αιτήματα στον εξισορροπητή.
Το πρόγραμμα εξισορρόπησης ονομάτων τομέα καθορίζει με ποιο κοντέινερ πρέπει να επικοινωνήσετε.
Μπορεί να είναι nginx, το οποίο δίνει στον διαχειριστή JS. Αυτό μπορεί να είναι το nginx, το οποίο δίνει το API, ή στατικά αρχεία, τα οποία δίνονται στο nginx με τη μορφή μεταφορτώσεων εικόνων.
Το διάγραμμα δείχνει ότι τα κοντέινερ συνδέονται μέσω ενός εικονικού δικτύου και είναι κρυμμένα πίσω από έναν διακομιστή μεσολάβησης.
Στο μηχάνημα του προγραμματιστή, μπορείτε να αποκτήσετε πρόσβαση στο κοντέινερ γνωρίζοντας την IP, αλλά καταρχήν δεν το χρησιμοποιούμε. Πρακτικά δεν υπάρχει ανάγκη για άμεση πρόσβαση.
Ποιο παράδειγμα να εξετάσετε για να προσαρμόσετε την εφαρμογή σας; Κατά τη γνώμη μου, ένα καλό παράδειγμα είναι η επίσημη εικόνα docker για τη MySQL.
Είναι αρκετά προκλητικό. Υπάρχουν πολλές εκδοχές. Αλλά η λειτουργικότητά του σας επιτρέπει να καλύψετε πολλές ανάγκες που μπορεί να προκύψουν στη διαδικασία περαιτέρω ανάπτυξης. Εάν αφιερώσετε χρόνο και καταλάβετε πώς αλληλεπιδρούν όλα αυτά, τότε νομίζω ότι δεν θα έχετε προβλήματα στην αυτο-υλοποίηση.
Το Hub.docker.com συνήθως περιέχει συνδέσμους προς το github.com, το οποίο περιέχει ακατέργαστα δεδομένα απευθείας από τα οποία μπορείτε να δημιουργήσετε μόνοι σας την εικόνα.
Περαιτέρω σε αυτό το αποθετήριο υπάρχει ένα σενάριο docker-endpoint.sh, το οποίο είναι υπεύθυνο για την αρχική προετοιμασία και για την περαιτέρω επεξεργασία της εκκίνησης της εφαρμογής.
Επίσης σε αυτό το παράδειγμα, υπάρχει η δυνατότητα ρύθμισης παραμέτρων χρησιμοποιώντας μεταβλητές περιβάλλοντος. Ορίζοντας μια μεταβλητή περιβάλλοντος κατά την εκτέλεση ενός μεμονωμένου κοντέινερ ή μέσω του docker-compose, μπορούμε να πούμε ότι πρέπει να ορίσουμε έναν κενό κωδικό πρόσβασης για το docker για root στη MySQL ή οτιδήποτε άλλο θέλουμε.
Υπάρχει η επιλογή δημιουργίας τυχαίου κωδικού πρόσβασης. Λέμε ότι χρειαζόμαστε έναν χρήστη, πρέπει να ορίσουμε έναν κωδικό πρόσβασης για τον χρήστη και πρέπει να δημιουργήσουμε μια βάση δεδομένων.
Στα έργα μας, ενοποιήσαμε ελαφρώς το Dockerfile, το οποίο είναι υπεύθυνο για την προετοιμασία. Εκεί το διορθώσαμε στις ανάγκες μας για να το κάνουμε απλώς μια επέκταση των δικαιωμάτων χρήστη που χρησιμοποιεί η εφαρμογή. Αυτό μας επέτρεψε να δημιουργήσουμε απλώς μια βάση δεδομένων από την κονσόλα εφαρμογών αργότερα. Οι εφαρμογές Ruby έχουν μια εντολή για τη δημιουργία, την τροποποίηση και τη διαγραφή βάσεων δεδομένων.
Αυτό είναι ένα παράδειγμα για το πώς φαίνεται μια συγκεκριμένη έκδοση της MySQL στο github.com. Μπορείτε να ανοίξετε το Dockerfile και να δείτε πώς γίνεται η εγκατάσταση εκεί.
Το docker-endpoint.sh είναι το σενάριο που είναι υπεύθυνο για το σημείο εισόδου. Κατά την αρχική προετοιμασία, απαιτούνται ορισμένα βήματα προετοιμασίας και όλες αυτές οι ενέργειες πραγματοποιούνται μόνο στο σενάριο προετοιμασίας.
Ας περάσουμε στο δεύτερο μέρος.
Για να αποθηκεύσουμε τους πηγαίους κώδικες, μεταβήκαμε στο gitlab. Αυτό είναι ένα αρκετά ισχυρό σύστημα που διαθέτει οπτική διεπαφή.
Ένα από τα στοιχεία του Gitlab είναι το Gitlab CI. Σας επιτρέπει να περιγράψετε μια ακολουθία εντολών που αργότερα θα χρησιμοποιηθούν για την οργάνωση ενός συστήματος παράδοσης κώδικα ή την εκτέλεση αυτόματων δοκιμών.
Συζήτηση Gitlab CI 2 - ρεπορτάζ από το Ruby Russia club - αρκετά αναλυτικό και ίσως σας ενδιαφέρει.
Τώρα θα δούμε τι απαιτείται για την ενεργοποίηση του Gitlab CI. Για να ξεκινήσουμε το Gitlab CI, πρέπει απλώς να βάλουμε το αρχείο .gitlab-ci.yml στη ρίζα του έργου.
Εδώ περιγράφουμε ότι θέλουμε να εκτελέσουμε μια ακολουθία καταστάσεων όπως μια δοκιμή, ανάπτυξη.
Εκτελούμε σενάρια που καλούν απευθείας το docker-compose για να δημιουργήσουμε την εφαρμογή μας. Αυτό είναι απλώς ένα παράδειγμα backend.
Στη συνέχεια, λέμε ότι είναι απαραίτητο να εκτελεστούν οι μετεγκαταστάσεις για να αλλάξετε τη βάση δεδομένων και να εκτελέσετε δοκιμές.
Εάν τα σενάρια εκτελούνται σωστά και δεν εμφανίζει κωδικό σφάλματος, τότε, κατά συνέπεια, το σύστημα προχωρά στο δεύτερο στάδιο της ανάπτυξης.
Το στάδιο της ανάπτυξης εφαρμόζεται επί του παρόντος για σταδιοποίηση. Δεν οργανώσαμε επανεκκίνηση μηδενικής διακοπής λειτουργίας.
Σβήνουμε δια της βίας όλα τα δοχεία και μετά σηκώνουμε ξανά όλα τα δοχεία, που συγκεντρώθηκαν στο πρώτο στάδιο κατά τη διάρκεια της δοκιμής.
Εκτελούμε για την τρέχουσα μεταβλητή περιβάλλοντος τις μετεγκαταστάσεις βάσης δεδομένων που γράφτηκαν από τους προγραμματιστές.
Υπάρχει μια σημείωση ότι αυτό ισχύει μόνο για τον κύριο κλάδο.
Κατά την αλλαγή άλλων κλάδων δεν εκτελείται.
Είναι δυνατή η οργάνωση λανσαρίσματος ανά υποκαταστήματα.
Για να το οργανώσουμε περαιτέρω, πρέπει να εγκαταστήσουμε το Gitlab Runner.
Αυτό το βοηθητικό πρόγραμμα είναι γραμμένο σε Golang. Είναι ένα ενιαίο αρχείο, όπως συνηθίζεται στον κόσμο του Golang, το οποίο δεν απαιτεί εξαρτήσεις.
Κατά την εκκίνηση, καταχωρούμε το Gitlab Runner.
Παίρνουμε το κλειδί στη διεπαφή ιστού Gitlab.
Στη συνέχεια καλούμε την εντολή προετοιμασίας στη γραμμή εντολών.
Ρύθμιση του Gitlab Runner διαδραστικά (Shell, Docker, VirtualBox, SSH)
Ο κώδικας στο Gitlab Runner θα εκτελείται σε κάθε δέσμευση, ανάλογα με τη ρύθμιση .gitlab-ci.yml.
Πώς φαίνεται οπτικά στο Gitlab στη διεπαφή ιστού. Αφού συνδέσουμε το GItlab CI, έχουμε μια σημαία που δείχνει την κατάσταση της κατασκευής αυτή τη στιγμή.
Βλέπουμε ότι έγινε δέσμευση πριν από 4 λεπτά, που πέρασε όλα τα τεστ και δεν δημιούργησε κανένα πρόβλημα.
Μπορούμε να ρίξουμε μια πιο προσεκτική ματιά στις κατασκευές. Εδώ βλέπουμε ότι έχουν ήδη περάσει δύο πολιτείες. Κατάσταση δοκιμής και κατάσταση ανάπτυξης κατά τη σταδιοποίηση.
Εάν κάνουμε κλικ σε μια συγκεκριμένη κατασκευή, τότε θα υπάρχει μια έξοδος κονσόλας με τις εντολές που εκτελέστηκαν στη διαδικασία σύμφωνα με το .gitlab-ci.yml.
Αυτό είναι το ιστορικό των προϊόντων μας. Βλέπουμε ότι υπήρξαν επιτυχημένες προσπάθειες. Όταν υποβάλλονται δοκιμές, δεν προχωρά στο επόμενο βήμα και ο κώδικας σταδιοποίησης δεν ενημερώνεται.
Ποιες εργασίες λύσαμε στη σκηνή όταν εφαρμόσαμε το docker; Το σύστημά μας αποτελείται από στοιχεία και χρειαζόταν επανεκκίνηση, μόνο μέρος των στοιχείων που ενημερώθηκαν στο αποθετήριο και όχι ολόκληρο το σύστημα.
Για να γίνει αυτό, έπρεπε να σπάσουμε τα πάντα σε ξεχωριστούς φακέλους.
Αφού το κάναμε αυτό, είχαμε πρόβλημα με το γεγονός ότι το Docker-compose δημιουργεί τον δικό του χώρο δικτύου για κάθε μπαμπά και δεν βλέπει τα στοιχεία του γείτονα.
Για να μετακινηθείτε, δημιουργήσαμε το δίκτυο στο Docker χειροκίνητα. Γράφτηκε στο Docker-compose ότι χρησιμοποιείτε ένα τέτοιο δίκτυο για αυτό το έργο.
Έτσι, κάθε στοιχείο που ξεκινά με αυτό το πλέγμα βλέπει εξαρτήματα σε άλλα μέρη του συστήματος.
Το επόμενο ζήτημα είναι ο διαχωρισμός της σταδιοποίησης σε πολλά έργα.
Αφού για να φαίνονται όλα αυτά όμορφα και όσο το δυνατόν πιο κοντά στην παραγωγή, καλό είναι να χρησιμοποιήσετε τη θύρα 80 ή 443 που χρησιμοποιείται παντού στο WEB.
Πώς το λύσαμε; Έχουμε εκχωρήσει ένα Gitlab Runner σε όλα τα μεγάλα έργα.
Το Gitlab σάς επιτρέπει να εκτελέσετε αρκετούς κατανεμημένους Gitlab Runners, οι οποίοι απλώς θα αναλάβουν όλες τις εργασίες με τη σειρά τους με χαοτικό τρόπο και θα τις εκτελέσουν.
Για να μην έχουμε σπίτι, περιορίσαμε την ομάδα των έργων μας σε ένα Gitlab Runner, το οποίο αντιμετωπίζει χωρίς προβλήματα τους όγκους μας.
Μεταφέραμε το nginx-proxy σε ένα ξεχωριστό σενάριο εκκίνησης και προσθέσαμε πλέγματα για όλα τα έργα σε αυτό.
Το έργο μας έχει ένα πλέγμα και ο εξισορροπητής έχει πολλά πλέγματα με ονόματα έργων. Μπορεί να διαμεσολαβήσει περαιτέρω με ονόματα τομέα.
Τα αιτήματά μας προέρχονται μέσω του τομέα στη θύρα 80 και επιλύονται σε μια ομάδα κοντέινερ που εξυπηρετεί αυτόν τον τομέα.
Τι άλλα προβλήματα υπήρχαν; Αυτό είναι αυτό που όλα τα κοντέινερ εκτελούνται ως root από προεπιλογή. Αυτή είναι η ρίζα άνιση με τον ξενιστή ρίζας του συστήματος.
Ωστόσο, εάν εισαγάγετε το κοντέινερ, θα είναι root και το αρχείο που δημιουργούμε σε αυτό το κοντέινερ αποκτά δικαιώματα root.
Εάν ο προγραμματιστής μπήκε στο κοντέινερ και έκανε κάποιες εντολές εκεί που δημιουργούν αρχεία, μετά έφυγε από το κοντέινερ, τότε έχει ένα αρχείο στον κατάλογο εργασίας του στο οποίο δεν έχει πρόσβαση.
Πώς μπορεί να λυθεί; Μπορείτε να προσθέσετε χρήστες που θα βρίσκονται στο κοντέινερ.
Τι προβλήματα προέκυψαν όταν προσθέσαμε τον χρήστη;
Κατά τη δημιουργία ενός χρήστη, συχνά δεν έχουμε το ίδιο αναγνωριστικό ομάδας (UID) και αναγνωριστικό χρήστη (GID).
Για να λύσουμε αυτό το πρόβλημα στο κοντέινερ, χρησιμοποιούμε χρήστες με ID 1000.
Στην περίπτωσή μας, αυτό συνέπεσε με το γεγονός ότι σχεδόν όλοι οι προγραμματιστές χρησιμοποιούν το Ubuntu OS. Και στο Ubuntu, ο πρώτος χρήστης έχει αναγνωριστικό 1000.
Έχουμε σχέδια;
Διαβάστε την τεκμηρίωση του Docker. Το έργο αναπτύσσεται ενεργά, η τεκμηρίωση αλλάζει. Τα δεδομένα που ελήφθησαν πριν από δύο ή τρεις μήνες γίνονται ήδη σιγά σιγά ξεπερασμένα.
Μερικά από τα προβλήματα που λύσαμε είναι πολύ πιθανό να έχουν ήδη λυθεί με τυπικά μέσα.
Θέλω λοιπόν να πάω πιο μακριά για να πάω κατευθείαν στην ενορχήστρωση.
Ένα παράδειγμα είναι ο ενσωματωμένος μηχανισμός του Docker που ονομάζεται Docker Swarm, ο οποίος βγαίνει από το κουτί. Θέλω να τρέξω κάτι στην παραγωγή που βασίζεται στην τεχνολογία Docker Swarm.
Τα δοχεία αναπαραγωγής καθιστούν άβολη την εργασία με κορμούς. Τώρα τα κούτσουρα είναι απομονωμένα. Είναι διάσπαρτα σε δοχεία. Μία από τις εργασίες είναι η εύκολη πρόσβαση στα αρχεία καταγραφής μέσω της διεπαφής Ιστού.
Πηγή: www.habr.com