Rolling Updates, गति और Controllers

सब कुछ एक साथ update न करें

Production के लिए छोटे batches में update करें ताकि ख़राब बदलाव कुछ ही hosts को प्रभावित करे। serial: 2 (या प्रतिशत) play को एक बार में दो hosts पर चलाता है, और max_fail_percentage बहुत ज़्यादा विफल होने पर rollout रोक देता है। Batches के बीच health checks जोड़ें (status URL पर जाने को ansible.builtin.uri) और load-balanced services के लिए update से पहले hosts को rotation से निकालें। गति के लिए forks बढ़ाएँ, SSH pipelining और ControlPersist चालू करें, और ज़रूरत न हो तो facts इकट्ठा करना छोड़ें। टीमों के लिए AWX (open source) या Red Hat Ansible Automation Platform web UI, scheduling, credentials, RBAC और audit logs देते हैं।

Rolling update play

उदाहरण। किसी batch के 25% से ज़्यादा विफल हों तो बाक़ी hosts तक पहुँचने से पहले rollout रुक जाता है।

- name: Rolling update of web tier
  hosts: web
  serial: 2
  max_fail_percentage: 25
  become: true
  tasks:
    - name: Deploy new release
      ansible.builtin.include_role:
        name: app_deploy
    - name: Wait for health check
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:{{ http_port }}/health"
        status_code: 200
      register: health
      until: health.status == 200
      retries: 10
      delay: 3

एक canary host से शुरू करें

बदलाव पहले एक host (--limit web1) पर चलाएँ, जाँचें, फिर दायरा बढ़ाएँ। Canary तब समस्याएँ पकड़ता है जब असर का दायरा एक ही मशीन होती है।

त्वरित जाँच: `serial: 2` क्या करता है?

• Play को दो सेकंड तक सीमित करता है
• सिर्फ़ दो tasks चलाता है
• Play को एक बार में दो hosts पर चलाता है
• दो inventories बनाता है