Οι συναντήσεις διαχειριστή συστήματος Sysadminka πραγματοποιούνται στο Τσελιάμπινσκ και στην τελευταία έδωσα μια αναφορά σχετικά με τη λύση μας για την εκτέλεση εφαρμογών στο 1C-Bitrix στο Kubernetes.
Bitrix, Kubernetes, Ceph - ένα υπέροχο μείγμα;
Θα σας πω πώς δημιουργήσαμε μια λειτουργική λύση από όλα αυτά.
Πάμε!
Η συνάντηση πραγματοποιήθηκε στις 18 Απριλίου στο Τσελιάμπινσκ. Μπορείτε να διαβάσετε για τις συναντήσεις μας στο και κοιτάξτε .
Εάν θέλετε να έρθετε σε μας με μια αναφορά ή ως ακροατής - καλώς ήρθατε, γράψτε στο [προστασία μέσω email] και στο Telegram t.me/vadimisakanov.
Η αναφορά μου
Λύση "Bitrix in Kubernetes, έκδοση Southbridge 1.0"
Θα μιλήσω για τη λύση μας στη μορφή "για ανδρείκελα στο Kubernetes", όπως έγινε στη συνάντηση. Αλλά υποθέτω ότι γνωρίζετε τις λέξεις Bitrix, Docker, Kubernetes, Ceph τουλάχιστον στο επίπεδο των άρθρων στη Wikipedia.
Τι είναι έτοιμο για το Bitrix στο Kubernetes;
Υπάρχουν πολύ λίγες πληροφορίες σε ολόκληρο το Διαδίκτυο σχετικά με τη λειτουργία των εφαρμογών Bitrix στο Kubernetes.
Βρήκα μόνο αυτά τα υλικά:
Αναφορά από τον Alexander Serbul, 1C-Bitrix, και τον Anton Tuzlukov από την Qsoft:
Προτείνω να το ακούσετε.
Ανάπτυξη της δικής σας λύσης από τον χρήστη .
Βρέθηκαν περισσότερα .
Aaand... στην πραγματικότητα, αυτό είναι όλο.
Σας προειδοποιώ, δεν έχουμε ελέγξει την ποιότητα των λύσεων στους παραπάνω συνδέσμους :)
Παρεμπιπτόντως, κατά την προετοιμασία της λύσης μας, μίλησα με τον Alexander Serbul, τότε η έκθεσή του δεν είχε εμφανιστεί ακόμα, επομένως στις διαφάνειές μου υπάρχει ένα στοιχείο "Το Bitrix δεν χρησιμοποιεί Kubernetes".
Αλλά υπάρχουν ήδη πολλές έτοιμες εικόνες Docker για εκτέλεση του Bitrix στο Docker:
Είναι αυτό αρκετό για να δημιουργήσετε μια ολοκληρωμένη λύση για το Bitrix στο Kubernetes;
Οχι. Υπάρχει ένας μεγάλος αριθμός προβλημάτων που πρέπει να λυθούν.
Ποια είναι τα προβλήματα με το Bitrix στο Kubernetes;
Πρώτον, οι έτοιμες εικόνες από το Dockerhub δεν είναι κατάλληλες για Kubernetes
Αν θέλουμε να δημιουργήσουμε μια αρχιτεκτονική microservices (και στο Kubernetes κάνουμε συνήθως), πρέπει να διαχωρίσουμε την εφαρμογή Kubernetes σε κοντέινερ και να κάνουμε κάθε κοντέινερ μια μικρή λειτουργία (και να το κάνει καλά). Γιατί μόνο ένα; Με λίγα λόγια, όσο πιο απλό τόσο πιο αξιόπιστο.
Για να γίνετε πιο συγκεκριμένοι, δείτε αυτό το άρθρο και το βίντεο, παρακαλώ:
Οι εικόνες Docker στο Dockerhub βασίζονται κυρίως στην αρχή του all-in-one, επομένως έπρεπε να φτιάξουμε το δικό μας ποδήλατο και ακόμη και να δημιουργήσουμε εικόνες από την αρχή.
Δεύτερον - ο κώδικας του ιστότοπου επεξεργάζεται από τον πίνακα διαχείρισης
Δημιουργήσαμε μια νέα ενότητα στον ιστότοπο - ο κώδικας ενημερώθηκε (προστέθηκε ένας κατάλογος με το όνομα της νέας ενότητας).
Εάν αλλάξατε τις ιδιότητες ενός στοιχείου από τον πίνακα διαχείρισης, ο κώδικας άλλαξε.
Το Kubernetes "από προεπιλογή" δεν μπορεί να λειτουργήσει με αυτό· τα κοντέινερ πρέπει να είναι ανιθαγενή.
Αιτία: Κάθε κοντέινερ (pod) στο σύμπλεγμα επεξεργάζεται μόνο ένα μέρος της κίνησης. Εάν αλλάξετε τον κώδικα σε ένα μόνο κοντέινερ (pod), τότε ο κώδικας θα είναι διαφορετικός σε διαφορετικές ομάδες, ο ιστότοπος θα λειτουργεί διαφορετικά και διαφορετικές εκδόσεις του ιστότοπου θα εμφανίζονται σε διαφορετικούς χρήστες. Δεν μπορείς να ζήσεις έτσι.
Τρίτον - πρέπει να λύσετε το πρόβλημα με την ανάπτυξη
Εάν έχουμε έναν μονόλιθο και έναν «κλασικό» διακομιστή, όλα είναι πολύ απλά: αναπτύσσουμε μια νέα βάση κώδικα, μεταφέρουμε τη βάση δεδομένων, αλλάζουμε την κυκλοφορία στη νέα έκδοση του κώδικα. Η εναλλαγή γίνεται αμέσως.
Αν έχουμε ένα site στο Kubernetes, κομμένο σε microservices, υπάρχουν πολλά κοντέινερ με κωδικό - ω. Πρέπει να συλλέξετε κοντέινερ με μια νέα έκδοση του κώδικα, να τα αναπτύξετε αντί για τα παλιά, να μεταφέρετε σωστά τη βάση δεδομένων και ιδανικά να το κάνετε αυτό απαρατήρητο από τους επισκέπτες. Ευτυχώς, η Kubernetes μας βοηθά σε αυτό, υποστηρίζοντας μια ολόκληρη σειρά διαφορετικών τύπων αναπτύξεων.
Τέταρτον - πρέπει να λύσετε το ζήτημα της αποθήκευσης στατικών
Εάν ο ιστότοπός σας είναι «μόνο» 10 gigabyte και τον αναπτύξετε εξ ολοκλήρου σε κοντέινερ, θα καταλήξετε με κοντέινερ 10 gigabyte που χρειάζονται για πάντα για να αναπτυχθούν.
Πρέπει να αποθηκεύσετε τα "βαρύτερα" μέρη του ιστότοπου εκτός κοντέινερ και τίθεται το ερώτημα πώς να το κάνετε σωστά
Τι λείπει από τη λύση μας;
Ολόκληρος ο κωδικός Bitrix δεν χωρίζεται σε μικροσυναρτήσεις/μικροϋπηρεσίες (έτσι ώστε η εγγραφή να είναι ξεχωριστή, η ενότητα του ηλεκτρονικού καταστήματος να είναι ξεχωριστή κ.λπ.). Αποθηκεύουμε ολόκληρη τη βάση του κώδικα σε κάθε δοχείο.
Επίσης, δεν αποθηκεύουμε τη βάση δεδομένων στο Kubernetes (εξακολουθώ να εφαρμόζω λύσεις με βάση δεδομένων στο Kubernetes για περιβάλλοντα ανάπτυξης, αλλά όχι για παραγωγή).
Θα εξακολουθεί να είναι αντιληπτό στους διαχειριστές του ιστότοπου ότι ο ιστότοπος εκτελείται στο Kubernetes. Η λειτουργία «έλεγχος συστήματος» δεν λειτουργεί σωστά· για να επεξεργαστείτε τον κώδικα του ιστότοπου από τον πίνακα διαχείρισης, πρέπει πρώτα να κάνετε κλικ στο κουμπί «Θέλω να επεξεργαστώ τον κώδικα».
Τα προβλήματα έχουν εντοπιστεί, η ανάγκη εφαρμογής μικροϋπηρεσιών έχει προσδιοριστεί, ο στόχος είναι σαφής - να αποκτήσετε ένα λειτουργικό σύστημα για την εκτέλεση εφαρμογών στο Bitrix στο Kubernetes, διατηρώντας τόσο τις δυνατότητες του Bitrix όσο και τα πλεονεκτήματα του Kubernetes. Ας ξεκινήσουμε την υλοποίηση.
Αρχιτεκτονική
Υπάρχουν πολλά "εργαζόμενα" pods με διακομιστή web (εργάτες).
One under με cron tasks (απαιτείται μόνο μία).
Μία αναβάθμιση για την επεξεργασία του κώδικα του ιστότοπου από τον πίνακα διαχείρισης (επίσης απαιτείται μόνο μία).
Λύνουμε ερωτήσεις:
- Πού να αποθηκεύονται οι συνεδρίες;
- Πού να αποθηκεύσετε την κρυφή μνήμη;
- Πού να αποθηκεύσετε στατικά, όχι να τοποθετήσετε gigabyte στατικά σε ένα σωρό δοχεία;
- Πώς θα λειτουργήσει η βάση δεδομένων;
Εικόνα Docker
Ξεκινάμε δημιουργώντας μια εικόνα Docker.
Η ιδανική επιλογή είναι ότι έχουμε μια καθολική εικόνα, στη βάση της λαμβάνουμε ομάδες εργασίας, ομάδες με Crontasks και αναβαθμισμένες ομάδες.
.
Περιλαμβάνει nginx, apache/php-fpm (μπορεί να επιλεγεί κατά την κατασκευή), msmtp για αποστολή αλληλογραφίας και cron.
Κατά τη συναρμολόγηση της εικόνας, ολόκληρη η βάση κώδικα του ιστότοπου αντιγράφεται στον κατάλογο /app (με εξαίρεση τα μέρη εκείνα που θα μετακινήσουμε σε ξεχωριστό κοινόχρηστο χώρο αποθήκευσης).
Μικροϋπηρεσίες, υπηρεσίες
λοβοί εργαζομένων:
- Δοχείο με nginx + κοντέινερ apache/php-fpm + msmtp
- Δεν λειτούργησε να μετακινήσετε το msmtp σε μια ξεχωριστή microservice, η Bitrix αρχίζει να αγανακτεί που δεν μπορεί να στείλει μηνύματα απευθείας
- Κάθε κοντέινερ έχει μια πλήρη βάση κωδικών.
- Απαγόρευση αλλαγής κωδικού σε κοντέινερ.
cron κάτω από:
- δοχείο με apache, php, cron
- περιλαμβάνεται πλήρης βάση κώδικα
- απαγόρευση αλλαγής κωδικού σε κοντέινερ
αναβάθμιση κάτω από:
- nginx container + apache/php-fpm container + msmtp
- Δεν υπάρχει απαγόρευση αλλαγής κωδικού σε κοντέινερ
αποθήκευση συνεδρίας
Αποθήκευση κρυφής μνήμης Bitrix
Ένα άλλο σημαντικό πράγμα: αποθηκεύουμε κωδικούς πρόσβασης για σύνδεση με τα πάντα, από τη βάση δεδομένων μέχρι την αλληλογραφία, στα μυστικά kubernetes. Παίρνουμε ένα μπόνους: οι κωδικοί πρόσβασης είναι ορατοί μόνο σε εκείνους στους οποίους δίνουμε πρόσβαση στα μυστικά και όχι σε όλους όσους έχουν πρόσβαση στη βάση κώδικα του έργου.
Αποθηκευτικός χώρος για στατικά
Μπορείτε να χρησιμοποιήσετε οτιδήποτε: ceph, nfs (αλλά δεν συνιστούμε nfs για παραγωγή), αποθήκευση δικτύου από παρόχους cloud κ.λπ.
Ο χώρος αποθήκευσης θα πρέπει να συνδεθεί σε κοντέινερ με τον κατάλογο /upload/ του ιστότοπου και άλλους καταλόγους με στατικό περιεχόμενο.
Βάση δεδομένων
Για απλότητα, συνιστούμε να μετακινήσετε τη βάση δεδομένων εκτός του Kubernetes. Η βάση στο Kubernetes είναι μια ξεχωριστή σύνθετη εργασία· θα κάνει το σχήμα μια τάξη μεγέθους πιο περίπλοκο.
Αποθήκευση συνεδρίας
Χρησιμοποιούμε memcached :)
Χειρίζεται καλά την αποθήκευση συνεδριών, είναι ομαδοποιημένη και υποστηρίζεται "natively" ως session.save_path στην php. Ένα τέτοιο σύστημα έχει δοκιμαστεί πολλές φορές στην κλασική μονολιθική αρχιτεκτονική, όταν κατασκευάσαμε clusters με μεγάλο αριθμό διακομιστών web. Για την ανάπτυξη χρησιμοποιούμε τιμόνι.
$ helm install stable/memcached --name sessionphp.ini - εδώ η εικόνα περιέχει ρυθμίσεις για την αποθήκευση συνεδριών σε memcached
Χρησιμοποιήσαμε μεταβλητές περιβάλλοντος για να μεταβιβάσουμε δεδομένα σχετικά με κεντρικούς υπολογιστές με memcached .
Αυτό σας επιτρέπει να χρησιμοποιείτε τον ίδιο κώδικα στα περιβάλλοντα dev, stage, test, prod (τα ονόματα κεντρικών υπολογιστών που έχουν ενσωματωθεί σε memcached θα είναι διαφορετικά, επομένως πρέπει να περάσουμε ένα μοναδικό όνομα κεντρικού υπολογιστή για περιόδους σύνδεσης σε κάθε περιβάλλον).
Αποθήκευση κρυφής μνήμης Bitrix
Χρειαζόμαστε αποθηκευτικό χώρο ανεκτικό σε σφάλματα, στον οποίο μπορούν να γράψουν και να διαβάσουν όλα τα pod.
Χρησιμοποιούμε επίσης memcached.
Αυτή η λύση συνιστάται από την ίδια την Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - εδώ στο Bitrix καθορίζεται πού είναι αποθηκευμένη η προσωρινή μνήμη
Χρησιμοποιούμε επίσης μεταβλητές περιβάλλοντος.
Κροντάσκη
Υπάρχουν διαφορετικές προσεγγίσεις για την εκτέλεση του Crontasks στο Kubernetes.
- ξεχωριστή ανάπτυξη με pod για την εκτέλεση του Crontasks
- cronjob για την εκτέλεση crontasks (αν πρόκειται για εφαρμογή ιστού - με wget , ή kubectl exec μέσα σε ένα από τα Worker pod, κ.λπ.)
- και ούτω καθεξής
Μπορείτε να διαφωνήσετε για το πιο σωστό, αλλά σε αυτήν την περίπτωση επιλέξαμε την επιλογή "ξεχωριστή ανάπτυξη με pods για Crontasks"
Πώς γίνεται:
- προσθέστε εργασίες cron μέσω του ConfigMap ή μέσω του αρχείου config/addcron
- σε μια περίπτωση εκκινούμε ένα κοντέινερ πανομοιότυπο με το worker pod + επιτρέπουμε την εκτέλεση εργασιών κορώνας σε αυτό
- χρησιμοποιείται η ίδια βάση κωδικών, χάρη στην ενοποίηση, η συναρμολόγηση του δοχείου είναι απλή
Τι καλό έχουμε:
- έχουμε λειτουργικά Crontasks σε περιβάλλον πανομοιότυπο με το περιβάλλον των προγραμματιστών (docker)
- Τα Crontasks δεν χρειάζεται να "ξαναγραφτούν" για το Kubernetes, λειτουργούν με την ίδια μορφή και την ίδια βάση κώδικα όπως πριν
- Οι εργασίες cron μπορούν να προστεθούν από όλα τα μέλη της ομάδας με δικαιώματα δέσμευσης στον κλάδο παραγωγής, όχι μόνο από διαχειριστές
Southbridge K8SDeploy module και επεξεργασία κώδικα από τον πίνακα διαχείρισης
Μιλούσαμε για αναβάθμιση κάτω;
Πώς να κατευθύνετε την κυκλοφορία εκεί;
Ούρα, γράψαμε μια ενότητα για αυτό στην PHP :) Αυτή είναι μια μικρή κλασική ενότητα για το Bitrix. Δεν είναι ακόμη διαθέσιμο στο κοινό, αλλά σκοπεύουμε να το ανοίξουμε.
Η μονάδα είναι εγκατεστημένη όπως μια κανονική μονάδα στο Bitrix:
Και μοιάζει με αυτό:
Σας επιτρέπει να ορίσετε ένα cookie που προσδιορίζει τον διαχειριστή του ιστότοπου και επιτρέπει στην Kubernetes να στέλνει επισκεψιμότητα στο pod αναβάθμισης.
Όταν ολοκληρωθούν οι αλλαγές, πρέπει να κάνετε κλικ στο git push, οι αλλαγές κώδικα θα σταλούν στο git και, στη συνέχεια, το σύστημα θα δημιουργήσει μια εικόνα με μια νέα έκδοση του κώδικα και θα την "ανοίξει" σε όλο το σύμπλεγμα, αντικαθιστώντας τα παλιά pods .
Ναι, είναι λίγο δεκανίκι, αλλά ταυτόχρονα διατηρούμε την αρχιτεκτονική microservice και δεν αφαιρούμε από τους χρήστες του Bitrix την αγαπημένη τους ευκαιρία να διορθώσουν τον κώδικα από τον πίνακα διαχείρισης. Τελικά, αυτή είναι μια επιλογή· μπορείτε να λύσετε το πρόβλημα της επεξεργασίας του κώδικα με διαφορετικό τρόπο.
Διάγραμμα τιμόνι
Για τη δημιουργία εφαρμογών στο Kubernetes, χρησιμοποιούμε συνήθως τον διαχειριστή πακέτων Helm.
Για τη λύση Bitrix στο Kubernetes, ο Sergey Bondarev, ο κορυφαίος διαχειριστής συστήματος, έγραψε ένα ειδικό διάγραμμα Helm.
Δημιουργεί worker, ugrade, cron pods, διαμορφώνει εισόδους, υπηρεσίες και μεταφέρει μεταβλητές από τα μυστικά Kubernetes σε pods.
Αποθηκεύουμε τον κώδικα στο Gitlab και εκτελούμε επίσης το Helm build από το Gitlab.
Εν ολίγοις, μοιάζει με αυτό
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionΤο Helm σάς επιτρέπει επίσης να κάνετε μια "αδιάλειπτη" επαναφορά αν ξαφνικά κάτι πάει στραβά κατά την ανάπτυξη. Είναι ωραίο όταν δεν είσαι σε πανικό "διορθώνεις τον κώδικα μέσω ftp επειδή έπεσε το prod", αλλά η Kubernetes το κάνει αυτόματα και χωρίς χρόνο διακοπής λειτουργίας.
Αναπτύσσω
Ναι, είμαστε θαυμαστές του Gitlab & Gitlab CI, το χρησιμοποιούμε :)
Κατά τη δέσμευση στο Gitlab στο αποθετήριο του έργου, το Gitlab ξεκινά μια διοχέτευση που αναπτύσσει μια νέα έκδοση του περιβάλλοντος.
Στάδια:
- build (δημιουργία νέας εικόνας Docker)
- δοκιμή (δοκιμή)
- καθαρισμός (κατάργηση του περιβάλλοντος δοκιμής)
- push (το στέλνουμε στο μητρώο Docker)
- αναπτύξτε (αναπτύξουμε την εφαρμογή στο Kubernetes μέσω Helm).
Ούρα, είναι έτοιμο, ας το εφαρμόσουμε!
Λοιπόν, ή κάντε ερωτήσεις εάν υπάρχουν.
Τι κάναμε λοιπόν
Από τεχνικής άποψης:
- ελλιμενισμένο Bitrix?
- "κόψτε" το Bitrix σε δοχεία, καθένα από τα οποία εκτελεί ελάχιστες λειτουργίες.
- επιτεύχθηκε κατάσταση ανιθαγένειας των εμπορευματοκιβωτίων·
- έλυσε το πρόβλημα με την ενημέρωση του Bitrix στο Kubernetes.
- όλες οι λειτουργίες Bitrix συνέχισαν να λειτουργούν (σχεδόν όλες).
- Δουλέψαμε για την ανάπτυξη στο Kubernetes και την επαναφορά μεταξύ των εκδόσεων.
Από επιχειρηματική άποψη:
- ανοχή σε σφάλματα;
- Εργαλεία Kubernetes (εύκολη ενσωμάτωση με το Gitlab CI, απρόσκοπτη ανάπτυξη κ.λπ.)
- μυστικούς κωδικούς πρόσβασης (ορατοί μόνο σε όσους έχουν απευθείας πρόσβαση στους κωδικούς πρόσβασης)·
- Είναι βολικό να δημιουργείτε πρόσθετα περιβάλλοντα (για ανάπτυξη, δοκιμές κ.λπ.) μέσα σε μια ενιαία υποδομή.
Πηγή: www.habr.com