Αναπτύξαμε το DevOps όσο καλύτερα μπορούσαμε. Ήμασταν 8 άτομα και ο Βάσια ήταν ο πιο κουλ στα Windows. Ξαφνικά ο Βάσια έφυγε και είχα το καθήκον να ξεκινήσω ένα νέο έργο που προμηθεύτηκε από την ανάπτυξη των Windows. Όταν πέταξα ολόκληρη τη στοίβα ανάπτυξης των Windows στο τραπέζι, συνειδητοποίησα ότι η κατάσταση ήταν οδυνηρή...
Έτσι ξεκινάει η ιστορία Αλεξάντρα Σιντσίνοβα επί . Όταν ο κορυφαίος ειδικός των Windows έφυγε από την εταιρεία, ο Αλέξανδρος αναρωτήθηκε τι να κάνει τώρα. Μετάβαση σε Linux, φυσικά! Ο Alexander θα σας πει πώς κατάφερε να δημιουργήσει ένα προηγούμενο και να μεταφέρει μέρος της ανάπτυξης των Windows στο Linux χρησιμοποιώντας το παράδειγμα ενός ολοκληρωμένου έργου για 100 τελικούς χρήστες.
Πώς να παραδώσετε εύκολα και αβίαστα ένα έργο στο RPM χρησιμοποιώντας πυρήνα TFS, Puppet, Linux .NET; Πώς να υποστηρίξετε την έκδοση μιας βάσης δεδομένων έργου εάν η ομάδα ανάπτυξης ακούσει τις λέξεις Postgres και Flyway για πρώτη φορά και η προθεσμία είναι μεθαύριο; Πώς να ενσωματωθεί με το Docker; Πώς να παρακινήσετε τους προγραμματιστές .NET να εγκαταλείψουν τα Windows και τα smoothies υπέρ του Puppet και του Linux; Πώς να επιλύσετε ιδεολογικές συγκρούσεις εάν δεν υπάρχει ούτε η δύναμη, ούτε η επιθυμία, ούτε οι πόροι για τη διατήρηση των Windows στην παραγωγή; Σχετικά με αυτό, καθώς και για το Web Deploy, τις δοκιμές, το CI, τις πρακτικές χρήσης TFS σε υπάρχοντα έργα και, φυσικά, σχετικά με τα σπασμένα δεκανίκια και τις λύσεις εργασίας, στη μεταγραφή της αναφοράς του Alexander.
Έτσι, ο Vasya έφυγε, το έργο είναι σε μένα, οι προγραμματιστές περιμένουν ανυπόμονα με πιρούνια. Όταν τελικά συνειδητοποίησα ότι η Vasya δεν μπορούσε να επιστραφεί, άρχισα να ασχολούμαι. Αρχικά, αξιολόγησα το ποσοστό των Win VM στον στόλο μας. Το σκορ δεν ήταν υπέρ των Windows.
Δεδομένου ότι αναπτύσσουμε ενεργά DevOps, συνειδητοποίησα ότι κάτι πρέπει να αλλάξει στην προσέγγιση για την παράδοση μιας νέας εφαρμογής. Υπήρχε μόνο μία λύση - αν είναι δυνατόν, μεταφέρετε τα πάντα στο Linux. Η Google με βοήθησε - εκείνη την εποχή το .Net είχε ήδη μεταφερθεί στο Linux και συνειδητοποίησα ότι αυτή ήταν η λύση!
Γιατί .NET core σε συνδυασμό με Linux;
Υπήρχαν αρκετοί λόγοι για αυτό. Ανάμεσα στο «πληρώνω χρήματα» και «δεν πληρώνω», η πλειοψηφία θα επιλέξει το δεύτερο - όπως εγώ. Μια άδεια για MSDB κοστίζει περίπου 1 $· η διατήρηση ενός στόλου εικονικών μηχανών Windows κοστίζει εκατοντάδες δολάρια. Για μια μεγάλη εταιρεία αυτό είναι μεγάλο κόστος. Να γιατί οικονομίες - πρώτος λόγος. Όχι το πιο σημαντικό, αλλά ένα από τα σημαντικότερα.
Οι εικονικές μηχανές των Windows καταλαμβάνουν περισσότερους πόρους από τους αδερφούς τους Linux - είναι βαριά. Δεδομένης της κλίμακας της μεγάλης εταιρείας, επιλέξαμε το Linux.
Το σύστημα είναι απλώς ενσωματωμένο στο υπάρχον CI. Θεωρούμε τους εαυτούς μας προοδευτικούς DevOps, χρησιμοποιούμε Bamboo, Jenkins και GitLab CI, επομένως το μεγαλύτερο μέρος της δουλειάς μας εκτελείται σε Linux.
Ο τελευταίος λόγος είναι βολικό συνοδευτικό. Χρειαζόμασταν να χαμηλώσουμε το εμπόδιο εισόδου για τους "συνοδούς" - τα παιδιά που κατανοούν το τεχνικό μέρος, εξασφαλίζουν αδιάλειπτη εξυπηρέτηση και διατηρούν τις υπηρεσίες από τη δεύτερη γραμμή. Ήταν ήδη εξοικειωμένοι με τη στοίβα Linux, επομένως τους είναι πολύ πιο εύκολο να κατανοήσουν, να υποστηρίξουν και να διατηρήσουν ένα νέο προϊόν παρά να ξοδέψουν πρόσθετους πόρους για να κατανοήσουν την ίδια λειτουργικότητα λογισμικού για την πλατφόρμα Windows.
Απαιτήσεις
Πρώτο και κύριο - ευκολία της νέας λύσης για προγραμματιστές. Δεν ήταν όλοι έτοιμοι για αλλαγή, ειδικά μετά την εκφώνηση της λέξης Linux. Οι προγραμματιστές θέλουν το αγαπημένο τους Visual Studio, το TFS με αυτόματες δοκιμές για συναρμολογήσεις και smoothies. Το πώς γίνεται η παράδοση στην παραγωγή δεν είναι σημαντικό για αυτούς. Ως εκ τούτου, αποφασίσαμε να μην αλλάξουμε τη συνήθη διαδικασία και να αφήσουμε τα πάντα αμετάβλητα για την ανάπτυξη των Windows.
Χρειάζεται νέο έργο ενσωμάτωση στο υπάρχον CI. Οι ράγες ήταν ήδη εκεί και όλη η δουλειά έπρεπε να γίνει λαμβάνοντας υπόψη τις παραμέτρους του συστήματος διαχείρισης διαμόρφωσης, τα αποδεκτά πρότυπα παράδοσης και τα συστήματα παρακολούθησης.
Ευκολία υποστήριξης και λειτουργίας, ως προϋπόθεση για το ελάχιστο όριο εισόδου για όλους τους νέους συμμετέχοντες από διαφορετικά τμήματα και το τμήμα υποστήριξης.
Προθεσμία - χθες.
Win Development Group
Με τι συνεργαζόταν τότε η ομάδα των Windows;
Τώρα μπορώ να το πω με σιγουριά IdentityServer4 είναι μια δροσερή δωρεάν εναλλακτική του ADFS με παρόμοιες δυνατότητες ή κάτι τέτοιο Πυρήνας πλαισίου οντοτήτων - ένας παράδεισος για έναν προγραμματιστή, όπου δεν χρειάζεται να μπείτε στον κόπο να γράψετε σενάρια SQL, αλλά να περιγράφετε ερωτήματα στη βάση δεδομένων με όρους OOP. Στη συνέχεια, όμως, κατά τη συζήτηση του σχεδίου δράσης, κοίταξα αυτή τη στοίβα σαν να ήταν σφηνοειδής γραφή των Σουμερίων, αναγνωρίζοντας μόνο τα PostgreSQL και Git.
Εκείνη την εποχή χρησιμοποιούσαμε ενεργά μαριονέτα ως σύστημα διαχείρισης διαμόρφωσης. Στα περισσότερα έργα μας χρησιμοποιήσαμε GitLab CI, Ελαστικό, ισορροπημένη χρήση υπηρεσιών υψηλού φορτίου HAProxy παρακολουθούσε τα πάντα με Zabbix, συνδέσμους Γκράφανα и Προμηθέας, Jaeger, και όλο αυτό στριφογύριζε πάνω σε κομμάτια σιδήρου HP c ESXi επί VMware. Όλοι το ξέρουν - ένα κλασικό του είδους.
Ας δούμε και ας προσπαθήσουμε να καταλάβουμε τι συνέβη πριν ξεκινήσουμε όλες αυτές τις παρεμβάσεις.
Τι συνέβη
Το TFS είναι ένα αρκετά ισχυρό σύστημα που όχι μόνο παραδίδει κώδικα από τον προγραμματιστή στην τελική μηχανή παραγωγής, αλλά διαθέτει επίσης ένα σύνολο για πολύ ευέλικτη ενοποίηση με διάφορες υπηρεσίες - για παροχή CI σε επίπεδο πολλαπλών πλατφορμών.
Προηγουμένως, αυτά ήταν συμπαγή παράθυρα. Το TFS χρησιμοποίησε αρκετούς πράκτορες Build, οι οποίοι χρησιμοποιήθηκαν για τη συναρμολόγηση πολλών έργων. Κάθε πράκτορας έχει 3-4 εργαζόμενους για να παραλληλίσει τις εργασίες και να βελτιστοποιήσει τη διαδικασία. Στη συνέχεια, σύμφωνα με τα σχέδια κυκλοφορίας, η TFS παρέδωσε το φρεσκοψημένο Build στον διακομιστή εφαρμογών των Windows.
Τι θέλαμε να πετύχουμε;
Χρησιμοποιούμε το TFS για παράδοση και ανάπτυξη και εκτελούμε την εφαρμογή σε διακομιστή εφαρμογών Linux και υπάρχει κάποιο είδος μαγείας μεταξύ τους. Αυτό Magic Box και υπάρχει το αλάτι της δουλειάς μπροστά. Πριν το αποσυναρμολογήσω, θα κάνω ένα βήμα στην άκρη και θα πω λίγα λόγια για την εφαρμογή.
Σχέδιο
Η εφαρμογή παρέχει λειτουργικότητα για το χειρισμό προπληρωμένων καρτών.
Πελάτης
Υπήρχαν δύο τύποι χρηστών. Πρώτα απέκτησε πρόσβαση μέσω σύνδεσης χρησιμοποιώντας ένα πιστοποιητικό SSL SHA-2. U το δεύτερο υπήρχε πρόσβαση με χρήση σύνδεσης και κωδικού πρόσβασης.
HAProxy
Στη συνέχεια, το αίτημα πελάτη πήγε στο HAProxy, το οποίο έλυσε τα ακόλουθα προβλήματα:
- πρωτογενής εξουσιοδότηση·
- Τερματισμός SSL.
- συντονισμός αιτημάτων HTTP.
- αιτήματα εκπομπής.
Το πιστοποιητικό πελάτη επαληθεύτηκε κατά μήκος της αλυσίδας. Εμείς - εξουσία και μπορούμε να το αντέξουμε οικονομικά, αφού οι ίδιοι εκδίδουμε πιστοποιητικά σε πελάτες εξυπηρέτησης.
Προσοχή στο τρίτο σημείο, θα επανέλθουμε λίγο αργότερα.
Backend
Σχεδίαζαν να κάνουν το backend στο Linux. Το backend αλληλεπιδρά με τη βάση δεδομένων, φορτώνει την απαραίτητη λίστα προνομίων και στη συνέχεια, ανάλογα με τα δικαιώματα που έχει ο εξουσιοδοτημένος χρήστης, παρέχει πρόσβαση για να υπογράψει οικονομικά έγγραφα και να τα στείλει για εκτέλεση ή να δημιουργήσει κάποιο είδος αναφοράς.
Εξοικονόμηση με HAProxy
Εκτός από τα δύο περιβάλλοντα στα οποία περιηγήθηκε κάθε πελάτης, υπήρχε επίσης ένα πλαίσιο ταυτότητας. IdentityServer4 απλά σας επιτρέπει να συνδεθείτε, αυτό είναι ένα δωρεάν και ισχυρό ανάλογο ADFS - Υπηρεσίες ομοσπονδιών υπηρεσίας καταλόγου Active Directory.
Το αίτημα ταυτότητας υποβλήθηκε σε επεξεργασία σε διάφορα βήματα. Το πρώτο βήμα - πελάτης μπήκε στο backend, το οποίο επικοινωνούσε με αυτόν τον διακομιστή και έλεγξε την παρουσία ενός διακριτικού για τον πελάτη. Εάν δεν βρέθηκε, το αίτημα επέστρεφε πίσω στο περιβάλλον από το οποίο προήλθε, αλλά με ανακατεύθυνση και με την ανακατεύθυνση πήγε στην ταυτότητα.
Δεύτερο βήμα - το αίτημα ελήφθη στη σελίδα εξουσιοδότησης στον IdentityServer, όπου ο πελάτης εγγράφηκε και αυτό το πολυαναμενόμενο διακριτικό εμφανίστηκε στη βάση δεδομένων IdentityServer.
Τρίτο βήμα - ο πελάτης ανακατευθύνθηκε πίσω στο πλαίσιο από το οποίο προήλθε.
Το IdentityServer4 έχει μια δυνατότητα: επιστρέφει την απάντηση στο αίτημα επιστροφής μέσω HTTP. Ανεξάρτητα από το πόσο δυσκολευτήκαμε με τη ρύθμιση του διακομιστή, ανεξάρτητα από το πόσο διαφωτιστήκαμε με την τεκμηρίωση, κάθε φορά λαμβάναμε ένα αρχικό αίτημα πελάτη με μια διεύθυνση URL που προερχόταν μέσω HTTPS και ο IdentityServer επέστρεφε το ίδιο πλαίσιο, αλλά με HTTP. Σοκαριστήκαμε! Και όλα αυτά τα μεταφέραμε μέσω του πλαισίου ταυτότητας στο HAProxy και στις κεφαλίδες έπρεπε να τροποποιήσουμε το πρωτόκολλο HTTP σε HTTPS.
Ποια είναι η βελτίωση και πού εξοικονομήσατε;
Εξοικονομήσαμε χρήματα χρησιμοποιώντας μια δωρεάν λύση για την εξουσιοδότηση μιας ομάδας χρηστών, πόρων, καθώς δεν τοποθετήσαμε το IdentityServer4 ως ξεχωριστό κόμβο σε ξεχωριστό τμήμα, αλλά το χρησιμοποιήσαμε μαζί με το backend στον ίδιο διακομιστή όπου εκτελείται το backend της εφαρμογής .
Πώς πρέπει να λειτουργεί
Έτσι, όπως υποσχέθηκα - Magic Box. Καταλαβαίνουμε ήδη ότι είναι εγγυημένο ότι θα προχωρήσουμε προς το Linux. Ας διαμορφώσουμε συγκεκριμένες εργασίες που απαιτούσαν λύσεις.
Εκδηλώσεις μαριονέτας. Για την παράδοση και τη διαχείριση της διαμόρφωσης υπηρεσιών και εφαρμογών, έπρεπε να γραφτούν ωραίες συνταγές. Ένα ρολό μολύβι δείχνει εύγλωττα πόσο γρήγορα και αποτελεσματικά έγινε.
Τρόπος παράδοσης. Το πρότυπο είναι RPM. Όλοι καταλαβαίνουν ότι στο Linux δεν μπορείτε να το κάνετε χωρίς αυτό, αλλά το ίδιο το έργο, μετά τη συναρμολόγηση, ήταν ένα σύνολο εκτελέσιμων αρχείων DLL. Ήταν περίπου 150, το έργο ήταν αρκετά δύσκολο. Η μόνη αρμονική λύση είναι να συσκευάσετε αυτό το δυαδικό σε RPM και να αναπτύξετε την εφαρμογή από αυτό.
Εκδόσεις. Έπρεπε να κυκλοφορούμε πολύ συχνά και έπρεπε να αποφασίσουμε πώς να σχηματίσουμε το όνομα του πακέτου. Αυτό είναι ένα ζήτημα του επιπέδου ενοποίησης με το TFS. Είχαμε έναν build agent στο Linux. Όταν το TFS στέλνει μια εργασία σε έναν χειριστή - εργαζόμενο - στον παράγοντα Build, του μεταβιβάζει επίσης μια δέσμη μεταβλητών που καταλήγουν στο περιβάλλον της διαδικασίας χειριστή. Αυτές οι μεταβλητές περιβάλλοντος περιέχουν το όνομα δόμησης, το όνομα έκδοσης και άλλες μεταβλητές. Διαβάστε περισσότερα σχετικά με αυτό στην ενότητα «Δημιουργία πακέτου RPM».
Ρύθμιση TFS κατέληξε στη δημιουργία Pipeline. Προηγουμένως, συλλέγαμε όλα τα έργα των Windows σε πράκτορες Windows, αλλά τώρα εμφανίζεται ένας παράγοντας Linux - ένας παράγοντας Build, ο οποίος πρέπει να συμπεριληφθεί στην ομάδα κατασκευής, να εμπλουτιστεί με ορισμένα τεχνουργήματα και να πει τι είδους έργα θα κατασκευαστούν σε αυτόν τον παράγοντα Build , και να τροποποιήσετε με κάποιο τρόπο το Pipeline.
IdentityServer. Το ADFS δεν είναι ο δρόμος μας, πηγαίνουμε για Ανοιχτό Κώδικα.
Ας περάσουμε από τα εξαρτήματα.
Magic Box
Αποτελείται από τέσσερα μέρη.
Πράκτορας Linux Build. Linux, γιατί χτίζουμε για αυτό - είναι λογικό. Αυτό το μέρος έγινε σε τρία βήματα.
- Διαμόρφωση εργαζομένων και όχι μόνος, αφού αναμενόταν κατανεμημένες εργασίες για το έργο.
- Εγκαταστήστε το .NET Core 1.x. Γιατί 1.x όταν το 2.0 είναι ήδη διαθέσιμο στο τυπικό αποθετήριο; Γιατί όταν ξεκινήσαμε την ανάπτυξη, η σταθερή έκδοση ήταν 1.09 και αποφασίστηκε να γίνει το έργο με βάση αυτό.
- Git 2.x.
RPM-αποθήκη. Τα πακέτα RPM έπρεπε να αποθηκευτούν κάπου. Θεωρήθηκε ότι θα χρησιμοποιούσαμε το ίδιο εταιρικό αποθετήριο RPM που είναι διαθέσιμο σε όλους τους κεντρικούς υπολογιστές Linux. Αυτό έκαναν. Ο διακομιστής αποθετηρίου έχει ρυθμιστεί γάντζος ιστού που κατέβασε το απαιτούμενο πακέτο RPM από την καθορισμένη τοποθεσία. Η έκδοση του πακέτου αναφέρθηκε στο webhook από τον παράγοντα Build.
GitLab. Προσοχή! Το GitLab εδώ χρησιμοποιείται όχι από προγραμματιστές, αλλά από το τμήμα λειτουργιών για τον έλεγχο των εκδόσεων εφαρμογών, των εκδόσεων πακέτων, την παρακολούθηση της κατάστασης όλων των μηχανών Linux και αποθηκεύει τη συνταγή - όλα τα μανιφέστα Puppet.
μαριονέτα — επιλύει όλα τα αμφιλεγόμενα ζητήματα και παρέχει ακριβώς τη διαμόρφωση που θέλουμε από το Gitlab.
Αρχίζουμε να βουτάμε. Πώς λειτουργεί η παράδοση DLL σε RPM;
Παράδοση DDL σε RPM
Ας πούμε ότι έχουμε έναν ροκ σταρ ανάπτυξης .NET. Χρησιμοποιεί το Visual Studio και δημιουργεί έναν κλάδο κυκλοφορίας. Μετά από αυτό, το ανεβάζει στο Git και το Git εδώ είναι μια οντότητα TFS, δηλαδή είναι το αποθετήριο εφαρμογών με το οποίο συνεργάζεται ο προγραμματιστής.
Μετά από αυτό το TFS βλέπει ότι έχει φτάσει μια νέα δέσμευση. Ποια εφαρμογή; Στις ρυθμίσεις TFS υπάρχει μια ετικέτα που υποδεικνύει τους πόρους που διαθέτει ένας συγκεκριμένος παράγοντας Build. Σε αυτήν την περίπτωση, βλέπει ότι χτίζουμε ένα έργο .NET Core και επιλέγει έναν παράγοντα Linux Build από το pool.
Ο παράγοντας Build λαμβάνει τις πηγές και πραγματοποιεί λήψη των απαραίτητων εξαρτήσεις από το αποθετήριο .NET, npm, κ.λπ. και μετά την κατασκευή της ίδιας της εφαρμογής και την επακόλουθη συσκευασία, στέλνει το πακέτο RPM στο αποθετήριο RPM.
Από την άλλη, συμβαίνει το εξής. Ο μηχανικός του τμήματος επιχειρήσεων εμπλέκεται άμεσα στην ανάπτυξη του έργου: αλλάζει τις εκδόσεις των πακέτων Ιερά στο αποθετήριο όπου είναι αποθηκευμένη η συνταγή της εφαρμογής, μετά την οποία ενεργοποιείται το Puppet yum, ανακτά το νέο πακέτο από το αποθετήριο και η νέα έκδοση της εφαρμογής είναι έτοιμη για χρήση.
Όλα είναι απλά στα λόγια, αλλά τι συμβαίνει μέσα στον ίδιο τον πράκτορα Build;
Συσκευασία DLL RPM
Λήψη πηγών έργου και δημιουργίας εργασιών από το TFS. Πράκτορας κατασκευής ξεκινά την κατασκευή του ίδιου του έργου από πηγές. Το συναρμολογημένο έργο είναι διαθέσιμο ως σετ αρχεία DLL, τα οποία είναι συσκευασμένα σε αρχείο zip για μείωση του φόρτου στο σύστημα αρχείων.
Το αρχείο ZIP πετιέται στον κατάλογο δημιουργίας πακέτου RPM. Στη συνέχεια, το σενάριο Bash προετοιμάζει τις μεταβλητές περιβάλλοντος, βρίσκει την έκδοση Build, την έκδοση του έργου, τη διαδρομή προς τον κατάλογο κατασκευής και εκτελεί το RPM-build. Μόλις ολοκληρωθεί η κατασκευή, το πακέτο δημοσιεύεται στο τοπικό αποθετήριο, το οποίο βρίσκεται στον παράγοντα Build.
Στη συνέχεια, από τον παράγοντα Build στον διακομιστή στο αποθετήριο RPM Το αίτημα JSON αποστέλλεται αναφέροντας το όνομα της έκδοσης και της κατασκευής. Το Webhook, για το οποίο μίλησα νωρίτερα, κατεβάζει αυτό το πακέτο από το τοπικό αποθετήριο του Build agent και κάνει τη νέα διάταξη διαθέσιμη για εγκατάσταση.
Γιατί αυτό το συγκεκριμένο πρόγραμμα παράδοσης πακέτου στο αποθετήριο RPM; Γιατί δεν μπορώ να στείλω αμέσως το συναρμολογημένο πακέτο στο αποθετήριο; Γεγονός είναι ότι αυτό αποτελεί προϋπόθεση για την εξασφάλιση της ασφάλειας. Αυτό το σενάριο περιορίζει την πιθανότητα μη εξουσιοδοτημένων ατόμων να ανεβάζουν πακέτα RPM σε έναν διακομιστή που είναι προσβάσιμος σε όλα τα μηχανήματα Linux.
Εκδόσεις βάσης δεδομένων
Σε μια διαβούλευση με την ομάδα ανάπτυξης, αποδείχθηκε ότι τα παιδιά ήταν πιο κοντά στο MS SQL, αλλά στα περισσότερα έργα που δεν ήταν Windows χρησιμοποιούσαμε ήδη την PostgreSQL με όλη τους τη δύναμη. Δεδομένου ότι είχαμε ήδη αποφασίσει να εγκαταλείψουμε οτιδήποτε πληρώνεται, αρχίσαμε να χρησιμοποιούμε την PostgreSQL και εδώ.
Σε αυτό το μέρος θέλω να σας πω πώς διαμορφώσαμε την έκδοση της βάσης δεδομένων και πώς επιλέξαμε μεταξύ Flyway και Entity Framework Core. Ας δούμε τα υπέρ και τα κατά τους.
Μειονεκτήματα
Το Flyway πηγαίνει μόνο με έναν τρόπο, εμείς δεν μπορούμε να κάνουμε πίσω - αυτό είναι ένα σημαντικό μειονέκτημα. Μπορείτε να το συγκρίνετε με το Entity Framework Core με άλλους τρόπους - όσον αφορά την ευκολία των προγραμματιστών. Θυμάστε ότι το βάλαμε αυτό στην πρώτη γραμμή και το βασικό κριτήριο ήταν να μην αλλάξει τίποτα για την ανάπτυξη των Windows.
Για το Flyway us χρειαζόταν κάποιο είδος περιτυλίγματοςγια να μην γράφουν τα παιδιά Ερωτήματα SQL. Είναι πολύ πιο κοντά στη λειτουργία με όρους OOP. Γράψαμε οδηγίες για την εργασία με αντικείμενα βάσης δεδομένων, δημιουργήσαμε ένα ερώτημα SQL και το εκτελέσαμε. Η νέα έκδοση της βάσης δεδομένων είναι έτοιμη, δοκιμασμένη - όλα είναι καλά, όλα λειτουργούν.
Το Entity Framework Core έχει ένα μείον - κάτω από μεγάλα φορτία δημιουργεί μη βέλτιστα ερωτήματα SQL, και η μείωση στη βάση δεδομένων μπορεί να είναι σημαντική. Επειδή όμως δεν έχουμε υπηρεσία υψηλού φορτίου, δεν υπολογίζουμε το φορτίο σε εκατοντάδες RPS, αποδεχθήκαμε αυτούς τους κινδύνους και αναθέσαμε το πρόβλημα σε εμάς.
Πλεονεκτήματα
Πυρήνας πλαισίου οντοτήτων λειτουργεί εκτός συσκευασίας και είναι εύκολο να αναπτυχθείκαι Flyway Ενσωματώνεται εύκολα στο υπάρχον CI. Αλλά το κάνουμε βολικό για τους προγραμματιστές :)
Διαδικασία συνάθροισης
Ο Puppet βλέπει ότι έρχεται μια αλλαγή στην έκδοση πακέτου, συμπεριλαμβανομένης αυτής που είναι υπεύθυνη για τη μετεγκατάσταση. Αρχικά, εγκαθιστά ένα πακέτο που περιέχει σενάρια μετεγκατάστασης και λειτουργικότητα που σχετίζεται με τη βάση δεδομένων. Μετά από αυτό, η εφαρμογή που λειτουργεί με τη βάση δεδομένων επανεκκινείται. Ακολουθεί η εγκατάσταση των υπόλοιπων εξαρτημάτων. Η σειρά με την οποία εγκαθίστανται τα πακέτα και εκκινούνται οι εφαρμογές περιγράφεται στο μανιφέστο Puppet.
Οι εφαρμογές χρησιμοποιούν ευαίσθητα δεδομένα, όπως μάρκες, κωδικούς πρόσβασης βάσης δεδομένων, όλα αυτά έλκονται στη διαμόρφωση από το Puppet master, όπου αποθηκεύονται σε κρυπτογραφημένη μορφή.
Προβλήματα TFS
Αφού αποφασίσαμε και συνειδητοποιήσαμε ότι όλα λειτουργούσαν πραγματικά για εμάς, αποφάσισα να κοιτάξω τι συνέβαινε με τις συναρμολογήσεις στο TFS στο σύνολό του για το τμήμα ανάπτυξης Win σε άλλα έργα - είτε κατασκευάζαμε/κυκλοφορούσαμε γρήγορα είτε όχι, και ανακάλυψε σημαντικά προβλήματα με την ταχύτητα.
Ένα από τα κύρια έργα χρειάζεται 12-15 λεπτά για να συναρμολογηθεί - είναι πολύς χρόνος, δεν μπορείτε να ζήσετε έτσι. Μια γρήγορη ανάλυση έδειξε μια τρομερή μείωση στο I/O, και αυτό ήταν σε πίνακες.
Αφού το ανέλυσα συστατικό προς συστατικό, εντόπισα τρεις εστίες. Πρώτα - "Kaspersky Antivirus", το οποίο σαρώνει πηγές σε όλους τους πράκτορες Windows Build. Δεύτερο - Windows Ευρετήριο. Δεν απενεργοποιήθηκε και όλα καταχωρήθηκαν σε πραγματικό χρόνο στους πράκτορες Build κατά τη διάρκεια της διαδικασίας ανάπτυξης.
Τρίτο - Npm εγκατάσταση. Αποδείχθηκε ότι στους περισσότερους αγωγούς χρησιμοποιήσαμε αυτό ακριβώς το σενάριο. Γιατί είναι κακός; Η διαδικασία εγκατάστασης Npm εκτελείται όταν σχηματίζεται το δέντρο εξάρτησης pack-lock.json, όπου καταγράφονται οι εκδόσεις των πακέτων που θα χρησιμοποιηθούν για την κατασκευή του έργου. Το μειονέκτημα είναι ότι η εγκατάσταση Npm ανασύρει τις πιο πρόσφατες εκδόσεις πακέτων από το Διαδίκτυο κάθε φορά, και αυτό απαιτεί πολύ χρόνο στην περίπτωση ενός μεγάλου έργου.
Οι προγραμματιστές μερικές φορές πειραματίζονται σε ένα τοπικό μηχάνημα για να δοκιμάσουν πώς λειτουργεί ένα συγκεκριμένο μέρος ή ολόκληρο το έργο. Μερικές φορές αποδεικνύεται ότι όλα ήταν δροσερά τοπικά, αλλά το συναρμολόγησαν, το ξεδίπλωσαν και τίποτα δεν λειτούργησε. Αρχίζουμε να καταλαβαίνουμε ποιο είναι το πρόβλημα - ναι, διαφορετικές εκδόσεις πακέτων με εξαρτήσεις.
Λύση
- Πηγές σε εξαιρέσεις AV.
- Απενεργοποιήστε την ευρετηρίαση.
- Παω σε npm ci.
Τα πλεονεκτήματα του npm ci είναι ότι εμείς Συλλέγουμε το δέντρο εξάρτησης μία φορά, και έχουμε την ευκαιρία να παρέχουμε στον προγραμματιστή τρέχουσα λίστα πακέτων, με το οποίο μπορεί να πειραματιστεί τοπικά όσο του αρέσει. Αυτό κερδίζει χρόνο προγραμματιστές που γράφουν κώδικα.
Διαμόρφωση
Τώρα λίγα για τη διαμόρφωση του αποθετηρίου. Ιστορικά χρησιμοποιούμε Nexus για τη διαχείριση αποθετηρίων, συμπεριλαμβανομένων Εσωτερική REPO. Αυτό το εσωτερικό αποθετήριο περιέχει όλα τα στοιχεία που χρησιμοποιούμε για εσωτερικούς σκοπούς, για παράδειγμα, αυτογραφική παρακολούθηση.
Χρησιμοποιούμε επίσης NuGet, καθώς έχει καλύτερη προσωρινή αποθήκευση σε σύγκριση με άλλους διαχειριστές πακέτων.
Αποτέλεσμα
Αφού βελτιστοποιήσαμε τους Build Agents, ο μέσος χρόνος κατασκευής μειώθηκε από 12 λεπτά σε 7.
Αν μετρήσουμε όλα τα μηχανήματα που θα μπορούσαμε να χρησιμοποιήσουμε για Windows, αλλά αλλάξαμε σε Linux σε αυτό το έργο, εξοικονομήσαμε περίπου 10 $. Και αυτό αφορά μόνο τις άδειες χρήσης και περισσότερα αν λάβουμε υπόψη το περιεχόμενο.
Σχέδια
Για το επόμενο τρίμηνο, σχεδιάζαμε να εργαστούμε για τη βελτιστοποίηση της παράδοσης κώδικα.
Μετάβαση σε μια προκατασκευασμένη εικόνα Docker. Το TFS είναι ένα ωραίο πράγμα με πολλές προσθήκες που σας επιτρέπουν να ενσωματωθείτε στο Pipeline, συμπεριλαμβανομένης της συναρμολόγησης βασισμένης σε έναυσμα, για παράδειγμα, μιας εικόνας Docker. Θέλουμε να κάνουμε αυτό το έναυσμα για το ίδιο pack-lock.json. Εάν η σύνθεση των στοιχείων που χρησιμοποιούνται για τη δημιουργία του έργου αλλάξει με κάποιο τρόπο, δημιουργούμε μια νέα εικόνα Docker. Αργότερα χρησιμοποιείται για την ανάπτυξη του κοντέινερ με τη συναρμολογημένη εφαρμογή. Αυτό δεν συμβαίνει τώρα, αλλά σχεδιάζουμε να στραφούμε σε μια αρχιτεκτονική microservice στο Kubernetes, η οποία αναπτύσσεται ενεργά στην εταιρεία μας και εξυπηρετεί λύσεις παραγωγής εδώ και πολύ καιρό.
Περίληψη
Προτρέπω όλους να πετάξουν τα Windows, αλλά δεν είναι επειδή δεν ξέρω πώς να τα μαγειρέψω. Ο λόγος είναι ότι οι περισσότερες λύσεις ανοιχτού κώδικα είναι Στοίβα Linux. είσαι καλά εξοικονόμηση πόρων. Κατά τη γνώμη μου, το μέλλον ανήκει στις λύσεις ανοιχτού κώδικα στο Linux με μια ισχυρή κοινότητα.
Προφίλ ομιλητή του Alexander Sinchinov .
είναι ένα συνέδριο για την ενοποίηση των διαδικασιών ανάπτυξης, δοκιμών και λειτουργίας για επαγγελματίες από επαγγελματίες. Γι' αυτό το έργο για το οποίο μίλησε ο Αλέξανδρος; υλοποιήθηκε και λειτουργεί, και την ημέρα της παράστασης υπήρξαν δύο επιτυχημένες εκδόσεις. Επί Στις 27 και 28 Μαΐου θα υπάρξουν ακόμη περισσότερα παρόμοια κρούσματα από ασκούμενους. Μπορείτε ακόμα να πηδήξετε στην τελευταία άμαξα και ή πάρτε το χρόνο σας εισιτήριο. Γνωρίστε μας στο Skolkovo!
Πηγή: www.habr.com