Η επερχόμενη κυκλοφορία του Red Hat Ansible Engine 2.9 φέρνει συναρπαστικές βελτιώσεις, μερικές από τις οποίες συζητούνται σε αυτό το άρθρο. Όπως πάντα, αναπτύσσουμε ανοιχτά βελτιώσεις στο Ansible Network, με την υποστήριξη της κοινότητας. Ελάτε μαζί μας - ρίξτε μια ματιά και μελέτη του σχεδίου ανάπτυξης για στη σελίδα wiki για .
Όπως ανακοινώσαμε πρόσφατα, τώρα περιλαμβάνει Ansible Tower, Ansible Engine και όλο το περιεχόμενο του Ansible Network. Σήμερα, οι πιο δημοφιλείς πλατφόρμες δικτύωσης υλοποιούνται μέσω των μονάδων Ansible. Για παράδειγμα:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Για μια πλήρη λίστα πλατφορμών που υποστηρίζονται πλήρως από τη Red Hat μέσω της συνδρομής Ansible Automation, .
Τι μάθαμε
Τα τελευταία τέσσερα χρόνια, μάθαμε πολλά για την ανάπτυξη μιας πλατφόρμας αυτοματισμού δικτύου. Το μάθαμε και αυτό как Τα τεχνουργήματα της πλατφόρμας χρησιμοποιούνται σε βιβλία και ρόλους Ansible από τελικούς χρήστες. Και να τι ανακαλύψαμε:
- Οι οργανισμοί αυτοματοποιούν συσκευές όχι μόνο από έναν, αλλά από πολλούς προμηθευτές.
- Ο αυτοματισμός δεν είναι μόνο τεχνικό φαινόμενο, αλλά και πολιτισμικό.
- Η αυτοματοποίηση δικτύων σε κλίμακα είναι πιο δύσκολη από ό,τι φαίνεται λόγω των θεμελιωδών αρχιτεκτονικών αρχών του σχεδιασμού αυτοματισμού.
Όταν συζητήσαμε τα μακροπρόθεσμα σχέδια ανάπτυξης μας πριν από ένα χρόνο, οι εταιρικοί πελάτες μας ζήτησαν τα εξής:
- Η συλλογή πληροφοριών πρέπει να τυποποιηθεί καλύτερα και να ευθυγραμμιστεί με τις ροές εργασίας αυτοματισμού σε όλες τις συσκευές.
- Η ενημέρωση των διαμορφώσεων στη συσκευή πρέπει επίσης να είναι τυποποιημένη και συνεπής, έτσι ώστε οι μονάδες Ansible να χειρίζονται το δεύτερο μισό του κύκλου μετά τη συλλογή στοιχείων.
- Χρειαζόμαστε αυστηρές και υποστηριζόμενες μεθόδους για τη μετατροπή της διαμόρφωσης της συσκευής σε δομημένα δεδομένα. Σε αυτή τη βάση, η πηγή της αλήθειας μπορεί να μετακινηθεί από τη συσκευή δικτύου.
Βελτιώσεις γεγονότων
Η συλλογή στοιχείων από συσκευές δικτύου που χρησιμοποιούν το Ansible συχνά συμβαίνει τυχαία. Οι πλατφόρμες που βασίζονται στο Web έχουν διαφορετικούς βαθμούς ικανότητας συλλογής στοιχείων, αλλά έχουν ελάχιστη ή καθόλου λειτουργικότητα για την ανάλυση και την τυποποίηση της αναπαράστασης δεδομένων σε ζεύγη κλειδιών-τιμών. Ανάγνωση Ken Celenza σχετικά με το πόσο δύσκολο και επίπονο μπορεί να είναι η ανάλυση και η τυποποίηση των πραγματικών δεδομένων.
Μπορεί να έχετε παρατηρήσει ότι δουλεύουμε στον ρόλο του Ansible Network Engine. Φυσικά, 24K λήψεις αργότερα, ο ρόλος του Network Engine έγινε γρήγορα ένας από τους πιο δημοφιλείς ρόλους Ansible στο Ansible Galaxy για σενάρια αυτοματισμού δικτύου. Πριν μεταφέρουμε μεγάλο μέρος αυτού στο Ansible 2.8 για να προετοιμαστούμε για ό,τι θα χρειαζόταν στο Ansible 2.9, αυτός ο ρόλος του Ansible παρείχε το πρώτο σύνολο εργαλείων που βοηθούσαν στην ανάλυση εντολών, τη διαχείριση εντολών και τη συλλογή δεδομένων για συσκευές δικτύου.
Εάν γνωρίζετε πώς να χρησιμοποιείτε το Network Engine, αυτός είναι ένας πολύ αποτελεσματικός τρόπος συλλογής, ανάλυσης και τυποποίησης δεδομένων γεγονότων για χρήση στο Ansible. Το μειονέκτημα αυτού του ρόλου είναι ότι πρέπει να δημιουργήσετε μια ολόκληρη δέσμη αναλυτών για κάθε πλατφόρμα και για όλες τις δραστηριότητες δικτύου. Για να καταλάβετε πόσο δύσκολο είναι να δημιουργήσετε, να στείλετε και να διατηρήσετε αναλυτές, ρίξτε μια ματιά από τα παιδιά της Cisco.
Με λίγα λόγια, η λήψη στοιχείων από συσκευές και η κανονικοποίησή τους σε ζεύγη κλειδιών-τιμών είναι απαραίτητη για την αυτοματοποίηση σε κλίμακα, αλλά η επίτευξη αυτού είναι δύσκολη όταν έχετε πολλούς προμηθευτές και πλατφόρμες δικτύου.
Κάθε λειτουργική μονάδα δεδομένων δικτύου στο Ansible 2.9 μπορεί τώρα να αναλύσει τη διαμόρφωση μιας συσκευής δικτύου και να επιστρέψει δομημένα δεδομένα - χωρίς πρόσθετες βιβλιοθήκες, ρόλους Ansible ή προσαρμοσμένους αναλυτές.
Από το Ansible 2.9, κάθε φορά που κυκλοφορεί μια ενημερωμένη λειτουργική μονάδα δικτύου, η λειτουργική μονάδα δεδομένων βελτιώνεται για να παρέχει δεδομένα σχετικά με αυτήν την ενότητα της διαμόρφωσης. Δηλαδή, η ανάπτυξη γεγονότων και ενοτήτων γίνεται πλέον με τον ίδιο ρυθμό και θα έχουν πάντα μια κοινή δομή δεδομένων.
Η διαμόρφωση των πόρων σε μια συσκευή δικτύου μπορεί να ανακτηθεί και να μετατραπεί σε δομημένα δεδομένα με δύο τρόπους. Και με τους δύο τρόπους, μπορείτε να συλλέξετε και να μεταμορφώσετε μια συγκεκριμένη λίστα πόρων χρησιμοποιώντας μια νέα λέξη-κλειδί gather_network_resources. Τα ονόματα των πόρων ταιριάζουν με τα ονόματα των μονάδων, κάτι που είναι πολύ βολικό.
Κατά τη συλλογή στοιχείων:
Χρησιμοποιώντας μια λέξη-κλειδί gather_facts μπορείτε να ανακτήσετε την τρέχουσα διαμόρφωση συσκευής στην αρχή του βιβλίου αναπαραγωγής και, στη συνέχεια, να τη χρησιμοποιήσετε σε ολόκληρο το βιβλίο αναπαραγωγής. Καθορίστε τους μεμονωμένους πόρους που θα ανακτηθούν από τη συσκευή.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueΜπορεί να έχετε παρατηρήσει κάτι νέο σε αυτά τα παραδείγματα, δηλαδή - gather_facts: true είναι πλέον διαθέσιμο για εγγενή συλλογή στοιχείων για συσκευές δικτύου.
Χρησιμοποιώντας απευθείας τη λειτουργική μονάδα δεδομένων δικτύου:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesΤο playbook επιστρέφει τα ακόλουθα στοιχεία σχετικά με τη διεπαφή:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Παρατηρήστε πώς το Ansible ανακτά την εγγενή διαμόρφωση από τη συσκευή Arista και τη μετατρέπει σε δομημένα δεδομένα για χρήση ως τυπικά ζεύγη κλειδιών-τιμών για εργασίες και λειτουργίες μεταγενέστερης ροής.
Τα στοιχεία διεπαφής μπορούν να προστεθούν σε αποθηκευμένες μεταβλητές Ansible και να χρησιμοποιηθούν αμέσως ή αργότερα ως είσοδος σε μια ενότητα πόρων eos_interfaces χωρίς πρόσθετη επεξεργασία ή μετατροπή.
Ενότητες πόρων
Έτσι, εξάγαμε τα γεγονότα, κανονικοποιήσαμε τα δεδομένα, τα τοποθετήσαμε σε ένα τυποποιημένο διάγραμμα εσωτερικής δομής δεδομένων και λάβαμε μια έτοιμη πηγή αλήθειας. Ζήτω! Αυτό είναι υπέροχο, φυσικά, αλλά πρέπει να μετατρέψουμε με κάποιο τρόπο τα ζεύγη κλειδιών-τιμών πίσω στη συγκεκριμένη διαμόρφωση που αναμένει η συγκεκριμένη πλατφόρμα συσκευής. Τώρα χρειαζόμαστε ενότητες για συγκεκριμένες πλατφόρμες για να ανταποκριθούμε σε αυτές τις νέες απαιτήσεις συλλογής δεδομένων και κανονικοποίησης.
Τι είναι μια ενότητα πόρων; Μπορείτε να σκεφτείτε τις ενότητες διαμόρφωσης μιας συσκευής ως πόρους που παρέχονται από αυτήν τη συσκευή. Οι μονάδες πόρων δικτύου περιορίζονται σκόπιμα σε έναν μόνο πόρο και μπορούν να στοιβάζονται σαν δομικά στοιχεία για τη διαμόρφωση σύνθετων υπηρεσιών δικτύου. Ως αποτέλεσμα, οι απαιτήσεις και οι προδιαγραφές για μια ενότητα πόρων απλοποιούνται φυσικά, καθώς η ενότητα πόρων μπορεί να διαβάσει и να διαμορφώσετε μια συγκεκριμένη υπηρεσία δικτύου σε μια συσκευή δικτύου.
Για να εξηγήσουμε τι κάνει μια λειτουργική μονάδα πόρου, ας δούμε ένα παράδειγμα βιβλίου παιχνιδιού που δείχνει μια ανεπαρκή λειτουργία χρησιμοποιώντας νέα στοιχεία πόρων δικτύου και λειτουργική μονάδα eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedΌπως μπορείτε να δείτε, τα δεδομένα που συλλέγονται από τη συσκευή μεταφέρονται απευθείας στην αντίστοιχη μονάδα πόρων χωρίς μετατροπή. Κατά την εκκίνηση, το βιβλίο αναπαραγωγής ανακτά τιμές από τη συσκευή και τις συγκρίνει με τις αναμενόμενες. Σε αυτό το παράδειγμα, οι τιμές που επιστρέφονται είναι οι αναμενόμενες (δηλαδή, ελέγχει για αποκλίσεις διαμόρφωσης) και αναφέρει εάν η διαμόρφωση έχει αλλάξει.
Ο ιδανικός τρόπος ανίχνευσης μετατόπισης διαμόρφωσης είναι η αποθήκευση δεδομένων σε αποθηκευμένες μεταβλητές Ansible και η περιοδική χρήση τους με τη μονάδα πόρων σε λειτουργία επιθεώρησης. Αυτή είναι μια απλή μέθοδος για να δείτε εάν κάποιος έχει αλλάξει με μη αυτόματο τρόπο τις τιμές. Στις περισσότερες περιπτώσεις, οι οργανισμοί επιτρέπουν τις αλλαγές και τις ρυθμίσεις παραμέτρων με μη αυτόματο τρόπο, αν και πολλές λειτουργίες εκτελούνται μέσω του Ansible Automation.
Πώς διαφέρουν οι νέες ενότητες πόρων από τις προηγούμενες;
Για έναν μηχανικό αυτοματισμού δικτύου, υπάρχουν 3 κύριες διαφορές μεταξύ των μονάδων πόρων στο Ansible 2.9 και των προηγούμενων εκδόσεων.
1) Για έναν δεδομένο πόρο δικτύου (που μπορεί επίσης να θεωρηθεί ως τμήμα διαμόρφωσης), οι μονάδες και τα γεγονότα θα εξελιχθούν σε όλα τα υποστηριζόμενα λειτουργικά συστήματα δικτύου ταυτόχρονα. Πιστεύουμε ότι εάν το Ansible υποστηρίζει τη διαμόρφωση πόρων σε μία πλατφόρμα δικτύου, θα πρέπει να το υποστηρίζουμε παντού. Αυτό απλοποιεί τη χρήση των μονάδων πόρων, επειδή ένας μηχανικός αυτοματισμού δικτύου μπορεί τώρα να διαμορφώσει έναν πόρο (όπως το LLDP) σε όλα τα λειτουργικά συστήματα δικτύου με εγγενείς και υποστηριζόμενες μονάδες.
2) Οι μονάδες πόρων περιλαμβάνουν πλέον μια τιμή κατάστασης.
merged: η διαμόρφωση συγχωνεύεται με την παρεχόμενη διαμόρφωση (προεπιλογή).replaced: Η διαμόρφωση πόρων θα αντικατασταθεί με την παρεχόμενη διαμόρφωση.overridden: Η διαμόρφωση πόρων θα αντικατασταθεί με την παρεχόμενη διαμόρφωση. οι περιττές παρουσίες πόρων θα διαγραφούν.deleted: Η διαμόρφωση του πόρου θα διαγραφεί/επαναφερθεί στην προεπιλογή.
3) Οι μονάδες πόρων περιλαμβάνουν πλέον σταθερές τιμές επιστροφής. Όταν η μονάδα πόρων δικτύου έχει κάνει (ή προτείνει) τις απαραίτητες αλλαγές στη συσκευή δικτύου, επιστρέφει τα ίδια ζεύγη κλειδιού-τιμής στο βιβλίο αναπαραγωγής.
before: διαμόρφωση στη συσκευή με τη μορφή δομημένων δεδομένων πριν από την εργασία.after: εάν η συσκευή έχει αλλάξει (ή μπορεί να αλλάξει εάν χρησιμοποιηθεί η λειτουργία δοκιμής), η διαμόρφωση που προκύπτει θα επιστραφεί ως δομημένα δεδομένα.commands: Τυχόν εντολές διαμόρφωσης εκτελούνται στη συσκευή για να τη φέρουν στην επιθυμητή κατάσταση.
Τι σημαίνουν όλα αυτά; Γιατί είναι σημαντικό?
Αυτή η ανάρτηση καλύπτει πολλές περίπλοκες έννοιες, αλλά ελπίζουμε ότι στο τέλος θα έχετε καλύτερη κατανόηση του τι ζητούν οι εταιρικοί πελάτες στην πραγματικότητα για τη συλλογή, την κανονικοποίηση δεδομένων και τη διαμόρφωση βρόχου για μια πλατφόρμα αυτοματισμού. Γιατί όμως χρειάζονται αυτές τις βελτιώσεις; Πολλοί οργανισμοί επιδιώκουν τώρα τον ψηφιακό μετασχηματισμό για να κάνουν τα περιβάλλοντα πληροφορικής τους πιο ευέλικτα και ανταγωνιστικά. Καλώς ή κακώς, πολλοί μηχανικοί δικτύων γίνονται προγραμματιστές δικτύων είτε από προσωπικό συμφέρον είτε κατόπιν εντολής της διοίκησης.
Οι οργανισμοί συνειδητοποιούν ότι η αυτοματοποίηση μεμονωμένων προτύπων δικτύου δεν λύνει το πρόβλημα των σιλό και αυξάνει μόνο την απόδοση σε κάποιο βαθμό. Η Red Hat Ansible Automation Platform παρέχει αυστηρά και κανονιστικά μοντέλα δεδομένων πόρων για τη διαχείριση μέσω προγραμματισμού των υποκείμενων δεδομένων σε μια συσκευή δικτύου. Δηλαδή, οι χρήστες σταδιακά εγκαταλείπουν μεμονωμένες μεθόδους διαμόρφωσης υπέρ πιο σύγχρονων μεθόδων με έμφαση στις τεχνολογίες (για παράδειγμα, διευθύνσεις IP, VLAN, LLDP, κ.λπ.), παρά σε μια συγκεκριμένη υλοποίηση προμηθευτή.
Σημαίνει αυτό ότι οι ημέρες αξιόπιστων και αποδεδειγμένων μονάδων εντολών και διαμόρφωσης είναι μετρημένες; Σε καμία περίπτωση. Οι αναμενόμενες μονάδες πόρων δικτύου δεν θα είναι εφαρμόσιμες σε όλες τις περιπτώσεις ή για κάθε προμηθευτή, επομένως οι μονάδες εντολών και διαμόρφωσης θα εξακολουθούν να χρειάζονται από τους μηχανικούς δικτύου για ορισμένες υλοποιήσεις. Ο σκοπός των λειτουργικών μονάδων πόρων είναι να απλοποιήσουν μεγάλα πρότυπα Jinja και να ομαλοποιήσουν τις μη δομημένες διαμορφώσεις συσκευών σε μια δομημένη μορφή JSON. Με τις μονάδες πόρων, θα είναι ευκολότερο για τα υπάρχοντα δίκτυα να μετατρέψουν τη διαμόρφωσή τους σε δομημένα ζεύγη κλειδιών-τιμών που αντιπροσωπεύουν μια ευανάγνωστη πηγή αλήθειας. Χρησιμοποιώντας δομημένα ζεύγη κλειδιών-τιμών, μπορείτε να μετακινηθείτε από τις εκτελούμενες διαμορφώσεις σε κάθε συσκευή στην εργασία με ανεξάρτητα δομημένα δεδομένα και να φέρετε τα δίκτυα στην πρώτη γραμμή μιας προσέγγισης υποδομής ως κώδικα.
Ποιες ενότητες πόρων θα κυκλοφορήσουν στο Ansible Engine 2.9;
Πριν σας πούμε λεπτομερώς τι θα συμβεί στο Ansible 2.9, ας θυμηθούμε πώς χωρίσαμε ολόκληρο το εύρος εργασίας.
Προσδιορίσαμε 7 κατηγορίες και εκχωρήσαμε συγκεκριμένους πόρους δικτύου σε καθεμία:
Σημείωση: Οι πόροι με έντονους χαρακτήρες σχεδιάστηκαν και εφαρμόστηκαν στο Ansible 2.9.
Με βάση τα σχόλια από εταιρικούς πελάτες και την κοινότητα, ήταν λογικό να αντιμετωπιστούν πρώτα εκείνες οι ενότητες που σχετίζονται με πρωτόκολλα τοπολογίας δικτύου, εικονικοποίηση και διεπαφές.
Οι παρακάτω ενότητες πόρων αναπτύχθηκαν από την ομάδα του Ansible Network και αντιστοιχούν στις πλατφόρμες που υποστηρίζει η Red Hat:
Οι ακόλουθες ενότητες αναπτύσσονται από την κοινότητα Ansible:
exos_lldp_global- από την Extreme Networks.nxos_bfd_interfaces- από τη Cisconxos_telemetry- από τη Cisco
Όπως μπορείτε να δείτε, η έννοια των λειτουργικών μονάδων πόρων εντάσσεται στη στρατηγική μας με επίκεντρο την πλατφόρμα. Δηλαδή, περιλαμβάνουμε τις απαραίτητες δυνατότητες και λειτουργίες στο ίδιο το Ansible για να υποστηρίξουμε την τυποποίηση στην ανάπτυξη μονάδων δικτύου, καθώς και για να απλοποιήσουμε την εργασία των χρηστών σε επίπεδο ρόλων και βιβλίων Ansible. Για να επεκτείνει την ανάπτυξη των λειτουργικών μονάδων πόρων, η ομάδα Ansible κυκλοφόρησε το εργαλείο Module Builder.
Σχέδια για το Ansible 2.10 και μετά
Μόλις κυκλοφορήσει το Ansible 2.9, θα εργαστούμε για το επόμενο σύνολο μονάδων πόρων για το Ansible 2.10, το οποίο μπορεί να χρησιμοποιηθεί για την περαιτέρω διαμόρφωση της τοπολογίας και της πολιτικής δικτύου, π.χ. . Το σχέδιο ανάπτυξης μπορεί ακόμα να προσαρμοστεί, επομένως εάν έχετε σχόλια, παρακαλούμε να το αναφέρετε .
Πόροι και ξεκίνημα
Πηγή: www.habr.com