วิธีที่ง่ายและปลอดภัยในการปรับใช้ Canary โดยอัตโนมัติด้วย Helm

การปรับใช้ Canary เป็นวิธีที่มีประสิทธิภาพมากในการทดสอบโค้ดใหม่กับผู้ใช้กลุ่มย่อย ช่วยลดปริมาณการรับส่งข้อมูลที่อาจเป็นปัญหาระหว่างกระบวนการปรับใช้ได้อย่างมาก เนื่องจากจะเกิดขึ้นภายในกลุ่มย่อยบางกลุ่มเท่านั้น หมายเหตุนี้เกี่ยวกับวิธีจัดระเบียบการปรับใช้ดังกล่าวโดยใช้ Kubernetes และการปรับใช้อัตโนมัติ ซึ่งถือว่าคุณมีความรู้เกี่ยวกับทรัพยากร Helm และ Kubernetes อยู่บ้าง.



การทำให้ Canary ใช้งานได้อย่างง่ายกับ Kubernetes มีทรัพยากรหลัก XNUMX อย่าง ได้แก่ ตัวบริการและเครื่องมือการปรับใช้ การปรับใช้ Canary ทำงานผ่านบริการเดียวที่สื่อสารกับทรัพยากรที่แตกต่างกันสองแห่งซึ่งให้บริการการรับส่งข้อมูลการอัพเดท หนึ่งในทรัพยากรเหล่านี้จะทำงานร่วมกับเวอร์ชัน "canary" และเวอร์ชันที่สอง - กับเวอร์ชันที่เสถียร ในสถานการณ์นี้ เราสามารถปรับจำนวนเวอร์ชัน Canary เพื่อลดปริมาณการรับส่งข้อมูลที่จำเป็นสำหรับการบำรุงรักษา ตัวอย่างเช่น หากคุณต้องการใช้ Yaml ก็จะมีลักษณะเช่นนี้ใน Kubernetes:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector will route traffic to both deployments.

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

ระบบอัตโนมัติการปรับใช้ Canary

ก่อนอื่น เราต้องมีแผนที่แผนภูมิ Helm ซึ่งมีทรัพยากรที่กล่าวถึงข้างต้นอยู่แล้ว ควรมีลักษณะดังนี้:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

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

selector:
  app.kubernetes.io/name: myapp

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

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v1       # Goes into app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

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

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Goes into app.kubernetes.io/name
  --set app.version=v2       # Goes into app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

นั่นคือทั้งหมด! หากคุณ ping บริการ คุณจะเห็นว่าการอัปเดต canary จะกำหนดเส้นทางการรับส่งข้อมูลเพียงบางส่วนเท่านั้น

หากคุณกำลังมองหาเครื่องมือการปรับใช้อัตโนมัติที่มีตรรกะที่อธิบายไว้ ลองดูที่ บอทส่งของ และ เครื่องมือการทำงานอัตโนมัติของ Helm บน GitHub. แผนภูมิ Helm ที่ใช้ในการใช้วิธีการที่อธิบายไว้ข้างต้นอยู่ใน Github ตรงนี้. โดยทั่วไปแล้ว เป็นภาพรวมทางทฤษฎีของการนำการปรับใช้อัตโนมัติของเวอร์ชัน canary ไปใช้ในทางปฏิบัติ โดยมีแนวคิดและตัวอย่างเฉพาะ

ที่มา: will.com