🥇Το Docker είναι παιχνίδι ή όχι; Ή είναι ακόμα αλήθεια;

Γεια σε όλους!

Θέλω πραγματικά να μπω κατευθείαν στο θέμα, αλλά θα ήταν πιο σωστό να πω λίγα λόγια για την ιστορία μου:

Είσοδος

Είμαι προγραμματιστής με εμπειρία στην ανάπτυξη εφαρμογών μιας σελίδας frontend, scala/java και nodejs στον διακομιστή.

Για αρκετό καιρό (σίγουρα δύο ή τρία χρόνια), ήμουν της άποψης ότι το Docker είναι μάννα εξ ουρανού και γενικά ένα πολύ ωραίο εργαλείο και απολύτως κάθε προγραμματιστής θα έπρεπε να μπορεί να το χρησιμοποιήσει. Και από αυτό προκύπτει ότι κάθε προγραμματιστής θα πρέπει να έχει εγκατεστημένο το Docker στον τοπικό του υπολογιστή. Τι γίνεται με τη γνώμη μου, κοιτάξτε τις κενές θέσεις που έχουν αναρτηθεί στο ίδιο ω. Κάθε δευτερόλεπτο περιέχει μια αναφορά για το docker και αν το κατέχετε, αυτό θα είναι το ανταγωνιστικό σας πλεονέκτημα 😉

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

Λόγοι χρήσης

Γιατί χρησιμοποίησα το docker; Πιθανώς για τους εξής λόγους:

εκκίνηση της βάσης δεδομένων, το 99% των εφαρμογών τις χρησιμοποιεί
εκκίνηση του nginx για διανομή frontend και proxy στο backend
μπορείτε να συσκευάσετε την εφαρμογή σε μια εικόνα docker, με αυτόν τον τρόπο η εφαρμογή μου θα λειτουργεί όπου υπάρχει docker, το πρόβλημα διανομής λύνεται αμέσως
ανακάλυψη υπηρεσίας από το κουτί, μπορείτε να δημιουργήσετε μικροϋπηρεσίες, κάθε κοντέινερ (συνδεδεμένο σε κοινό δίκτυο) μπορεί εύκολα να φτάσει σε άλλο μέσω ενός ψευδωνύμου, πολύ βολικό
Είναι διασκεδαστικό να δημιουργείς ένα δοχείο και να "παίζεις" σε αυτό.

Αυτό που πάντα ΔΕΝ μου αρέσει στο docker:

Για να λειτουργήσει η εφαρμογή μου, χρειάζομαι το ίδιο το Docker στον διακομιστή. Γιατί το χρειάζομαι αυτό εάν οι εφαρμογές μου εκτελούνται σε jre ή nodejs και το περιβάλλον για αυτές είναι ήδη στον διακομιστή;
αν θέλω να εκτελέσω την (ιδιωτική) τοπικά χτισμένη εικόνα μου σε έναν απομακρυσμένο διακομιστή, τότε χρειάζομαι το δικό μου αποθετήριο docker, χρειάζομαι το μητρώο για να λειτουργήσει κάπου και πρέπει επίσης να ρυθμίσω το https, επειδή το docker cli λειτουργεί μόνο μέσω https. Ωχ διάολε... υπάρχουν επιλογές, φυσικά, να αποθηκεύσετε την εικόνα τοπικά μέσω docker save και απλώς στείλτε την εικόνα μέσω scp... Αλλά αυτό είναι πολλές κινήσεις του σώματος. Και επιπλέον, μοιάζει με «δεκανίκι» μέχρι να εμφανιστεί το δικό σας αποθετήριο
docker-compose. Χρειάζεται μόνο για τη λειτουργία δοχείων. Αυτό είναι όλο. Δεν μπορεί να κάνει κάτι άλλο. Docker-compose έχει ένα σωρό εκδόσεις των αρχείων του, τη δική του σύνταξη. Όσο δηλωτικό κι αν είναι, δεν θέλω να διαβάσω την τεκμηρίωσή τους. Δεν θα το χρειαστώ πουθενά αλλού.
όταν εργάζονται σε μια ομάδα, οι περισσότεροι άνθρωποι γράφουν ένα Dockerfile πολύ στραβά, δεν καταλαβαίνουν πώς αποθηκεύεται στην κρυφή μνήμη, προσθέτουν όλα όσα χρειάζονται και δεν χρειάζονται στην εικόνα, κληρονομούν από εικόνες που δεν βρίσκονται στο Dockerhub ή σε ιδιωτικό αποθετήριο, δημιουργούν κάποιες docker-compose αρχεία με βάσεις δεδομένων και τίποτα δεν επιμένει. Ταυτόχρονα, οι προγραμματιστές δηλώνουν με περηφάνια ότι ο Docker είναι κουλ, όλα λειτουργούν τοπικά γι 'αυτούς και το HR γράφει σημαντικά στην κενή θέση: "Χρησιμοποιούμε το Docker και χρειαζόμαστε έναν υποψήφιο με τέτοια εργασιακή εμπειρία."
Με στοιχειώνουν διαρκώς οι σκέψεις για το ανέβασμα των πάντων στο Docker: postgresql, kafka, redis. Είναι κρίμα που δεν λειτουργούν όλα σε κοντέινερ, δεν είναι όλα εύκολο να ρυθμιστούν και να εκτελεστούν. Αυτό υποστηρίζεται από τρίτους προγραμματιστές και όχι από τους ίδιους τους προμηθευτές. Και παρεμπιπτόντως, τίθεται αμέσως το ερώτημα: οι πωλητές δεν ανησυχούν για τη διατήρηση των προϊόντων τους στο Docker, γιατί συμβαίνει αυτό, ίσως γνωρίζουν κάτι;
Πάντα προκύπτει το ερώτημα σχετικά με τη διατήρηση των δεδομένων κοντέινερ. και μετά σκέφτεστε, πρέπει απλώς να προσαρτήσω τον κατάλογο κεντρικού υπολογιστή ή να δημιουργήσω έναν τόμο docker ή να δημιουργήσω ένα κοντέινερ δεδομένων που είναι τώρα deprecated? Εάν προσαρτήσω έναν κατάλογο, τότε πρέπει να βεβαιωθώ ότι το uid και το gid του χρήστη στο κοντέινερ ταιριάζουν με το αναγνωριστικό του χρήστη που ξεκίνησε το κοντέινερ, διαφορετικά τα αρχεία που δημιουργούνται από το κοντέινερ θα δημιουργηθούν με δικαιώματα ρίζας. Αν χρησιμοποιήσω volume τότε τα δεδομένα θα δημιουργηθούν απλώς σε κάποια /usr/* και θα υπάρχει η ίδια ιστορία με το uid και το gid όπως στην πρώτη περίπτωση. Εάν εκκινείτε ένα στοιχείο τρίτου κατασκευαστή, πρέπει να διαβάσετε την τεκμηρίωση και να αναζητήσετε την απάντηση στην ερώτηση: "σε ποιους καταλόγους κοντέινερ εγγράφει αρχεία το στοιχείο;"

Πάντα δεν μου άρεσε το γεγονός ότι έπρεπε να ασχολούμαι με τον Docker για πολύ καιρό στο αρχικό στάδιο: Ανακάλυψα πώς να εκκινήσω κοντέινερ, από ποιες εικόνες να εκκινήσω, έφτιαξα MakeFiles που περιείχαν ψευδώνυμα σε μεγάλες εντολές Docker. Μισούσα το docker-compose γιατί δεν ήθελα να μάθω άλλο εργαλείο στο οικοσύστημα του docker. ΚΑΙ docker-compose up Με ενοχλούσε, ειδικά αν συναντιόντουσαν ακόμα εκεί build κατασκευές, αντί για ήδη συναρμολογημένες εικόνες. Το μόνο που ήθελα πραγματικά ήταν να φτιάξω ένα προϊόν αποτελεσματικά και γρήγορα. Αλλά δεν μπορούσα να καταλάβω πώς να χρησιμοποιήσω το docker.

Παρουσιάζοντας το Ansible

Πρόσφατα (πριν από τρεις μήνες), δούλεψα με μια ομάδα DevOps, σχεδόν κάθε μέλος της οποίας είχε αρνητική στάση απέναντι στο Docker. Για λόγους:

docker κανόνες iptables (αν και μπορείτε να το απενεργοποιήσετε στο daemon.json)
Το docker είναι buggy και δεν θα το τρέξουμε στην παραγωγή
Εάν ο δαίμονας του docker συντριβεί, τότε όλα τα κοντέινερ με υποδομή συντρίβονται ανάλογα
δεν χρειαζεται docker
γιατί docker αν υπάρχει Ansible και εικονικές μηχανές

Στην ίδια δουλειά, γνώρισα ένα άλλο εργαλείο - το Ansible. Το άκουσα μια φορά, αλλά δεν προσπάθησα να γράψω τα δικά μου βιβλία. Και τώρα άρχισα να γράφω τις εργασίες μου και μετά άλλαξε τελείως το όραμά μου! Επειδή συνειδητοποίησα: Το Ansible έχει λειτουργικές μονάδες για την εκτέλεση των ίδιων κοντέινερ docker, εκδόσεων εικόνων, δικτύων κ.λπ., και τα κοντέινερ μπορούν να εκτελεστούν όχι μόνο τοπικά, αλλά και σε απομακρυσμένους διακομιστές! Η χαρά μου δεν είχε όρια - βρήκα ένα ΚΑΝΟΝΙΚΟ εργαλείο και πέταξα τα αρχεία Makefile και docker-compose, αντικαταστάθηκαν με εργασίες yaml. Ο κώδικας μειώθηκε χρησιμοποιώντας δομές όπως loop, whenΚ.λπ.

Docker για την εκτέλεση στοιχείων τρίτων, όπως βάσεις δεδομένων

Πρόσφατα γνώρισα τα ssh tunnels. Αποδείχθηκε ότι είναι πολύ εύκολο να "προωθήσετε" τη θύρα ενός απομακρυσμένου διακομιστή σε μια τοπική θύρα. Ο απομακρυσμένος διακομιστής μπορεί να είναι είτε μια μηχανή στο cloud είτε μια εικονική μηχανή που τρέχει στο VirtualBox. Εάν ο συνάδελφός μου ή εγώ χρειαζόμαστε μια βάση δεδομένων (ή κάποιο άλλο στοιχείο τρίτου κατασκευαστή), μπορούμε απλώς να ξεκινήσουμε τον διακομιστή με αυτό το στοιχείο και να τον απενεργοποιήσουμε όταν δεν χρειάζεται ο διακομιστής. Η προώθηση θύρας δίνει το ίδιο αποτέλεσμα με μια βάση δεδομένων που εκτελείται σε ένα κοντέινερ docker.

Αυτή η εντολή προωθεί την τοπική μου θύρα σε έναν απομακρυσμένο διακομιστή που εκτελεί το postgresql:

ssh -L 9000:localhost:5432 [προστασία μέσω email]

Η χρήση απομακρυσμένου διακομιστή λύνει το πρόβλημα με την ανάπτυξη ομάδας. Ένας τέτοιος διακομιστής μπορεί να χρησιμοποιηθεί από πολλούς προγραμματιστές ταυτόχρονα· δεν χρειάζεται να είναι σε θέση να ρυθμίσουν το postgresql, να κατανοήσουν το Docker και άλλες περιπλοκές. Σε έναν απομακρυσμένο διακομιστή, μπορείτε να εγκαταστήσετε την ίδια βάση δεδομένων στο ίδιο το Docker, εάν είναι δύσκολο να εγκαταστήσετε μια συγκεκριμένη έκδοση. Το μόνο που χρειάζονται οι προγραμματιστές είναι να παρέχουν πρόσβαση ssh!

Πρόσφατα διάβασα ότι οι σήραγγες SSH είναι μια περιορισμένη λειτουργικότητα ενός κανονικού VPN! Μπορείτε απλά να εγκαταστήσετε το OpenVPN ή άλλες υλοποιήσεις VPN, να ρυθμίσετε την υποδομή και να τη δώσετε σε προγραμματιστές για χρήση. Αυτό είναι τόσο ωραίο!

Ευτυχώς, το AWS, το GoogleCloud και άλλα σας δίνουν ένα χρόνο δωρεάν χρήσης, γι' αυτό χρησιμοποιήστε τα! Είναι φθηνά αν τα απενεργοποιήσετε όταν δεν τα χρησιμοποιείτε. Πάντα αναρωτιόμουν γιατί θα χρειαζόμουν έναν απομακρυσμένο διακομιστή όπως το gcloud, φαίνεται ότι τους βρήκα.

Ως τοπική εικονική μηχανή, μπορείτε να χρησιμοποιήσετε το ίδιο Alpine, το οποίο χρησιμοποιείται ενεργά σε κοντέινερ docker. Λοιπόν, ή κάποιες άλλες ελαφριές διανομές για να κάνετε την εκκίνηση του μηχανήματος πιο γρήγορα.

Κατώτατη γραμμή: μπορείτε και πρέπει να εκτελείτε βάσεις δεδομένων και άλλα καλούδια υποδομής σε απομακρυσμένους διακομιστές ή σε εικονικό κουτί. Δεν χρειάζομαι docker για αυτούς τους σκοπούς.

Λίγα λόγια για τις εικόνες και τη διανομή του docker

Έγραψα ήδη ένα άρθρο στην οποία ήθελα να μεταφέρω ότι η χρήση εικόνων docker δεν παρέχει καμία εγγύηση. Οι εικόνες Docker χρειάζονται μόνο για τη δημιουργία ενός κοντέινερ docker. Εάν κάνετε αναβάθμιση σε εικόνα docker, τότε κάνετε αναβάθμιση για να χρησιμοποιήσετε κοντέινερ docker και θα τα χρησιμοποιείτε μόνο.

Έχετε δει πουθενά όπου οι προγραμματιστές λογισμικού μεταφέρουν τα προϊόντα τους μόνο σε μια εικόνα docker;
Το αποτέλεσμα των περισσότερων προϊόντων είναι δυαδικά αρχεία για μια συγκεκριμένη πλατφόρμα· απλώς προστίθενται στην εικόνα του docker, η οποία κληρονομείται από την επιθυμητή πλατφόρμα. Έχετε αναρωτηθεί ποτέ γιατί υπάρχουν τόσες πολλές παρόμοιες εικόνες στο dockerhub; Εισαγάγετε το nginx για παράδειγμα, θα δείτε 100500 εικόνες από διαφορετικούς ανθρώπους. Αυτοί οι άνθρωποι δεν ανέπτυξαν το ίδιο το nginx, απλώς πρόσθεσαν το επίσημο nginx στην εικόνα του docker τους και το καρύκευσαν με τις δικές τους ρυθμίσεις για τη διευκόλυνση της εκτόξευσης κοντέινερ.

Σε γενικές γραμμές, μπορείτε απλά να το αποθηκεύσετε σε tgz, εάν κάποιος χρειάζεται να το εκτελέσει στο docker, αφήστε τον να προσθέσει tgz στο αρχείο Docker, να κληρονομήσει από το επιθυμητό περιβάλλον και να δημιουργήσει πρόσθετα bun που δεν αλλάζουν την ίδια την εφαρμογή στο tgz. Όποιος θα δημιουργήσει μια εικόνα docker θα ξέρει τι είναι το tgz και τι χρειάζεται για να δουλέψει. Έτσι χρησιμοποιώ το docker εδώ

Κατώτατη γραμμή: Δεν χρειάζομαι μητρώο docker, θα χρησιμοποιήσω κάποιο είδος S3 ή απλώς αποθήκευση αρχείων όπως το google drive/dropbox

Docker στο CI

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

Αυτές οι εταιρείες χρησιμοποιούν docker στους διακομιστές τους όπου εκτελείται η διαδικασία CI. Ερώτηση: Γιατί χρειάζεται να δημιουργήσετε έργα σε ένα docker container στους διακομιστές σας; Γιατί να μην προετοιμάσετε απλώς ένα περιβάλλον για την κατασκευή, για παράδειγμα, να γράψετε ένα βιβλίο αναπαραγωγής Ansible που θα εγκαταστήσει τις απαραίτητες εκδόσεις των κλειδιών nodejs, php, jdk, αντιγραφής ssh κ.λπ. στον διακομιστή στον οποίο θα πραγματοποιηθεί η κατασκευή;

Τώρα καταλαβαίνω ότι αυτό πυροβολώ τον εαυτό μου στο πόδι, γιατί το docker δεν φέρνει κανένα κέρδος με την απομόνωσή του. Προβλήματα που αντιμετώπισα με το CI στο docker:

πάλι χρειάζεστε μια εικόνα docker για να δημιουργήσετε. πρέπει να αναζητήσετε μια εικόνα ή να γράψετε το δικό σας αρχείο docker.
90% ότι πρέπει να προωθήσετε μερικά κλειδιά ssh, μυστικά δεδομένα που δεν θέλετε να γράψετε στην εικόνα του docker.
το κοντέινερ δημιουργείται και πεθαίνει, μαζί με αυτό χάνονται όλες οι κρυφές μνήμες. η επόμενη έκδοση θα κατεβάσει ξανά όλες τις εξαρτήσεις του έργου, κάτι που είναι χρονοβόρο και αναποτελεσματικό και ο χρόνος είναι χρήμα.

Οι προγραμματιστές δεν δημιουργούν έργα σε κοντέινερ docker (κάποτε ήμουν τόσο θαυμαστής, πραγματικά, λυπάμαι τον εαυτό μου στο παρελθόν xD). Στη java είναι δυνατό να έχετε πολλές εκδόσεις και να τις αλλάξετε με μία εντολή σε αυτή που χρειάζεστε τώρα. Το ίδιο είναι και στα nodejs, υπάρχει nvm.

Παραγωγή

Πιστεύω ότι το docker είναι ένα πολύ ισχυρό και ευέλικτο εργαλείο, αυτό είναι το μειονέκτημά του (ακούγεται περίεργο, ναι). Με τη βοήθειά του, οι εταιρείες μπορούν εύκολα να γαντζωθούν σε αυτό και να το χρησιμοποιήσουν όπου χρειάζεται και δεν χρειάζεται. Οι προγραμματιστές λανσάρουν τα κοντέινερ τους, ορισμένα από τα περιβάλλοντά τους, και στη συνέχεια όλα ρέουν ομαλά στο CI και στην παραγωγή. Η ομάδα DevOps γράφει κάποιο είδος κώδικα για να τρέξει αυτά τα κοντέινερ.

Χρησιμοποιήστε το docker μόνο σε το πιο πρόσφατο στάδιο στη ροή εργασίας σας, μην το σύρετε στο έργο στην αρχή. Δεν θα λύσει τα επαγγελματικά σας προβλήματα. Θα μεταφέρει μόνο τα προβλήματα σε ΑΛΛΟ επίπεδο και θα προσφέρει τις δικές του λύσεις, θα κάνετε διπλή δουλειά.

Όταν χρειάζεται docker: Κατέληξα στο συμπέρασμα ότι το docker είναι πολύ καλό στη βελτιστοποίηση μιας δεδομένης διαδικασίας, αλλά όχι στη δημιουργία βασικών λειτουργιών

Εάν εξακολουθείτε να αποφασίζετε να χρησιμοποιήσετε το docker, τότε:

να είστε εξαιρετικά προσεκτικοί
μην αναγκάζετε τους προγραμματιστές να χρησιμοποιούν docker
τοπικοποιήστε τη χρήση του σε ένα μέρος, μην το διαδώσετε σε όλα τα αποθετήρια Dockfile και docker-compose

PS:

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

Σας ευχαριστώ για την ανάγνωση, σας εύχομαι διαφανείς αποφάσεις στις υποθέσεις σας και παραγωγικές εργάσιμες ημέρες!

Πηγή: www.habr.com

Το Docker είναι παιχνίδι ή όχι; Ή είναι ακόμα;