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 คุณยังคงต้องส่งไปยังเซิร์ฟเวอร์ ก่อนหน้านี้ในวันแรกใครบางคนจะดึงรหัสที่ด้วยตนเองเรียกใช้การทดสอบบางอย่างบนเครื่องของตัวเองแพคเกจและใช้ในการผลิต ซึ่งทํางานได้หากคุณใช้การใช้งานบ่อยน้อย แต่เมื่อทีมงานทําการอัปเดตบ่อย (เพิ่มคุณสมบัติมากขึ้น) วิธีที่ด้วยตนเองกลายเป็นขีดข่วน ข้อผิดพลาดหลีกเลี่ยง - จากการพลาดขั้นตอนการทดสอบจนถึงการใช้งานในสภาพแวดล้อมที่ไม่ถูกต้อง นี่คือเหตุผลที่ท่อ CI / CD อัตโนมัติมีความจําเป็น +===================================================+ | 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 อัตโนมัติขั้นตอนระหว่างการเขียนโค้ดและการใช้มันในการผลิต เมื่อโค้ดถูกกดเข้าไปในสํารองข้อมูลท่อจะครอบครอง มันบรรจุโค้ดลงใน build แล้วดําเนินการทดสอบอัตโนมัติ - การทดสอบหน่วยเพื่อตรวจสอบฟังก์ชั่นแต่ละส่วนการทดสอบการบูรณาการเพื่อให้มั่นใจว่าชิ้นส่วนต่างๆทํางานร่วมกันการสแกนความเสี่ยงด้านความปลอดภัยและการทดสอบประสิทธิภาพเพื่อตรวจสอบสุขภาพโดยรวม ทั้งหมดนี้เกิดขึ้นโดยไม่จําเป็นต้องจําแต่ละงานและสามารถเน้นการพัฒนาคุณลักษณะใหม่ได้มากขึ้น ╔═══════════════════════════════════════════════╗ ║ 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: การปรับปรุงประสิทธิภาพของนักพัฒนา หากทุกอย่างผ่านไปการสร้างจะไปที่สภาพแวดล้อมการทดสอบหรือการพัฒนาซึ่งโค้ดใหม่จะถูกทดสอบพร้อมกับสิ่งที่มีอยู่แล้ว เมื่อทุกอย่างดูดีมันจะถูกใช้งานสด Jenkins, GitHub Actions, Azure DevOps และ Harness เป็นตัวอย่างของเครื่องมือ CI / CD ที่ได้รับความนิยม ╔═══════════════════════════════════════════════╗ ║ 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 : สภาพแวดล้อมการทดสอบ / Dev ไปยังสภาพแวดล้อมการผลิต แผนภาพ 10 : สภาพแวดล้อมการทดสอบ / Dev ไปยังสภาพแวดล้อมการผลิต ปัญหาความสอดคล้องด้านสิ่งแวดล้อม หลังจากไปถึงที่นี่เราจะพบกับข้อบกพร่องอื่น ๆ อีกครั้ง: บางครั้งรหัสทํางานบนแล็ปท็อปของผู้พัฒนา แต่เกิดความล้มเหลวในการผลิตเนื่องจากสภาพแวดล้อมพื้นฐานแตกต่างกัน วิธีที่ซอฟต์แวร์โต้ตอบกับระบบปฏิบัติการของซอฟต์แวร์ห้องสมุดหรือรุ่นที่เฉพาะเจาะจงของความเสี่ยงสามารถเปลี่ยนแปลงได้ง่ายจากเครื่องหนึ่งไปยังเครื่องอื่น ๆ นั่นคือที่ความจําเป็นในการแยกมาดังนั้นแอปพลิเคชันจึงไม่มีเวลาหยุดทํางาน ╔═══════════════════════════════════════════════╗ ║ "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 : ประโยชน์ของการแยก นี่คือเหตุผลที่คอนเทนเนอร์ถูกนํามาใช้ คอนเทนเนอร์ทําหน้าที่เหมือนแพคเกจเล็ก ๆ น้อย ๆ: มันพกพาทุกสิ่งที่แอปพลิเคชันต้องการ - รหัสเวลาทํางานเครื่องมือระบบห้องสมุด - เพื่อให้สามารถทํางานได้เหมือนกันไม่ว่ามันจะถูกนํามาใช้ที่ไหน คอนเทนเนอร์แยกแอปพลิเคชันจากสภาพแวดล้อมพื้นฐานทําให้ "มันทํางานบนเครื่องของฉัน" เป็นเรื่องของอดีต Out of the various container technologies, Docker is one of the most popular. Docker makes it easy to create, deploy, test, and manage containers. As a result, your app runs the same everywhere - from local machines to production servers. ╔══════════════════════════════════════════════╗ ║ 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 ทํางานเหมือนกันในทุกสภาพแวดล้อม การท้าทาย orchestration Docker เหมาะสําหรับการบรรจุแอพพลิเคชันอย่างสม่ําเสมอ แต่เมื่อคุณมีคอนเทนเนอร์จํานวนมากในการผลิตสําหรับสิ่งต่าง ๆ เช่นเซิร์ฟเวอร์เว็บฐานข้อมูลแคชและไมโครเซิร์ฟเวอร์การจัดการด้วยตนเองไม่สามารถติดตามได้ หากคอนเทนเนอร์หยุดการจราจรต้องเปลี่ยนเส้นทางการปรับขนาดเป็นสิ่งจําเป็นตามความต้องการที่เปลี่ยนแปลงและการเชื่อมต่อเครือข่ายกลายเป็นซับซ้อน นี่คือจุดที่ Kubernetes ขั้นตอน ╔═════════════════════════════════════════════╗ ║ 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 เป็นชั้น orchestration ด้านบนของ Docker มันจัดการคอนเทนเนอร์โดยอัตโนมัติ - รีสตาร์ทคอนเทนเนอร์ที่ล้มเหลวการปรับขนาดขึ้นหรือลดลงการสมดุลการจราจรและการเชื่อมต่อคอนเทนเนอร์เข้าด้วยกัน Docker จัดการ containerization Kubernetes จัดการ orchestration ทั่วโครงสร้างพื้นฐานของคุณไม่ว่าจะอยู่ในคลาวด์ (AWS, Azure, Google Cloud) หรือในสถานที่ ╔═════════════════════════════════════════════╗ ║ 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: Balancing Load แผนภาพ 19: Balancing Load ╔══════════════════════════════════════════════╗ ║ 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 อื่น ๆ - ผู้ให้บริการคลาวด์, เครื่องมือ 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 อีเมล์ อีเมล์ การเชื่อมโยง การเชื่อมโยง . X X คุณสามารถอ่านบทความของฉันใน system design . here ที่นี่ หากคุณต้องการฉันเขียนเกี่ยวกับหัวข้ออื่น ๆ โปรดแจ้งให้ฉันทราบในความคิดเห็น เชื่อมโยงกับฉัน . โปรไฟล์ HackerNoon