Επιτάχυνση του Ansible

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

Εδώ και παρακάτω συζητάμε το Ansible 2.9.x, το οποίο εγκαταστάθηκε σε ένα πρόσφατα δημιουργημένο virtualenv με τον αγαπημένο σας τρόπο.

Μετά την εγκατάσταση, δημιουργήστε ένα αρχείο "ansible.cfg" δίπλα στο βιβλίο αναπαραγωγής σας - αυτή η τοποθεσία θα σας επιτρέψει να μεταφέρετε αυτές τις ρυθμίσεις μαζί με το έργο, καθώς και να φορτώνονται αρκετά αυτόματα.

Σωληνώσεις

Κάποιοι μπορεί να έχουν ήδη ακούσει για την ανάγκη χρήσης pipelining, δηλαδή όχι αντιγραφή μονάδων στο σύστημα αρχείων του συστήματος προορισμού, αλλά μεταφορά ενός αρχείου zip τυλιγμένο στο Base64 απευθείας στο stdin του διερμηνέα Python, αλλά άλλοι μπορεί όχι, αλλά το γεγονός παραμένει γεγονός: αυτή τη ρύθμιση παραμένει ακόμη υποτιμημένο. Δυστυχώς, ορισμένες από τις δημοφιλείς διανομές Linux που χρησιμοποιούνται για τη ρύθμιση του sudo δεν είναι πολύ καλά από προεπιλογή - έτσι ώστε αυτή η εντολή απαιτούσε ένα tty (τερματικό), οπότε ο Ansible άφησε αυτήν την πολύ χρήσιμη ρύθμιση απενεργοποιημένη από προεπιλογή.

pipelining = True

Συγκέντρωση στοιχείων

Γνωρίζατε ότι με τις προεπιλεγμένες ρυθμίσεις, το Ansible για κάθε παιχνίδι ξεκινά τη συλλογή στοιχείων για όλους τους οικοδεσπότες που συμμετέχουν σε αυτό; Γενικά, αν δεν ήξερες, τώρα ξέρεις. Για να μην συμβεί αυτό, πρέπει να ενεργοποιήσετε είτε τη λειτουργία ρητού αιτήματος για τη συλλογή γεγονότων (ρητά) είτε την έξυπνη λειτουργία. Σε αυτό, στοιχεία θα συλλέγονται μόνο από εκείνους τους οικοδεσπότες που δεν συναντήθηκαν σε προηγούμενα παιχνίδια.
UPD. Κατά την αντιγραφή, θα πρέπει να επιλέξετε μία από αυτές τις ρυθμίσεις.

gathering = smart|explicit

Επαναχρησιμοποίηση συνδέσεων ssh

Εάν έχετε εκτελέσει ποτέ το Ansible σε λειτουργία εντοπισμού σφαλμάτων (η επιλογή "v", επαναλαμβάνεται μία έως εννέα φορές), μπορεί να έχετε παρατηρήσει ότι οι συνδέσεις ssh γίνονται συνεχώς και διακόπτονται. Έτσι, υπάρχουν και εδώ μερικές λεπτές αποχρώσεις.

Μπορείτε να αποφύγετε το βήμα της επανεγκατάστασης μιας σύνδεσης ssh σε δύο επίπεδα ταυτόχρονα: τόσο απευθείας στο πρόγραμμα-πελάτη ssh όσο και κατά τη μεταφορά αρχείων στον διαχειριζόμενο κεντρικό υπολογιστή από τον διαχειριστή.
Για να χρησιμοποιήσετε ξανά μια ανοιχτή σύνδεση ssh, απλώς περάστε τα απαραίτητα κλειδιά στον πελάτη ssh. Στη συνέχεια θα αρχίσει να κάνει τα εξής: όταν δημιουργείτε μια σύνδεση ssh για πρώτη φορά, θα δημιουργήσει επιπλέον μια λεγόμενη υποδοχή ελέγχου, σε επόμενες εγκαταστάσεις, θα ελέγξει την ύπαρξη αυτής της υποδοχής και εάν είναι επιτυχής, θα επαναχρησιμοποιήσει την υπάρχουσα σύνδεση ssh. Και για να είναι λογικό όλο αυτό, ας ορίσουμε τον χρόνο διατήρησης της σύνδεσης όταν είναι ανενεργή. Μπορείτε να διαβάσετε περισσότερα στο τεκμηρίωση ssh, και στο πλαίσιο του Ansible χρησιμοποιούμε απλώς «προώθηση» των απαραίτητων επιλογών στον πελάτη ssh.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

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

transfer_method = piped

Παρεμπιπτόντως, στον κλάδο "ανάπτυξη" υπάρχει και αυτή η ρύθμιση να μην πάει πουθενά.

Μη φοβάσαι το μαχαίρι, φοβάσαι το πιρούνι

Μια άλλη χρήσιμη ρύθμιση είναι τα πιρούνια. Καθορίζει τον αριθμό των διεργασιών εργασίας που θα συνδεθούν ταυτόχρονα με τους κεντρικούς υπολογιστές και θα εκτελούν εργασίες. Λόγω των ιδιαιτεροτήτων της Python ως γλώσσας, χρησιμοποιούνται διεργασίες, όχι νήματα, επειδή το Ansible εξακολουθεί να υποστηρίζει την Python 2.7 - δεν υπάρχει asyncio για εσάς, δεν έχει νόημα να εισάγετε ασύγχρονη συμπεριφορά εδώ! Από προεπιλογή το Ansible εκτελείται πέντε εργαζόμενοι, αλλά αν ζητηθεί σωστά, θα ξεκινήσει περισσότερα:

forks = 20

Απλώς σας προειδοποιώ αμέσως ότι ενδέχεται να υπάρχουν κάποιες δυσκολίες που σχετίζονται με τη διαθέσιμη ποσότητα μνήμης στο μηχάνημα ελέγχου. Με άλλα λόγια, μπορείς φυσικά να ορίσεις forks=100500, αλλά ποιος είπε ότι θα λειτουργήσει;

Βάζοντάς τα όλα μαζί

Ως αποτέλεσμα, για το ansible.cfg (μορφή ini), οι απαραίτητες ρυθμίσεις μπορεί να φαίνονται ως εξής:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

Και αν θέλετε να κρύψετε τα πάντα σε έναν κανονικό κατάλογο YaML ενός υγιούς ατόμου, τότε μπορεί να μοιάζει κάπως έτσι:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Δυστυχώς, αυτό δεν θα λειτουργήσει με τις ρυθμίσεις "gathering = smart/explicit" και "forks = 20": τα ισοδύναμα YaML τους δεν υπάρχουν. Είτε τα ορίζουμε στο ansible.cfg είτε τα περνάμε από τις μεταβλητές περιβάλλοντος ANSIBLE_GATHERING και ANSIBLE_FORKS.

Σχετικά με το Mitogen
- Πού είναι αυτό για το Mitogen; - έχεις το δικαίωμα να ρωτήσεις, αγαπητέ αναγνώστη. Πουθενά σε αυτό το άρθρο. Αλλά αν είστε πραγματικά έτοιμοι να διαβάσετε τον κώδικά του και να καταλάβετε γιατί το playbook σας κολλάει με το Mitogen, αλλά λειτουργεί καλά με το Vanilla Ansible ή γιατί το ίδιο βιβλίο λειτουργούσε καλά πριν, αλλά μετά από μια ενημέρωση άρχισε να κάνει περίεργα πράγματα - καλά, το Mitogen θα μπορούσε ενδεχομένως να είναι το εργαλείο σας. Εφαρμόστε το, κατανοήστε το, γράψτε άρθρα - θα το διαβάσω με ενδιαφέρον.

Γιατί δεν χρησιμοποιώ προσωπικά το Mitogen; Επειδή το gladiolus λειτουργεί μόνο εφόσον οι εργασίες είναι πραγματικά απλές και όλα είναι καλά. Ωστόσο, αν στρίψετε λίγο προς τα αριστερά ή προς τα δεξιά - αυτό είναι, φτάσαμε: σε απάντηση, μια χούφτα αδιάκριτες εξαιρέσεις πετούν κατά πάνω σας και για να συμπληρώσετε την εικόνα, το μόνο που λείπει είναι η κοινή φράση "ευχαριστώ όλους σας , όλοι είναι ελεύθεροι». Γενικά, απλά δεν θέλω να χάσω χρόνο για να μάθω τους λόγους για το επόμενο "υπόγειο χτύπημα".

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

Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. Συνδεθείτε, Σας παρακαλούμε.

Ποιες από τις παρακάτω ρυθμίσεις Ansible χρησιμοποιείτε για να επιταχύνετε τα έργα σας;

  • 69,6%pipelining=true32

  • 34,8%συγκέντρωση = έξυπνος/ρητός16

  • 52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24

  • 17,4%transfer_method = σωλήνωση8

  • 63,0%πιρούνια = XXX29

  • 6,5%Τίποτα από αυτά, μόνο Mitogen3

  • 8,7%Mitogen + Θα σημειώσω ποια από αυτές τις ρυθμίσεις4

Ψήφισαν 46 χρήστες. 21 χρήστης απείχε.

Θέλετε περισσότερα πράγματα για το Ansible;

  • 78,3%ναι, φυσικά54

  • 21,7%ναι, θέλω απλώς περισσότερα σκληροπυρηνικά πράγματα!15

  • 0,0%όχι, και δεν είναι απαραίτητο για τίποτα0

  • 0,0%όχι, είναι περίπλοκο!!!0

Ψήφισαν 69 χρήστες. 7 χρήστες απείχαν.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο