Πρώτον, μια μικρή θεωρία. Τι συνέβη ?
Με απλά λόγια, αυτό το έγγραφο έχει σχεδιαστεί για να απλοποιεί την ανάπτυξη εφαρμογών SaaS, βοηθώντας τους προγραμματιστές και τους μηχανικούς DevOps για τα προβλήματα και τις πρακτικές που συναντώνται συχνότερα στην ανάπτυξη σύγχρονων εφαρμογών.
Το έγγραφο δημιουργήθηκε από τους προγραμματιστές της πλατφόρμας Heroku.
Η εφαρμογή Twelve-Factor μπορεί να εφαρμοστεί σε εφαρμογές γραμμένες σε οποιαδήποτε γλώσσα προγραμματισμού και χρησιμοποιώντας οποιονδήποτε συνδυασμό υπηρεσιών υποστήριξης (βάσεις δεδομένων, ουρές μηνυμάτων, κρυφές μνήμες κ.λπ.).
Εν συντομία σχετικά με τους παράγοντες στους οποίους βασίζεται αυτή η μεθοδολογία:
- Βάση κωδικών – Μία βάση κώδικα που παρακολουθείται στον έλεγχο έκδοσης – πολλαπλές αναπτύξεις
- Εξαρτήσεις – Ρητή δήλωση και απομόνωση εξαρτήσεων
- Διαμόρφωση – Αποθήκευση διαμόρφωσης σε χρόνο εκτέλεσης
- Υπηρεσίες υποστήριξης – Εξετάστε τις υπηρεσίες υποστήριξης ως πρόσθετους πόρους
- Κατασκευάστε, απελευθερώστε, τρέξτε – Διαχωρίστε αυστηρά τα στάδια συναρμολόγησης και εκτέλεσης
- Διαδικασίες – Εκτελέστε την εφαρμογή ως μία ή περισσότερες διαδικασίες χωρίς ιθαγένεια
- Λιμενικό δέσιμο – Υπηρεσίες εξαγωγής μέσω port binding
- Παραλληλισμός – Κλιμακώστε την εφαρμογή σας χρησιμοποιώντας διαδικασίες
- Μιας χρήσης – Μεγιστοποιήστε την αξιοπιστία με γρήγορη εκκίνηση και καθαρό τερματισμό λειτουργίας
- Ισοτιμία ανάπτυξης/λειτουργίας εφαρμογών – Διατηρήστε τα περιβάλλοντα ανάπτυξης, σκηνοθεσίας και παραγωγής όσο το δυνατόν πιο παρόμοια
- Ξύλευση – Προβολή του αρχείου καταγραφής ως ροή γεγονότων
- Καθήκοντα διοίκησης – Εκτελέστε εργασίες διαχείρισης/διαχείρισης χρησιμοποιώντας ad hoc διαδικασίες
Μπορείτε να λάβετε περισσότερες πληροφορίες σχετικά με τους 12 παράγοντες από τους ακόλουθους πόρους:
- - Πρέπει να διαβαστεί
- — επίσημη μετάφραση
- - μια νέα ματιά στους 12 παράγοντες με στόχο τη βελτίωσή τους.
Τι είναι η ανάπτυξη του μπλε-πράσινου;
Η ανάπτυξη του μπλε-πράσινου είναι μια μέθοδος παράδοσης μιας εφαρμογής σε παραγωγή με τέτοιο τρόπο ώστε ο τελικός πελάτης να μην βλέπει καμία αλλαγή από την πλευρά του. Με άλλα λόγια, ανάπτυξη μιας εφαρμογής με μηδέν downtime.
Το κλασικό σχήμα BG Deploy μοιάζει με αυτό που φαίνεται στην παρακάτω εικόνα.
- Στην αρχή υπάρχουν 2 φυσικοί διακομιστές με τον ίδιο απολύτως κωδικό, εφαρμογή, έργο, και υπάρχει ένας δρομολογητής (balancer).
- Ο δρομολογητής κατευθύνει αρχικά όλα τα αιτήματα σε έναν από τους διακομιστές (πράσινος).
- Τη στιγμή που πρέπει να κυκλοφορήσετε ξανά, ολόκληρο το έργο ενημερώνεται σε άλλο διακομιστή (синий), η οποία δεν επεξεργάζεται προς το παρόν κανένα αίτημα.
- Αφού ενεργοποιηθεί ο κωδικός μπλε Ο διακομιστής είναι πλήρως ενημερωμένος, ο δρομολογητής λαμβάνει μια εντολή για εναλλαγή πράσινο επί синий υπηρέτης.
- Τώρα όλοι οι πελάτες βλέπουν το αποτέλεσμα του κώδικα που εκτελείται με μπλε υπηρέτης.
- Για κάποιο χρονικό διάστημα, πράσινος ο διακομιστής χρησιμεύει ως αντίγραφο ασφαλείας σε περίπτωση ανεπιτυχούς ανάπτυξης σε синий διακομιστή και σε περίπτωση αποτυχίας και σφαλμάτων, ο δρομολογητής επιστρέφει τη ροή χρήστη πράσινος διακομιστή με την παλιά σταθερή έκδοση και ο νέος κώδικας αποστέλλεται για αναθεώρηση και δοκιμή.
- Και στο τέλος της διαδικασίας, ενημερώνεται με τον ίδιο τρόπο πράσινος υπηρέτης. Και μετά την ενημέρωσή του, ο δρομολογητής αλλάζει ξανά τη ροή αιτημάτων πράσινος υπηρέτης.
Όλα φαίνονται πολύ καλά και με την πρώτη ματιά δεν θα πρέπει να υπάρχουν προβλήματα με αυτό.
Αλλά επειδή ζούμε στον σύγχρονο κόσμο, η επιλογή με φυσική εναλλαγή όπως υποδεικνύεται στο κλασικό σχήμα δεν μας ταιριάζει. Καταγράψτε τις πληροφορίες προς το παρόν, θα επανέλθουμε σε αυτές αργότερα.
Κακές και καλές συμβουλές
Αποποίηση ευθυνών: Τα παρακάτω παραδείγματα δείχνουν τα βοηθητικά προγράμματα/μεθοδολογίες που χρησιμοποιώ, μπορείτε να χρησιμοποιήσετε απολύτως οποιεσδήποτε εναλλακτικές με παρόμοιες λειτουργίες.
Τα περισσότερα από τα παραδείγματα θα διασταυρωθούν με τον ένα ή τον άλλο τρόπο με την ανάπτυξη ιστού (αυτό είναι έκπληξη), με την PHP και το Docker.
Οι παρακάτω παράγραφοι παρέχουν μια απλή πρακτική περιγραφή της χρήσης παραγόντων χρησιμοποιώντας συγκεκριμένα παραδείγματα. Εάν θέλετε να αποκτήσετε περισσότερη θεωρία σχετικά με αυτό το θέμα, ακολουθήστε τους παραπάνω συνδέσμους προς την αρχική πηγή.
1. Βάση κωδικών
Χρησιμοποιήστε FTP και FileZilla για να ανεβάσετε αρχεία στους διακομιστές ένα κάθε φορά, μην αποθηκεύετε τον κώδικα οπουδήποτε αλλού εκτός από τον διακομιστή παραγωγής.
Το έργο πρέπει να έχει πάντα μια ενιαία βάση κώδικα, δηλαδή όλος ο κώδικας προέρχεται από έναν Git αποθήκη. Οι διακομιστές (παραγωγή, σταδιοποίηση, test1, test2...) χρησιμοποιούν κώδικα από κλάδους ενός κοινού αποθετηρίου. Με αυτόν τον τρόπο επιτυγχάνουμε συνέπεια κώδικα.
2. Εξαρτήσεις
Κάντε λήψη όλων των βιβλιοθηκών σε φακέλους απευθείας στη ρίζα του έργου. Πραγματοποιήστε ενημερώσεις απλώς μεταφέροντας τον νέο κώδικα στον φάκελο με την τρέχουσα έκδοση της βιβλιοθήκης. Εγκαταστήστε όλα τα απαραίτητα βοηθητικά προγράμματα απευθείας στον κεντρικό διακομιστή όπου εκτελούνται άλλες 20 υπηρεσίες.
Ένα έργο πρέπει πάντα να έχει μια σαφώς κατανοητή λίστα εξαρτήσεων (με τον όρο εξαρτήσεις εννοώ και το περιβάλλον). Όλες οι εξαρτήσεις πρέπει να ορίζονται ρητά και να απομονώνονται.
Ας πάρουμε ως παράδειγμα Συνθέτης и Λιμενεργάτης.
Συνθέτης — ένας διαχειριστής πακέτων που σας επιτρέπει να εγκαταστήσετε βιβλιοθήκες στην PHP. Το Composer σάς επιτρέπει να προσδιορίζετε εκδόσεις αυστηρά ή χαλαρά και να τις ορίζετε ρητά. Μπορούν να υπάρχουν 20 διαφορετικά έργα στον διακομιστή και το καθένα θα έχει μια προσωπική λίστα πακέτων και βιβλιοθηκών ανεξάρτητα από το άλλο.
Λιμενεργάτης — ένα βοηθητικό πρόγραμμα που σας επιτρέπει να ορίσετε και να απομονώσετε το περιβάλλον στο οποίο θα εκτελείται η εφαρμογή. Αντίστοιχα, όπως και με τον συνθέτη, αλλά πιο διεξοδικά, μπορούμε να προσδιορίσουμε με τι λειτουργεί η εφαρμογή. Επιλέξτε μια συγκεκριμένη έκδοση της PHP, εγκαταστήστε μόνο τα πακέτα που είναι απαραίτητα για να λειτουργήσει το έργο, χωρίς να προσθέσετε τίποτα επιπλέον. Και το πιο σημαντικό, χωρίς να παρεμβαίνουν στα πακέτα και το περιβάλλον της μηχανής υποδοχής και άλλων έργων. Δηλαδή, όλα τα έργα στον διακομιστή που εκτελούνται μέσω του Docker μπορούν να χρησιμοποιούν απολύτως οποιοδήποτε σύνολο πακέτων και ένα εντελώς διαφορετικό περιβάλλον.
3. Διαμόρφωση
Αποθηκεύστε τις ρυθμίσεις παραμέτρων ως σταθερές απευθείας στον κώδικα. Ξεχωριστές σταθερές για τον δοκιμαστικό διακομιστή, ξεχωριστές για παραγωγή. Δέστε τη λειτουργία της εφαρμογής ανάλογα με το περιβάλλον απευθείας στην επιχειρηματική λογική του έργου χρησιμοποιώντας το if else constructs.
Διαμορφώσεις - αυτός είναι ο μόνος τρόπος που πρέπει να διαφέρουν οι αναπτύξεις έργων. Στην ιδανική περίπτωση, οι διαμορφώσεις θα πρέπει να περνούν μέσω μεταβλητών περιβάλλοντος (env vars).
Δηλαδή, ακόμα κι αν αποθηκεύσετε πολλά αρχεία διαμόρφωσης .config.prod .config.local και τα μετονομάσετε σε .config (η κύρια διαμόρφωση από την οποία η εφαρμογή διαβάζει δεδομένα) - αυτή δεν θα είναι η σωστή προσέγγιση, καθώς Σε αυτήν την περίπτωση, οι πληροφορίες από τις διαμορφώσεις θα είναι δημόσια διαθέσιμες σε όλους τους προγραμματιστές εφαρμογών και τα δεδομένα από τον διακομιστή παραγωγής θα παραβιαστούν. Όλες οι διαμορφώσεις πρέπει να αποθηκεύονται απευθείας στο σύστημα ανάπτυξης (CI/CD) και να δημιουργούνται για διαφορετικά περιβάλλοντα με διαφορετικές τιμές απαραίτητες για ένα συγκεκριμένο περιβάλλον τη στιγμή της ανάπτυξης.
4. Υπηρεσίες τρίτων
Να είστε αυστηρά συνδεδεμένοι με το περιβάλλον, να χρησιμοποιείτε διαφορετικές συνδέσεις για τις ίδιες υπηρεσίες σε ορισμένα περιβάλλοντα.
Στην πραγματικότητα, αυτό το σημείο επικαλύπτεται έντονα με το σημείο σχετικά με τις διαμορφώσεις, καθώς χωρίς αυτό το σημείο, δεν μπορούν να γίνουν κανονικά δεδομένα διαμόρφωσης και, γενικά, η δυνατότητα ρύθμισης παραμέτρων θα πέσει σε τίποτα.
Όλες οι συνδέσεις με εξωτερικές υπηρεσίες, όπως διακομιστές ουράς, βάσεις δεδομένων, υπηρεσίες προσωρινής αποθήκευσης, πρέπει να είναι ίδιες τόσο για το τοπικό περιβάλλον όσο και για το περιβάλλον τρίτων/παραγωγής. Με άλλα λόγια, ανά πάσα στιγμή, αλλάζοντας τη συμβολοσειρά σύνδεσης, μπορώ να αντικαταστήσω τις κλήσεις στη βάση #1 με τη βάση #2 χωρίς να αλλάξω τον κωδικό της εφαρμογής. Ή, κοιτάζοντας μπροστά, για παράδειγμα, κατά την κλιμάκωση της υπηρεσίας, δεν θα χρειαστεί να καθορίσετε τη σύνδεση με κάποιον ειδικό τρόπο για έναν πρόσθετο διακομιστή προσωρινής μνήμης.
5. Κατασκευή, απελευθέρωση, εκτέλεση
Έχετε μόνο την τελική έκδοση του κώδικα στον διακομιστή, χωρίς καμία πιθανότητα επαναφοράς της κυκλοφορίας. Δεν χρειάζεται να γεμίσετε χώρο στο δίσκο. Όποιος πιστεύει ότι μπορεί να κυκλοφορήσει κώδικα στην παραγωγή με ένα λάθος είναι κακός προγραμματιστής!
Όλα τα στάδια ανάπτυξης πρέπει να είναι διαχωρισμένα μεταξύ τους.
Έχετε την ευκαιρία να γυρίσετε πίσω. Κάντε εκδόσεις με παλιά αντίγραφα της εφαρμογής (ήδη συναρμολογημένα και έτοιμα για μάχη) αποθηκευμένα σε γρήγορη πρόσβαση, ώστε σε περίπτωση σφαλμάτων να μπορείτε να επαναφέρετε την παλιά έκδοση. Δηλαδή, υπό όρους υπάρχει ένας φάκελος κυκλοφορίες και φάκελο ρεύμα, και μετά την επιτυχή ανάπτυξη και συναρμολόγηση του φακέλου ρεύμα συνδέεται με έναν συμβολικό σύνδεσμο με τη νέα κυκλοφορία που βρίσκεται μέσα κυκλοφορίες με τη συμβατική ονομασία του αριθμού κυκλοφορίας.
Εδώ θυμόμαστε την ανάπτυξη του Blue-Green, που σας επιτρέπει όχι μόνο να κάνετε εναλλαγή μεταξύ κώδικα, αλλά και να κάνετε εναλλαγή μεταξύ όλων των πόρων και ακόμη και περιβαλλόντων με τη δυνατότητα να επαναφέρετε τα πάντα.
6. Διαδικασίες
Αποθηκεύστε δεδομένα κατάστασης εφαρμογής απευθείας μέσα στην ίδια την εφαρμογή. Χρησιμοποιήστε συνεδρίες στη μνήμη RAM της ίδιας της εφαρμογής. Χρησιμοποιήστε όσο το δυνατόν περισσότερη κοινή χρήση μεταξύ υπηρεσιών τρίτων. Επιμείνετε στο γεγονός ότι η εφαρμογή μπορεί να έχει μόνο μία διαδικασία και να μην επιτρέπεται η κλιμάκωση.
Όσον αφορά τις περιόδους σύνδεσης, αποθηκεύστε δεδομένα μόνο σε μια κρυφή μνήμη που ελέγχεται από υπηρεσίες τρίτων (memcached, redis), οπότε ακόμα κι αν έχετε 20 διαδικασίες εφαρμογών που εκτελούνται, οποιαδήποτε από αυτές, έχοντας πρόσβαση στην προσωρινή μνήμη, θα μπορεί να συνεχίσει να εργάζεται με τον πελάτη στο την ίδια κατάσταση στην οποία ο χρήστης εργαζόταν με την εφαρμογή σε άλλη διαδικασία. Με αυτήν την προσέγγιση, αποδεικνύεται ότι ανεξάρτητα από το πόσα αντίγραφα υπηρεσιών τρίτων χρησιμοποιείτε, όλα θα λειτουργούν κανονικά και χωρίς προβλήματα με την πρόσβαση στα δεδομένα.
7. Λιμενικό δέσιμο
Μόνο ο διακομιστής Ιστού πρέπει να γνωρίζει πώς να λειτουργεί με υπηρεσίες τρίτων. Ή ακόμα καλύτερα, εγκαταστήστε υπηρεσίες τρίτων απευθείας μέσα στον web server. Για παράδειγμα, ως λειτουργική μονάδα PHP στον Apache.
Όλες οι υπηρεσίες σας πρέπει να είναι προσβάσιμες μεταξύ τους μέσω πρόσβασης σε κάποια διεύθυνση και θύρα (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), δηλαδή από το nginx μπορώ να έχω πρόσβαση και στα php-fpm και σε postgres, και από php-fpm έως postgres και nginx και στην πραγματικότητα από κάθε υπηρεσία μπορώ να έχω πρόσβαση σε άλλη υπηρεσία. Με αυτόν τον τρόπο, η βιωσιμότητα μιας υπηρεσίας δεν συνδέεται με τη βιωσιμότητα μιας άλλης υπηρεσίας.
8. Παραλληλισμός
Εργαστείτε με μία διαδικασία, διαφορετικά πολλές διεργασίες δεν θα μπορέσουν να συνεννοηθούν μεταξύ τους!
Αφήστε χώρο για κλιμάκωση. Το σμήνος Docker είναι εξαιρετικό για αυτό.
Το Docker Swarm είναι ένα εργαλείο για τη δημιουργία και τη διαχείριση συστάδων κοντέινερ τόσο μεταξύ διαφορετικών μηχανών όσο και σε μια δέσμη κοντέινερ στο ίδιο μηχάνημα.
Χρησιμοποιώντας το swarm, μπορώ να προσδιορίσω πόσους πόρους θα διαθέσω σε κάθε διεργασία και πόσες διεργασίες της ίδιας υπηρεσίας θα εκκινήσω και ο εσωτερικός εξισορροπητής, που λαμβάνει δεδομένα σε μια δεδομένη θύρα, θα το μεταφέρει αυτόματα στις διεργασίες. Έτσι, βλέποντας ότι ο φόρτος στον διακομιστή έχει αυξηθεί, μπορώ να προσθέσω περισσότερες διεργασίες, μειώνοντας έτσι το φόρτο σε ορισμένες διεργασίες.
9. Μίας χρήσης
Μην χρησιμοποιείτε ουρές για να εργαστείτε με διαδικασίες και δεδομένα. Η θανάτωση μιας διαδικασίας θα πρέπει να επηρεάσει ολόκληρη την εφαρμογή. Αν πέσει μια υπηρεσία, πέφτουν όλα.
Κάθε διαδικασία και υπηρεσία μπορεί να απενεργοποιηθεί ανά πάσα στιγμή και αυτό δεν πρέπει να επηρεάζει άλλες υπηρεσίες (φυσικά, αυτό δεν σημαίνει ότι η υπηρεσία δεν θα είναι διαθέσιμη για άλλη υπηρεσία, αλλά ότι άλλη υπηρεσία δεν θα απενεργοποιηθεί μετά από αυτήν). Όλες οι διαδικασίες πρέπει να τερματίζονται με χάρη, έτσι ώστε όταν τερματιστούν, να μην καταστραφούν δεδομένα και το σύστημα να λειτουργεί σωστά την επόμενη φορά που θα το ενεργοποιήσετε. Δηλαδή, ακόμη και σε περίπτωση έκτακτης τερματισμού, τα δεδομένα δεν θα πρέπει να καταστραφούν (ο μηχανισμός συναλλαγής είναι κατάλληλος εδώ, τα ερωτήματα στη βάση δεδομένων λειτουργούν μόνο σε ομάδες και εάν τουλάχιστον ένα ερώτημα από την ομάδα αποτύχει ή εκτελεστεί με σφάλμα, τότε κανένα άλλο ερώτημα από την ομάδα δεν αποτυγχάνει τελικά στην πραγματικότητα).
10. Ισοτιμία ανάπτυξης/λειτουργίας εφαρμογών
Η παραγωγή, το σκηνικό και η τοπική έκδοση της εφαρμογής πρέπει να διαφέρουν. Στην παραγωγή χρησιμοποιούμε το πλαίσιο Yii Lite, και τοπικά το Yii, ώστε να λειτουργεί πιο γρήγορα στην παραγωγή!
Στην πραγματικότητα, όλες οι αναπτύξεις και η εργασία με κώδικα θα πρέπει να είναι σχεδόν σε ίδιο περιβάλλον (δεν μιλάμε για φυσικό υλικό). Επίσης, οποιοσδήποτε υπάλληλος ανάπτυξης θα πρέπει να μπορεί να αναπτύξει τον κώδικα στην παραγωγή εάν είναι απαραίτητο, και όχι κάποιο ειδικά εκπαιδευμένο τμήμα devops, το οποίο μόνο χάρη στην ειδική δύναμη μπορεί να φέρει την εφαρμογή στην παραγωγή.
Ο Docker μας βοηθά επίσης σε αυτό. Εάν τηρηθούν όλα τα προηγούμενα σημεία, η χρήση του docker θα φέρει τη διαδικασία ανάπτυξης του περιβάλλοντος τόσο στην παραγωγή όσο και στο τοπικό μηχάνημα στην εισαγωγή μίας ή δύο εντολών.
11. Κορμούς
Γράφουμε αρχεία καταγραφής σε αρχεία και βάσεις δεδομένων! Δεν καθαρίζουμε αρχεία και βάσεις δεδομένων από αρχεία καταγραφής. Ας αγοράσουμε απλώς έναν σκληρό δίσκο με 9000 Peta byte και αυτό είναι εντάξει.
Όλα τα αρχεία καταγραφής πρέπει να θεωρούνται ως μια ροή γεγονότων. Η ίδια η εφαρμογή δεν πρέπει να εμπλέκεται στην επεξεργασία αρχείων καταγραφής. Τα αρχεία καταγραφής πρέπει να εξάγονται είτε στο stdout είτε να αποστέλλονται μέσω πρωτοκόλλου όπως το udp, έτσι ώστε η εργασία με αρχεία καταγραφής να μην δημιουργεί προβλήματα στην εφαρμογή. Το graylog είναι καλό για αυτό. Η Graylog που λαμβάνει όλα τα αρχεία καταγραφής μέσω udp (αυτό το πρωτόκολλο δεν απαιτεί αναμονή για απάντηση σχετικά με την επιτυχή λήψη του πακέτου) δεν παρεμβαίνει με κανέναν τρόπο στην εφαρμογή και ασχολείται μόνο με τη δόμηση και την επεξεργασία αρχείων καταγραφής. Η λογική της εφαρμογής δεν αλλάζει για να λειτουργήσει με τέτοιες προσεγγίσεις.
12. Καθήκοντα διοίκησης
Για να ενημερώσετε δεδομένα, βάσεις δεδομένων κ.λπ., χρησιμοποιήστε ένα ξεχωριστά δημιουργημένο τελικό σημείο στο API, η εκτέλεσή του 2 φορές στη σειρά θα έχει ως αποτέλεσμα τα πάντα να αντιγραφούν. Αλλά δεν είστε ανόητοι, δεν θα κάνετε κλικ δύο φορές και δεν χρειαζόμαστε μετεγκατάσταση.
Όλες οι εργασίες διαχείρισης πρέπει να εκτελούνται στο ίδιο περιβάλλον με όλους τους κωδικούς, στο επίπεδο έκδοσης. Δηλαδή, αν χρειαστεί να αλλάξουμε τη δομή της βάσης δεδομένων, τότε δεν θα το κάνουμε χειροκίνητα αλλάζοντας τα ονόματα των στηλών και προσθέτοντας νέες μέσω κάποιων οπτικών εργαλείων διαχείρισης βάσεων δεδομένων. Για τέτοια πράγματα, δημιουργούμε ξεχωριστά scripts - migrations, τα οποία εκτελούνται παντού και σε όλα τα περιβάλλοντα με τον ίδιο τρόπο με ένα κοινό και κατανοητό αποτέλεσμα. Για όλες τις άλλες εργασίες, όπως η πλήρωση του έργου με δεδομένα, θα πρέπει να χρησιμοποιούνται παρόμοιες μεθοδολογίες.
Παράδειγμα υλοποίησης σε PHP, Laravel, Laradock, Docker-Compose
P.S Όλα τα παραδείγματα έγιναν σε MacOS. Τα περισσότερα από αυτά είναι κατάλληλα και για Linux. Χρήστες Windows, με συγχωρείτε, αλλά δεν έχω δουλέψει με τα Windows για πολύ καιρό.
Ας φανταστούμε μια κατάσταση όπου δεν έχουμε καμία έκδοση της PHP εγκατεστημένη στον υπολογιστή μας και τίποτα απολύτως.
Εγκαταστήστε τις πιο πρόσφατες εκδόσεις του docker και του docker-compose. (αυτό μπορεί να βρεθεί στο Διαδίκτυο)
docker -v &&
docker-compose -v
1. Βάλτε
git clone https://github.com/Laradock/laradock.git &&
ls
Σχετικά με το Laradock, θα πω ότι είναι ένα πολύ δροσερό πράγμα, που περιέχει πολλά δοχεία και βοηθητικά πράγματα. Αλλά δεν θα συνιστούσα να χρησιμοποιήσετε το Laradock ως τέτοιο χωρίς τροποποιήσεις στην παραγωγή λόγω του πλεονασμού του. Είναι καλύτερα να δημιουργήσετε τα δικά σας κοντέινερ με βάση παραδείγματα στο Laradock, αυτό θα είναι πολύ πιο βελτιστοποιημένο, γιατί κανείς δεν χρειάζεται ό,τι υπάρχει ταυτόχρονα.
2. Διαμορφώστε το Laradock για να τρέξει την εφαρμογή μας.
cd laradock &&
cp env-example .env
2.1. Ανοίξτε τον κατάλογο habr (τον γονικό φάκελο στον οποίο έχει κλωνοποιηθεί το laradock) σε κάποιο πρόγραμμα επεξεργασίας. (Στην περίπτωσή μου PHPStorm)
Σε αυτό το στάδιο δίνουμε μόνο ένα όνομα στο έργο.
2.2. Εκκινήστε την εικόνα του χώρου εργασίας. (Στην περίπτωσή σας, η δημιουργία των εικόνων θα χρειαστεί λίγο χρόνο)
Ο χώρος εργασίας είναι μια ειδικά προετοιμασμένη εικόνα για εργασία με το πλαίσιο για λογαριασμό του προγραμματιστή.
Μπαίνουμε μέσα στο δοχείο χρησιμοποιώντας
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Εγκατάσταση Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Μετά την εγκατάσταση, ελέγχουμε αν ο κατάλογος με το έργο έχει δημιουργηθεί και kill compose.
ls
exit
docker-compose down
2.5. Ας επιστρέψουμε στο PHPStorm και ας ορίσουμε τη σωστή διαδρομή για την εφαρμογή laravel στο αρχείο .env.
3. Προσθέστε όλο τον κώδικα στο Git.
Για να γίνει αυτό, θα δημιουργήσουμε ένα αποθετήριο στο Github (ή οπουδήποτε αλλού). Ας πάμε στον κατάλογο habr στο τερματικό και ας εκτελέσουμε τον παρακάτω κώδικα.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Ας ελέγξουμε αν όλα είναι εντάξει.
Για ευκολία, προτείνω να χρησιμοποιήσετε κάποια οπτική διεπαφή για το Git, στην περίπτωσή μου . (εδώ είναι ένας σύνδεσμος παραπομπής)
4. Ας ξεκινήσουμε!
Πριν ξεκινήσετε, βεβαιωθείτε ότι τίποτα δεν κρέμεται στις θύρες 80 και 443.
docker-compose up -d nginx php-fpm
Έτσι, το έργο μας αποτελείται από 3 ξεχωριστές υπηρεσίες:
- nginx - διακομιστής ιστού
- php-fpm - php για λήψη αιτημάτων από διακομιστή web
- χώρος εργασίας - php για προγραμματιστές
Αυτή τη στιγμή, έχουμε καταφέρει να δημιουργήσουμε μια εφαρμογή που πληροί 4 βαθμούς από τους 12, και συγκεκριμένα:
1. Βάση κωδικών — όλος ο κώδικας βρίσκεται σε ένα αποθετήριο (μικρή σημείωση: μπορεί να είναι σωστό να προσθέσετε docker μέσα στο έργο laravel, αλλά αυτό δεν είναι σημαντικό).
2. Εξαρτήσεις - Όλες οι εξαρτήσεις μας είναι ρητά γραμμένες στο application/composer.json και σε κάθε Dockerfile κάθε κοντέινερ.
3. Υπηρεσίες υποστήριξης — Κάθε μία από τις υπηρεσίες (php-fom, nignx, χώρος εργασίας) ζει τη δική της ζωή και συνδέεται από έξω και όταν εργάζεστε με τη μία υπηρεσία, η άλλη δεν θα επηρεαστεί.
4. Διαδικασίες — κάθε υπηρεσία είναι μία διαδικασία. Κάθε μία από τις υπηρεσίες δεν διατηρεί εσωτερική κατάσταση.
5. Λιμενικό δέσιμο
docker ps
Όπως μπορούμε να δούμε, κάθε υπηρεσία εκτελείται στη δική της θύρα και είναι προσβάσιμη σε όλες τις άλλες υπηρεσίες.
6. Παραλληλισμός
Το Docker μας επιτρέπει να δημιουργήσουμε πολλαπλές διεργασίες των ίδιων υπηρεσιών με αυτόματη εξισορρόπηση φορτίου μεταξύ τους.
Ας σταματήσουμε τα κοντέινερ και ας τα περάσουμε μέσα από τη σημαία --κλίμακα
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Όπως μπορούμε να δούμε, έχουν δημιουργηθεί αντίγραφα του κοντέινερ php-fpm. Δεν χρειάζεται να αλλάξουμε τίποτα κατά την εργασία με αυτό το κοντέινερ. Συνεχίζουμε επίσης να έχουμε πρόσβαση στη θύρα 9000 και το Docker ρυθμίζει το φορτίο μεταξύ των εμπορευματοκιβωτίων για εμάς.
7. Μιας χρήσης - κάθε δοχείο μπορεί να σκοτωθεί χωρίς να βλάψει το άλλο. Η διακοπή ή η επανεκκίνηση του κοντέινερ δεν θα επηρεάσει τη λειτουργία της εφαρμογής κατά τις επόμενες εκκινήσεις. Κάθε δοχείο μπορεί επίσης να ανυψωθεί ανά πάσα στιγμή.
8. Ισοτιμία ανάπτυξης/λειτουργίας εφαρμογών - όλα τα περιβάλλοντα μας είναι ίδια. Με την εκτέλεση του συστήματος σε έναν διακομιστή σε παραγωγή, δεν θα χρειαστεί να αλλάξετε τίποτα στις εντολές σας. Όλα θα βασίζονται στο Docker με τον ίδιο τρόπο.
9. Ξύλευση — όλα τα αρχεία καταγραφής σε αυτά τα κοντέινερ μεταφέρονται σε ροή και είναι ορατά στην κονσόλα Docker. (στην περίπτωση αυτή, στην πραγματικότητα, με άλλα σπιτικά δοχεία, αυτό μπορεί να μην συμβαίνει εάν δεν το φροντίζετε εσείς)
docker-compose logs -f
Αλλά υπάρχει μια αβεβαιότητα στο ότι οι προεπιλεγμένες τιμές στην PHP και στο Nginx γράφουν επίσης αρχεία καταγραφής σε ένα αρχείο. Για να πληρούνται οι 12 παράγοντες, είναι απαραίτητο αποσυνδέστε εγγραφή αρχείων καταγραφής σε ένα αρχείο στις διαμορφώσεις κάθε κοντέινερ χωριστά.
Το Docker παρέχει επίσης τη δυνατότητα αποστολής αρχείων καταγραφής όχι μόνο στο stdout, αλλά και σε πράγματα όπως το graylog, το οποίο ανέφερα παραπάνω. Και μέσα στο graylog, μπορούμε να λειτουργήσουμε τα αρχεία καταγραφής όπως θέλουμε και η εφαρμογή μας δεν θα το παρατηρήσει αυτό με κανέναν τρόπο.
10. Καθήκοντα διοίκησης — όλες οι εργασίες διαχείρισης επιλύονται από τη laravel χάρη στο εργαλείο artisan ακριβώς όπως θα ήθελαν οι δημιουργοί της εφαρμογής 12 παραγόντων.
Για παράδειγμα, θα δείξω πώς εκτελούνται ορισμένες εντολές.
Μπαίνουμε στο δοχείο.
docker-compose exec workspace bash
php artisan list
Τώρα μπορούμε να χρησιμοποιήσουμε οποιαδήποτε εντολή. (παρακαλούμε σημειώστε ότι δεν ρυθμίσαμε τη βάση δεδομένων και την κρυφή μνήμη, επομένως οι μισές εντολές δεν θα εκτελεστούν σωστά, επειδή έχουν σχεδιαστεί για να λειτουργούν με τη μνήμη cache και τη βάση δεδομένων).
11. Διαμορφώσεις και 12. Κατασκευάστε, απελευθερώστε, τρέξτε
Ήθελα να αφιερώσω αυτό το μέρος στο Blue-Green Deployment, αλλά αποδείχτηκε πολύ εκτενές για αυτό το άρθρο. Θα γράψω ένα ξεχωριστό άρθρο για αυτό.
Με λίγα λόγια, η ιδέα βασίζεται σε συστήματα CI/CD όπως Jenkins и Gitlab CI. Και στα δύο, μπορείτε να ορίσετε μεταβλητές περιβάλλοντος που σχετίζονται με ένα συγκεκριμένο περιβάλλον. Αντίστοιχα, σε αυτήν την περίπτωση, το σημείο γ θα πληρούται Διαμορφώσεις.
Και το θέμα για Κατασκευάστε, απελευθερώστε, τρέξτε επιλύεται με ενσωματωμένες συναρτήσεις με το όνομα Pipeline.
Pipeline σας επιτρέπει να διαιρέσετε τη διαδικασία ανάπτυξης σε πολλά στάδια, επισημαίνοντας τα στάδια συναρμολόγησης, απελευθέρωσης και εκτέλεσης. Επίσης στο Pipeline, μπορείτε να δημιουργήσετε αντίγραφα ασφαλείας, και μάλιστα οτιδήποτε. Αυτό είναι ένα εργαλείο με απεριόριστες δυνατότητες.
Ο κωδικός της αίτησης βρίσκεται στο .
Μην ξεχάσετε να αρχικοποιήσετε την υπομονάδα κατά την κλωνοποίηση αυτού του αποθετηρίου.
P.S.: Όλες αυτές οι προσεγγίσεις μπορούν να χρησιμοποιηθούν με οποιαδήποτε άλλα βοηθητικά προγράμματα και γλώσσες προγραμματισμού. Το κύριο πράγμα είναι ότι η ουσία δεν διαφέρει.
Πηγή: www.habr.com