हेलम के साथ कैनरी परिनियोजन को स्वचालित करने का एक सरल और सुरक्षित तरीका

उपयोगकर्ताओं के एक सबसेट पर नए कोड का परीक्षण करने के लिए कैनरी परिनियोजन एक बहुत प्रभावी तरीका है। यह ट्रैफ़िक लोड को महत्वपूर्ण रूप से कम कर देता है जो तैनाती के दौरान समस्याग्रस्त हो सकता है क्योंकि यह केवल एक विशिष्ट उपसमूह के भीतर होता है। यह नोट कुबेरनेट्स और परिनियोजन स्वचालन का उपयोग करके इस तरह की तैनाती को व्यवस्थित करने के तरीके के लिए समर्पित है। हम मानते हैं कि आप हेल्म और कुबेरनेट्स संसाधनों के बारे में कुछ जानते हैं.



कुबेरनेट्स में एक सरल कैनरी परिनियोजन में दो प्रमुख संसाधन शामिल हैं: सेवा स्वयं और परिनियोजन उपकरण। कैनरी परिनियोजन एक एकल सेवा के माध्यम से काम करता है जो अद्यतन ट्रैफ़िक प्रदान करने वाले दो अलग-अलग संसाधनों के साथ इंटरैक्ट करता है। इनमें से एक संसाधन "कैनरी" संस्करण के साथ काम करेगा, और दूसरा स्थिर संस्करण के साथ काम करेगा। इस स्थिति में, हम सेवा के लिए आवश्यक ट्रैफ़िक की मात्रा को कम करने के लिए कैनरी संस्करणों की संख्या को विनियमित कर सकते हैं। यदि, उदाहरण के लिए, आप यमल का उपयोग करना पसंद करते हैं, तो यह कुबेरनेट्स में इस तरह दिखेगा:

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 और in का उपयोग करके इस विकल्प की कल्पना करना और भी आसान है कुबेरनेट्स दस्तावेज़ीकरण इस परिदृश्य पर एक पूर्ण ट्यूटोरियल भी है। लेकिन इस पोस्ट का मुख्य प्रश्न यह है कि हम हेल्म का उपयोग करके इस प्रक्रिया को कैसे स्वचालित करेंगे।

कैनरी परिनियोजन का स्वचालन

सबसे पहले, हमें एक हेल्म चार्ट मानचित्र की आवश्यकता है, जिसमें पहले से ही वे संसाधन शामिल हैं जिनकी हमने ऊपर चर्चा की है। यह कुछ इस तरह दिखना चाहिए:

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

हेल्म अवधारणा का आधार बहु-संस्करण रिलीज़ का प्रबंधन है। स्थिर संस्करण हमारे प्रोजेक्ट कोड की मुख्य स्थिर शाखा है। लेकिन हेल्म के साथ हम अपने प्रायोगिक कोड के साथ कैनरी रिलीज़ को तैनात कर सकते हैं। मुख्य बात स्थिर संस्करण और कैनरी रिलीज़ के बीच ट्रैफ़िक विनिमय बनाए रखना है। हम एक विशेष चयनकर्ता का उपयोग करके यह सब प्रबंधित करेंगे:

selector:
  app.kubernetes.io/name: myapp

हमारे "कैनरी" और स्थिर परिनियोजन संसाधन मॉड्यूल पर इस लेबल को इंगित करेंगे। यदि सब कुछ सही ढंग से कॉन्फ़िगर किया गया है, तो हमारे हेल्म चार्ट मानचित्र के कैनरी संस्करण की तैनाती के दौरान हम देखेंगे कि ट्रैफ़िक को नए तैनात मॉड्यूल की ओर निर्देशित किया जाएगा। इस कमांड का स्थिर संस्करण इस तरह दिखेगा:

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

आइए अब हमारी कैनरी रिलीज़ की जाँच करें। कैनरी संस्करण को तैनात करने के लिए, हमें दो बातें याद रखनी होंगी। रिलीज़ नाम अलग होना चाहिए ताकि हम वर्तमान स्थिर संस्करण के लिए अपडेट रोल आउट न करें। संस्करण और टैग भी भिन्न होने चाहिए ताकि हम अन्य कोड को तैनात कर सकें और संसाधन टैग द्वारा अंतर की पहचान कर सकें।

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

बस इतना ही! यदि आप सेवा को पिंग करते हैं, तो आप देख सकते हैं कि कैनरी अपडेट ट्रैफ़िक को केवल कुछ समय के लिए रूट करता है।

यदि आप परिनियोजन स्वचालन उपकरण की तलाश कर रहे हैं जिसमें वर्णित तर्क शामिल हैं, तो ध्यान दें डिलिवरीबॉट और GitHub पर हेल्म स्वचालन उपकरण. ऊपर वर्णित विधि को लागू करने के लिए उपयोग किए जाने वाले हेल्म चार्ट जीथब पर हैं, यहां. सामान्य तौर पर, यह विशिष्ट अवधारणाओं और उदाहरणों के साथ व्यवहार में कैनरी संस्करणों की तैनाती के स्वचालन को कैसे लागू किया जाए, इसका एक सैद्धांतिक अवलोकन था।

स्रोत: www.habr.com