🥇Πώς να ξεκινήσετε να δοκιμάζετε το Ansible, να αναδιαμορφώνετε ένα έργο σε ένα χρόνο και να μην τρελαίνεστε

Αυτή είναι η μεταγραφή παραστάσεις επί DevOps-40 2020-03-18:

Ξεκινώντας από το δεύτερο commit, οποιοσδήποτε κώδικας γίνεται κληρονομιά, γιατί οι αρχικές ιδέες αρχίζουν να αποκλίνουν από τη σκληρή πραγματικότητα. Αυτό δεν είναι ούτε καλό ούτε κακό, είναι δεδομένο με το οποίο είναι δύσκολο να διαφωνήσεις και πρέπει να το ζήσεις. Μέρος αυτής της διαδικασίας είναι η ανακατασκευή. Refactoring Infrastructure as Code. Αφήστε την ιστορία να ξεκινήσει για το πώς να αναμορφώσετε τον Ansible σε ένα χρόνο και να μην τρελαθείτε.

The Birth of Legacy

Ημέρα #1: Ασθενής Μηδέν

Μια φορά κι έναν καιρό υπήρχε ένα έργο υπό όρους. Είχε μια ομάδα ανάπτυξης Dev και μηχανικούς Ops. Έλυναν το ίδιο πρόβλημα: πώς να αναπτύξετε διακομιστές και να εκτελέσετε μια εφαρμογή. Το πρόβλημα ήταν ότι κάθε ομάδα έλυνε αυτό το πρόβλημα με τον δικό της τρόπο. Στο έργο, αποφασίστηκε να χρησιμοποιηθεί το Ansible για να συγχρονιστεί η γνώση μεταξύ των ομάδων Dev και Ops.

Ημέρα #89: Η Γέννηση της Κληρονομιάς

Χωρίς να το προσέξουν οι ίδιοι, ήθελαν να το κάνουν όσο το δυνατόν καλύτερα, αλλά αποδείχθηκε ότι ήταν κληρονομιά. Πώς συμβαίνει αυτό;

Έχουμε ένα επείγον καθήκον εδώ, ας κάνουμε ένα βρώμικο χακάρισμα και μετά ας το διορθώσουμε.
Δεν χρειάζεται να γράψετε τεκμηρίωση και όλα είναι ξεκάθαρα τι συμβαίνει εδώ.
Ξέρω τα Ansible/Python/Bash/Terraform! Κοίτα πώς μπορώ να αποφύγω!
Είμαι προγραμματιστής Full Stack Overflow και το έχω αντιγράψει από το stackoverflow, δεν ξέρω πώς λειτουργεί, αλλά φαίνεται ωραίο και λύνει το πρόβλημα.

Ως αποτέλεσμα, μπορείτε να πάρετε έναν ακατανόητο τύπο κώδικα για τον οποίο δεν υπάρχει τεκμηρίωση, δεν είναι σαφές τι κάνει, αν χρειάζεται, αλλά το πρόβλημα είναι ότι πρέπει να τον αναπτύξετε, να τον τροποποιήσετε, να προσθέσετε πατερίτσες και υποστηρίγματα , κάνοντας την κατάσταση ακόμα χειρότερη.

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

Ημέρα #109: Επίγνωση του προβλήματος

Το αρχικά σχεδιασμένο και εφαρμοσμένο μοντέλο IaC δεν ανταποκρίνεται πλέον στις απαιτήσεις των χρηστών / επιχειρήσεων / άλλων ομάδων και ο χρόνος για να γίνουν αλλαγές στην υποδομή παύει να είναι αποδεκτός. Αυτή τη στιγμή, έρχεται η κατανόηση ότι είναι ώρα να αναλάβουμε δράση.

Ανακατασκευή IaC

Ημέρα # 139: Χρειάζεστε πραγματικά ανακατασκευή;

Πριν βιαστείτε να κάνετε refactor, πρέπει να απαντήσετε σε ορισμένες σημαντικές ερωτήσεις:

Γιατί τα χρειάζεστε όλα αυτά;
Εχεις χρόνο?
Αρκεί η γνώση;

Εάν δεν ξέρετε πώς να απαντήσετε στις ερωτήσεις, τότε η αναδιαμόρφωση θα τελειώσει πριν καν αρχίσει ή μπορεί μόνο να χειροτερέψει. Επειδή είχε εμπειρία ( Τι έμαθα από τη δοκιμή 200 γραμμών κώδικα υποδομής), τότε το έργο έλαβε αίτημα βοήθειας για να διορθώσει τους ρόλους και να τους καλύψει με δοκιμές.

Ημέρα #149: Προετοιμασία της ανακατασκευής

Το πρώτο πράγμα είναι να προετοιμαστείτε. Αποφασίστε τι θα κάνουμε. Για να το κάνουμε αυτό, επικοινωνούμε, βρίσκουμε προβληματικές περιοχές και βρίσκουμε τρόπους επίλυσής τους. Καταγράφουμε τις έννοιες που προκύπτουν με κάποιο τρόπο, για παράδειγμα ένα άρθρο σε συρροή, έτσι ώστε όταν τίθεται το ερώτημα "τι είναι καλύτερο;" ή "ποιο είναι σωστό;" Δεν έχουμε χάσει το δρόμο μας. Στην περίπτωσή μας, μείναμε στην ιδέα Διαίρει και βασίλευε: χωρίζουμε την υποδομή σε μικρά κομμάτια/τούβλα. Αυτή η προσέγγιση σάς επιτρέπει να πάρετε ένα απομονωμένο κομμάτι υποδομής, να κατανοήσετε τι κάνει, να το καλύψετε με δοκιμές και να το αλλάξετε χωρίς να φοβάστε ότι θα σπάσετε οτιδήποτε.

Αποδεικνύεται ότι η δοκιμή υποδομής γίνεται ο ακρογωνιαίος λίθος και εδώ αξίζει να αναφερθεί η πυραμίδα δοκιμών υποδομής. Ακριβώς η ίδια ιδέα που βρίσκεται σε εξέλιξη, αλλά για την υποδομή: μεταβαίνουμε από φτηνές γρήγορες δοκιμές που ελέγχουν απλά πράγματα, όπως η εσοχή, σε ακριβές πλήρεις δοκιμές που αναπτύσσουν ολόκληρη την υποδομή.

Ανυπόφορες προσπάθειες δοκιμών

Πριν ξεκινήσουμε να περιγράψουμε πώς καλύψαμε τις δοκιμές Ansible στο έργο, θα περιγράψω τις προσπάθειες και τις προσεγγίσεις που είχα την ευκαιρία να χρησιμοποιήσω νωρίτερα για να κατανοήσω το πλαίσιο των αποφάσεων που ελήφθησαν.

Ημέρα Αρ. -997: Παροχή SDS

Η πρώτη φορά που δοκίμασα το Ansible ήταν σε ένα έργο ανάπτυξης SDS (Software Defined Storage). Υπάρχει ξεχωριστό άρθρο για αυτό το θέμα
Πώς να σπάσετε τα ποδήλατα πάνω από πατερίτσες κατά τη δοκιμή της διανομής σας, αλλά με λίγα λόγια, καταλήξαμε σε μια ανεστραμμένη πυραμίδα δοκιμών και δοκιμάζοντας αφιερώσαμε 60-90 λεπτά σε έναν ρόλο, που είναι πολύς χρόνος. Η βάση ήταν τα τεστ e2e, δηλ. αναπτύξαμε μια πλήρη εγκατάσταση και στη συνέχεια τη δοκιμάσαμε. Αυτό που ήταν ακόμη πιο επιβαρυντικό ήταν η εφεύρεση του δικού του ποδηλάτου. Αλλά πρέπει να ομολογήσω ότι αυτή η λύση λειτούργησε και επέτρεψε μια σταθερή απελευθέρωση.

Ημέρα # -701: Ansible και δοκιμαστική κουζίνα

Η ανάπτυξη της ιδέας των δοκιμών Ansible ήταν η χρήση έτοιμων εργαλείων, δηλαδή η δοκιμή κουζίνας / κουζίνας-ci και η επιθεώρηση. Η επιλογή καθορίστηκε από τη γνώση της Ruby (για περισσότερες λεπτομέρειες, δείτε το άρθρο στο Habré: Ονειρεύονται οι προγραμματιστές YML να δοκιμάσουν το Ansible;) δούλεψε πιο γρήγορα, περίπου 40 λεπτά για 10 ρόλους. Δημιουργήσαμε ένα πακέτο εικονικών μηχανών και πραγματοποιήσαμε δοκιμές μέσα.

Γενικά, το διάλυμα λειτούργησε, αλλά υπήρχε κάποιο ίζημα λόγω ετερογένειας. Όταν ο αριθμός των ατόμων που δοκιμάστηκαν αυξήθηκε σε 13 βασικούς ρόλους και 2 μετα-ρόλους που συνδυάζουν μικρότερους ρόλους, τότε ξαφνικά τα τεστ άρχισαν να τρέχουν για 70 λεπτά, δηλαδή σχεδόν 2 φορές περισσότερο. Ήταν δύσκολο να μιλήσουμε για πρακτικές XP (ακραίος προγραμματισμός) γιατί... κανείς δεν θέλει να περιμένει 70 λεπτά. Αυτός ήταν ο λόγος για την αλλαγή της προσέγγισης

Ημέρα # -601: Ansible και μόριο

Εννοιολογικά, αυτό είναι παρόμοιο με το testkitchen, μόνο που μεταφέραμε τη δοκιμή ρόλων στο docker και αλλάξαμε τη στοίβα. Ως αποτέλεσμα, ο χρόνος μειώθηκε στα σταθερά 20-25 λεπτά για 7 ρόλους.

Αυξάνοντας τον αριθμό των δοκιμασμένων ρόλων σε 17 και προσθέτοντας 45 ρόλους, το εκτελέσαμε σε 28 λεπτά σε 2 σκλάβους jenkins.

Ημέρα #167: Προσθήκη δοκιμών Ansible στο έργο

Πιθανότατα, δεν θα είναι δυνατό να γίνει η εργασία ανακατασκευής βιαστικά. Το έργο πρέπει να είναι μετρήσιμο, ώστε να μπορείτε να το σπάσετε σε μικρά κομμάτια και να φάτε τον ελέφαντα κομμάτι-κομμάτι με ένα κουταλάκι του γλυκού. Πρέπει να υπάρχει κατανόηση για το εάν κινείστε προς τη σωστή κατεύθυνση, πόσο καιρό πρέπει να πάτε.

Γενικά, δεν έχει σημασία πώς θα γίνει, μπορείτε να γράψετε σε ένα κομμάτι χαρτί, μπορείτε να βάλετε αυτοκόλλητα στο ντουλάπι, μπορείτε να δημιουργήσετε εργασίες στο Jira ή μπορείτε να ανοίξετε τα Έγγραφα Google και να σημειώσετε την τρέχουσα κατάσταση εκεί. Τα πόδια μεγαλώνουν από το γεγονός ότι η διαδικασία δεν είναι άμεση, θα είναι μακρά και κουραστική. Είναι απίθανο κάποιος να θέλει να ξεφύγετε από ιδέες, να κουραστείτε και να πνιγείτε κατά τη διάρκεια της ανακατασκευής.

Η ανακατασκευή είναι απλή:

Τρώω.
Κοιμηθείτε.
Κώδικας.
Δοκιμή IaC.
επαναλαμβάνω

και το επαναλαμβάνουμε μέχρι να φτάσουμε στον επιδιωκόμενο στόχο.

Ίσως να μην είναι δυνατό να ξεκινήσουμε να δοκιμάζουμε τα πάντα αμέσως, οπότε το πρώτο μας καθήκον ήταν να ξεκινήσουμε με το linting και τον έλεγχο της σύνταξης.

Ημέρα #181: Green Build Master

Το Linting είναι ένα μικρό πρώτο βήμα προς το Green Build Master. Αυτό δεν θα σπάσει σχεδόν τίποτα, αλλά θα σας επιτρέψει να διορθώσετε διεργασίες και να δημιουργήσετε πράσινες εκδόσεις στο Jenkins. Η ιδέα είναι να αναπτυχθούν συνήθειες μεταξύ της ομάδας:

Τα κόκκινα τεστ είναι κακά.
Ήρθα να φτιάξω κάτι και ταυτόχρονα να κάνω τον κώδικα λίγο καλύτερο από ό,τι ήταν πριν από εσάς.

Ημέρα #193: Από το lining στις δοκιμές μονάδας

Έχοντας δημιουργήσει τη διαδικασία εισαγωγής του κώδικα στο κύριο, μπορείτε να ξεκινήσετε τη διαδικασία βελτίωσης βήμα-βήμα - αντικαθιστώντας το linting με ρόλους εκκίνησης, μπορείτε ακόμη και να το κάνετε χωρίς ανικανότητα. Πρέπει να κατανοήσετε πώς να εφαρμόσετε τους ρόλους και πώς λειτουργούν.

Ημέρα #211: Από τη μονάδα στις δοκιμές ολοκλήρωσης

Όταν οι περισσότεροι ρόλοι καλύπτονται με δοκιμές μονάδας και όλα είναι γραμμωμένα, μπορείτε να προχωρήσετε στην προσθήκη δοκιμών ενοποίησης. Εκείνοι. δοκιμάζοντας όχι ένα μόνο τούβλο στην υποδομή, αλλά έναν συνδυασμό τους, για παράδειγμα, μια πλήρη διαμόρφωση παρουσίας.

Χρησιμοποιώντας jenkins, δημιουργήσαμε πολλά στάδια που περιείχαν παράλληλα ρόλους/βιβλία, μετά δοκιμές μονάδων σε κοντέινερ και, τέλος, δοκιμές ενσωμάτωσης.

Jenkins + Docker + Ansible = Δοκιμές

Check repo και δημιουργία σταδίων κατασκευής.
Εκτελέστε τα στάδια του lint playbook παράλληλα.
Εκτελέστε τα στάδια ρόλου χνούδι παράλληλα.
Εκτελέστε τα στάδια του ρόλου ελέγχου σύνταξης παράλληλα.
Εκτελέστε τα στάδια δοκιμαστικού ρόλου παράλληλα.
1. Ρόλος λιντ.
2. Ελέγξτε την εξάρτηση από άλλους ρόλους.
3. Ελέγξτε τη σύνταξη.
4. Δημιουργία παρουσίας docker
5. Εκτέλεση molecule/default/playbook.yml.
6. Ελέγξτε την ανικανότητα.
Εκτελέστε δοκιμές ενοποίησης
φινίρισμα

Ημέρα #271: Bus Factor

Στην αρχή, η ανακατασκευή πραγματοποιήθηκε από μια μικρή ομάδα δύο ή τριών ατόμων. Εξέτασαν τον κώδικα στο master. Με την πάροδο του χρόνου, η ομάδα ανέπτυξε γνώση του τρόπου σύνταξης κώδικα και αναθεώρησης κώδικα συνέβαλε στη διάδοση της γνώσης σχετικά με την υποδομή και τον τρόπο λειτουργίας της. Το αποκορύφωμα εδώ ήταν ότι οι κριτές επιλέχθηκαν ένας προς έναν, σύμφωνα με ένα χρονοδιάγραμμα, δηλ. με κάποιο βαθμό πιθανότητας θα σκαρφαλώσετε σε μια νέα υποδομή.

Και εδώ πρέπει να είναι άνετα. Είναι βολικό να κάνετε μια ανασκόπηση, να δείτε στο πλαίσιο της εργασίας που έγινε και το ιστορικό των συζητήσεων. Έχουμε ενσωματώσει jenkins + bitbucket + jira.

Αλλά ως εκ τούτου, μια αναθεώρηση δεν είναι πανάκεια· κατά κάποιο τρόπο, μπήκαμε στον κύριο κώδικα, που μας έκανε να κάνουμε δοκιμές flop:

- 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 }}"

Μετά το έφτιαξαν, αλλά το υπόλειμμα παρέμεινε.

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 }}"

Ημέρα #311: Επιτάχυνση δοκιμών

Με την πάροδο του χρόνου, έγιναν περισσότερες δοκιμές, οι κατασκευές έτρεχαν πιο αργά, έως και μια ώρα στη χειρότερη περίπτωση. Σε ένα από τα ρετρό υπήρχε μια φράση όπως "είναι καλό που υπάρχουν δοκιμές, αλλά είναι αργές". Ως αποτέλεσμα, εγκαταλείψαμε τις δοκιμές ενσωμάτωσης σε εικονικές μηχανές και τις προσαρμόσαμε για το Docker για να το κάνει πιο γρήγορο. Αντικαταστήσαμε επίσης το testinfra με έναν ήπιο επαληθευτή για να μειώσουμε τον αριθμό των εργαλείων που χρησιμοποιούνται.

Αυστηρά μιλώντας, υπήρχε ένα σύνολο μέτρων:

Μετάβαση σε docker.
Καταργήστε τη δοκιμή ρόλων, η οποία είναι διπλότυπη λόγω εξαρτήσεων.
Αυξήστε τον αριθμό των σκλάβων.
Δοκιμαστική σειρά.
Δυνατότητα χνούδι ΟΛΑ τοπικά με μία εντολή.

Ως αποτέλεσμα, ο Pipeline για τα jenkins ενοποιήθηκε επίσης

Δημιουργήστε στάδια κατασκευής.
Χνούδι όλα παράλληλα.
Εκτελέστε τα στάδια δοκιμαστικού ρόλου παράλληλα.
Φινίρισμα.

Διδάγματα

Αποφύγετε τις καθολικές μεταβλητές

Το Ansible χρησιμοποιεί καθολικές μεταβλητές, υπάρχει μια μερική λύση στη φόρμα private_role_vars, αλλά αυτό δεν είναι πανάκεια.

Επιτρέψτε μου να σας δώσω ένα παράδειγμα. Ας έχουμε 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}}

Το αστείο είναι ότι το αποτέλεσμα των βιβλίων παιχνιδιού θα εξαρτηθεί από πράγματα που δεν είναι πάντα προφανή, όπως η σειρά με την οποία παρατίθενται οι ρόλοι. Δυστυχώς, αυτή είναι η φύση του Ansible και το καλύτερο που μπορεί να γίνει είναι να χρησιμοποιήσετε κάποιο είδος συμφωνίας, για παράδειγμα, μέσα σε έναν ρόλο, να χρησιμοποιήσετε μόνο τη μεταβλητή που περιγράφεται σε αυτόν τον ρόλο.

BAD: χρήση καθολικής μεταβλητής.

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

ΚΑΛΗ: V defaults ορίστε τις απαραίτητες μεταβλητές και αργότερα χρησιμοποιήστε μόνο αυτές.

# 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

Μεταβλητές ρόλου προθέματος

BAD: χρήση καθολικής μεταβλητής.

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

ΚΑΛΗ: Στους ρόλους για μεταβλητές, χρησιμοποιήστε μεταβλητές με πρόθεμα το όνομα ρόλου· αυτό, κοιτάζοντας το απόθεμα, θα διευκολύνει την κατανόηση του τι συμβαίνει.

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

Χρησιμοποιήστε τη μεταβλητή ελέγχου βρόχου

BAD: Χρησιμοποιήστε τυπική μεταβλητή σε βρόχους item, εάν αυτή η εργασία/βιβλίο συμπεριληφθεί κάπου, αυτό μπορεί να οδηγήσει σε απροσδόκητη συμπεριφορά

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

ΚΑΛΗ: Επαναπροσδιορίστε μια μεταβλητή σε έναν βρόχο μέσω loop_var.

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

Ελέγξτε τις μεταβλητές εισόδου

Συμφωνήσαμε να χρησιμοποιήσουμε προθέματα μεταβλητών· δεν θα ήταν περιττό να ελέγξουμε ότι ορίζονται όπως αναμένουμε και, για παράδειγμα, δεν έχουν παρακαμφθεί από μια κενή τιμή

ΚΑΛΗ: Ελέγξτε τις μεταβλητές.

- 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

Αποφύγετε τα λεξικά κατακερματισμού, χρησιμοποιήστε επίπεδη δομή

Εάν ένας ρόλος αναμένει κατακερματισμό/λεξικό σε μία από τις παραμέτρους του, τότε αν θέλουμε να αλλάξουμε μία από τις θυγατρικές παραμέτρους, θα χρειαστεί να παρακάμψουμε ολόκληρο το κατακερματισμό/λεξικό, γεγονός που θα αυξήσει την πολυπλοκότητα της διαμόρφωσης.

BAD: Χρησιμοποιήστε κατακερματισμό/λεξικό.

---
user:
  name: admin
  group: admin

ΚΑΛΗ: Χρησιμοποιήστε μια επίπεδη μεταβλητή δομή.

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

Δημιουργήστε αδύναμα βιβλία και ρόλους

Οι ρόλοι και τα βιβλία πρέπει να είναι ανίκανα, γιατί μειώνει τη μετατόπιση της διαμόρφωσης και τον φόβο να σπάσει κάτι. Αλλά αν χρησιμοποιείτε μόριο, τότε αυτή είναι η προεπιλεγμένη συμπεριφορά.

Αποφύγετε τη χρήση μονάδων κελύφους εντολών

Η χρήση μιας ενότητας κελύφους έχει ως αποτέλεσμα ένα πρότυπο επιτακτικής περιγραφής, αντί για το δηλωτικό, που είναι ο πυρήνας του Ansible.

Δοκιμάστε τους ρόλους σας μέσω μορίου

Το μόριο είναι ένα πολύ ευέλικτο πράγμα, ας δούμε μερικά σενάρια.

Μόριο Πολλαπλές περιπτώσεις

В molecule.yml στο τμήμα platforms μπορείτε να περιγράψετε πολλούς κεντρικούς υπολογιστές που μπορείτε να αναπτύξετε.

---
    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

Κατά συνέπεια, αυτοί οι οικοδεσπότες μπορούν στη συνέχεια να είναι converge.yml χρήση:

---
- 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

Ανεξάρτητος επαληθευτής

Στο molecule είναι δυνατό να χρησιμοποιήσετε το ansible για να ελέγξετε ότι το στιγμιότυπο έχει ρυθμιστεί σωστά, επιπλέον, αυτή ήταν η προεπιλογή από την έκδοση 3. Δεν είναι τόσο ευέλικτο όσο το testinfra/inspec, αλλά μπορούμε να ελέγξουμε ότι τα περιεχόμενα του αρχείου ταιριάζουν με τις προσδοκίες μας:

---
- 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

Ή αναπτύξτε την υπηρεσία, περιμένετε να γίνει διαθέσιμη και κάντε μια δοκιμή καπνού:

---
  - 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

Βάλτε σύνθετη λογική σε modules & plugins

Το Ansible υποστηρίζει μια δηλωτική προσέγγιση, επομένως όταν κάνετε διακλάδωση κώδικα, μετασχηματισμό δεδομένων, λειτουργικές μονάδες κελύφους, ο κώδικας γίνεται δυσανάγνωστος. Για να το καταπολεμήσετε και να το διατηρήσετε απλό στην κατανόηση, δεν θα ήταν περιττό να καταπολεμήσετε αυτήν την πολυπλοκότητα δημιουργώντας τις δικές σας ενότητες.

Συνοψίστε Συμβουλές και κόλπα

Αποφύγετε τις καθολικές μεταβλητές.
Μεταβλητές ρόλου προθέματος.
Χρησιμοποιήστε τη μεταβλητή ελέγχου βρόχου.
Ελέγξτε τις μεταβλητές εισόδου.
Αποφύγετε τα λεξικά κατακερματισμού, χρησιμοποιήστε επίπεδη δομή.
Δημιουργήστε αδύναμα βιβλία και ρόλους.
Αποφύγετε τη χρήση μονάδων κελύφους εντολών.
Δοκιμάστε τους ρόλους σας μέσω μορίου.
Βάλτε σύνθετη λογική σε modules & plugins.

Συμπέρασμα

Δεν μπορείτε απλώς να πάτε και να αναδιαμορφώσετε την υποδομή σε ένα έργο, ακόμα κι αν έχετε IaC. Αυτή είναι μια μακρά διαδικασία που απαιτεί υπομονή, χρόνο και γνώση.

Links

UPD1 2020.05.01 20:30 — Για πρωταρχικό προφίλ βιβλίων που μπορείτε να χρησιμοποιήσετε callback_whitelist = profile_tasks για να καταλάβετε τι ακριβώς λειτουργεί για μεγάλο χρονικό διάστημα. Μετά περνάμε Κλασικά Ansible επιτάχυνση. Μπορείτε επίσης να δοκιμάσετε μιτογόνο
UPD2 2020.05.03 16:34 - Αγγλική έκδοση

Πηγή: www.habr.com

Πώς να ξεκινήσετε να δοκιμάζετε το Ansible, ανανεώστε το έργο σε ένα χρόνο και μην τρελαθείτε