Κάποια στιγμή αποφάσισα να γράψω ένα άρθρο για την παράδοση με τη μορφή κοντέινερ και 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. Μέχρι στιγμής, είναι μόνο στο αρχικό του στάδιο, με τη μορφή ιστότοπων. Κανείς δεν ονειρεύεται πραγματικά υπηρεσίες. αλλά ήταν ένα σημείο καμπής στον κλάδο τόσο της ανάπτυξης όσο και της πραγματικής παράδοσης εφαρμογών.
Για τον εαυτό μου, σημείωσα ότι εκείνη τη στιγμή υπήρξε μια αλλαγή γενεών προγραμματιστών (ή ήταν απλώς στον κύκλο μου) και ένιωσα ότι όλες οι παλιές καλές μέθοδοι παράδοσης ξεχάστηκαν σε μια στιγμή και όλα ξεκίνησαν από την αρχή: όλη η παράδοση άρχισε να γίνεται με σενάρια και το ονόμασαν περήφανα "Συνεχής παράδοση". Στην πραγματικότητα, έχει ξεκινήσει μια περίοδος χάους, όταν το παλιό ξεχνιέται και δεν χρησιμοποιείται, και απλά δεν υπάρχει νέο.
Θυμάμαι τις εποχές που στην εταιρεία όπου δούλευα τότε (δεν θα την ονομάσω), αντί να χτίζουν μέσω ant (το 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, συναντούσαμε συχνά το γεγονός ότι το δίκτυο δεν λειτουργούσε σωστά (κάτι που πιθανότατα οφειλόταν και στην ωμότητα του ίδιου του Docker) ή ήταν δύσκολο να επεκταθούν τα κοντέινερ άλλων ανθρώπων.
Τι ταλαιπωρίες συναντήσαμε;
- Προβλήματα δικτύου σε λειτουργία γέφυρας
- Δεν είναι βολικό να προβάλλετε αρχεία καταγραφής σε ένα κοντέινερ (αν δεν μετακινηθούν χωριστά στο σύστημα αρχείων του κεντρικού υπολογιστή)
- Περιοδικά περίεργο πάγωμα του ElasticSearch μέσα στο δοχείο, ο λόγος δεν διαπιστώθηκε, το δοχείο είναι επίσημο
- Δεν είναι βολικό να χρησιμοποιήσετε το κέλυφος μέσα στο δοχείο - όλα είναι πολύ περιορισμένα, δεν υπάρχουν συνηθισμένα εργαλεία
- Μεγάλο μέγεθος συλλεχθέντων δοχείων - ακριβό στην αποθήκευση
- Λόγω του μεγάλου μεγέθους των κοντέινερ, είναι δύσκολο να υποστηριχθούν πολλαπλές εκδόσεις.
- Μεγαλύτερος χρόνος κατασκευής από άλλες μεθόδους (σενάρια ή πακέτα deb)
Από την άλλη πλευρά, γιατί είναι χειρότερο να αναπτύξετε μια υπηρεσία Spring με τη μορφή αρχείου jar μέσω του ίδιου deb; Είναι πραγματικά απαραίτητη η απομόνωση πόρων; Αξίζει να χάσετε τα βολικά εργαλεία του λειτουργικού συστήματος στριμώχνοντας την υπηρεσία σε ένα πολύ μειωμένο κοντέινερ;
Όπως έχει δείξει η πρακτική, στην πραγματικότητα αυτό δεν είναι απαραίτητο. το πακέτο deb επαρκεί στο 90% των περιπτώσεων.
Πότε αποτυγχάνει το παλιό καλό deb και πότε χρειαζόμαστε πραγματικά docker;
Για εμάς ήταν η ανάπτυξη υπηρεσιών σε python. Πολλές βιβλιοθήκες που απαιτούνται για μηχανική εκμάθηση και δεν περιλαμβάνονται στην τυπική παράδοση του λειτουργικού συστήματος (και ό,τι υπήρχε δεν ήταν η σωστή έκδοση), hacks με ρυθμίσεις, η ανάγκη για διαφορετικές εκδόσεις για διαφορετικές υπηρεσίες που ζουν στο ίδιο σύστημα κεντρικού υπολογιστή οδήγησαν στο γεγονός ότι ο μόνος λογικός τρόπος παράδοσης αυτού του πυρηνικού μείγματος ήταν το Docker. Η ένταση εργασίας της συναρμολόγησης ενός κοντέινερ docker αποδείχθηκε χαμηλότερη από την ιδέα να συσκευαστούν όλα αυτά σε ξεχωριστά πακέτα deb με εξαρτήσεις, και στην πραγματικότητα, κανείς με το σωστό μυαλό του δεν θα το είχε αναλάβει.
Το δεύτερο σημείο όπου σχεδιάζεται να χρησιμοποιηθεί το docker είναι για την ανάπτυξη υπηρεσιών που χρησιμοποιούν το μπλε-πράσινο σχήμα ανάπτυξης. Αλλά εδώ θέλουμε να έχουμε μια σταδιακή αύξηση της πολυπλοκότητας: πρώτα, δημιουργούνται πακέτα deb και, στη συνέχεια, δημιουργείται ένα κοντέινερ docker από αυτά.
Πακέτα Snap
Ας επιστρέψουμε στα πακέτα snap. Εμφανίστηκαν επίσημα για πρώτη φορά το Ubuntu 16.04 Απριλίου. Σε αντίθεση με τα παραδοσιακά πακέτα DEB και RPM, τα snap περιλαμβάνουν όλες τις εξαρτήσεις. Ενώ αυτό αποφεύγει τις διενέξεις βιβλιοθηκών, σημαίνει επίσης ότι το πακέτο που προκύπτει είναι μεγαλύτερο. Επιπλέον, αυτό μπορεί να επηρεάσει την ασφάλεια του συστήματος: κατά την ανάπτυξη snap, ο προγραμματιστής που δημιουργεί το πακέτο πρέπει να διαχειρίζεται όλες τις αλλαγές στις βιβλιοθήκες που περιλαμβάνονται. Συνολικά, δεν είναι τόσο απλό και η χρήση τους δεν είναι πάντα μια κατάσταση win-win. Ωστόσο, είναι μια απολύτως λογική εναλλακτική λύση εάν, για παράδειγμα, το Docker χρησιμοποιείται αποκλειστικά ως εργαλείο συσκευασίας και όχι για εικονικοποίηση.
Ως αποτέλεσμα, χρησιμοποιούμε πλέον τόσο τα πακέτα deb όσο και τα κοντέινερ docker σε λογικό συνδυασμό, τα οποία μπορεί να αντικαταστήσουμε με πακέτα snap σε ορισμένες περιπτώσεις.
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Τι χρησιμοποιείτε για την παράδοση;
Αυτογραφικά σενάρια
Αντιγραφή χειροκίνητα στο FTP
πακέτα deb
πακέτα στροφών ανά λεπτό
πακέτα snap
Εικόνες Docker
Εικόνες εικονικής μηχανής
Κλωνοποιήστε ολόκληρο τον σκληρό δίσκο
μαριονέτα
αδύνατο
Άλλος
Ψήφισαν 109 χρήστες. 32 χρήστες απείχαν.
Πηγή: www.habr.com
