Το DevOps δεν είναι εργαλείο, είναι μια αλυσιδωτή αντίδραση

Καλά. Ας ξεκινήσουμε. Αυτό το άρθρο προορίζεται να δώσει μια εισαγωγή για έναν αρχάριο σε μερικά από τα βασικά συστατικά του DevOps και πώς ταιριάζουν μαζί στη σύγχρονη διαδικασία ανάπτυξης. Υπάρχουν αμέτρητα άρθρα στο διαδίκτυο που περιγράφουν το ίδιο θέμα και δεν σκοπεύω να προσφέρω κάτι πρωτοποριακό εδώ. +------------------------------------------------+ | THE DEVOPS PROCESS FLOW | +==================+=============================+ | STAGE | KEY ACTION | +==================+=============================+ | 1. Code | Write and commit changes | +------------------+-----------------------------+ | 2. Build | Compile and package code | +------------------+-----------------------------+ | 3. Test | Run automated tests | +------------------+-----------------------------+ | 4. Deploy | Release to production | +------------------+-----------------------------+ | 5. Feedback | Monitor and inform new code | +------------------+-----------------------------+ | (Repeat) | The loop continues... | +------------------+-----------------------------+ Διάγραμμα 1: ροή διαδικασιών του DevOps Διάγραμμα 1: ροή διαδικασιών του DevOps +======================================================+ | Process Transformation: DevOps | +======================+===============================+ | STAGE | MANUAL (BEFORE) | +======================+===============================+ | Code Integration | Manual merges, "merge hell" | | Build | Run on local machine | | Test | Manual testing, slow | | Deploy | Manual scripts, risky | |----------------------+-------------------------------| | **Result** | Slow, Error-Prone, Stressful | +======================+===============================+ | STAGE | AUTOMATED (AFTER) | +======================+===============================+ | Code Integration | Auto-merge via CI server | | Build | Automated build on push | | Test | Automated tests run in pipe | | Deploy | Automated CD to production | |----------------------+-------------------------------| | **Result** | Fast, Reliable, Repeatable | +======================+===============================+ Διάγραμμα 2: Πλεονεκτήματα του DevOps Διάγραμμα 2: Πλεονεκτήματα του DevOps Από την απλή ανάπτυξη στην πολύπλοκη πραγματικότητα Όταν σκεφτόμαστε την ανάπτυξη, συνήθως το φανταζόμαστε με πολύ απλούς όρους. Ένας προγραμματιστής γράφει τον κώδικα και αυτό υλοποιείται στον ιστότοπο. Αλλά στην πράξη, η διαδικασία μπορεί να περιπλέξει σημαντικά σε σύντομο χρονικό διάστημα. Πολλοί προγραμματιστές μπορεί να εργάζονται στην ίδια βάση κώδικα. Οι αλλαγές κώδικα που κάνει ένα άτομο μπορεί να επηρεάσουν αυτό που έχει ήδη κατασκευάσει ένας άλλος. Αυτό είναι όπου ένα σύστημα διαχείρισης πηγαίου κώδικα όπως το Git έρχεται - παρακολουθεί κάθε αλλαγή, κάθε έκδοση και επιτρέπει σε πολλούς προγραμματιστές να συνεργάζονται αποτελεσματικά και ομαλά. ╔═══════════════════════════════════════════════════╗ ║ THE ILLUSION VS REALITY OF DEVELOPMENT ║ ╚═══════════════════════════════════════════════════╝ WHAT WE IMAGINE WHAT ACTUALLY HAPPENS ┌──────────────┐ ┌──────────────┐ │ Programmer │ │ Programmer A │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Code │ │ Code v1 │◄─┐ └──────┬───────┘ └──────────────┘ │ │ │ │ ▼ │ CONFLICT! ┌──────────────┐ │ │ │ Website │ ▼ │ └──────────────┘ ┌──────────────┐ │ │ Code v2 │──┘ SIMPLE └──────────────┘ ▲ │ ┌──────┴───────┐ │ Programmer B │ └──────────────┘ COMPLEX Διάγραμμα 3: Εξηγεί την πραγματικότητα της ανάπτυξης λογισμικού Διάγραμμα 3: Εξηγεί την πραγματικότητα της ανάπτυξης λογισμικού ╔═════════════════════════════════════════════╗ ║ THE CHANGE TRACKING CHALLENGE ║ ╚═════════════════════════════════════════════╝ BEFORE GIT (CHAOS) Week 1 Week 2 Week 3 │ │ │ ▼ ▼ ▼ Change Change Something Made Made Broke! │ │ │ └───────────┴───────────┘ │ ▼ ┌───────────────┐ │ Who did it? │ │ When? │ │ Why? │ │ How to undo? │ └───────────────┘ │ ▼ [ MYSTERY ] NEED: TRACKING SYSTEM Διάγραμμα 4: Ανάπτυξη λογισμικού χωρίς Git (σύστημα ελέγχου εκδόσεων) Διάγραμμα 4: Ανάπτυξη λογισμικού χωρίς Git (σύστημα ελέγχου εκδόσεων) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Διάγραμμα 5: Ανάπτυξη λογισμικού με το Git (σύστημα ελέγχου εκδόσεων) Διάγραμμα 5: Ανάπτυξη λογισμικού με το Git (σύστημα ελέγχου εκδόσεων) ╔═══════════════════════════════════════════════╗ ║ THE ROLLBACK SAFETY NET CONCEPT ║ ╚═══════════════════════════════════════════════╝ WITHOUT GIT Past ──────────────► Present │ ▼ ┌────────┐ │ BROKEN │ └────────┘ │ ▼ [ NO WAY BACK ] WITH GIT ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ v1 │───►│ v2 │───►│ v3 │───►│ v4 │ └────┘ └────┘ └────┘ └────┘ ▲ │ │ │ │ SOMETHING BROKE │ │ ▼ │ │ ┌────────┐ │ │ │ROLLBACK│ │ └─────────┤ TO v1 │◄──────────┘ └────────┘ SAFETY GUARANTEED Διάγραμμα 6: Η έννοια του rollback στο Git Διάγραμμα 6: Η έννοια του rollback στο Git Το πρόβλημα της χειροκίνητης τοποθέτησης Μόλις ο κώδικας είναι ασφαλής στο Git, πρέπει ακόμα να τον πάρετε σε έναν διακομιστή. Νωρίτερα, στις πρώτες ημέρες, κάποιος θα τραβούσε χειροκίνητα αυτόν τον κώδικα, θα εκτελούσε μερικές δοκιμές στο δικό του μηχάνημα, θα τον συσκευάζει και θα τον αναπτύσσει στην παραγωγή. Τα λάθη ξεφεύγουν - από το να χάσετε ένα βήμα δοκιμής μέχρι την ανάπτυξη στο λάθος περιβάλλον. +===================================================+ | The Manual Bottleneck Effect | +===================================================+ LOW SCALE (1x/Month) -------------------- [Commit] ---> ( 👤 ) ---> [Deploy OK] (No pressure) HIGH SCALE (10x/Week) --------------------- [Commit] --\ [Commit] -- \ [Commit] --- > ( 👤 ) --- > [ERROR] [Commit] -- / (Pressure) [CONFLICT] [Commit] --/ (Overwhelmed) [FAILURE] CONCLUSION: A human 👤 cannot process high volume. SOLUTION: Need an automated CI/CD pipeline. Διάγραμμα 7: Εγχειρίδιο εγκατάστασης Διάγραμμα 7: Εγχειρίδιο εγκατάστασης Αυτοματισμός της διαδικασίας κατασκευής και δοκιμών Ένας αγωγός CI/CD αυτοματοποιεί τα βήματα μεταξύ της γραφής του κώδικα και της ανάπτυξής του στην παραγωγή.Όταν ο κώδικας πιέζεται στο αποθετήριο, ο αγωγός αναλαμβάνει. Πακέτα τον κώδικα σε μια κατασκευή, στη συνέχεια εκτελεί αυτοματοποιημένες δοκιμές - δοκιμές μονάδας για τον έλεγχο των μεμονωμένων λειτουργιών, δοκιμές ενσωμάτωσης για να εξασφαλιστεί η συνεργασία των διαφόρων τμημάτων, σάρωση ασφαλείας για τρωτά σημεία και δοκιμές απόδοσης για τον έλεγχο της συνολικής υγείας. Όλα αυτά συμβαίνουν χωρίς κανέναν να χρειάζεται να θυμάται κάθε εργασία, και περισσότερη έμφαση μπορεί να δοθεί στην ανάπτυξη νεότερων χαρακτηριστικών. ╔═══════════════════════════════════════════════╗ ║ THE CI/CD PIPELINE ANATOMY ║ ╚═══════════════════════════════════════════════╝ ┌─────────────┐ │ CODE PUSHED │ │ TO REPO │ └──────┬──────┘ │ ▼ ╔══════════════════════╗ ║ CI/CD PIPELINE ║ ║ ║ ║ ┌────────────────┐ ║ ║ │ 1. PACKAGE │ ║ ║ │ (Build) │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 2. TEST │ ║ ║ │ - Unit │ ║ ║ │ - Integration│ ║ ║ │ - Security │ ║ ║ │ - Performance│ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 3. DEPLOY │ ║ ║ │ Test/Dev Env │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 4. DEPLOY │ ║ ║ │ Production │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ Διάγραμμα 8: Ο αγωγός CI/CD Διάγραμμα 8: Ο αγωγός CI/CD ╔═════════════════════════════════════════════╗ ║ THE CI/CD AUTOMATION ENGINE ║ ╚═════════════════════════════════════════════╝ DEVELOPER CI/CD DOES ALL: │ │ ┌──────────┐ │ │ Package │ ▼ └────┬─────┘ ┌────────────┐ │ │ PUSH CODE │ │ └────────────┘ ▼ │ ┌──────────┐ │ │Unit Test │ │ └────┬─────┘ │ │ │ ▼ Developer's ┌──────────┐ Job Done! │Integrate │ │ │ Test │ │ └────┬─────┘ │ │ ▼ ▼ ┌────────────┐ ┌──────────┐ │ FOCUS ON │ │ Security │ │ NEXT │ │ Scan │ │ FEATURE │ └────┬─────┘ └────────────┘ │ ▼ ┌──────────┐ │Performnce│ │ Test │ └────┬─────┘ │ ▼ ┌──────────┐ │ Deploy │ └──────────┘ Διάγραμμα 9: Βελτίωση της αποτελεσματικότητας του προγραμματιστή Διάγραμμα 9: Βελτίωση της αποτελεσματικότητας του προγραμματιστή Εάν όλα πάνε καλά, η κατασκευή πηγαίνει σε ένα περιβάλλον δοκιμών ή ανάπτυξης, όπου ο νέος κώδικας δοκιμάζεται μαζί με αυτό που είναι ήδη σε παραγωγή.Όταν τα πράγματα φαίνονται καλά, αναπτύσσεται ζωντανά. ╔═══════════════════════════════════════════════╗ ║ THE ENVIRONMENT PROMOTION LADDER ║ ╚═══════════════════════════════════════════════╝ ┌──────────────┐ │ CODE PUSHED │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ CI/CD RUNS │ │ TESTS │ └──────┬───────┘ │ TESTS PASS │ ▼ ╔════════════════════════╗ ║ TEST/DEV ENVIRON ║ ◄── Try Here First ║ ║ ║ New Code + Old Code ║ ║ Working Together? ║ ╚════════════╤═══════════╝ │ LOOKS GOOD │ ▼ ╔════════════════════════╗ ║ PRODUCTION ENVIRON ║ ◄── Deploy Live ║ ║ ║ Users Get Update ║ ╚════════════════════════╝ SAFE PROGRESSION TEST → PRODUCTION Διάγραμμα 10 : Το περιβάλλον δοκιμής / ανάπτυξης στο περιβάλλον παραγωγής Διάγραμμα 10 : Το περιβάλλον δοκιμής / ανάπτυξης στο περιβάλλον παραγωγής Το πρόβλημα της περιβαλλοντικής συνοχής Αφού προχωρήσουμε μέχρι εδώ, φυσικά θα συναντήσουμε ένα ακόμη μειονέκτημα: Μερικές φορές ο κώδικας λειτουργεί στο φορητό υπολογιστή ενός προγραμματιστή, αλλά καταρρέει στην παραγωγή επειδή τα υποκείμενα περιβάλλοντα είναι διαφορετικά. ο τρόπος με τον οποίο ένα κομμάτι λογισμικού αλληλεπιδρά με το λειτουργικό σύστημα, τις βιβλιοθήκες ή συγκεκριμένες εκδόσεις εξαρτήσεων μπορεί εύκολα να αλλάξει από το ένα μηχάνημα στο άλλο. ╔═══════════════════════════════════════════════╗ ║ "IT WORKS ON MY MACHINE" SYNDROME ║ ╚═══════════════════════════════════════════════╝ DEVELOPER'S LAPTOP PRODUCTION SERVER ┌──────────┐ ┌──────────┐ │ CODE │ │ CODE │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Python │ │ Python │ │ 3.9 │ │ 3.7 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Library │ │ Library │ │ v2.0 │ │ v1.5 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ OS │ │ OS │ │ Ubuntu22 │ │ Ubuntu20 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ [ ✓ WORKS ] [ ✗ CRASHES ] THE ENVIRONMENT MISMATCH PROBLEM Διάγραμμα 11: Το πρόβλημα της περιβαλλοντικής ασυμφωνίας Διάγραμμα 11: Το πρόβλημα της περιβαλλοντικής ασυμφωνίας ╔═══════════════════════════════════════════════╗ ║ THE ISOLATION LAYER VISUALIZATION ║ ╚═══════════════════════════════════════════════╝ WITHOUT CONTAINERS ┌───────────────────────────┐ │ Operating System │ │ │ │ App1 App2 App3 App4 │ │ │ │ │ │ │ │ └─────┴─────┴─────┘ │ │ │ │ │ Shared Resources │ │ (Conflicts!) │ └───────────────────────────┘ WITH CONTAINERS ┌───────────────────────────┐ │ Operating System │ ├───────────────────────────┤ │ ╔═══╗ ╔═══╗ ╔═══╗ ╔═══╗ │ │ ║App║ ║App║ ║App║ ║App║ │ │ ║ 1 ║ ║ 2 ║ ║ 3 ║ ║ 4 ║ │ │ ╚═══╝ ╚═══╝ ╚═══╝ ╚═══╝ │ │ │ │ Each Isolated & Protected │ └───────────────────────────┘ Διάγραμμα 12 : Τα οφέλη της απομόνωσης Διάγραμμα 12 : Τα οφέλη της απομόνωσης Αυτός είναι ο λόγος για τον οποίο εισήχθησαν τα εμπορευματοκιβώτια. Ένα εμπορευματοκιβώτιο λειτουργεί σαν ένα μικρό πακέτο: τυλίγει όλα όσα χρειάζεται μια εφαρμογή - τον κώδικα, τον χρόνο εκτέλεσης, τα εργαλεία συστήματος, τις βιβλιοθήκες - έτσι ώστε να μπορεί να τρέξει με τον ίδιο τρόπο ανεξάρτητα από το πού αναπτύσσεται. Από τις διάφορες τεχνολογίες εμπορευματοκιβωτίων, το Docker είναι μία από τις πιο δημοφιλείς. Το Docker διευκολύνει τη δημιουργία, την ανάπτυξη, τη δοκιμή και τη διαχείριση εμπορευματοκιβωτίων. ╔══════════════════════════════════════════════╗ ║ THE DEPENDENCY ISOLATION SHIELD ║ ╚══════════════════════════════════════════════╝ HOST MACHINE (ANY OS) ┌────────────────────────────────────┐ │ │ │ ╔═══════════════════════════════╗ │ │ ║ CONTAINER SHIELD ║ │ │ ║ ║ │ │ ║ ┌─────────────────────────┐ ║ │ │ ║ │ YOUR APPLICATION │ ║ │ │ ║ │ │ ║ │ │ ║ │ • Code │ ║ │ │ ║ │ • Runtime │ ║ │ │ ║ │ • System Tools │ ║ │ │ ║ │ • Libraries │ ║ │ │ ║ │ • Dependencies │ ║ │ │ ║ │ │ ║ │ │ ║ └─────────────────────────┘ ║ │ │ ║ ║ │ │ ║ ISOLATED FROM HOST ║ │ │ ╚═══════════════════════════════╝ │ │ │ │ Host Changes Don't Affect App! │ └────────────────────────────────────┘ Διάγραμμα 13 : Σχεδιασμός κοντέινερ Διάγραμμα 13 : Σχεδιασμός κοντέινερ ╔═══════════════════════════════════════════════╗ ║ FROM LOCAL DEVELOPMENT TO PRODUCTION ║ ╚═══════════════════════════════════════════════╝ SINGLE CONTAINER ╔═════════════╗ ║ Docker ║ ║ Container ║ ╚══════╤══════╝ │ │ DEPLOY JOURNEY │ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ LOCAL │ │ STAGING │ │ PROD │ │ DEV │ │ SERVER │ │ SERVER │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ [IDENTICAL] [IDENTICAL] [IDENTICAL] NO CONFIGURATION DRIFT! NO ENVIRONMENT SURPRISES! PREDICTABLE DEPLOYMENTS! Διάγραμμα 14 : Οι εφαρμογές σε δοχεία Docker λειτουργούν πανομοιότυπα σε όλα τα περιβάλλοντα Διάγραμμα 14 : Οι εφαρμογές σε δοχεία Docker λειτουργούν πανομοιότυπα σε όλα τα περιβάλλοντα Η πρόκληση της ορχήστρας Το Docker είναι ιδανικό για τη συνεπή συσκευασία εφαρμογών, αλλά όταν έχετε πολλά δοχεία στην παραγωγή για πράγματα όπως web servers, βάσεις δεδομένων, caches και microservices, η χειροκίνητη διαχείριση δεν μπορεί να συμβαδίσει. ╔═════════════════════════════════════════════╗ ║ THE ORCHESTRATION REQUIREMENT ║ ╚═════════════════════════════════════════════╝ PRODUCTION REALITY Web Server Database Cache APIs Containers Containers Containers Containers │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐┌────┐ ┌────┐┌────┐ ┌────┐ ┌────┐ │ W1 ││ W2 │ │ D1 ││ D2 │ │ C1 │ │ A1 │ └────┘└────┘ └────┘└────┘ └────┘ └────┘ ┌────┐┌────┐ ┌────┐ │ W3 ││ W4 │ │ A2 │ └────┘└────┘ └────┘ MANUAL QUESTIONS: • Which container crashed? • How to reroute traffic? • When to scale up/down? • How to connect them? ▼ NEED ORCHESTRATOR ▼ KUBERNETES! Διάγραμμα 15: Ανάγκη για ορχήστρα εμπορευματοκιβωτίων Διάγραμμα 15: Ανάγκη για ορχήστρα εμπορευματοκιβωτίων Το Kubernetes είναι ένα στρώμα ορχήστρας στην κορυφή του Docker. Διαχειρίζεται αυτόματα τα εμπορευματοκιβώτια - επανεκκίνηση αποτυχημένων εμπορευματοκιβωτίων, κλιμάκωση ή μείωση της κλίμακας, εξισορρόπηση της κυκλοφορίας και σύνδεση των εμπορευματοκιβωτίων. ╔═════════════════════════════════════════════╗ ║ THE AUTOMATIC MANAGEMENT LOOP ║ ╚═════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ CONTROL PLANE ║ ╚═════════╤═════════════╝ │ Constantly Monitors │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ A │ │ B │ │ C │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────┼─────────────┘ │ Reports Status │ ▼ ╔═══════════════════╗ ║ AUTO ACTIONS: ║ ║ • Restart ║ ║ • Scale ║ ║ • Balance ║ ║ • Link ║ ╚═══════════════════╝ CONTINUOUS AUTOMATION Διάγραμμα 16: Αυτόματη διαχείριση Διάγραμμα 16: Αυτόματη διαχείριση ╔══════════════════════════════════════════════╗ ║ THE FAILED CONTAINER AUTO-RECOVERY ║ ╚══════════════════════════════════════════════╝ TIME LINE t=0 t=1 t=2 t=3 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌─────────┐ │Running │ │Crashed!│ │Detected│ │Restarted│ └────────┘ └───╳────┘ └────────┘ └─────────┘ │ │ │ │ ▼ │ │ ╔═══════════════╗ │ │ ║ KUBERNETES ║ │ └───►║ Monitors ║ │ ║ & Acts ║───┘ ╚═══════════════╝ AUTOMATIC HEALING NO MANUAL INTERVENTION Διάγραμμα 17: Αυτόματη ανάκτηση Διάγραμμα 17: Αυτόματη ανάκτηση ╔═══════════════════════════════════════════════╗ ║ THE SCALING AUTOMATION ENGINE ║ ╚═══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Watches Metrics ║ ╚═══════╤═══════════════╝ │ ┌───────────┴───────────┐ │ │ LOW DEMAND HIGH DEMAND │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Scale │ │ Scale │ │ DOWN │ │ UP │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌────┐ ┌────┐┌────┐ │ C1 │ │ C1 ││ C2 │ └────┘ └────┘└────┘ ┌────┐┌────┐ 1 Container │ C3 ││ C4 │ Enough └────┘└────┘ 4 Containers Needed ELASTIC SCALING Διάγραμμα 18: Ελαστική κλιμάκωση Διάγραμμα 18: Ελαστική κλιμάκωση ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD Διάγραμμα 19: Ισορροπία φορτίου Διάγραμμα 19: Ισορροπία φορτίου ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS Διάγραμμα 20: Σύνδεση των εμπορευματοκιβωτίων Διάγραμμα 20: Σύνδεση των εμπορευματοκιβωτίων ╔═════════════════════════════════════════════╗ ║ THE DIVISION OF RESPONSIBILITIES ║ ╚═════════════════════════════════════════════╝ DOCKER'S JOB KUBERNETES' JOB ┌─────────────┐ ┌─────────────┐ │ CREATE │ │ DEPLOY │ │ Containers │ │ Where? │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ PACKAGE │ │ MONITOR │ │ Application │ │ Health │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ RUN │ │ SCALE │ │ Containers │ │ Count │ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ │ MANAGE │ │ Lifecycle │ └─────────────┘ CONTAINERIZATION ORCHESTRATION Διάγραμμα 21: Μοντέλο κοινής ευθύνης Διάγραμμα 21: Μοντέλο κοινής ευθύνης Δείτε τι συμβαίνει στην παραγωγή Η εργασία δεν ολοκληρώνεται μετά την ανάπτυξη. Είναι απαραίτητο να παρατηρήσετε πώς λειτουργεί πραγματικά η εφαρμογή στην παραγωγή. Τα σφάλματα αυξάνονται; Η εφαρμογή είναι αργή; Τα εργαλεία παρακολούθησης παρακολουθούν μετρήσεις όπως η χρήση της CPU, η χρήση της μνήμης, οι χρόνοι απόκρισης και τα ποσοστά σφαλμάτων. Η καταγραφή καταγράφει τι κάνει η εφαρμογή και τα σφάλματα που συμβαίνουν. Όταν κάτι πάει στραβά, αυτή η υποδομή σας βοηθά να εντοπίσετε γρήγορα και να διορθώσετε προβλήματα πριν από την ειδοποίηση των τελικών χρηστών. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ Διάγραμμα 22: Παρακολούθηση, καταγραφή και ανταπόκριση σε συμβάντα Διάγραμμα 22: Παρακολούθηση, καταγραφή και ανταπόκριση σε συμβάντα ╔══════════════════════════════════════════════╗ ║ DETECTING ISSUES BEFORE USERS ║ ╚══════════════════════════════════════════════╝ WITHOUT MONITORING Error Occurs ──► User Complains ──► Fix │ │ └───────────────────┘ Hours/Days Later! WITH MONITORING Error Occurs │ ▼ ╔═════════════╗ ║ MONITORING ║ ║ Detects ║ ──► Alerts Team ║ Instantly ║ ╚═════╤═══════╝ │ ▼ Team Fixes Issue │ ▼ Users Never Know! PROACTIVE > REACTIVE Διάγραμμα 23: Προληπτική ανταπόκριση Διάγραμμα 23: Προληπτική ανταπόκριση Τι πρέπει να έχει κανείς στο μυαλό Όποιος θέλει να αποκτήσει περισσότερη εμπειρία στο DevOps θα πρέπει επίσης να επικεντρωθεί στην κατανόηση των διαφόρων τύπων αυτοματοποιημένων δοκιμών που γράφονται. ╔══════════════════════════════════════════════╗ ║ THINKING THROUGH USE & MISUSE ║ ╚══════════════════════════════════════════════╝ ┌─────────────────┐ │ FEATURE TO │ │ BE TESTED │ └────────┬────────┘ │ Think About: │ ┌────────────┴────────────┐ │ │ ▼ ▼ ┌───────────┐ ┌───────────┐ │ NORMAL │ │ ABNORMAL │ │ USE │ │ USE │ │ │ │ │ │• Expected │ │• Wrong │ │ Inputs │ │ Inputs │ │• Happy │ │• Edge │ │ Path │ │ Cases │ │• Valid │ │• Malicious│ │ Flow │ │ Intent │ └─────┬─────┘ └─────┬─────┘ │ │ └────────────┬────────────┘ │ ▼ [ COMPREHENSIVE TEST COVERAGE ] Διάγραμμα 24: Δοκιμαστική εξέταση Διάγραμμα 24: Δοκιμαστική εξέταση Οι δεξιότητες γλώσσας προγραμματισμού, η εξοικείωση με το API, η γνώση του τομέα και η συνειδητοποίηση των πλαισίων δοκιμών βοηθούν. Οι επιλογές εδώ θα πρέπει να λειτουργούν με το υπόλοιπο οικοσύστημα του DevOps - πάροχο cloud, εργαλείο CI / CD, πλατφόρμα αυτοματισμού. για παράδειγμα, το Jenkins (ένα εργαλείο CI / CD) ενσωματώνεται με διάφορες γλώσσες, συμπεριλαμβανομένου του Python και των πλαισίων όπως το pytest, οπότε είναι σημαντικό να γνωρίζετε ποια εργαλεία λειτουργούν καλά μαζί. ╔═════════════════════════════════════════════╗ ║ THE DEVOPS ECOSYSTEM COMPATIBILITY ║ ╚═════════════════════════════════════════════╝ ┌─────────────────┐ │ TEST CHOICE │ └────────┬────────┘ │ Must Work With: │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Cloud │ │ CI/CD │ │Automation│ │ Provider │ │ Tool │ │ Platform │ │ │ │ │ │ │ │AWS/Azure │ │ Jenkins │ │ Etc. │ │ /GCP │ │ GitHub │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ INTEGRATION ║ ║ IS CRITICAL ║ ╚═══════════════╝ Διάγραμμα 25: Συμβατότητα των οικοσυστημάτων Διάγραμμα 25: Συμβατότητα των οικοσυστημάτων Συμπίεση Αυτό είναι ένα σημείο εκκίνησης για να κάνετε νόημα στο DevOps, συνδέοντας τα βήματα από τον κώδικα και τη συνεργασία με την αυτοματοποίηση και την υποδομή με την παρακολούθηση και την ανατροφοδότηση.Κάθε στρώμα εμφανίζεται για να αντιμετωπίσει ένα πρόβλημα που δεν μπορούσε να λυθεί μόνο με το προηγούμενο.Καθώς αυτό το τοπίο συνεχίζει να εξελίσσεται, η παρατήρηση αυτών των βασικών μεταβάσεων είναι αυτό που βοηθά να μετατραπούν οι περίπλοκες εφαρμογές σε κάτι που λειτουργεί πραγματικά. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ Πίνακας 26: Σύνοψη Πίνακας 26: Σύνοψη Περισσότερο από οτιδήποτε άλλο, το DevOps είναι για την κατανόηση του πώς τα κομμάτια ταιριάζουν μεταξύ τους και γιατί το καθένα είναι απαραίτητο, και όχι μόνο για την εκμάθηση εργαλείων μεμονωμένα. Εάν έχετε οποιεσδήποτε ερωτήσεις, παρακαλούμε μη διστάσετε να μου στείλετε μήνυμα ηλεκτρονικού ταχυδρομείου.Μπορείτε επίσης να επικοινωνήσετε μαζί μου μέσω LinkedIn.Μπορείτε επίσης να με ακολουθήσετε στο X. email email Λίνκινγκ Λίνκινγκ . X X Μπορείτε να διαβάσετε το άρθρο μου στο system design . here ΕΔΩ Αν θέλετε να γράψω για οποιοδήποτε άλλο θέμα, παρακαλώ ενημερώστε με στα σχόλια. Σύνδεσμος με το δικό μου . Προφίλ Χάκερ