Το πρώτο βήμα για την ανάπτυξη στο Kubernetes είναι η τοποθέτηση της εφαρμογής σας σε ένα κοντέινερ. Σε αυτήν τη σειρά, θα εξετάσουμε πώς μπορείτε να δημιουργήσετε μια μικρή, ασφαλή εικόνα κοντέινερ.
Χάρη στο Docker, η δημιουργία εικόνων κοντέινερ δεν ήταν ποτέ ευκολότερη. Καθορίστε μια εικόνα βάσης, προσθέστε τις αλλαγές σας και δημιουργήστε ένα κοντέινερ.
Αν και αυτή η τεχνική είναι εξαιρετική για να ξεκινήσετε, η χρήση προεπιλεγμένων βασικών εικόνων μπορεί να οδηγήσει σε μη ασφαλή εργασία με μεγάλες εικόνες γεμάτες ευπάθειες.
Επιπλέον, οι περισσότερες εικόνες στο Docker χρησιμοποιούν Debian ή Ubuntu για τη βασική εικόνα και ενώ αυτό παρέχει εξαιρετική συμβατότητα και εύκολη προσαρμογή (ένα αρχείο Docker απαιτεί μόνο δύο γραμμές κώδικα), οι βασικές εικόνες μπορούν να προσθέσουν εκατοντάδες megabyte επιπλέον φορτίου στο κοντέινερ σας. Για παράδειγμα, ένα απλό αρχείο node.js για μια εφαρμογή Go "hello-world" είναι περίπου 700 megabyte, ενώ η πραγματική σας εφαρμογή έχει μέγεθος μόνο μερικά megabyte.
Έτσι, όλος αυτός ο επιπλέον φόρτος εργασίας είναι σπατάλη ψηφιακού χώρου και μια εξαιρετική κρυψώνα για τρωτά σημεία ασφαλείας και σφάλματα. Ας δούμε λοιπόν δύο τρόπους μείωσης του μεγέθους μιας εικόνας κοντέινερ.
Το πρώτο είναι η χρήση μικρών εικόνων βάσης, το δεύτερο είναι η χρήση του μοτίβου Builder. Η χρήση μικρότερων εικόνων βάσης είναι ίσως ο ευκολότερος τρόπος για να μειώσετε το μέγεθος του κοντέινερ σας. Πιθανότατα, η γλώσσα ή η στοίβα που χρησιμοποιείτε παρέχει μια αρχική εικόνα εφαρμογής που είναι πολύ μικρότερη από την προεπιλεγμένη εικόνα. Ας ρίξουμε μια ματιά στο κοντέινερ node.js.
Από προεπιλογή στο Docker, το βασικό μέγεθος εικόνας node:8 είναι 670 MB και το μέγεθος εικόνας node: 8-alpine είναι μόνο 65 MB, δηλαδή 10 φορές μικρότερο. Χρησιμοποιώντας τη μικρότερη εικόνα βάσης των Άλπεων, θα μειώσετε σημαντικά το μέγεθος του κοντέινερ σας. Το Alpine είναι μια μικρή και ελαφριά διανομή Linux που είναι πολύ δημοφιλής στους χρήστες του Docker επειδή είναι συμβατή με πολλές εφαρμογές, ενώ διατηρεί τα κοντέινερ μικρά. Σε αντίθεση με την τυπική εικόνα "κόμβου" του Docker, το "node:alpine" αφαιρεί πολλά αρχεία υπηρεσίας και προγράμματα, αφήνοντας μόνο εκείνα που επαρκούν για την εκτέλεση της εφαρμογής σας.
Για να μετακινηθείτε σε μια μικρότερη εικόνα βάσης, απλώς ενημερώστε το Dockerfile για να ξεκινήσετε να εργάζεστε με τη νέα εικόνα βάσης:
Τώρα, σε αντίθεση με την παλιά εικόνα onbuild, πρέπει να αντιγράψετε τον κώδικά σας στο κοντέινερ και να εγκαταστήσετε τυχόν εξαρτήσεις. Σε ένα νέο Dockerfile, το κοντέινερ ξεκινά με μια εικόνα node:alpine, στη συνέχεια δημιουργεί έναν κατάλογο για τον κώδικα, εγκαθιστά εξαρτήσεις χρησιμοποιώντας τη διαχείριση πακέτων NPM και, τέλος, εκτελεί το server.js.
Αυτή η αναβάθμιση έχει ως αποτέλεσμα ένα δοχείο που είναι 10 φορές μικρότερο σε μέγεθος. Εάν η γλώσσα προγραμματισμού ή η στοίβα σας δεν διαθέτει βασική λειτουργία μείωσης εικόνας, χρησιμοποιήστε το Alpine Linux. Θα παρέχει επίσης τη δυνατότητα πλήρους διαχείρισης του περιεχομένου του δοχείου. Η χρήση μικρών εικόνων βάσης είναι ένας πολύ καλός τρόπος για να δημιουργήσετε γρήγορα μικρά δοχεία. Αλλά ακόμη μεγαλύτερη μείωση μπορεί να επιτευχθεί χρησιμοποιώντας το Μοτίβο Δόμησης.
Στις διερμηνευμένες γλώσσες, ο πηγαίος κώδικας μεταβιβάζεται πρώτα στον διερμηνέα και στη συνέχεια εκτελείται απευθείας. Στις μεταγλωττισμένες γλώσσες, ο πηγαίος κώδικας μετατρέπεται πρώτα σε μεταγλωττισμένο κώδικα. Ωστόσο, η μεταγλώττιση χρησιμοποιεί συχνά εργαλεία που στην πραγματικότητα δεν χρειάζονται για την εκτέλεση του κώδικα. Αυτό σημαίνει ότι μπορείτε να αφαιρέσετε εντελώς αυτά τα εργαλεία από το τελικό δοχείο. Μπορείτε να χρησιμοποιήσετε το Builder Pattern για αυτό.
Ο κώδικας δημιουργείται στο πρώτο κοντέινερ και μεταγλωττίζεται. Στη συνέχεια, ο μεταγλωττισμένος κώδικας συσκευάζεται σε ένα τελικό κοντέινερ χωρίς τους μεταγλωττιστές και τα εργαλεία που απαιτούνται για τη μεταγλώττιση αυτού του κώδικα. Ας εκτελέσουμε μια εφαρμογή Go μέσω αυτής της διαδικασίας. Αρχικά, θα περάσουμε από την εικόνα του ενσωματωμένου στο Alpine Linux.
Στο νέο Dockerfile, το κοντέινερ ξεκινά με μια εικόνα golang:alpine. Στη συνέχεια, δημιουργεί έναν κατάλογο για τον κώδικα, τον αντιγράφει στον πηγαίο κώδικα, δημιουργεί αυτόν τον πηγαίο κώδικα και εκτελεί την εφαρμογή. Αυτό το κοντέινερ είναι πολύ μικρότερο από το ενσωματωμένο κοντέινερ, αλλά εξακολουθεί να περιέχει τον μεταγλωττιστή και άλλα εργαλεία Go που δεν χρειαζόμαστε πραγματικά. Ας εξαγάγουμε λοιπόν το μεταγλωττισμένο πρόγραμμα και ας το βάλουμε στο δικό του δοχείο.
Μπορεί να παρατηρήσετε κάτι περίεργο σε αυτό το αρχείο Docker: περιέχει δύο γραμμές FROM. Το πρώτο τμήμα 4 γραμμών μοιάζει ακριβώς με το προηγούμενο Dockerfile, εκτός από το ότι χρησιμοποιεί τη λέξη-κλειδί AS για να ονομάσει αυτό το στάδιο. Η επόμενη ενότητα έχει μια νέα γραμμή FROM για να ξεκινήσει μια νέα εικόνα, όπου αντί για την εικόνα golang:alpine θα χρησιμοποιήσουμε το Raw alpine ως βασική εικόνα.
Το Raw Alpine Linux δεν έχει εγκατεστημένα πιστοποιητικά SSL, γεγονός που θα προκαλέσει την αποτυχία των περισσότερων κλήσεων API μέσω HTTPS, οπότε ας εγκαταστήσουμε ορισμένα πιστοποιητικά CA root.
Τώρα έρχεται το διασκεδαστικό μέρος: για να αντιγράψετε τον μεταγλωττισμένο κώδικα από το πρώτο κοντέινερ στο δεύτερο, μπορείτε απλά να χρησιμοποιήσετε την εντολή COPY που βρίσκεται στη γραμμή 5 της δεύτερης ενότητας. Θα αντιγράψει μόνο ένα αρχείο εφαρμογής και δεν θα επηρεάσει τα βοηθητικά εργαλεία Go. Το νέο αρχείο Docker πολλαπλών σταδίων θα περιέχει μια εικόνα κοντέινερ που έχει μέγεθος μόνο 12 megabyte, σε σύγκριση με την αρχική εικόνα κοντέινερ που ήταν 700 megabyte, που είναι μεγάλη διαφορά!
Επομένως, η χρήση μικρών εικόνων βάσης και μοτίβου Builder είναι υπέροχοι τρόποι για να δημιουργήσετε πολύ μικρότερα κοντέινερ χωρίς πολλή δουλειά.
Είναι πιθανό ότι ανάλογα με τη στοίβα εφαρμογών, υπάρχουν πρόσθετοι τρόποι για να μειώσετε το μέγεθος της εικόνας και του κοντέινερ, αλλά τα μικρά κοντέινερ έχουν πραγματικά ένα μετρήσιμο όφελος; Ας δούμε δύο τομείς όπου τα μικρά δοχεία είναι εξαιρετικά αποτελεσματικά - απόδοση και ασφάλεια.
Για να αξιολογήσετε την αύξηση της απόδοσης, εξετάστε τη διάρκεια της διαδικασίας δημιουργίας ενός κοντέινερ, εισαγωγής στο μητρώο (push) και, στη συνέχεια, ανάκτησή του από εκεί (τραβήξτε). Μπορείτε να δείτε ότι ένα μικρότερο δοχείο έχει ένα σαφές πλεονέκτημα σε σχέση με ένα μεγαλύτερο δοχείο.
Το Docker θα αποθηκεύσει προσωρινά τα επίπεδα, έτσι οι επόμενες εκδόσεις θα είναι πολύ γρήγορες. Ωστόσο, πολλά συστήματα CI που χρησιμοποιούνται για την κατασκευή και τη δοκιμή κοντέινερ δεν αποθηκεύουν επίπεδα κρυφής μνήμης, επομένως υπάρχει σημαντική εξοικονόμηση χρόνου. Όπως μπορείτε να δείτε, ο χρόνος για την κατασκευή ενός μεγάλου κοντέινερ, ανάλογα με την ισχύ του μηχανήματός σας, είναι από 34 έως 54 δευτερόλεπτα και όταν χρησιμοποιείτε δοχείο μειώνεται χρησιμοποιώντας το Μοτίβο Δόμησης - από 23 σε 28 δευτερόλεπτα. Για εργασίες αυτού του είδους, η αύξηση της παραγωγικότητας θα είναι 40-50%. Σκεφτείτε λοιπόν πόσες φορές δημιουργείτε και δοκιμάζετε τον κώδικα σας.
Μετά την κατασκευή του κοντέινερ, πρέπει να ωθήσετε την εικόνα του (εικόνα κοντέινερ ώθησης) στο μητρώο κοντέινερ, ώστε να μπορείτε στη συνέχεια να το χρησιμοποιήσετε στο σύμπλεγμα Kubernetes. Συνιστώ να χρησιμοποιήσετε το Μητρώο κοντέινερ Google.
Με το Μητρώο κοντέινερ Google (GCR), πληρώνετε μόνο για ακατέργαστη αποθήκευση και δικτύωση και δεν υπάρχουν πρόσθετες χρεώσεις διαχείρισης κοντέινερ. Είναι ιδιωτικό, ασφαλές και πολύ γρήγορο. Το GCR χρησιμοποιεί πολλά κόλπα για να επιταχύνει τη λειτουργία έλξης. Όπως μπορείτε να δείτε, η εισαγωγή ενός κοντέινερ εικόνας Docker με χρήση του go:onbuild θα διαρκέσει από 15 έως 48 δευτερόλεπτα, ανάλογα με την απόδοση του υπολογιστή, και η ίδια λειτουργία με ένα μικρότερο κοντέινερ θα διαρκέσει από 14 έως 16 δευτερόλεπτα και για λιγότερο παραγωγικά μηχανήματα το πλεονέκτημα στην ταχύτητα λειτουργίας αυξάνεται κατά 3 φορές. Για μεγαλύτερα μηχανήματα, ο χρόνος είναι περίπου ο ίδιος, αφού το GCR χρησιμοποιεί μια καθολική κρυφή μνήμη για μια κοινόχρηστη βάση δεδομένων εικόνων, που σημαίνει ότι δεν χρειάζεται να τις φορτώσετε καθόλου. Σε έναν υπολογιστή χαμηλής κατανάλωσης, η CPU είναι το σημείο συμφόρησης, επομένως το πλεονέκτημα της χρήσης μικρών κοντέινερ είναι πολύ μεγαλύτερο εδώ.
Εάν χρησιμοποιείτε το GCR, σας συνιστώ να χρησιμοποιήσετε το Google Container Builder (GCB) ως μέρος του συστήματος κατασκευής σας.
Όπως μπορείτε να δείτε, η χρήση του σάς επιτρέπει να επιτύχετε πολύ καλύτερα αποτελέσματα στη μείωση της διάρκειας της λειτουργίας Build+Push ακόμη και από ένα παραγωγικό μηχάνημα - σε αυτήν την περίπτωση, η διαδικασία κατασκευής και αποστολής κοντέινερ στον κεντρικό υπολογιστή επιταχύνεται σχεδόν 2 φορές . Επιπλέον, λαμβάνετε 120 δωρεάν λεπτά κατασκευής κάθε μέρα, τα οποία καλύπτουν τις ανάγκες σας για κατασκευή κοντέινερ στις περισσότερες περιπτώσεις.
Ακολουθεί η πιο σημαντική μέτρηση απόδοσης – η ταχύτητα ανάκτησης ή λήψης, Τραβήξτε κοντέινερ. Και αν δεν σας ενδιαφέρει πολύ ο χρόνος που αφιερώνεται σε μια λειτουργία ώθησης, τότε η διάρκεια της διαδικασίας έλξης έχει σοβαρό αντίκτυπο στη συνολική απόδοση του συστήματος. Ας υποθέσουμε ότι έχετε ένα σύμπλεγμα τριών κόμβων και ένας από αυτούς αποτυγχάνει. Εάν χρησιμοποιείτε ένα σύστημα διαχείρισης όπως το Google Kubernetes Engine, θα αντικαταστήσει αυτόματα τον νεκρό κόμβο με έναν νέο. Ωστόσο, αυτός ο νέος κόμβος θα είναι εντελώς άδειος και θα πρέπει να σύρετε όλα τα κοντέινερ σε αυτόν για να αρχίσει να λειτουργεί. Εάν η λειτουργία έλξης διαρκεί αρκετά, το σύμπλεγμα σας θα λειτουργεί με χαμηλότερη απόδοση όλη την ώρα.
Υπάρχουν πολλές περιπτώσεις όπου αυτό μπορεί να συμβεί: προσθήκη νέου κόμβου σε ένα σύμπλεγμα, αναβάθμιση κόμβων ή ακόμη και μετάβαση σε νέο κοντέινερ για ανάπτυξη. Έτσι, η ελαχιστοποίηση του χρόνου εξαγωγής έλξης γίνεται βασικός παράγοντας. Είναι αναμφισβήτητο ότι ένα μικρό κοντέινερ κατεβάζει πολύ πιο γρήγορα από ένα μεγάλο. Εάν χρησιμοποιείτε πολλά κοντέινερ σε ένα σύμπλεγμα Kubernetes, η εξοικονόμηση χρόνου μπορεί να είναι σημαντική.
Ρίξτε μια ματιά σε αυτήν τη σύγκριση: μια λειτουργία έλξης σε μικρά δοχεία απαιτεί 4-9 φορές λιγότερο χρόνο, ανάλογα με την ισχύ του μηχανήματος, από την ίδια λειτουργία χρησιμοποιώντας το go:onbuild. Η χρήση κοινών εικόνων βάσης μικρών κοντέινερ επιταχύνει σημαντικά τον χρόνο και την ταχύτητα με την οποία μπορούν να αναπτυχθούν και να συνδεθούν στο διαδίκτυο νέοι κόμβοι Kubernetes.
Ας δούμε το θέμα της ασφάλειας. Τα μικρότερα δοχεία θεωρούνται πολύ πιο ασφαλή από τα μεγαλύτερα επειδή έχουν μικρότερη επιφάνεια επίθεσης. Είναι αλήθεια; Ένα από τα πιο χρήσιμα χαρακτηριστικά του Google Container Registry είναι η δυνατότητα αυτόματης σάρωσης των κοντέινερ σας για ευπάθειες. Πριν από μερικούς μήνες δημιούργησα και κοντέινερ επί κατασκευής και πολλαπλών σταδίων, οπότε ας δούμε αν υπάρχουν ευπάθειες εκεί.
Το αποτέλεσμα είναι εκπληκτικό: μόνο 3 μεσαίες ευπάθειες εντοπίστηκαν σε ένα μικρό κοντέινερ και 16 κρίσιμα και 376 άλλα τρωτά σημεία βρέθηκαν σε ένα μεγάλο δοχείο. Αν κοιτάξουμε τα περιεχόμενα ενός μεγάλου κοντέινερ, μπορούμε να δούμε ότι τα περισσότερα από τα προβλήματα ασφαλείας δεν έχουν καμία σχέση με την εφαρμογή μας, αλλά σχετίζονται με προγράμματα που δεν χρησιμοποιούμε καν. Έτσι, όταν οι άνθρωποι μιλούν για μια μεγάλη επιφάνεια επίθεσης, αυτό εννοούν.
Το takeaway είναι ξεκάθαρο: κατασκευάστε μικρά κοντέινερ επειδή παρέχουν πραγματικά οφέλη απόδοσης και ασφάλειας στο σύστημά σας.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com