Ansible'ı test etmeye nasıl başlanır, projeyi bir yıl içinde yeniden düzenler ve çıldırmazsınız

Bu transkript Kütüphaneler üzerinde DevOps-40 2020-03-18:

İkinci işlemden başlayarak herhangi bir kod eski hale gelir, çünkü İlk fikirler sert gerçeklikten uzaklaşmaya başlar. Bu ne iyi ne de kötü, tartışılması zor ve yaşanması gereken bir veri. Bu sürecin bir kısmı yeniden düzenlemedir. Altyapıyı Kod Olarak Yeniden Düzenleme. Ansible'ın bir yıl içinde nasıl yeniden düzenleneceğini ve çıldırmayacağını anlatan hikaye başlasın.

Mirasın Doğuşu

1. Gün: Sıfır Hasta

Bir zamanlar şartlı bir proje vardı. Bir Geliştirme geliştirme ekibi ve Operasyon mühendisleri vardı. Aynı sorunu çözüyorlardı: sunucuların nasıl dağıtılacağı ve bir uygulamanın nasıl çalıştırılacağı. Sorun, her takımın bu sorunu kendi yöntemiyle çözmesiydi. Projede Dev ve Ops ekipleri arasındaki bilgiyi senkronize etmek için Ansible'ın kullanılmasına karar verildi.

Gün #89: Mirasın Doğuşu

Kendileri farkına varmadan bunu mümkün olan en iyi şekilde yapmak istediler ama bunun bir miras olduğu ortaya çıktı. Bu nasıl oluyor?

• Burada acil bir görevimiz var, haydi kirli bir hack yapalım ve sonra düzeltelim.
• Belge yazmanıza gerek yok ve burada neler olduğu her şey açık.
• Ansible/Python/Bash/Terraform'u biliyorum! Bakın nasıl kaçabilirim!
• Ben bir Tam Yığın Taşması Geliştiricisiyim ve bunu stackoverflow'tan kopyaladım, nasıl çalıştığını bilmiyorum ama harika görünüyor ve sorunu çözüyor.

Sonuç olarak, hiçbir dokümantasyonu olmayan, ne yaptığı, gerekli olup olmadığı belli olmayan, anlaşılmaz bir kod türü elde edebilirsiniz, ancak sorun şu ki, onu geliştirmeniz, değiştirmeniz, koltuk değneği ve destek eklemeniz gerekiyor. durumu daha da kötüleştiriyor.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Gün #109: Sorunun Farkındalığı

Başlangıçta tasarlanan ve uygulanan IaC modeli artık kullanıcıların / işletmenin / diğer ekiplerin gereksinimlerini karşılamıyor ve altyapıda değişiklik yapma süresi artık kabul edilemez. Şu anda harekete geçme zamanının geldiği anlayışı geliyor.

IaC yeniden düzenleme

Gün #139: Gerçekten yeniden düzenlemeye ihtiyacınız var mı?

Yeniden düzenlemeye geçmeden önce bir dizi önemli soruyu yanıtlamanız gerekir:

1. Bütün bunlara neden ihtiyacın var?
2. Zamanın varmı?
3. Bilgi yeterli mi?

Sorulara nasıl cevap vereceğinizi bilmiyorsanız, yeniden düzenleme işlemi daha başlamadan sona erecek veya daha da kötüleşecektir. Çünkü tecrübem vardı ( 200 Satır Altyapı Kodunun Test Edilmesinden Öğrendiklerim), ardından proje, rolleri düzeltmek ve bunları testlerle kaplamak için yardım talebi aldı.

Gün #149: Yeniden düzenlemeye hazırlanma

İlk şey hazırlanmak. Ne yapacağımıza karar verin. Bunu yapmak için iletişim kurar, sorunlu alanları bulur ve bunları çözmenin yollarını buluruz. Ortaya çıkan kavramları bir şekilde kaydediyoruz, örneğin bir makaleyi bir araya getiriyoruz, böylece “en iyisi nedir?” sorusu ortaya çıkıyor. veya "hangisi doğru?" Biz yolumuzu kaybetmedik. Bizim durumumuzda bu fikre sadık kaldık böl ve yönet: Altyapıyı küçük parçalara/tuğlalara ayırıyoruz. Bu yaklaşım, izole edilmiş bir altyapı parçasını almanıza, ne yaptığını anlamanıza, testlerle kaplamanıza ve hiçbir şeyi bozma korkusu olmadan değiştirmenize olanak tanır.

Altyapı testinin temel taşı haline geldiği ortaya çıktı ve burada altyapı test piramidinden bahsetmeye değer. Geliştirme aşamasındaki fikrin tamamen aynısı, ancak altyapı için: Girinti gibi basit şeyleri kontrol eden ucuz hızlı testlerden, tüm altyapıyı dağıtan pahalı, tam teşekküllü testlere geçiyoruz.

Ansible test denemeleri

Projede Ansible testlerini nasıl ele aldığımızı anlatmaya geçmeden önce, alınan kararların bağlamını anlamak için daha önce kullanma fırsatı bulduğum girişimleri ve yaklaşımları anlatacağım.

Gün No. -997: SDS sağlanması

Ansible'ı ilk kez SDS (Yazılım Tanımlı Depolama) geliştirme projesinde test ettim. Bu konuyla ilgili ayrı bir makale var
Dağıtımınızı test ederken koltuk değneği üzerinden bisiklet nasıl kırılırama kısacası ters bir test piramidiyle karşılaştık ve testlerde tek bir rol üzerinde 60-90 dakika harcadık ki bu uzun bir süre. Temel e2e testleriydi, yani. Tam teşekküllü bir kurulumu devreye aldık ve ardından test ettik. Daha da ağırlaştırıcı olanı ise kendi bisikletinin icadıydı. Ancak itiraf etmeliyim ki bu çözüm işe yaradı ve kararlı bir sürüme izin verdi.

Gün # -701: Ansible ve test mutfağı

Ansible test fikrinin gelişimi, test kitchen / kitchen-ci ve inspec gibi hazır araçların kullanılmasıydı. Seçim Ruby bilgisine göre belirlendi (daha fazla ayrıntı için Habré hakkındaki makaleye bakın: YML programcıları Ansible'ı test etmeyi hayal ediyor mu?) daha hızlı çalıştı; 40 rol için yaklaşık 10 dakika. Bir paket sanal makine oluşturduk ve içinde testler yaptık.

Genel olarak çözüm işe yaradı ancak heterojenlik nedeniyle bir miktar tortu oluştu. Test edilen kişi sayısı 13 temel role ve daha küçük rolleri birleştiren 2 meta role çıkarıldığında, testler aniden 70 dakika boyunca yürütülmeye başlandı, bu da neredeyse 2 kat daha uzundu. XP (ekstrem programlama) uygulamalarından bahsetmek zordu çünkü... kimse 70 dakika beklemek istemez. Yaklaşımın değişmesinin nedeni buydu

Gün # -601: Ansible ve molekül

Kavramsal olarak bu testkitchen'a benzer, yalnızca rol testini docker'a taşıdık ve yığını değiştirdik. Sonuç olarak süre 20 rol için sabit 25-7 dakikaya düşürüldü.

Test edilen rol sayısını 17'ye çıkararak ve 45 rolü astarlayarak bunu 28 jenkins köle üzerinde 2 dakikada çalıştırdık.

Gün #167: Ansible testlerinin projeye eklenmesi

Büyük olasılıkla, yeniden düzenleme görevini aceleyle gerçekleştirmek mümkün olmayacaktır. Görev ölçülebilir olmalı ki onu küçük parçalara ayırıp bir çay kaşığıyla fili parça parça yiyebilesiniz. Doğru yönde ilerleyip ilerlemediğiniz, ne kadar süre ilerleyeceğiniz konusunda bir anlayışa sahip olmalısınız.

Genel olarak nasıl yapılacağı önemli değil, bir kağıda yazabilir, dolaba çıkartmalar yapıştırabilir, Jira'da görevler oluşturabilir veya Google Dokümanlar'ı açıp mevcut durumu yazabilirsiniz. Orası. İşlemin hemen olmaması nedeniyle bacaklar büyür, uzun ve sıkıcı olacaktır. Yeniden düzenleme sırasında kimsenin fikirleri tüketmenizi, yorulmanızı ve bunalmanızı istemesi pek olası değildir.

Yeniden düzenleme basittir:

• Yemek.
• Uyku.
• Kod.
• IaC testi.
• Tekrar et

ve amaçlanan hedefe ulaşana kadar bunu tekrarlıyoruz.

Her şeyi hemen test etmeye başlamak mümkün olmayabilir, bu nedenle ilk görevimiz, sözdizimini kontrol etmek ve astarlamakla başlamaktı.

Gün #181: Yeşil Yapı Ustası

Linting, Green Build Master'a doğru küçük bir ilk adımdır. Bu neredeyse hiçbir şeyi bozmaz ancak süreçlerde hata ayıklamanıza ve Jenkins'te yeşil yapılar oluşturmanıza olanak tanır. Buradaki fikir ekip içinde alışkanlıklar geliştirmektir:

• Kırmızı testler kötü.
• Bir şeyi düzeltmeye ve aynı zamanda kodu sizden öncekinden biraz daha iyi hale getirmeye geldim.

Gün #193: Linting'den ünite testlerine

Kodu ana programa alma sürecini oluşturduktan sonra, adım adım iyileştirme sürecine başlayabilirsiniz - astarlamayı rolleri başlatmakla değiştirerek, bunu boşluk olmadan bile yapabilirsiniz. Rollerin nasıl uygulanacağını ve nasıl çalıştığını anlamalısınız.

Gün #211: Birimden entegrasyon testlerine

Çoğu rol birim testleriyle kaplandığında ve her şey sınırlı olduğunda entegrasyon testleri eklemeye geçebilirsiniz. Onlar. Altyapıdaki tek bir tuğlayı değil, bunların bir kombinasyonunu, örneğin tam bir örnek yapılandırmasını test ediyoruz.

Jenkins'i kullanarak rolleri/oyun kitaplarını paralel olarak sıralayan birçok aşama oluşturduk, ardından kaplarda birim testleri ve son olarak entegrasyon testleri yaptık.

Jenkins + Docker + Ansible = Testler

1. Ödeme deposunu kontrol edin ve derleme aşamaları oluşturun.
2. Lint playbook aşamalarını paralel olarak çalıştırın.
3. Lint rolü aşamalarını paralel olarak çalıştırın.
4. Sözdizimi kontrolü rol aşamalarını paralel olarak çalıştırın.
5. Test rolü aşamalarını paralel olarak çalıştırın.
   1. Lint rolü.
   2. Diğer rollere bağımlılığı kontrol edin.
   3. Söz dizimini kontrol edin.
   4. Liman işçisi örneği oluştur
   5. Molekül/default/playbook.yml'yi çalıştırın.
   6. İdempotens'i kontrol edin.
6. Entegrasyon testlerini çalıştırın
7. Bitiş

Gün #271: Otobüs Faktörü

İlk başta yeniden düzenleme iki veya üç kişilik küçük bir grup tarafından gerçekleştirildi. Master'daki kodu incelediler. Zamanla ekip, kodun nasıl yazılacağına dair bilgi geliştirdi ve kod incelemesi, altyapı ve altyapının nasıl çalıştığına ilişkin bilgilerin yayılmasına katkıda bulundu. Burada öne çıkan nokta, incelemecilerin bir programa göre teker teker seçilmesiydi; bir dereceye kadar olasılıkla yeni bir altyapı parçasına tırmanacaksınız.

Ve burası rahat olmalı. Bir inceleme yapmak, hangi görevin yapıldığını ve tartışmaların geçmişini görmek uygundur. Jenkins + bitbucket + jira'yı entegre ettik.

Ancak bu haliyle inceleme her derde deva değil; bir şekilde ana koda girdik, bu da bizi flop testleri yaptı:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

Sonra tamir ettiler ama tortu kaldı.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

Gün #311: Testleri hızlandırmak

Zamanla daha fazla test yapıldı, derlemeler yavaşladı, en kötü durumda bir saate kadar çıktı. Retrolardan birinde “Testlerin olması iyi ama yavaş” gibi bir ifade vardı. Sonuç olarak sanal makineler üzerindeki entegrasyon testlerini bıraktık ve daha hızlı olması için bunları Docker'a uyarladık. Ayrıca kullanılan araç sayısını azaltmak için testinfra'yı ansible doğrulayıcıyla değiştirdik.

Açıkça söylemek gerekirse, bir dizi önlem vardı:

1. Docker'a geçin.
2. Bağımlılıklar nedeniyle kopyalanan rol testini kaldırın.
3. Köle sayısını artırın.
4. Test çalıştırması sırası.
5. Tüy bırakma yeteneği TÜM tek komutla yerel olarak.

Sonuç olarak Jenkins'teki Pipeline da birleştirildi

1. Yapım aşamaları oluşturun.
2. Hepsi paralel olarak lint.
3. Test rolü aşamalarını paralel olarak çalıştırın.
4. Finish.

Öğrenilen Dersler

Global değişkenlerden kaçının

Ansible global değişkenleri kullanıyor; formda kısmi bir geçici çözüm var özel_role_varsama bu her derde deva değil.

Sana bir örnek vereyim. Alalım role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

Komik olan şey, taktik kitaplarının sonucunun, rollerin listelenme sırası gibi her zaman açık olmayan şeylere bağlı olmasıdır. Ne yazık ki Ansible'ın doğası budur ve yapılabilecek en iyi şey bir tür anlaşma kullanmaktır; örneğin bir rol içerisinde yalnızca bu rolde açıklanan değişkeni kullanın.

KÖTÜ: global değişkeni kullanın.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

İYİ: V defaults gerekli değişkenleri tanımlayın ve daha sonra yalnızca bunları kullanın.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

Önek rol değişkenleri

KÖTÜ: global değişkeni kullanın.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

İYİ: Değişkenler için rollerde, rol adı ön eki olan değişkenleri kullanın; bu, envantere bakarak neler olduğunu anlamayı kolaylaştıracaktır.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

Döngü kontrol değişkenini kullan

KÖTÜ: Döngülerde standart değişkeni kullanın item, eğer bu görev/başvuru kitabı bir yere dahil edilmişse, bu beklenmeyen davranışlara yol açabilir

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

İYİ: Bir döngüdeki değişkeni aracılığıyla yeniden tanımlayın loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

Giriş değişkenlerini kontrol edin

Değişken öneklerini kullanmayı kabul ettik; bunların beklediğimiz gibi tanımlanıp tanımlanmadıklarını ve örneğin boş bir değer tarafından geçersiz kılınmadıklarını kontrol etmek gereksiz olmayacaktır.

İYİ: Değişkenleri kontrol edin.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

Karma sözlüklerden kaçının, düz yapı kullanın

Bir rol, parametrelerinden birinde karma/sözlük bekliyorsa, alt parametrelerden birini değiştirmek istersek, karma/sözlüğün tamamını geçersiz kılmamız gerekecektir, bu da yapılandırma karmaşıklığını artıracaktır.

KÖTÜ: Karma/sözlük kullanın.

---
user:
  name: admin
  group: admin

İYİ: Düz değişken yapısı kullanın.

---
user_name: admin
user_group: "{{ user_name }}"

Bağımsız oyun kitapları ve roller oluşturun

Roller ve taktikler bağımsız olmalıdır çünkü konfigürasyon kaymasını ve bir şeyin kırılma korkusunu azaltır. Ancak molekül kullanıyorsanız bu varsayılan davranıştır.

Komut kabuğu modüllerini kullanmaktan kaçının

Bir kabuk modülünün kullanılması, Ansible'ın özü olan bildirimsel olanın yerine zorunlu bir açıklama paradigmasıyla sonuçlanır.

Rollerinizi molekül aracılığıyla test edin

Molekül çok esnek bir şeydir, birkaç senaryoya bakalım.

Molekül Birden çok örnek

В molecule.yml kısımda platforms Dağıtabileceğiniz birçok ana bilgisayarı tanımlayabilirsiniz.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

Buna göre, bu ana bilgisayarlar daha sonra converge.yml kullanın:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

Yanıtlayıcı doğrulayıcı

Molekülde örneğin doğru şekilde yapılandırıldığını kontrol etmek için ansible'ı kullanmak mümkündür; ayrıca bu, sürüm 3'ten beri varsayılandır. testinfra/inspec kadar esnek değildir ancak dosya içeriğinin beklentilerimizle eşleşip eşleşmediğini kontrol edebiliriz:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

Veya hizmeti dağıtın, kullanılabilir olmasını bekleyin ve duman testi yapın:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

Modüllere ve eklentilere karmaşık mantık yerleştirin

Ansible bildirimsel bir yaklaşımı savunur; bu nedenle kod dallandırma, veri dönüşümü, kabuk modülleri yaptığınızda kodun okunması zorlaşır. Bununla mücadele etmek ve anlaşılmasını basit tutmak için, kendi modüllerinizi oluşturarak bu karmaşıklıkla mücadele etmek gereksiz olmayacaktır.

İpuçları ve Püf Noktalarını Özetleyin

1. Küresel değişkenlerden kaçının.
2. Önek rol değişkenleri.
3. Döngü kontrol değişkenini kullanın.
4. Giriş değişkenlerini kontrol edin.
5. Karma sözlüklerden kaçının, düz yapı kullanın.
6. Bağımsız oyun kitapları ve roller oluşturun.
7. Komut kabuğu modüllerini kullanmaktan kaçının.
8. Rollerinizi molekül aracılığıyla test edin.
9. Modüllere ve eklentilere karmaşık mantık ekleyin.

Sonuç

IaC'niz olsa bile bir projede altyapıyı öylece yeniden düzenleyemezsiniz. Bu sabır, zaman ve bilgi gerektiren uzun bir süreçtir.

Hızlı Linkler

• Slaytlar Ansible nasıl test edilir ve çıldırmayın
• Video Ansible nasıl test edilir ve çıldırmayın
• 200 Satır Altyapı Kodunun Test Edilmesinden Öğrendiklerim
• Ansible: 120 VM yapılandırmasının Coreos'tan Centos'a 18 ayda taşınması
• Dağıtımınızı test ederken koltuk değneği üzerinden bisiklet nasıl kırılır
• Yapabiliyorsanız beni test edin veya YML programcıları Ansible'ı test etmeyi hayal ediyor mu?
• Harika IaC test makaleleri, konuşmaları ve bağlantılarının listesi
• çapraz yazı
• İngilizce sürümü

UPD1 2020.05.01 20:30 — Başucu kitaplarının birincil profilini oluşturmak için şunları kullanabilirsiniz: callback_whitelist = profile_tasks uzun süre tam olarak neyin işe yaradığını anlamak için. Sonra geçiyoruz Ansible hızlandırma klasikleri. Ayrıca deneyebilirsiniz mitojenle
UPD2 2020.05.03 16:34 - İngilizce sürümü

Kaynak: habr.com