การทำให้ Jenkins หยุดทำงานแบบต่อเนื่องเป็นศูนย์ด้วย Terraform บน AWS

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

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

ในบทความนี้ เราจะพูดถึงส่วนหลังอย่างชัดเจน วิธีที่เราสามารถมีไปป์ไลน์การปรับใช้อย่างต่อเนื่องของเว็บแอปพลิเคชันสามระดับที่สร้างใน Node.js บน AWS Cloud โดยใช้ Terraform เป็นผู้ประสานงานโครงสร้างพื้นฐาน เราจะใช้ Jenkins สำหรับส่วนการปรับใช้อย่างต่อเนื่องและ Bitbucket เพื่อโฮสต์ codebase ของเรา

ที่เก็บรหัส

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

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

โครงสร้างของ repo มีดังนี้:

• API: รหัสสำหรับเลเยอร์ API
• เว็บ: รหัสสำหรับเว็บเลเยอร์
• Terraform: รหัสสำหรับการประสานโครงสร้างพื้นฐานโดยใช้ Terraform
• Jenkins: รหัสสำหรับผู้ประสานงานโครงสร้างพื้นฐานสำหรับเซิร์ฟเวอร์ Jenkins ที่ใช้สำหรับไปป์ไลน์ CI/CD

ตอนนี้เราเข้าใจสิ่งที่เราต้องปรับใช้แล้ว เรามาพูดถึงสิ่งที่เราต้องทำเพื่อปรับใช้แอปพลิเคชันนี้บน AWS จากนั้นเราจะพูดถึงวิธีสร้างส่วนนั้นของไปป์ไลน์ CI/CD

อบรูปภาพ

เนื่องจากเราใช้ Terraform สำหรับตัวประสานโครงสร้างพื้นฐาน การมีอิมเมจสำเร็จรูปสำหรับแต่ละระดับหรือแอปพลิเคชันที่คุณต้องการปรับใช้จึงเหมาะสมที่สุด และสำหรับสิ่งนั้น เราจะใช้ผลิตภัณฑ์อื่นจาก Hashicorp นั่นคือ Packer

Packer เป็นเครื่องมือโอเพนซอร์ซที่ช่วยในการสร้าง Amazon Machine Image หรือ AMI ซึ่งจะใช้สำหรับการปรับใช้บน AWS สามารถใช้สร้างอิมเมจสำหรับแพลตฟอร์มต่างๆ เช่น EC2, VirtualBox, VMware และอื่นๆ

นี่คือตัวอย่างวิธีการใช้ไฟล์กำหนดค่า Packer ( terraform/packer-ami-api.json ) เพื่อสร้าง AMI สำหรับเลเยอร์ API

 { "builders": [{ "type": "amazon-ebs", "region": "eu-west-1", "source_ami": "ami-844e0bf7", "instance_type": "t2.micro", "ssh_username": "ubuntu", "ami_name": "api-instance {{timestamp}}" }], "provisioners": [ { "type": "shell", "inline": ["mkdir api", "sudo apt-get update", "sudo apt-get -y install npm nodejs-legacy"], "pause_before": "10s" }, { "type": "file", "source" : "../api/", "destination" : "api" }, { "type": "shell", "inline": ["cd api", "npm install"], "pause_before": "10s" } ] }

และคุณต้องเรียกใช้คำสั่งต่อไปนี้เพื่อสร้าง AMI:

 packer build -machine-readable packer-ami-api.json

เราจะเรียกใช้คำสั่งนี้จาก Jenkins build ในบทความนี้ ในทำนองเดียวกัน เราจะใช้ไฟล์กำหนดค่า Packer ( terraform/packer-ami-web.json ) สำหรับเลเยอร์เว็บด้วยเช่นกัน

มาดูไฟล์กำหนดค่า Packer ด้านบนและทำความเข้าใจว่าไฟล์นั้นพยายามทำอะไร

1. ดังที่กล่าวไว้ก่อนหน้านี้ Packer สามารถใช้สร้างอิมเมจสำหรับหลายแพลตฟอร์ม และเนื่องจากเรากำลังปรับใช้แอปพลิเคชันของเรากับ AWS เราจะใช้ตัวสร้าง “amazon-ebs” เนื่องจากเป็นตัวสร้างที่ง่ายที่สุดในการเริ่มต้น
2. ส่วนที่สองของการกำหนดค่าจะใช้รายการของตัวจัดเตรียมซึ่งคล้ายกับสคริปต์หรือบล็อกโค้ดซึ่งคุณสามารถใช้กำหนดค่ารูปภาพของคุณได้
   • ขั้นตอนที่ 1 เรียกใช้ตัวจัดเตรียมเชลล์เพื่อสร้างโฟลเดอร์ API และติดตั้ง Node.js บนอิมเมจโดยใช้คุณสมบัติ inline ซึ่งเป็นชุดของคำสั่งที่คุณต้องการเรียกใช้
   • ขั้นตอนที่ 2 เรียกใช้ตัวจัดเตรียมไฟล์เพื่อคัดลอกซอร์สโค้ดของเราจากโฟลเดอร์ API ไปยังอินสแตนซ์
   • ขั้นตอนที่ 3 เรียกใช้ตัวจัดเตรียมเชลล์อีกครั้ง แต่คราวนี้ใช้คุณสมบัติสคริปต์เพื่อระบุไฟล์ (terraform/scripts/install_api_software.sh) ด้วยคำสั่งที่ต้องเรียกใช้
   • ขั้นตอนที่ 4 คัดลอกไฟล์กำหนดค่าไปยังอินสแตนซ์ที่จำเป็นสำหรับ Cloudwatch ซึ่งได้รับการติดตั้งในขั้นตอนต่อไป
   • ขั้นตอนที่ 5 เรียกใช้ตัวจัดเตรียมเชลล์เพื่อติดตั้งตัวแทน AWS Cloudwatch อินพุตของคำสั่งนี้จะเป็นไฟล์ปรับแต่งที่คัดลอกไว้ในขั้นตอนก่อนหน้า เราจะพูดถึงรายละเอียดเกี่ยวกับ Cloudwatch ในบทความต่อไป

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

การตั้งค่าการปรับใช้อย่างต่อเนื่องของเจนกินส์

ต่อไป เราจะพิจารณาการตั้งค่าเซิร์ฟเวอร์ Jenkins ซึ่งจะใช้สำหรับไปป์ไลน์ CI/CD ของเรา เราจะใช้ Terraform และ AWS ในการตั้งค่านี้เช่นกัน

รหัส Terraform สำหรับการตั้งค่า Jenkins อยู่ในโฟลเดอร์ jenkins/setup มาดูสิ่งที่น่าสนใจบางอย่างเกี่ยวกับการตั้งค่านี้กัน

1. ข้อมูลประจำตัว AWS: คุณสามารถระบุ ID คีย์การเข้าถึง AWS และคีย์การเข้าถึงแบบลับให้กับผู้ให้บริการ Terraform AWS ( instance.tf ) หรือคุณสามารถระบุตำแหน่งของไฟล์ข้อมูลรับรองให้กับคุณสมบัติ shared_credentials_file ในผู้ให้บริการ AWS
2. บทบาท IAM: เนื่องจากเราจะใช้งาน Packer และ Terraform จากเซิร์ฟเวอร์ Jenkins พวกเขาจะเข้าถึง S3, EC2, RDS, IAM, โหลดบาลานซ์ และบริการปรับขนาดอัตโนมัติบน AWS ดังนั้นไม่ว่าเราจะให้ข้อมูลประจำตัวของเราเกี่ยวกับ Jenkins for Packer & Terraform เพื่อเข้าถึงบริการเหล่านี้หรือเราสามารถสร้างโปรไฟล์ IAM ( iam.tf ) โดยใช้ซึ่งเราจะสร้างอินสแตนซ์ของ Jenkins
3. สถานะ Terraform: Terraform ต้องรักษาสถานะของโครงสร้างพื้นฐานไว้ที่ใดที่หนึ่งในไฟล์ และด้วย S3 ( backend.tf ) คุณสามารถรักษาไว้ที่นั่นได้ ดังนั้นคุณจึงสามารถทำงานร่วมกับเพื่อนร่วมงานคนอื่น ๆ และทุกคนสามารถเปลี่ยนแปลงและปรับใช้ได้ตั้งแต่อยู่ในสถานะ ถูกเก็บไว้ในที่ห่างไกล
4. คู่คีย์สาธารณะ/ส่วนตัว: คุณจะต้องอัปโหลดคีย์สาธารณะของคู่คีย์ของคุณพร้อมกับอินสแตนซ์ เพื่อให้คุณสามารถ ssh ลงในอินสแตนซ์ Jenkins ได้เมื่อพร้อมใช้งาน เราได้กำหนดทรัพยากร aws_key_pair ( key.tf ) ซึ่งคุณระบุตำแหน่งของกุญแจสาธารณะของคุณโดยใช้ตัวแปร Terraform

ขั้นตอนในการตั้งค่าเจนกินส์:

ขั้นตอนที่ 1: สำหรับการรักษาสถานะระยะไกลของ Terraform คุณจะต้องสร้างที่ฝากข้อมูลด้วยตนเองใน S3 ซึ่ง Terraform สามารถใช้ได้ นี่เป็นขั้นตอนเดียวที่ทำนอก Terraform ตรวจสอบให้แน่ใจว่าคุณเรียกใช้ AWS configure ก่อนเรียกใช้คำสั่งด้านล่างเพื่อระบุข้อมูลรับรอง AWS ของคุณ

 aws s3api create-bucket --bucket node-aws-jenkins-terraform --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1

ขั้นตอนที่ 2: เรียกใช้ terraform init การดำเนินการนี้จะเริ่มต้นสถานะและกำหนดค่าให้เก็บไว้ใน S3 และดาวน์โหลดปลั๊กอินของผู้ให้บริการ AWS

ขั้นตอนที่ 3: เรียกใช้ terraform apply การดำเนินการนี้จะตรวจสอบโค้ด Terraform ทั้งหมดและสร้างแผนและแสดงจำนวนทรัพยากรที่จะสร้างขึ้นหลังจากขั้นตอนนี้เสร็จสิ้น

ขั้นตอนที่ 4: พิมพ์ yes จากนั้นขั้นตอนก่อนหน้าจะเริ่มสร้างทรัพยากรทั้งหมด หลังจากคำสั่งเสร็จสิ้น คุณจะได้รับที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ Jenkins

ขั้นตอนที่ 5: Ssh ลงในเซิร์ฟเวอร์ Jenkins โดยใช้คีย์ส่วนตัวของคุณ ubuntu เป็นชื่อผู้ใช้เริ่มต้นสำหรับอินสแตนซ์ที่ได้รับการสนับสนุนจาก AWS EBS ใช้ที่อยู่ IP ที่ส่งคืนโดยคำสั่ง terraform apply

 ssh -i mykey [email protected]

ขั้นตอนที่ 6: เริ่ม Jenkins web UI โดยไปที่ http://34.245.4.73:8080 รหัสผ่านสามารถพบได้ที่ /var/lib/jenkins/secrets/initialAdminPassword

ขั้นตอนที่ 7: เลือก "ติดตั้งปลั๊กอินที่แนะนำ" และสร้างผู้ใช้ผู้ดูแลระบบสำหรับเจนกินส์

การตั้งค่า CI Pipeline ระหว่าง Jenkins และ Bitbucket

1. สำหรับสิ่งนี้ เราจำเป็นต้องติดตั้งปลั๊กอิน Bitbucket ใน Jenkins ไปที่ Manage Jenkins → Manage Plugins และจาก Plugins ที่ มีให้ ติดตั้ง Bitbucket plugin
2. ที่ด้าน repo Bitbucket ให้ไปที่ Settings → Webhooks เพิ่ม webhook ใหม่ เบ็ดนี้จะส่งการเปลี่ยนแปลงทั้งหมดในที่เก็บไปยังเจนกินส์ และจะทริกเกอร์ไปป์ไลน์

Jenkins ไปป์ไลน์ในการอบ/สร้างรูปภาพ

1. ขั้นตอนต่อไปคือการสร้างไปป์ไลน์ในเจนกินส์
2. ไปป์ไลน์แรกจะเป็นโปรเจ็กต์ Freestyle ซึ่งจะใช้สร้าง AMI ของแอปพลิเคชันโดยใช้ Packer
3. คุณต้องระบุข้อมูลประจำตัวและ URL สำหรับที่เก็บ Bitbucket ของคุณ

4. ระบุทริกเกอร์บิลด์

5. เพิ่มขั้นตอนการสร้างสองขั้นตอน ขั้นตอนแรกสำหรับการสร้าง AMI สำหรับโมดูลแอป และขั้นตอนอื่นๆ เพื่อสร้าง AMI สำหรับโมดูลเว็บ

6. เมื่อเสร็จแล้ว คุณสามารถบันทึกโปรเจ็กต์ Jenkins ได้ และตอนนี้ เมื่อคุณพุชอะไรก็ได้ไปยังที่เก็บ Bitbucket ของคุณ มันจะทริกเกอร์บิลด์ใหม่ในเจนกินส์ ซึ่งจะสร้าง AMI และพุชไฟล์ Terraform ที่มีหมายเลข AMI ของอิมเมจนั้นไปที่ บัคเก็ต S3 ที่คุณสามารถดูได้จากสองบรรทัดสุดท้ายในขั้นตอนการสร้าง

 echo 'variable "WEB_INSTANCE_AMI" { default = "'${AMI_ID_WEB}'" }' > amivar_web.tf aws s3 cp amivar_web.tf s3://node-aws-jenkins-terraform/amivar_web.tf

Jenkins Pipeline เพื่อทริกเกอร์ Terraform Script

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

1. เราสร้างโปรเจ็กต์ฟรีสไตล์เจนกินส์ nodejs-terraform ซึ่งจะเรียกใช้โค้ด Terraform เพื่อปรับใช้แอปพลิเคชัน
2. ขั้นแรกเราจะสร้างข้อมูลประจำตัวประเภท "ข้อความลับ" ในโดเมนข้อมูลรับรองส่วนกลาง ซึ่งจะใช้เป็นข้อมูลป้อนเข้าของสคริปต์ Terraform เนื่องจากเราไม่ต้องการฮาร์ดโค้ดรหัสผ่านสำหรับบริการ RDS ใน Terraform และ Git เราจึงส่งผ่านคุณสมบัตินั้นโดยใช้ข้อมูลประจำตัวของ Jenkins

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

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

6. ตอนนี้เราพร้อมที่จะเพิ่มขั้นตอนการสร้าง ซึ่งจะดาวน์โหลดไฟล์สคริปต์ Terraform ( amivar_api.tf และ amivar_web.tf ) ซึ่งถูกอัปโหลดไปยัง S3 โดยโครงการก่อนหน้าแล้วเรียกใช้โค้ด Terraform เพื่อสร้างแอปพลิเคชันทั้งหมดบน AWS

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

Terraform Zero Downtime Config สำหรับ AWS

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

สิ่งแรกคือ Terraform จัดเตรียมบล็อกการกำหนดค่าวงจรชีวิตสำหรับทรัพยากรที่คุณมีตัวเลือก create_before_destroy เป็นแฟล็ก ซึ่งหมายความว่า Terraform ควรสร้างทรัพยากรประเภทเดียวกันก่อนที่จะทำลายทรัพยากรปัจจุบัน

ตอนนี้เราใช้ประโยชน์จากคุณลักษณะนี้ในทรัพยากร aws_autoscaling_group และ aws_launch_configuration ดังนั้น aws_launch_configuration กำหนดค่าประเภทของอินสแตนซ์ EC2 ที่ควรได้รับการจัดเตรียมและวิธีที่เราติดตั้งซอฟต์แวร์บนอินสแตนซ์นั้น และทรัพยากร aws_autoscaling_group จะจัดเตรียมกลุ่มการปรับขนาดอัตโนมัติของ AWS

สิ่งที่น่าสนใจที่นี่คือทรัพยากรทั้งหมดใน Terraform ควรมีชื่อและประเภทที่ไม่ซ้ำกัน ดังนั้นหากคุณไม่มีชื่ออื่นสำหรับ aws_autoscaling_group และ aws_launch_configuration ใหม่ คุณจะไม่สามารถทำลายชื่อปัจจุบันได้

Terraform จัดการข้อจำกัดนี้โดยจัดเตรียมคุณสมบัติ name_prefix ให้กับทรัพยากร aws_launch_configuration เมื่อกำหนดคุณสมบัตินี้แล้ว Terraform จะเพิ่มส่วนต่อท้ายที่ไม่ซ้ำกันให้กับทรัพยากร aws_launch_configuration ทั้งหมด จากนั้นคุณสามารถใช้ชื่อเฉพาะนั้นเพื่อสร้างทรัพยากร aws_autoscaling_group

คุณสามารถตรวจสอบรหัสสำหรับทั้งหมดข้างต้นได้ใน terraform/autoscaling-api.tf

 resource "aws_launch_configuration" "api-launchconfig" { name_prefix = "api-launchconfig-" image_ instance_type = "t2.micro" security_groups = ["${aws_security_group.api-instance.id}"] user_data = "${data.template_file.api-shell-script.rendered}" iam_instance_profile = "${aws_iam_instance_profile.CloudWatchAgentServerRole-instanceprofile.name}" connection { user = "${var.INSTANCE_USERNAME}" private_key = "${file("${var.PATH_TO_PRIVATE_KEY}")}" } lifecycle { create_before_destroy = true } } resource "aws_autoscaling_group" "api-autoscaling" { name = "${aws_launch_configuration.api-launchconfig.name}-asg" vpc_zone_identifier = ["${aws_subnet.main-public-1.id}"] launch_configuration = "${aws_launch_configuration.api-launchconfig.name}" min_size = 2 max_size = 2 health_check_grace_period = 300 health_check_type = "ELB" load_balancers = ["${aws_elb.api-elb.name}"] force_delete = true lifecycle { create_before_destroy = true } tag { key = "Name" value = "api ec2 instance" propagate_at_launch = true } }

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

เพื่อแก้ปัญหานั้น aws_launch_configuration มีคุณสมบัติ user_data ซึ่งรองรับคุณสมบัติการปรับขนาดอัตโนมัติของ AWS user_data ซึ่งคุณสามารถส่งสคริปต์ใดๆ ที่คุณต้องการเรียกใช้เมื่อเริ่มต้นอินสแตนซ์ใหม่โดยเป็นส่วนหนึ่งของกลุ่มการปรับขนาดอัตโนมัติ ในตัวอย่างของเรา เราปรับแต่งบันทึกของเซิร์ฟเวอร์แอปและรอให้ข้อความเริ่มต้นปรากฏ คุณยังสามารถตรวจสอบเซิร์ฟเวอร์ HTTP และดูว่าเซิร์ฟเวอร์พร้อมใช้งานเมื่อใด

 until tail /var/log/syslog | grep 'node ./bin/www' > /dev/null; do sleep 5; done

นอกจากนั้น คุณยังสามารถเปิดใช้งานการตรวจสอบ ELB ในระดับทรัพยากร aws_autoscaling_group ซึ่งจะทำให้แน่ใจว่ามีการเพิ่มอินสแตนซ์ใหม่เพื่อผ่านการตรวจสอบ ELB ก่อนที่ Terraform จะทำลายอินสแตนซ์เก่า นี่คือลักษณะที่ ELB ตรวจสอบ API เลเยอร์ จะตรวจสอบปลายทาง /api/status เพื่อส่งคืนความสำเร็จ

 resource "aws_elb" "api-elb" { name = "api-elb" subnets = ["${aws_subnet.main-public-1.id}"] security_groups = ["${aws_security_group.elb-securitygroup.id}"] listener { instance_port = "${var.API_PORT}" instance_protocol = "http" lb_port = 80 lb_protocol = "http" } health_check { healthy_threshold = 2 unhealthy_threshold = 2 timeout = 3 target = "HTTP:${var.API_PORT}/api/status" interval = 30 } cross_zone_load_balancing = true connection_draining = true connection_draining_timeout = 400 tags { Name = "my-elb" } }

สรุปและขั้นตอนต่อไป

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

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

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

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

หากคุณสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงานของ Terraform และวิธีที่คุณสามารถปรับใช้กับ AWS โดยใช้เทคโนโลยีนี้ ฉันแนะนำ Terraform AWS Cloud: Sane Infrastructure Management ซึ่งเพื่อน Toptaler Radoslaw Szalski อธิบาย Terraform แล้วแสดงขั้นตอนที่จำเป็นในการกำหนดค่าหลาย -สภาพแวดล้อมและการตั้งค่า Terraform ที่พร้อมสำหรับการผลิตสำหรับทีม