เราจะเริ่มบล็อกของเราด้วยสิ่งพิมพ์ตามคำปราศรัยล่าสุดของผู้อำนวยการด้านเทคนิคของเรา (ดมิทรี สโตลยารอฟ). ทั้งหมดนี้เกิดขึ้นในปี 2016 ในกิจกรรมระดับมืออาชีพต่างๆ และเน้นไปที่หัวข้อ DevOps และ Docker เรามีวิดีโอหนึ่งรายการจากการประชุม Docker Moscow ที่สำนักงาน Badoo ออนไลน์. บทความใหม่จะมาพร้อมกับบทความที่ถ่ายทอดสาระสำคัญของรายงาน ดังนั้น…
วันที่ 31 พฤษภาคม ในงานสัมมนา ซึ่งจัดขึ้นโดยเป็นส่วนหนึ่งของเทศกาล “Russian Internet Technologies” (RIT++ 2016) ส่วน “Continuous Deployment and Deployment” เปิดขึ้นพร้อมกับรายงาน “Best Practices of Continuous Delivery with Docker” โดยสรุปและจัดระบบแนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างกระบวนการจัดส่งต่อเนื่อง (CD) โดยใช้ Docker และผลิตภัณฑ์ Open Source อื่นๆ เราทำงานร่วมกับโซลูชันเหล่านี้ในการผลิต ซึ่งช่วยให้เราสามารถพึ่งพาประสบการณ์เชิงปฏิบัติได้
หากคุณมีโอกาสใช้เวลาหนึ่งชั่วโมง เราแนะนำให้ดูแบบเต็มๆ มิฉะนั้น ด้านล่างนี้คือบทสรุปหลักในรูปแบบข้อความ
การส่งมอบอย่างต่อเนื่องด้วย Docker
ใต้ การจัดส่งแบบต่อเนื่อง เราเข้าใจสายโซ่ของเหตุการณ์ซึ่งเป็นผลมาจากการที่โค้ดแอปพลิเคชันจากที่เก็บ Git มาใช้งานจริงก่อน จากนั้นจึงไปจบลงที่ไฟล์เก็บถาวร ดูเหมือนว่านี้: Git → สร้าง → ทดสอบ → ปล่อย → ดำเนินการ.
รายงานส่วนใหญ่เน้นไปที่ขั้นตอนการสร้าง (การประกอบแอปพลิเคชัน) และหัวข้อการเผยแพร่และการดำเนินการจะได้รับการพูดถึงโดยย่อ เราจะพูดถึงปัญหาและรูปแบบที่ช่วยให้คุณสามารถแก้ไขได้ และการใช้งานรูปแบบเหล่านี้โดยเฉพาะอาจแตกต่างกัน
เหตุใด Docker จึงต้องการที่นี่เลย? ไม่ใช่เพื่ออะไรที่เราตัดสินใจพูดคุยเกี่ยวกับแนวทางปฏิบัติในการจัดส่งอย่างต่อเนื่องในบริบทของเครื่องมือโอเพ่นซอร์สนี้ แม้ว่ารายงานทั้งหมดจะเน้นไปที่การใช้งาน แต่ก็มีการเปิดเผยเหตุผลหลายประการเมื่อพิจารณารูปแบบหลักของการเปิดตัวโค้ดแอปพลิเคชัน
รูปแบบการเปิดตัวหลัก
ดังนั้นเมื่อเราเปิดตัวแอปพลิเคชั่นเวอร์ชั่นใหม่เราก็ต้องเผชิญกับอย่างแน่นอน ปัญหาการหยุดทำงานสร้างขึ้นระหว่างการสลับเซิร์ฟเวอร์ที่ใช้งานจริง การรับส่งข้อมูลจากแอปพลิเคชันเวอร์ชันเก่าไปเป็นเวอร์ชันใหม่ไม่สามารถสลับได้ทันที ก่อนอื่นเราต้องตรวจสอบให้แน่ใจว่าเวอร์ชันใหม่ไม่เพียงดาวน์โหลดสำเร็จ แต่ยัง "อุ่นเครื่อง" ด้วย (เช่น พร้อมที่จะให้บริการคำขอโดยสมบูรณ์)
ดังนั้นแอปพลิเคชันทั้งสองเวอร์ชัน (เก่าและใหม่) จะทำงานพร้อมกันในบางครั้ง ซึ่งจะนำไปสู่โดยอัตโนมัติ ความขัดแย้งของทรัพยากรที่ใช้ร่วมกัน: เครือข่าย, ระบบไฟล์, IPC เป็นต้น ด้วย Docker ปัญหานี้แก้ไขได้อย่างง่ายดายด้วยการเรียกใช้แอปพลิเคชันเวอร์ชันต่างๆ ในคอนเทนเนอร์ที่แยกจากกัน ซึ่งรับประกันการแยกทรัพยากรภายในโฮสต์เดียวกัน (เซิร์ฟเวอร์/เครื่องเสมือน) แน่นอนคุณสามารถใช้ลูกเล่นบางอย่างได้โดยไม่ต้องมีฉนวนเลย แต่ถ้ามีเครื่องมือสำเร็จรูปและสะดวกสบายก็มีเหตุผลตรงกันข้าม - อย่าละเลย
การบรรจุคอนเทนเนอร์ให้ประโยชน์อื่นๆ มากมายเมื่อใช้งาน แอปพลิเคชันใด ๆ ขึ้นอยู่กับ รุ่นเฉพาะ (หรือช่วงเวอร์ชัน) ล่ามความพร้อมใช้งานของโมดูล/ส่วนขยาย ฯลฯ รวมถึงเวอร์ชันต่างๆ และสิ่งนี้ไม่เพียงแต่ใช้กับสภาพแวดล้อมที่ปฏิบัติการได้ในทันที แต่ยังรวมถึงสภาพแวดล้อมทั้งหมดด้วย ซึ่งรวมถึง ซอฟต์แวร์ระบบ และเวอร์ชันของมัน (ขึ้นอยู่กับการแจกจ่าย Linux ที่ใช้) เนื่องจากคอนเทนเนอร์ไม่เพียงมีรหัสแอปพลิเคชันเท่านั้น แต่ยังรวมถึงระบบและซอฟต์แวร์แอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าในเวอร์ชันที่ต้องการด้วยคุณจึงสามารถลืมปัญหาเกี่ยวกับการพึ่งพาได้
ขอสรุป รูปแบบการเปิดตัวหลัก เวอร์ชันใหม่โดยคำนึงถึงปัจจัยดังต่อไปนี้:
- ในตอนแรก แอปพลิเคชันเวอร์ชันเก่าจะทำงานในคอนเทนเนอร์แรก
- จากนั้นเวอร์ชันใหม่จะถูกเปิดตัวและ "อุ่นเครื่อง" ในคอนเทนเนอร์ที่สอง เป็นที่น่าสังเกตว่าเวอร์ชันใหม่นี้อาจไม่เพียงมีโค้ดแอปพลิเคชันที่อัปเดตเท่านั้น แต่ยังรวมถึงการอ้างอิงใด ๆ รวมถึงส่วนประกอบของระบบด้วย (เช่น OpenSSL เวอร์ชันใหม่หรือการแจกจ่ายทั้งหมด)
- เมื่อเวอร์ชันใหม่พร้อมที่จะให้บริการคำขอโดยสมบูรณ์ การรับส่งข้อมูลจะสลับจากคอนเทนเนอร์แรกไปเป็นคอนเทนเนอร์ที่สอง
- รุ่นเก่าสามารถหยุดได้แล้ว
วิธีการปรับใช้เวอร์ชันต่างๆ ของแอปพลิเคชันในคอนเทนเนอร์ที่แยกจากกันนี้ให้ความสะดวกอีกอย่างหนึ่ง - ย้อนกลับอย่างรวดเร็ว เป็นเวอร์ชันเก่า (หลังจากนั้นก็เพียงพอที่จะเปลี่ยนการรับส่งข้อมูลไปยังคอนเทนเนอร์ที่ต้องการ)
คำแนะนำแรกสุดท้ายฟังดูเหมือนเป็นสิ่งที่แม้แต่กัปตันก็ยังจับผิดไม่ได้: “[เมื่อจัดการจัดส่งต่อเนื่องด้วย Docker] ใช้นักเทียบท่า [และเข้าใจว่ามันให้อะไร]" โปรดจำไว้ว่านี่ไม่ใช่กระสุนเงินที่จะแก้ปัญหาทุกปัญหา แต่เป็นเครื่องมือที่ให้รากฐานที่ยอดเยี่ยม
ความสามารถในการทำซ้ำ
คำว่า "ความสามารถในการทำซ้ำ" เราหมายถึงชุดปัญหาทั่วไปที่พบเมื่อใช้งานแอปพลิเคชัน เรากำลังพูดถึงกรณีดังกล่าว:
- สคริปต์ที่ตรวจสอบโดยแผนกคุณภาพสำหรับการแสดงละครจะต้องทำซ้ำอย่างถูกต้องในการผลิต
- แอปพลิเคชันได้รับการเผยแพร่บนเซิร์ฟเวอร์ที่สามารถรับแพ็คเกจจากมิเรอร์พื้นที่เก็บข้อมูลที่แตกต่างกัน (เมื่อเวลาผ่านไป แอปพลิเคชันจะได้รับการอัปเดตและเวอร์ชันของแอปพลิเคชันที่ติดตั้งด้วย)
- “ทุกอย่างใช้ได้ผลสำหรับฉันในท้องถิ่น!” (...และผู้พัฒนาไม่ได้รับอนุญาตให้เข้าสู่การผลิต)
- คุณต้องตรวจสอบบางอย่างในเวอร์ชันเก่า (เก็บถาวร)
- ...
สาระสำคัญโดยทั่วไปอยู่ที่ความจริงที่ว่าการปฏิบัติตามสภาพแวดล้อมที่ใช้อย่างสมบูรณ์ (รวมถึงการไม่มีปัจจัยมนุษย์) เป็นสิ่งจำเป็น เราจะรับประกันความสามารถในการทำซ้ำได้อย่างไร? สร้างภาพนักเทียบท่า ตามโค้ดจาก Git จากนั้นใช้สำหรับงานใด ๆ : บนไซต์ทดสอบ, ในการใช้งานจริง, บนเครื่องท้องถิ่นของโปรแกรมเมอร์... ในเวลาเดียวกันสิ่งสำคัญคือต้องลดการดำเนินการที่ดำเนินการให้เหลือน้อยที่สุด หลังจาก การประกอบภาพ: ยิ่งง่ายก็ยิ่งมีโอกาสเกิดข้อผิดพลาดน้อยลงเท่านั้น
โครงสร้างพื้นฐานคือรหัส
หากข้อกำหนดด้านโครงสร้างพื้นฐาน (ความพร้อมใช้งานของซอฟต์แวร์เซิร์ฟเวอร์ เวอร์ชัน ฯลฯ) ไม่ได้ถูกกำหนดอย่างเป็นทางการและ "ถูกตั้งโปรแกรมไว้" การเปิดตัวการอัปเดตแอปพลิเคชันใดๆ อาจส่งผลให้เกิดผลที่ตามมาร้ายแรง ตัวอย่างเช่นในการจัดเตรียมคุณได้เปลี่ยนมาใช้ PHP 7.0 แล้วและเขียนโค้ดใหม่ตามนั้น - จากนั้นการปรากฏตัวในการใช้งานจริงด้วย PHP เก่า (5.5) จะทำให้ใครบางคนประหลาดใจอย่างแน่นอน คุณอาจไม่ลืมเกี่ยวกับการเปลี่ยนแปลงครั้งใหญ่ในเวอร์ชันล่าม แต่ "ปีศาจอยู่ในรายละเอียด": สิ่งที่น่าประหลาดใจอาจอยู่ที่การอัปเดตเล็กน้อยของการพึ่งพาใด ๆ
แนวทางแก้ไขปัญหานี้เรียกว่า IaC (โครงสร้างพื้นฐานเป็นรหัส “โครงสร้างพื้นฐานเป็นรหัส”) และเกี่ยวข้องกับการจัดเก็บข้อกำหนดโครงสร้างพื้นฐานพร้อมกับรหัสแอปพลิเคชัน เมื่อใช้สิ่งนี้ นักพัฒนาและผู้เชี่ยวชาญ DevOps สามารถทำงานกับพื้นที่เก็บข้อมูลแอปพลิเคชัน Git เดียวกัน แต่ในส่วนที่แตกต่างกัน จากโค้ดนี้ อิมเมจ Docker จะถูกสร้างขึ้นใน Git ซึ่งแอปพลิเคชันจะถูกปรับใช้โดยคำนึงถึงลักษณะเฉพาะทั้งหมดของโครงสร้างพื้นฐาน พูดง่ายๆ ก็คือ สคริปต์ (กฎ) สำหรับการประกอบรูปภาพควรอยู่ในพื้นที่เก็บข้อมูลเดียวกันกับซอร์สโค้ดและรวมเข้าด้วยกัน
ในกรณีของสถาปัตยกรรมแอปพลิเคชันแบบหลายชั้น เช่น มี nginx ซึ่งยืนอยู่ด้านหน้าแอปพลิเคชันที่ทำงานอยู่ในคอนเทนเนอร์ Docker จะต้องสร้างอิมเมจ Docker จากโค้ดใน Git สำหรับแต่ละเลเยอร์ จากนั้นรูปภาพแรกจะมีแอปพลิเคชันที่มีล่ามและการอ้างอิงแบบ "ปิด" อื่นๆ และรูปภาพที่สองจะมีอัปสตรีม nginx
ภาพนักเทียบท่าการสื่อสารกับ Git
เราแบ่งอิมเมจ Docker ทั้งหมดที่รวบรวมจาก Git ออกเป็นสองประเภท: ชั่วคราวและเผยแพร่ ภาพชั่วคราว ติดแท็กด้วยชื่อสาขาใน Git สามารถเขียนทับได้ด้วยการคอมมิตครั้งถัดไป และเผยแพร่เพื่อดูตัวอย่างเท่านั้น (ไม่ใช่สำหรับการใช้งานจริง) นี่คือข้อแตกต่างที่สำคัญจากเวอร์ชันรีลีส: คุณไม่มีทางรู้ได้เลยว่าคอมมิตใดอยู่ในนั้น
มันสมเหตุสมผลที่จะรวบรวมเป็นรูปภาพชั่วคราว: สาขาหลัก (คุณสามารถขยายไปยังไซต์อื่นได้โดยอัตโนมัติเพื่อดูเวอร์ชันปัจจุบันของต้นแบบอย่างต่อเนื่อง), สาขาที่มีการเผยแพร่, สาขาของนวัตกรรมเฉพาะ
หลังจากที่การแสดงตัวอย่างภาพชั่วคราวมาถึงความจำเป็นในการแปลไปสู่การใช้งานจริง นักพัฒนาได้ใส่แท็กบางอย่าง รวบรวมโดยอัตโนมัติด้วยแท็ก ปล่อยภาพ (แท็กของมันสอดคล้องกับแท็กจาก Git) และเปิดตัวสู่การแสดงละคร หากได้รับการตรวจสอบจากแผนกคุณภาพเรียบร้อยแล้ว ก็จะเข้าสู่การผลิต
Dapp
ทุกสิ่งที่อธิบายไว้ (การเปิดตัว การประกอบอิมเมจ การบำรุงรักษาในภายหลัง) สามารถนำไปใช้ได้อย่างอิสระโดยใช้สคริปต์ Bash และเครื่องมือ "ชั่วคราว" อื่น ๆ แต่ถ้าคุณทำเช่นนี้ เมื่อถึงจุดหนึ่งการนำไปปฏิบัติจะนำไปสู่ความซับซ้อนอย่างมากและการควบคุมที่ไม่ดี เมื่อเข้าใจสิ่งนี้ เราจึงสร้างยูทิลิตี้เวิร์กโฟลว์เฉพาะของเราเองสำหรับการสร้าง CI/CD - Dapp.
ซอร์สโค้ดของมันเขียนด้วยภาษา Ruby ซึ่งเป็นโอเพ่นซอร์สและเผยแพร่บน . ขออภัย ขณะนี้เอกสารประกอบเป็นจุดอ่อนที่สุดของเครื่องมือ แต่เรากำลังดำเนินการแก้ไข และเราจะเขียนและพูดคุยเกี่ยวกับ dApp มากกว่าหนึ่งครั้ง เพราะ... เราแทบรอไม่ไหวที่จะแบ่งปันความสามารถกับชุมชนที่สนใจทั้งหมด แต่ในระหว่างนี้ โปรดส่งปัญหาของคุณและดึงคำขอ และ/หรือติดตามการพัฒนาของโครงการบน GitHub
อัปเดตเมื่อวันที่ 13 สิงหาคม 2019: ปัจจุบันเป็นโครงการ Dapp เปลี่ยนชื่อเป็น โค้ดได้รับการเขียนใหม่ทั้งหมดใน Go และเอกสารประกอบได้รับการปรับปรุงอย่างมาก
Kubernetes
เครื่องมือโอเพ่นซอร์สสำเร็จรูปอีกตัวหนึ่งที่ได้รับการยอมรับอย่างมากในสภาพแวดล้อมแบบมืออาชีพก็คือ Kubernetes,คลัสเตอร์การจัดการนักเทียบท่า หัวข้อการใช้งานในการดำเนินงานโปรเจ็กต์ที่สร้างบน Docker นั้นอยู่นอกเหนือขอบเขตของรายงาน ดังนั้นการนำเสนอจึงจำกัดอยู่เพียงภาพรวมของคุณสมบัติที่น่าสนใจบางอย่าง
สำหรับการเปิดตัว Kubernetes นำเสนอ:
- การสอบสวนความพร้อม - ตรวจสอบความพร้อมของแอปพลิเคชันเวอร์ชันใหม่ (เพื่อเปลี่ยนการรับส่งข้อมูล)
- การอัปเดตแบบต่อเนื่อง - การอัปเดตรูปภาพตามลำดับในกลุ่มคอนเทนเนอร์ (การปิดระบบ การอัปเดต การเตรียมการเปิดตัว การสลับการรับส่งข้อมูล)
- การอัปเดตแบบซิงโครนัส - อัปเดตรูปภาพในคลัสเตอร์ด้วยวิธีการอื่น: ครั้งแรกที่ครึ่งหนึ่งของคอนเทนเนอร์จากนั้นในส่วนที่เหลือ
- เผยแพร่ canary - เปิดตัวอิมเมจใหม่บนคอนเทนเนอร์จำนวนจำกัด (น้อย) เพื่อติดตามความผิดปกติ
เนื่องจากการจัดส่งแบบต่อเนื่องไม่ได้เป็นเพียงการเปิดตัวเวอร์ชันใหม่เท่านั้น Kubernetes จึงมีความสามารถหลายประการสำหรับการบำรุงรักษาโครงสร้างพื้นฐานในภายหลัง เช่น การตรวจสอบและบันทึกคอนเทนเนอร์ในตัวสำหรับคอนเทนเนอร์ทั้งหมด การปรับขนาดอัตโนมัติ ฯลฯ ทั้งหมดนี้ใช้งานได้แล้วและกำลังรอเพียงความเหมาะสม การนำไปใช้ในกระบวนการของคุณ
คำแนะนำขั้นสุดท้าย
- ใช้นักเทียบท่า
- สร้างอิมเมจ Docker ของแอปพลิเคชันสำหรับทุกความต้องการของคุณ
- ปฏิบัติตามหลักการ “Infrastructure is code”
- เชื่อมโยง Git กับ Docker
- ควบคุมลำดับการเปิดตัว
- ใช้แพลตฟอร์มสำเร็จรูป (Kubernetes หรืออื่น ๆ )
วิดีโอและสไลด์
วิดีโอจากการแสดง (ประมาณหนึ่งชั่วโมง) (รายงานตัวเริ่มตั้งแต่นาทีที่ 5 - ตามลิงค์ไปเล่นตั้งแต่นาทีนี้).
การนำเสนอรายงาน:
PS
รายงานอื่น ๆ ในหัวข้อในบล็อกของเรา:
- «» (Dmitry Stolyarov; 27 พฤษภาคม 2019 ที่ DevOpsConf);
- «» (Dmitry Stolyarov; 8 พฤศจิกายน 2018 บน HighLoad++);
- «» (Dmitry Stolyarov; 7 พฤศจิกายน 2017 บน HighLoad++);
- «» (Dmitry Stolyarov; 6 มิถุนายน 2017 ที่ RootConf).
ที่มา: will.com