Κάλλιο αργά παρά ποτέ. Ή πώς σχεδόν κάναμε ένα σοβαρό λάθος επειδή δεν είχαμε υποστήριξη για κανονικά Dockerfiles για τη δημιουργία εικόνων εφαρμογών.
Θα μιλήσουμε για — Το βοηθητικό πρόγραμμα GitOps που ενσωματώνεται με οποιοδήποτε σύστημα CI/CD και παρέχει διαχείριση ολόκληρου του κύκλου ζωής της εφαρμογής, επιτρέποντας:
- συλλογή και δημοσίευση εικόνων,
- ανάπτυξη εφαρμογών στο Kubernetes,
- διαγράψτε αχρησιμοποίητες εικόνες χρησιμοποιώντας ειδικές πολιτικές.
Η φιλοσοφία του έργου είναι η συλλογή εργαλείων χαμηλού επιπέδου σε ένα ενιαίο ενοποιημένο σύστημα που δίνει στους μηχανικούς DevOps τον έλεγχο των εφαρμογών. Εάν είναι δυνατόν, θα πρέπει να χρησιμοποιηθούν υπάρχοντα βοηθητικά προγράμματα (όπως το Helm και το Docker). Εάν δεν υπάρχει λύση σε ένα πρόβλημα, μπορούμε να δημιουργήσουμε και να υποστηρίξουμε όλα τα απαραίτητα για αυτό.
Φόντο: ο δικός σας συλλέκτης εικόνων
Αυτό συνέβη με τον συλλέκτη εικόνων στο werf: το συνηθισμένο Dockerfile δεν ήταν αρκετό για εμάς. Αν ρίξετε μια γρήγορη ματιά στην ιστορία του έργου, αυτό το πρόβλημα εμφανίστηκε ήδη στις πρώτες εκδόσεις του werf (τότε ακόμα ).
Κατά τη δημιουργία ενός εργαλείου για τη δημιουργία εφαρμογών σε εικόνες Docker, συνειδητοποιήσαμε γρήγορα ότι το Dockerfile δεν ήταν κατάλληλο για εμάς για ορισμένες πολύ συγκεκριμένες εργασίες:
- Η ανάγκη δημιουργίας τυπικών μικρών διαδικτυακών εφαρμογών σύμφωνα με το ακόλουθο τυπικό σχήμα:
- εγκατάσταση εξαρτήσεων εφαρμογών σε όλο το σύστημα,
- εγκαταστήστε μια δέσμη βιβλιοθηκών εξαρτήσεων εφαρμογών,
- συλλογή περιουσιακών στοιχείων,
- και το πιο σημαντικό, ενημερώστε τον κώδικα στην εικόνα γρήγορα και αποτελεσματικά.
- Όταν γίνονται αλλαγές στα αρχεία έργου, το πρόγραμμα δημιουργίας πρέπει να δημιουργήσει γρήγορα ένα νέο επίπεδο εφαρμόζοντας μια ενημερωμένη έκδοση κώδικα στα αρχεία που έχουν αλλάξει.
- Εάν ορισμένα αρχεία έχουν αλλάξει, τότε είναι απαραίτητο να δημιουργήσετε ξανά το αντίστοιχο εξαρτημένο στάδιο.
Σήμερα ο συλλέκτης μας έχει πολλές άλλες δυνατότητες, αλλά αυτές ήταν οι αρχικές επιθυμίες και ορμές.
Γενικά, χωρίς να το ξανασκεφτούμε, οπλιστήκαμε με τη γλώσσα προγραμματισμού που χρησιμοποιήσαμε (Δες παρακάτω) και βγήκε στον δρόμο για την εφαρμογή δικό του DSL! Σύμφωνα με τους στόχους, προοριζόταν να περιγραφεί σταδιακά η διαδικασία συναρμολόγησης και να προσδιοριστούν οι εξαρτήσεις αυτών των σταδίων από αρχεία. Και το συμπλήρωσε δικός συλλέκτης, που μετέτρεψε το DSL στον τελικό στόχο - μια συναρμολογημένη εικόνα. Στην αρχή το DSL ήταν στο Ruby, αλλά όπως — η διαμόρφωση του συλλέκτη μας άρχισε να περιγράφεται σε ένα αρχείο YAML.
Παλιά διαμόρφωση για το dapp στο Ruby
Τρέχουσα διαμόρφωση για το werf στο YAML
Ο μηχανισμός του συλλέκτη άλλαξε επίσης με την πάροδο του χρόνου. Στην αρχή, δημιουργήσαμε απλώς ένα προσωρινό αρχείο Docker on the fly από τη διαμόρφωσή μας και, στη συνέχεια, αρχίσαμε να εκτελούμε οδηγίες συναρμολόγησης σε προσωρινά κοντέινερ και να δεσμεύουμε.
NB: Αυτή τη στιγμή, ο συλλέκτης μας, ο οποίος λειτουργεί με το δικό του config (στο YAML) και ονομάζεται συλλέκτης Stapel, έχει ήδη εξελιχθεί σε ένα αρκετά ισχυρό εργαλείο. Η λεπτομερής περιγραφή του αξίζει ξεχωριστά άρθρα και βασικές λεπτομέρειες μπορείτε να βρείτε στο .
Επίγνωση του προβλήματος
Αλλά καταλάβαμε, και όχι αμέσως, ότι κάναμε ένα λάθος: δεν προσθέσαμε την ικανότητα δημιουργία εικόνων μέσω τυπικού Dockerfile και να τις ενσωματώσει στην ίδια υποδομή διαχείρισης εφαρμογών από άκρο σε άκρο (δηλαδή συλλογή εικόνων, ανάπτυξη και καθαρισμός τους). Πώς θα ήταν δυνατό να δημιουργήσετε ένα εργαλείο για ανάπτυξη στο Kubernetes και να μην εφαρμόσετε υποστήριξη Dockerfile, π.χ. τυπικός τρόπος περιγραφής εικόνων για τα περισσότερα έργα;...
Αντί να απαντήσουμε σε αυτή την ερώτηση, προσφέρουμε μια λύση. Τι γίνεται αν έχετε ήδη ένα Dockerfile (ή ένα σύνολο Dockerfiles) και θέλετε να χρησιμοποιήσετε το werf;
NB: Παρεμπιπτόντως, γιατί θα θέλατε να χρησιμοποιήσετε το werf; Τα κύρια χαρακτηριστικά καταλήγουν στα εξής:
- πλήρης κύκλος διαχείρισης εφαρμογών, συμπεριλαμβανομένου του καθαρισμού εικόνας.
- τη δυνατότητα διαχείρισης της συναρμολόγησης πολλών εικόνων ταυτόχρονα από μία μόνο διαμόρφωση.
- Βελτιωμένη διαδικασία ανάπτυξης για χάρτες συμβατούς με Helm.
Μια πιο πλήρης λίστα με αυτά μπορείτε να βρείτε στη διεύθυνση .
Έτσι, αν νωρίτερα θα είχαμε προσφερθεί να ξαναγράψουμε το Dockerfile στη διαμόρφωση μας, τώρα θα πούμε ευχαρίστως: "Αφήστε το werf να δημιουργήσει τα Dockerfiles σας!"
Πώς να χρησιμοποιήσετε;
Η πλήρης εφαρμογή αυτής της δυνατότητας εμφανίστηκε στην έκδοση . Η γενική αρχή είναι απλή: ο χρήστης καθορίζει τη διαδρομή προς ένα υπάρχον Dockerfile στη διαμόρφωση werf και, στη συνέχεια, εκτελεί την εντολή werf build... και αυτό είναι - η werf θα συναρμολογήσει την εικόνα. Ας δούμε ένα αφηρημένο παράδειγμα.
Ας ανακοινώσουμε το επόμενο Dockerfile στη ρίζα του έργου:
FROM ubuntu:18.04
RUN echo Building ...
Και θα ανακοινώσουμε werf.yamlπου χρησιμοποιεί αυτό Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Ολα! Αριστερά τρέξιμο werf build:
Επιπλέον, μπορείτε να δηλώσετε τα εξής werf.yaml για να δημιουργήσετε πολλές εικόνες από διαφορετικά Dockerfiles ταυτόχρονα:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Τέλος, υποστηρίζει επίσης τη μετάδοση πρόσθετων παραμέτρων κατασκευής, όπως π.χ --build-arg и --add-host - μέσω της ρύθμισης werf. Μια πλήρης περιγραφή της διαμόρφωσης εικόνας Dockerfile είναι διαθέσιμη στη διεύθυνση .
Πώς λειτουργεί;
Κατά τη διαδικασία δημιουργίας, η τυπική κρυφή μνήμη των τοπικών επιπέδων στο Docker λειτουργεί. Ωστόσο, αυτό που είναι σημαντικό είναι και αυτό ενσωματώνει τη διαμόρφωση του Dockerfile στην υποδομή του. Τι σημαίνει αυτό?
- Κάθε εικόνα που δημιουργείται από ένα Dockerfile αποτελείται από ένα στάδιο που ονομάζεται
dockerfile(μπορείτε να διαβάσετε περισσότερα σχετικά με τα στάδια στο werf ). - Για σκηνή
dockerfileΤο werf υπολογίζει μια υπογραφή που εξαρτάται από τα περιεχόμενα της διαμόρφωσης Dockerfile. Όταν αλλάζει η διαμόρφωση του Dockerfile, αλλάζει η υπογραφή του σταδίουdockerfileκαι το werf ξεκινά μια ανακατασκευή αυτού του σταδίου με μια νέα διαμόρφωση Dockerfile. Εάν η υπογραφή δεν αλλάξει, τότε η werf παίρνει την εικόνα από την κρυφή μνήμη (περισσότερες λεπτομέρειες σχετικά με τη χρήση των υπογραφών στο werf περιγράφονται στο ). - Στη συνέχεια, οι συλλεγμένες εικόνες μπορούν να δημοσιευτούν με την εντολή
werf publish(ήwerf build-and-publish) και χρησιμοποιήστε το για ανάπτυξη στο Kubernetes. Οι δημοσιευμένες εικόνες στο Μητρώο Docker θα καθαρίζονται χρησιμοποιώντας τυπικά εργαλεία καθαρισμού werf, π.χ. Παλιές εικόνες (παλαιότερες από N ημέρες), εικόνες που σχετίζονται με ανύπαρκτους κλάδους Git και άλλες πολιτικές θα καθαρίζονται αυτόματα.
Περισσότερες λεπτομέρειες σχετικά με τα σημεία που περιγράφονται εδώ μπορείτε να βρείτε στην τεκμηρίωση:
- ;
- ;
- .
Σημειώσεις και προφυλάξεις
1. Η εξωτερική διεύθυνση URL δεν υποστηρίζεται στο ADD
Προς το παρόν δεν υποστηρίζεται η χρήση εξωτερικής διεύθυνσης URL σε μια οδηγία ADD. Το Werf δεν θα ξεκινήσει μια ανακατασκευή όταν αλλάξει ο πόρος στο καθορισμένο URL. Σκοπεύουμε να προσθέσουμε αυτήν τη δυνατότητα σύντομα.
2. Δεν μπορείτε να προσθέσετε .git στην εικόνα
Σε γενικές γραμμές, προσθέτοντας έναν κατάλογο .git στην εικόνα - μια κακή κακή πρακτική και να γιατί:
- αν
.gitπαραμένει στην τελική εικόνα, αυτό παραβιάζει τις αρχές : Δεδομένου ότι η τελική εικόνα πρέπει να συνδεθεί με μία μόνο δέσμευση, δεν θα πρέπει να είναι δυνατό να γίνειgit checkoutαυθαίρετη δέσμευση. -
.gitαυξάνει το μέγεθος της εικόνας (το αποθετήριο μπορεί να είναι μεγάλο λόγω του γεγονότος ότι μια φορά προστέθηκαν μεγάλα αρχεία σε αυτό και στη συνέχεια διαγράφηκαν). Το μέγεθος ενός δέντρου εργασίας που σχετίζεται μόνο με μια συγκεκριμένη δέσμευση δεν θα εξαρτάται από το ιστορικό των λειτουργιών στο Git. Σε αυτή την περίπτωση, η προσθήκη και η επακόλουθη αφαίρεση.gitαπό την τελική εικόνα δεν θα λειτουργήσει: η εικόνα θα εξακολουθεί να αποκτά ένα επιπλέον επίπεδο - έτσι λειτουργεί το Docker. - Ο Docker μπορεί να ξεκινήσει μια περιττή ανακατασκευή, ακόμα κι αν η ίδια δέσμευση δημιουργείται, αλλά από διαφορετικά δέντρα εργασίας. Για παράδειγμα, το GitLab δημιουργεί ξεχωριστούς κλωνοποιημένους καταλόγους
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectόταν είναι ενεργοποιημένη η παράλληλη συναρμολόγηση. Η επιπλέον επανασυναρμολόγηση θα οφείλεται στο γεγονός ότι ο κατάλογος.gitείναι διαφορετικό σε διαφορετικές κλωνοποιημένες εκδόσεις του ίδιου αποθετηρίου, ακόμα κι αν έχει δημιουργηθεί η ίδια δέσμευση.
Το τελευταίο σημείο έχει επίσης συνέπειες κατά τη χρήση του werf. Το Werf απαιτεί να υπάρχει η ενσωματωμένη κρυφή μνήμη κατά την εκτέλεση ορισμένων εντολών (π.χ. werf deploy). Όταν εκτελούνται αυτές οι εντολές, η werf υπολογίζει τις υπογραφές σταδίου για τις εικόνες που καθορίζονται σε werf.yaml, και πρέπει να βρίσκονται στην κρυφή μνήμη συναρμολόγησης - διαφορετικά η εντολή δεν θα μπορεί να συνεχίσει να λειτουργεί. Αν η σκηνική υπογραφή εξαρτάται από το περιεχόμενο .git, τότε λαμβάνουμε μια προσωρινή μνήμη που είναι ασταθής σε αλλαγές σε άσχετα αρχεία και το werf δεν θα μπορεί να συγχωρήσει μια τέτοια παράβλεψη (για περισσότερες λεπτομέρειες, βλ. ).
Σε γενικές γραμμές, προσθέτοντας μόνο ορισμένα απαραίτητα αρχεία μέσα από τις οδηγίες ADD σε κάθε περίπτωση αυξάνει την αποτελεσματικότητα και την αξιοπιστία του γραπτού Dockerfile, και επίσης βελτιώνει τη σταθερότητα της κρυφής μνήμης που συλλέγεται για αυτό Dockerfile, σε άσχετες αλλαγές στο Git.
Σύνολο
Η αρχική μας διαδρομή για τη σύνταξη του δικού μας builder για συγκεκριμένες ανάγκες ήταν δύσκολη, ειλικρινής και απλή: αντί να χρησιμοποιούμε δεκανίκια πάνω από το τυπικό Dockerfile, γράψαμε τη λύση μας με προσαρμοσμένη σύνταξη. Και αυτό είχε τα πλεονεκτήματά του: ο συλλέκτης Stapel αντιμετωπίζει τέλεια το έργο του.
Ωστόσο, κατά τη διαδικασία σύνταξης του δικού μας δημιουργού, χάσαμε τα μάτια μας για την υποστήριξη για τα υπάρχοντα Dockerfiles. Αυτό το ελάττωμα έχει πλέον επιδιορθωθεί και στο μέλλον σκοπεύουμε να αναπτύξουμε υποστήριξη Dockerfile μαζί με το προσαρμοσμένο μας πρόγραμμα δημιουργίας Stapel για κατανεμημένες εκδόσεις και για εκδόσεις που χρησιμοποιούν Kubernetes (δηλαδή build σε runners μέσα στο Kubernetes, όπως γίνεται στο kaniko).
Λοιπόν, αν ξαφνικά έχετε μερικά Dockerfiles γύρω... δοκιμάστε το !
ΥΓ Κατάλογος τεκμηρίωσης για το θέμα
- ;
- ;
- ;
- ;
- ;
- ;
- .
Διαβάστε επίσης στο blog μας: "».
Πηγή: www.habr.com