การดำเนินการปรับใช้อย่างต่อเนื่องของเราบนแพลตฟอร์มของลูกค้า

พวกเราที่ True Engineering ได้จัดทำกระบวนการส่งมอบการอัพเดตไปยังเซิร์ฟเวอร์ของลูกค้าอย่างต่อเนื่องและต้องการแบ่งปันประสบการณ์นี้

ประการแรก เราได้พัฒนาระบบออนไลน์สำหรับลูกค้าและปรับใช้ในคลัสเตอร์ Kubernetes ของเราเอง ขณะนี้โซลูชันที่มีภาระงานสูงของเราได้ย้ายไปยังแพลตฟอร์มของลูกค้าแล้ว ซึ่งเราได้ตั้งค่ากระบวนการปรับใช้อย่างต่อเนื่องแบบอัตโนมัติเต็มรูปแบบ ด้วยเหตุนี้ เราจึงเร่งเวลาออกสู่ตลาด - การส่งมอบการเปลี่ยนแปลงต่อสภาพแวดล้อมของผลิตภัณฑ์

ในบทความนี้ เราจะพูดถึงทุกขั้นตอนของกระบวนการใช้งานต่อเนื่อง (CD) หรือการส่งมอบการอัปเดตไปยังแพลตฟอร์มของลูกค้า:

1. กระบวนการนี้เริ่มต้นอย่างไร?
2. การซิงโครไนซ์กับที่เก็บ Git ของลูกค้า
3. การประกอบแบ็กเอนด์และส่วนหน้า
4. การปรับใช้แอปพลิเคชันอัตโนมัติในสภาพแวดล้อมการทดสอบ
5. การปรับใช้อัตโนมัติกับ Prod.

เราจะแชร์รายละเอียดการตั้งค่าตลอดทาง

1. เริ่มซีดี

การปรับใช้อย่างต่อเนื่องเริ่มต้นด้วยการที่นักพัฒนาผลักดันการเปลี่ยนแปลงไปยังสาขาการเผยแพร่ของพื้นที่เก็บข้อมูล Git ของเรา

แอปพลิเคชันของเราทำงานบนสถาปัตยกรรมไมโครเซอร์วิส และส่วนประกอบทั้งหมดจะถูกจัดเก็บไว้ในที่เก็บข้อมูลเดียว ด้วยเหตุนี้ ไมโครเซอร์วิสทั้งหมดจึงถูกรวบรวมและติดตั้ง แม้ว่าจะมีการเปลี่ยนแปลงรายการใดรายการหนึ่งก็ตาม

เราจัดระเบียบงานผ่านที่เก็บข้อมูลเดียวด้วยเหตุผลหลายประการ:

• ง่ายต่อการพัฒนา - แอปพลิเคชันกำลังพัฒนาอย่างต่อเนื่อง ดังนั้นคุณจึงสามารถทำงานกับโค้ดทั้งหมดได้ในคราวเดียว
• ไปป์ไลน์ CI/CD เดียวที่รับประกันว่าแอปพลิเคชันในฐานะระบบเดียวผ่านการทดสอบทั้งหมดและถูกส่งไปยังสภาพแวดล้อมการใช้งานจริงของลูกค้า
• เราขจัดความสับสนในเวอร์ชัน - เราไม่จำเป็นต้องจัดเก็บแมปของเวอร์ชันไมโครเซอร์วิส และอธิบายการกำหนดค่าสำหรับไมโครเซอร์วิสแต่ละรายการในสคริปต์ Helm

2. การซิงโครไนซ์กับที่เก็บ Git ของซอร์สโค้ดของลูกค้า

การเปลี่ยนแปลงที่ทำจะถูกซิงโครไนซ์กับพื้นที่เก็บข้อมูล Git ของลูกค้าโดยอัตโนมัติ มีการกำหนดค่าแอสเซมบลีของแอปพลิเคชันซึ่งจะเปิดตัวหลังจากอัปเดตสาขาและปรับใช้เพื่อดำเนินการต่อ กระบวนการทั้งสองมีต้นกำเนิดในสภาพแวดล้อมจากที่เก็บ Git

เราไม่สามารถทำงานกับพื้นที่เก็บข้อมูลของลูกค้าได้โดยตรง เนื่องจากเราต้องการสภาพแวดล้อมของเราเองสำหรับการพัฒนาและการทดสอบ เราใช้พื้นที่เก็บข้อมูล Git ของเราเพื่อวัตถุประสงค์เหล่านี้ - มันถูกซิงโครไนซ์กับพื้นที่เก็บข้อมูล Git ของพวกเขา ทันทีที่นักพัฒนาโพสต์การเปลี่ยนแปลงไปยังสาขาที่เหมาะสมของพื้นที่เก็บข้อมูลของเรา GitLab จะพุชการเปลี่ยนแปลงเหล่านี้ให้กับลูกค้าทันที

หลังจากนี้คุณจะต้องทำการประกอบ ประกอบด้วยหลายขั้นตอน: การประกอบแบ็กเอนด์และส่วนหน้า การทดสอบ และการส่งมอบสู่การใช้งานจริง

3. การประกอบส่วนหลังและส่วนหน้า

การสร้างแบ็กเอนด์และฟรอนต์เอนด์เป็นงานสองงานคู่ขนานที่ดำเนินการในระบบ GitLab Runner การกำหนดค่าแอสเซมบลีดั้งเดิมนั้นอยู่ในที่เก็บเดียวกัน

บทช่วยสอนสำหรับการเขียนสคริปต์ YAML สำหรับการสร้างใน GitLab.

GitLab Runner รับโค้ดจากพื้นที่เก็บข้อมูลที่ต้องการ ประกอบด้วยคำสั่ง Java Application build และส่งไปยังรีจิสทรี Docker ที่นี่เราประกอบแบ็กเอนด์และฟรอนต์เอนด์ รับอิมเมจ Docker ซึ่งเราใส่ไว้ในที่เก็บฝั่งลูกค้า ในการจัดการอิมเมจ Docker ที่เราใช้ ปลั๊กอิน Gradle.

เราซิงโครไนซ์เวอร์ชันของรูปภาพของเรากับเวอร์ชันเผยแพร่ที่จะเผยแพร่ใน Docker เพื่อการทำงานที่ราบรื่น เราได้ทำการปรับเปลี่ยนหลายประการ:

1. คอนเทนเนอร์ไม่ได้ถูกสร้างขึ้นใหม่ระหว่างสภาพแวดล้อมการทดสอบและสภาพแวดล้อมการใช้งานจริง เราทำการกำหนดพารามิเตอร์เพื่อให้คอนเทนเนอร์เดียวกันสามารถทำงานกับการตั้งค่า ตัวแปรสภาพแวดล้อม และบริการทั้งหมด ทั้งในสภาพแวดล้อมการทดสอบและในการใช้งานจริงโดยไม่ต้องสร้างใหม่

2. หากต้องการอัปเดตแอปพลิเคชันผ่าน Helm คุณต้องระบุเวอร์ชันของแอปพลิเคชัน เราสร้างแบ็กเอนด์ ฟรอนท์เอนด์ และอัปเดตแอปพลิเคชัน ซึ่งเป็นงานที่แตกต่างกันสามงาน ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องใช้แอปพลิเคชันเวอร์ชันเดียวกันในทุกที่ สำหรับงานนี้ เราใช้ข้อมูลจากประวัติ Git เนื่องจากการกำหนดค่าคลัสเตอร์ K8S และแอปพลิเคชันของเราอยู่ในพื้นที่เก็บข้อมูล Git เดียวกัน

เราได้รับเวอร์ชันของแอปพลิเคชันจากผลการดำเนินการคำสั่ง
git describe --tags --abbrev=7.

4. การปรับใช้การเปลี่ยนแปลงทั้งหมดกับสภาพแวดล้อมการทดสอบ (UAT) โดยอัตโนมัติ

ขั้นตอนถัดไปในสคริปต์บิลด์นี้คือการอัปเดตคลัสเตอร์ K8S โดยอัตโนมัติ กรณีนี้เกิดขึ้นโดยมีเงื่อนไขว่าแอปพลิเคชันทั้งหมดได้ถูกสร้างขึ้น และสิ่งประดิษฐ์ทั้งหมดได้รับการเผยแพร่ไปยัง Docker Registry หลังจากนี้ การอัปเดตสภาพแวดล้อมการทดสอบจะเริ่มต้นขึ้น

การอัปเดตคลัสเตอร์เริ่มต้นใช้งานแล้ว อัพเดตหมวกกันน็อค. หากเป็นผลให้ มีบางอย่างไม่เป็นไปตามแผน Helm จะย้อนกลับการเปลี่ยนแปลงทั้งหมดโดยอัตโนมัติและเป็นอิสระ งานของเขาไม่จำเป็นต้องถูกควบคุม

เราจัดหาการกำหนดค่าคลัสเตอร์ K8S พร้อมกับชุดประกอบ ดังนั้น ขั้นตอนต่อไปคือการอัปเดต: configMaps, การใช้งาน, บริการ, ข้อมูลลับ และการกำหนดค่า K8S อื่นๆ ที่เราเปลี่ยนแปลง

จากนั้น Helm จะรันการอัปเดต RollOut ของแอปพลิเคชันเองในสภาพแวดล้อมการทดสอบ ก่อนนำแอปพลิเคชันไปใช้งานจริง การทำเช่นนี้เพื่อให้ผู้ใช้สามารถทดสอบคุณลักษณะทางธุรกิจที่เราใส่ไว้ในสภาพแวดล้อมการทดสอบได้ด้วยตนเอง

5. ปรับใช้การเปลี่ยนแปลงทั้งหมดกับผลิตภัณฑ์โดยอัตโนมัติ

หากต้องการปรับใช้การอัปเดตในสภาพแวดล้อมการผลิต คุณเพียงแค่คลิกปุ่มเดียวใน GitLab และคอนเทนเนอร์จะถูกส่งไปยังสภาพแวดล้อมการผลิตทันที

แอปพลิเคชันเดียวกันสามารถทำงานได้ในสภาพแวดล้อมที่แตกต่างกัน ทั้งการทดสอบและการใช้งานจริง โดยไม่ต้องสร้างใหม่ เราใช้สิ่งประดิษฐ์เดียวกันโดยไม่มีการเปลี่ยนแปลงใดๆ ในแอปพลิเคชัน และเราตั้งค่าพารามิเตอร์จากภายนอก

การกำหนดพารามิเตอร์ที่ยืดหยุ่นของการตั้งค่าแอปพลิเคชันจะขึ้นอยู่กับสภาพแวดล้อมที่แอปพลิเคชันจะถูกดำเนินการ เราได้ย้ายการตั้งค่าสภาพแวดล้อมทั้งหมดไปภายนอก: ทุกอย่างได้รับการกำหนดพารามิเตอร์ผ่านการกำหนดค่า K8S และพารามิเตอร์ Helm เมื่อ Helm ปรับใช้แอสเซมบลีกับสภาพแวดล้อมการทดสอบ การตั้งค่าการทดสอบจะถูกนำไปใช้กับมัน และการตั้งค่าผลิตภัณฑ์จะถูกนำไปใช้กับสภาพแวดล้อมการผลิต

สิ่งที่ยากที่สุดคือการกำหนดพารามิเตอร์บริการและตัวแปรที่ใช้ทั้งหมดซึ่งขึ้นอยู่กับสภาพแวดล้อม และแปลเป็นตัวแปรสภาพแวดล้อมและการกำหนดค่าคำอธิบายของพารามิเตอร์สภาพแวดล้อมสำหรับ Helm

การตั้งค่าแอปพลิเคชันใช้ตัวแปรสภาพแวดล้อม ค่าของพวกเขาถูกตั้งค่าในคอนเทนเนอร์โดยใช้ K8S configmap ซึ่งสร้างเทมเพลตโดยใช้เทมเพลต Go ตัวอย่างเช่น การตั้งค่าตัวแปรสภาพแวดล้อมให้กับชื่อโดเมนสามารถทำได้ดังนี้:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – ตัวแปรนี้เก็บชื่อของสภาพแวดล้อม (prod, stage, UAT)
.Values.app.properties.app_external_domain – ในตัวแปรนี้ เราตั้งค่าโดเมนที่ต้องการในไฟล์ .Values.yaml

เมื่ออัปเดตแอปพลิเคชัน Helm จะสร้างไฟล์ configmap.yaml จากเทมเพลตและเติมค่า APP_EXTERNAL_DOMAIN ด้วยค่าที่ต้องการ ขึ้นอยู่กับสภาพแวดล้อมที่การอัปเดตแอปพลิเคชันเริ่มต้น ตัวแปรนี้ได้รับการตั้งค่าไว้ในคอนเทนเนอร์แล้ว สามารถเข้าถึงได้จากแอปพลิเคชัน ดังนั้นแต่ละสภาพแวดล้อมของแอปพลิเคชันจะมีค่าที่แตกต่างกันสำหรับตัวแปรนี้

เมื่อไม่นานมานี้ การสนับสนุน K8S ปรากฏใน Spring Cloud รวมถึงการทำงานกับ configMaps: สปริงคลาวด์ Kubernetes. ในขณะที่โครงการกำลังพัฒนาและเปลี่ยนแปลงอย่างรุนแรง แต่เราไม่สามารถใช้มันในการผลิตได้ แต่เราตรวจสอบสภาพของมันอย่างแข็งขันและใช้ในการกำหนดค่า DEV ทันทีที่มันเสถียร เราจะเปลี่ยนจากการใช้ตัวแปรสภาพแวดล้อมมาใช้

เบ็ดเสร็จ

ดังนั้น Continue Deployment จึงได้รับการกำหนดค่าและใช้งานได้ การอัปเดตทั้งหมดเกิดขึ้นด้วยการกดแป้นพิมพ์เพียงครั้งเดียว การส่งมอบการเปลี่ยนแปลงสภาพแวดล้อมของผลิตภัณฑ์จะเป็นไปโดยอัตโนมัติ และที่สำคัญการอัพเดตไม่ได้หยุดระบบ

แผนในอนาคต: การย้ายฐานข้อมูลอัตโนมัติ

เราคิดถึงการอัปเกรดฐานข้อมูลและความเป็นไปได้ในการย้อนกลับการเปลี่ยนแปลงเหล่านี้ ท้ายที่สุดแล้ว แอปพลิเคชันสองเวอร์ชันที่แตกต่างกันกำลังทำงานในเวลาเดียวกัน: เวอร์ชันเก่ากำลังทำงานอยู่ และเวอร์ชันใหม่เริ่มทำงาน และเราจะปิดอันเก่าเมื่อเราแน่ใจว่าเวอร์ชันใหม่ใช้งานได้เท่านั้น การย้ายฐานข้อมูลควรอนุญาตให้คุณทำงานกับแอปพลิเคชันทั้งสองเวอร์ชันได้

ดังนั้นเราจึงไม่สามารถเปลี่ยนชื่อคอลัมน์หรือข้อมูลอื่นๆ เพียงอย่างเดียวได้ แต่เราสามารถสร้างคอลัมน์ใหม่ คัดลอกข้อมูลจากคอลัมน์เก่าลงไปแล้วเขียนทริกเกอร์ที่เมื่ออัปเดตข้อมูลจะคัดลอกและอัปเดตในอีกคอลัมน์หนึ่งไปพร้อมๆ กัน และหลังจากการปรับใช้แอปพลิเคชันเวอร์ชันใหม่สำเร็จ หลังจากระยะเวลาการสนับสนุนหลังการเปิดตัว เราจะสามารถลบคอลัมน์เก่าและทริกเกอร์ที่ไม่จำเป็นออกไปได้

หากแอปพลิเคชันเวอร์ชันใหม่ทำงานไม่ถูกต้อง เราสามารถย้อนกลับไปเป็นเวอร์ชันก่อนหน้าได้ รวมถึงเวอร์ชันก่อนหน้าของฐานข้อมูลด้วย กล่าวโดยสรุป การเปลี่ยนแปลงของเราจะทำให้คุณสามารถทำงานพร้อมกันกับแอปพลิเคชันหลายเวอร์ชันได้

เราวางแผนที่จะทำให้การย้ายฐานข้อมูลเป็นอัตโนมัติผ่านงาน K8S โดยรวมเข้ากับกระบวนการซีดี และเราจะแบ่งปันประสบการณ์นี้กับHabréอย่างแน่นอน

ที่มา: will.com