Κάποια στιγμή αποφάσισα να γράψω ένα άρθρο για την παράδοση με τη μορφή δοχείων Docker και πακέτων deb, αλλά όταν ξεκίνησα, για κάποιο λόγο μεταφέρθηκα πίσω στις μακρινές εποχές των πρώτων προσωπικών υπολογιστών και ακόμη και αριθμομηχανών. Γενικά, αντί για ξερές συγκρίσεις docker και deb, πήραμε αυτές τις σκέψεις σχετικά με το θέμα της εξέλιξης, τις οποίες παρουσιάζω προς εξέταση.
Οποιοδήποτε προϊόν, ανεξάρτητα από το τι είναι, πρέπει με κάποιο τρόπο να φτάσει στους διακομιστές προϊόντων, πρέπει να ρυθμιστεί και να ξεκινήσει. Αυτό θα είναι αυτό το άρθρο.
Θα σκεφτώ σε ένα ιστορικό πλαίσιο, «αυτό που βλέπω είναι αυτό για το οποίο τραγουδάω», τι είδα όταν άρχισα να γράφω κώδικα και τι παρατηρώ τώρα, τι χρησιμοποιούμε εμείς οι ίδιοι αυτή τη στιγμή και γιατί. Το άρθρο δεν προσποιείται ότι είναι μια ολοκληρωμένη μελέτη, κάποια σημεία χάνονται, αυτή είναι η προσωπική μου άποψη για το τι ήταν και τι είναι τώρα.
Έτσι, στις παλιές καλές εποχές... η πιο πρώιμη μέθοδος παράδοσης που βρήκα ήταν κασέτες από μαγνητόφωνα. Είχα έναν υπολογιστή BK-0010.01...
Η εποχή των αριθμομηχανών
Όχι, υπήρχε μια ακόμα πιο παλιά στιγμή, υπήρχε και αριθμομηχανή и .
Όταν λοιπόν είχα , τότε ο τρόπος μεταφοράς του προγράμματος ήταν ένα συνηθισμένο κομμάτι χαρτί σε ένα κουτί στο οποίο ήταν γραμμένο ένα πρόγραμμα, το οποίο, αν χρειαζόταν, για να το εκτελέσετε χειροκίνητα, το έγραφε στην αριθμομηχανή. Εάν θέλετε να παίξετε (ναι, ακόμη και αυτή η αριθμομηχανή πριν από τη διάλυση είχε παιχνίδια) - κάθεστε και εισάγετε το πρόγραμμα στην αριθμομηχανή. Όπως ήταν φυσικό, όταν η αριθμομηχανή απενεργοποιήθηκε, το πρόγραμμα εξαφανίστηκε στη λήθη. Εκτός από τους κωδικούς της αριθμομηχανής που γράφτηκαν σε χαρτί στο χέρι του, τα προγράμματα δημοσιεύτηκαν στα περιοδικά «Ράδιο» και «Τεχνολογία για τη Νεολαία» και δημοσιεύτηκαν επίσης σε βιβλία εκείνης της εποχής.
Η επόμενη τροποποίηση ήταν μια αριθμομηχανή , έχει ήδη κάποια εμφάνιση μη ασταθούς αποθήκευσης δεδομένων. Τώρα το παιχνίδι ή το πρόγραμμα δεν χρειαζόταν να εισαχθεί χειροκίνητα, αλλά αφού έκανε μερικά μαγικά περάσματα με τα κουμπιά, φορτώθηκε μόνο του.
Το μέγεθος του μεγαλύτερου προγράμματος στην αριθμομηχανή ήταν 105 βήματα και το μέγεθος της μόνιμης μνήμης στο MK-52 ήταν 512 βήματα.
Παρεμπιπτόντως, αν υπάρχουν θαυμαστές αυτών των αριθμομηχανών που διαβάζουν αυτό το άρθρο, κατά τη διαδικασία σύνταξης του άρθρου βρήκα τόσο έναν εξομοιωτή αριθμομηχανής για Android όσο και προγράμματα για αυτόν. Εμπρός στο παρελθόν!
Μια σύντομη παρέκβαση για το MK-52 (από τη Wikipedia)
Το MK-52 πέταξε στο διάστημα με το διαστημόπλοιο Soyuz TM-7. Υποτίθεται ότι θα χρησιμοποιηθεί για τον υπολογισμό της τροχιάς προσγείωσης σε περίπτωση που αποτύχει ο ενσωματωμένος υπολογιστής.
Από το 52, το MK-1988 με τη μονάδα επέκτασης μνήμης Elektronika-Astro παρέχεται σε πλοία του Πολεμικού Ναυτικού ως μέρος ενός κιτ υπολογιστών πλοήγησης.
Οι πρώτοι προσωπικοί υπολογιστές
Ας επιστρέψουμε στους καιρούς . Είναι σαφές ότι υπήρχε περισσότερη μνήμη εκεί και η πληκτρολόγηση του κώδικα από ένα κομμάτι χαρτί δεν ήταν πλέον επιλογή (αν και στην αρχή έκανα ακριβώς αυτό, γιατί απλά δεν υπήρχε άλλο μέσο). Οι κασέτες ήχου για μαγνητόφωνα γίνονται το κύριο μέσο αποθήκευσης και παράδοσης λογισμικού.
Η αποθήκευση σε μια κασέτα ήταν συνήθως με τη μορφή ενός ή δύο δυαδικών αρχείων, όλα τα άλλα περιέχονταν μέσα. Η αξιοπιστία ήταν πολύ χαμηλή, έπρεπε να κρατήσω 2-3 αντίγραφα του προγράμματος. Οι χρόνοι φόρτωσης ήταν επίσης απογοητευτικοί και οι λάτρεις πειραματίστηκαν με διαφορετικές κωδικοποιήσεις συχνοτήτων για να ξεπεράσουν αυτές τις ελλείψεις. Εκείνη την εποχή, εγώ ο ίδιος δεν είχα ακόμη ασχοληθεί με την ανάπτυξη επαγγελματικού λογισμικού (χωρίς να υπολογίζουμε τα απλά προγράμματα στο BASIC), οπότε, δυστυχώς, δεν θα σας πω λεπτομερώς πώς ήταν τακτοποιημένα όλα μέσα. Το ίδιο το γεγονός ότι ο υπολογιστής είχε μόνο RAM ως επί το πλείστον καθόρισε την απλότητα του συστήματος αποθήκευσης δεδομένων.
Η εμφάνιση αξιόπιστων και μεγάλων μέσων αποθήκευσης
Αργότερα, εμφανίστηκαν δισκέτες, η διαδικασία αντιγραφής απλοποιήθηκε και η αξιοπιστία αυξήθηκε.
Αλλά η κατάσταση αλλάζει δραματικά μόνο όταν εμφανίζονται αρκετά μεγάλοι τοπικοί χώροι αποθήκευσης με τη μορφή σκληρών δίσκων.
Ο τύπος παράδοσης αλλάζει ριζικά: εμφανίζονται προγράμματα εγκατάστασης που διαχειρίζονται τη διαδικασία διαμόρφωσης του συστήματος, καθώς και τον καθαρισμό μετά την αφαίρεση, καθώς τα προγράμματα δεν διαβάζονται απλώς στη μνήμη, αλλά αντιγράφονται ήδη στην τοπική αποθήκευση, από την οποία πρέπει να να είναι σε θέση να καθαρίσει περιττά πράγματα εάν είναι απαραίτητο.
Ταυτόχρονα, η πολυπλοκότητα του παρεχόμενου λογισμικού αυξάνεται.
Ο αριθμός των αρχείων στην παράδοση αυξάνεται από μερικά σε εκατοντάδες και χιλιάδες, οι συγκρούσεις μεταξύ των εκδόσεων της βιβλιοθήκης και άλλες χαρές ξεκινούν όταν διαφορετικά προγράμματα χρησιμοποιούν τα ίδια δεδομένα.
Εκείνη την εποχή, η ύπαρξη του Linux δεν ήταν ακόμη ανοιχτή για μένα· ζούσα στον κόσμο του MS DOS και, αργότερα, των Windows, και έγραφα στο Borland Pascal και στους Delphi, μερικές φορές κοιτάζοντας προς τη C++. Πολλοί άνθρωποι χρησιμοποιούσαν το InstallShield για την παράδοση προϊόντων τότε. , το οποίο έλυσε με μεγάλη επιτυχία όλες τις ανατεθείσες εργασίες ανάπτυξης και διαμόρφωσης του λογισμικού.
Εποχή του Διαδικτύου
Σταδιακά, η πολυπλοκότητα των συστημάτων λογισμικού γίνεται ακόμη πιο περίπλοκη· από τις μονολιθικές και επιτραπέζιες εφαρμογές γίνεται μετάβαση σε κατανεμημένα συστήματα, thin clients και microservices. Τώρα πρέπει να διαμορφώσετε όχι μόνο ένα πρόγραμμα, αλλά ένα σύνολο από αυτά, και έτσι ώστε να λειτουργούν όλα μαζί.
Η έννοια άλλαξε εντελώς, ήρθε το Διαδίκτυο, έφτασε η εποχή των υπηρεσιών cloud. Μέχρι στιγμής, μόνο στο αρχικό στάδιο, με τη μορφή ιστοσελίδων, κανείς δεν έχει ονειρευτεί ιδιαίτερα υπηρεσίες. αλλά ήταν ένα σημείο καμπής τόσο στην ανάπτυξη όσο και στην παράδοση των εφαρμογών.
Για τον εαυτό μου, σημείωσα ότι εκείνη τη στιγμή υπήρξε μια αλλαγή σε γενιές προγραμματιστών (ή ήταν μόνο στο περιβάλλον μου) και υπήρχε η αίσθηση ότι όλες οι παλιές καλές μέθοδοι παράδοσης ξεχάστηκαν σε μια στιγμή και όλα ξεκίνησαν από την αρχή αρχή: όλες οι παραδόσεις άρχισαν να γίνονται σενάρια γονάτων και το ονόμασαν περήφανα «Συνεχής παράδοση». Στην πραγματικότητα, έχει ξεκινήσει μια περίοδος χάους, που το παλιό ξεχνιέται και δεν χρησιμοποιείται, και το νέο απλά δεν υπάρχει.
Θυμάμαι τις εποχές που στην εταιρεία μας όπου δούλευα τότε (δεν θα το ονομάσω), αντί να χτίζουν μέσω μυρμήγκι (το maven δεν ήταν ακόμα δημοφιλές ή δεν υπήρχε καθόλου), οι άνθρωποι απλώς μάζευαν βάζα στο IDE και δεσμεύονταν γαλήνια είναι στο SVN. Κατά συνέπεια, η ανάπτυξη συνίστατο στην ανάκτηση του αρχείου από το SVN και στην αντιγραφή του μέσω SSH στο επιθυμητό μηχάνημα. Είναι τόσο απλό και αδέξιο.
Παράλληλα, η παράδοση απλών τοποθεσιών σε PHP έγινε με πολύ πρωτόγονο τρόπο με απλή αντιγραφή του διορθωμένου αρχείου μέσω FTP στο μηχάνημα-στόχο. Μερικές φορές δεν υπήρχε κάτι τέτοιο - ο κώδικας επεξεργαζόταν ζωντανά στον διακομιστή του προϊόντος και ήταν ιδιαίτερα κομψό αν υπήρχαν κάπου αντίγραφα ασφαλείας.
Πακέτα RPM και DEB
Από την άλλη πλευρά, με την ανάπτυξη του Διαδικτύου, τα συστήματα που μοιάζουν με UNIX άρχισαν να αποκτούν ολοένα και μεγαλύτερη δημοτικότητα, συγκεκριμένα, ήταν εκείνη την εποχή που ανακάλυψα το RedHat Linux 6, περίπου το 2000. Φυσικά, υπήρχαν επίσης ορισμένα μέσα για την παράδοση λογισμικού· σύμφωνα με τη Wikipedia, το RPM ως ο κύριος διαχειριστής πακέτων εμφανίστηκε ήδη το 1995, στην έκδοση του RedHat Linux 2.0. Και από τότε και μέχρι σήμερα, το σύστημα παραδίδεται με τη μορφή πακέτων RPM και υπάρχει και αναπτύσσεται με μεγάλη επιτυχία.
Οι διανομές της οικογένειας Debian ακολούθησαν παρόμοια πορεία και υλοποίησαν την παράδοση με τη μορφή πακέτων deb, η οποία έχει παραμείνει αμετάβλητη μέχρι σήμερα.
Οι διαχειριστές πακέτων σάς επιτρέπουν να παραδίδετε οι ίδιοι τα προϊόντα λογισμικού, να τα διαμορφώνετε κατά τη διαδικασία εγκατάστασης, να διαχειρίζεστε εξαρτήσεις μεταξύ διαφορετικών πακέτων, να αφαιρείτε προϊόντα και να καθαρίζετε τα περιττά στοιχεία κατά τη διαδικασία απεγκατάστασης. Εκείνοι. ως επί το πλείστον, αυτό είναι το μόνο που χρειάζεται, γι' αυτό και κράτησαν αρκετές δεκαετίες ουσιαστικά αμετάβλητες.
Το cloud computing έχει προσθέσει εγκατάσταση στους διαχειριστές πακέτων όχι μόνο από φυσικά μέσα, αλλά και από αποθετήρια cloud, αλλά ουσιαστικά λίγα έχουν αλλάξει.
Αξίζει να σημειωθεί ότι επί του παρόντος γίνονται κάποιες κινήσεις προς την απομάκρυνση από το deb και τη μετάβαση σε πακέτα snap, αλλά περισσότερα για αυτό αργότερα.
Έτσι, αυτή η νέα γενιά προγραμματιστών cloud, που δεν ήξεραν ούτε DEB ούτε RPM, επίσης μεγάλωσε σιγά σιγά, απέκτησε εμπειρία, τα προϊόντα έγιναν πιο περίπλοκα και χρειάστηκαν κάποιες πιο λογικές μέθοδοι παράδοσης από το FTP, τα σενάρια bash και παρόμοιες χειροτεχνίες μαθητών.
Και εδώ είναι που εμφανίζεται το Docker, ένα είδος μείγματος εικονικοποίησης, οριοθέτησης πόρων και μεθόδου παράδοσης. Είναι μοντέρνο και νεανικό τώρα, αλλά χρειάζεται για όλα; Είναι αυτό πανάκεια;
Από τις παρατηρήσεις μου, πολύ συχνά το Docker προτείνεται όχι ως λογική επιλογή, αλλά απλώς επειδή, αφενός, γίνεται λόγος στην κοινότητα και όσοι το προτείνουν μόνο το γνωρίζουν. Από την άλλη, ως επί το πλείστον σιωπούν για τα παλιά καλά συστήματα συσκευασίας - υπάρχουν και κάνουν τη δουλειά τους αθόρυβα και απαρατήρητα. Σε μια τέτοια κατάσταση, δεν υπάρχει πραγματικά άλλη επιλογή - η επιλογή είναι προφανής - Docker.
Θα προσπαθήσω να μοιραστώ την εμπειρία μου για το πώς εφαρμόσαμε το Docker και τι συνέβη ως αποτέλεσμα.
Αυτογραφικά σενάρια
Αρχικά, υπήρχαν σενάρια bash που ανέπτυξαν αρχεία jar στα απαιτούμενα μηχανήματα. Αυτή τη διαδικασία διαχειρίστηκε ο Jenkins. Αυτό λειτούργησε με επιτυχία, καθώς το ίδιο το αρχείο jar είναι ήδη ένα συγκρότημα που περιέχει κλάσεις, πόρους και ακόμη και ρυθμίσεις. Εάν βάλετε τα πάντα σε αυτό στο μέγιστο, τότε η επέκταση του σε ένα σενάριο δεν είναι το πιο δύσκολο πράγμα που χρειάζεστε
Αλλά τα σενάρια έχουν πολλά μειονεκτήματα:
- Τα σενάρια συνήθως γράφονται βιαστικά και επομένως είναι τόσο πρωτόγονα που περιέχουν μόνο ένα σενάριο της καλύτερης περίπτωσης. Αυτό διευκολύνεται από το γεγονός ότι ο προγραμματιστής ενδιαφέρεται για γρήγορη παράδοση και ένα κανονικό σενάριο απαιτεί την επένδυση ενός αξιοπρεπούς όγκου πόρων
- Ως συνέπεια του προηγούμενου σημείου, τα σενάρια δεν περιέχουν διαδικασίες απεγκατάστασης
- καμία καθιερωμένη διαδικασία αναβάθμισης
- Όταν εμφανίζεται ένα νέο προϊόν, πρέπει να γράψετε ένα νέο σενάριο
- καμία υποστήριξη εξάρτησης
Φυσικά, μπορείτε να γράψετε ένα εκλεπτυσμένο σενάριο, αλλά, όπως έγραψα παραπάνω, αυτός είναι ο χρόνος ανάπτυξης, και, όπως ξέρουμε, πάντα δεν υπάρχει αρκετός χρόνος.
Όλα αυτά προφανώς περιορίζουν το εύρος εφαρμογής αυτής της μεθόδου ανάπτυξης μόνο στα πιο απλά συστήματα. Ήρθε η ώρα να αλλάξει αυτό.
Λιμενεργάτης
Κάποια στιγμή, άρχισαν να μας έρχονται φρεσκοκομμένες μεσαίες, που έβραζαν από ιδέες και τρελάθηκαν για τον λιμενεργό. Λοιπόν, σημαία στο χέρι - ας το κάνουμε! Έγιναν δύο προσπάθειες. Και οι δύο ήταν ανεπιτυχείς - ας πούμε, λόγω μεγάλων φιλοδοξιών, αλλά έλλειψης πραγματικής εμπειρίας. Ήταν απαραίτητο να το αναγκάσουμε και να το τελειώσουμε με κάθε απαραίτητο μέσο; Είναι απίθανο - η ομάδα πρέπει να εξελιχθεί στο απαιτούμενο επίπεδο προτού μπορέσει να χρησιμοποιήσει τα κατάλληλα εργαλεία. Επιπλέον, όταν χρησιμοποιούσαμε έτοιμες εικόνες Docker, συναντούσαμε συχνά το γεγονός ότι το δίκτυο δεν λειτουργούσε σωστά (που μπορεί να οφειλόταν στην υγρασία του ίδιου του Docker) ή ήταν δύσκολο να επεκταθούν τα κοντέινερ άλλων ανθρώπων.
Τι ταλαιπωρίες συναντήσαμε;
- Προβλήματα δικτύου σε λειτουργία γέφυρας
- Δεν είναι βολικό να προβάλλετε αρχεία καταγραφής σε ένα κοντέινερ (εάν δεν αποθηκεύονται χωριστά στο σύστημα αρχείων του κεντρικού υπολογιστή)
- Το ElasticSearch κατά καιρούς παγώνει παράξενα μέσα στο δοχείο, ο λόγος δεν έχει προσδιοριστεί, το δοχείο είναι επίσημο
- Είναι απαραίτητο να χρησιμοποιήσετε ένα κέλυφος μέσα σε ένα δοχείο - όλα είναι πολύ απογυμνωμένα, δεν υπάρχουν γνωστά εργαλεία
- Μεγάλο μέγεθος συλλεχθέντων δοχείων - ακριβό στην αποθήκευση
- Λόγω του μεγάλου μεγέθους των κοντέινερ, είναι δύσκολο να υποστηριχθούν πολλαπλές εκδόσεις
- Μεγαλύτερος χρόνος κατασκευής, σε αντίθεση με άλλες μεθόδους (σενάρια ή πακέτα deb)
Από την άλλη πλευρά, γιατί είναι χειρότερο να αναπτύξετε μια υπηρεσία Spring με τη μορφή αρχείου jar μέσω του ίδιου deb; Είναι πραγματικά απαραίτητη η απομόνωση πόρων; Αξίζει να χάσετε τα βολικά εργαλεία του λειτουργικού συστήματος βάζοντας μια υπηρεσία σε ένα πολύ μειωμένο δοχείο;
Όπως έχει δείξει η πρακτική, στην πραγματικότητα αυτό δεν είναι απαραίτητο, το πακέτο deb είναι αρκετό στο 90% των περιπτώσεων.
Πότε αποτυγχάνει το παλιό καλό deb και πότε χρειαζόμαστε πραγματικά docker;
Για εμάς, αυτό ήταν η ανάπτυξη υπηρεσιών σε python. Πολλές βιβλιοθήκες που απαιτούνται για μηχανική εκμάθηση και δεν περιλαμβάνονται στην τυπική διανομή του λειτουργικού συστήματος (και τι υπήρχε ήταν οι λάθος εκδόσεις), hacks με ρυθμίσεις, η ανάγκη για διαφορετικές εκδόσεις για διαφορετικές υπηρεσίες που ζουν στο ίδιο σύστημα υποδοχής οδήγησαν σε αυτό, ότι ο μόνος λογικός τρόπος για να παραδοθεί αυτό το πυρηνικό μείγμα ήταν ο λιμένας. Η ένταση εργασίας της συναρμολόγησης ενός κοντέινερ docker αποδείχθηκε χαμηλότερη από την ιδέα να τα συσκευάσουμε όλα σε ξεχωριστά πακέτα deb με εξαρτήσεις, και στην πραγματικότητα κανείς με το σωστό μυαλό του δεν θα το αναλάμβανε.
Το δεύτερο σημείο όπου σχεδιάζεται να χρησιμοποιηθεί το Docker είναι η ανάπτυξη υπηρεσιών σύμφωνα με το μπλε-πράσινο σχέδιο ανάπτυξης. Αλλά εδώ θέλω να αποκτήσω μια σταδιακή αύξηση της πολυπλοκότητας: πρώτα, δημιουργούνται πακέτα deb και, στη συνέχεια, δημιουργείται ένα δοχείο docker από αυτά.
Πακέτα Snap
Ας επιστρέψουμε στα πακέτα snap. Εμφανίστηκαν επίσημα για πρώτη φορά στο Ubuntu 16.04. Σε αντίθεση με τα συνηθισμένα πακέτα deb και πακέτα rpm, το snap φέρει όλες τις εξαρτήσεις. Από τη μία πλευρά, αυτό σας επιτρέπει να αποφύγετε τις συγκρούσεις βιβλιοθήκης, από την άλλη πλευρά, το πακέτο που προκύπτει είναι μεγαλύτερο σε μέγεθος. Επιπλέον, αυτό μπορεί επίσης να επηρεάσει την ασφάλεια του συστήματος: στην περίπτωση της άμεσης παράδοσης, όλες οι αλλαγές στις συμπεριλαμβανόμενες βιβλιοθήκες πρέπει να παρακολουθούνται από τον προγραμματιστή που δημιουργεί το πακέτο. Γενικά, δεν είναι όλα τόσο απλά και η καθολική ευτυχία δεν προέρχεται από τη χρήση τους. Ωστόσο, αυτή είναι μια απολύτως λογική εναλλακτική εάν το ίδιο Docker χρησιμοποιείται μόνο ως εργαλείο συσκευασίας και όχι για εικονικοποίηση.
Ως αποτέλεσμα, χρησιμοποιούμε πλέον τόσο πακέτα deb όσο και κοντέινερ docker σε λογικό συνδυασμό, τα οποία, ίσως, σε ορισμένες περιπτώσεις θα αντικαταστήσουμε με πακέτα snap.
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Τι χρησιμοποιείτε για την παράδοση;
-
Αυτογραφικά σενάρια
-
Αντιγραφή χειροκίνητα στο FTP
-
πακέτα deb
-
πακέτα στροφών ανά λεπτό
-
πακέτα snap
-
Docker-εικόνες
-
Εικόνες εικονικής μηχανής
-
Κλωνοποιήστε ολόκληρο τον σκληρό δίσκο
-
μαριονέτα
-
αδύνατο
-
Άλλος
Ψήφισαν 109 χρήστες. 32 χρήστες απείχαν.
Πηγή: www.habr.com