English · Ελληνικά
Το να ρυθμίζεις ένα switch στο χέρι είναι εντάξει. Το να ρυθμίζεις είκοσι με τον ίδιο τρόπο είναι το πώς μπαίνουν μέσα drift και τυπογραφικά. Το Ansible μετατρέπει το config σου σε κώδικα με version control που στέλνεις σε κάθε συσκευή ταυτόχρονα — με ένα dry-run που δείχνει ακριβώς τι θα αλλάξει πριν αγγίξει οτιδήποτε.
Το EEM αυτοματοποιεί μια μεμονωμένη συσκευή που αντιδρά στα δικά της γεγονότα. Το Ansible κάνει το αντίθετο: οργανώνει αλλαγή σε πολλές συσκευές από ένα μέρος. Είναι agentless — τίποτα δεν εγκαθίσταται στα switch· το Ansible απλώς κάνει SSH μέσα (χρησιμοποιώντας την πρόσβαση που έστησες στο First Contact) και τρέχει εντολές IOS μέσω της συλλογής cisco.ios. Η επιθυμητή ρύθμισή σου ζει ως YAML σε git, οπότε κάθε αλλαγή ελέγχεται, έχει version, και επαναλαμβάνεται.
Το όφελος είναι τριπλό: συνέπεια (η ίδια θωρακισμένη βάση και στα 20 switch, όχι 20 ελαφρώς-διαφορετικές χειροποίητες δουλειές), ταχύτητα (πρόσθεσε ένα VLAN σε όλο το site σε ένα run), και ασφάλεια (το mode --check δείχνει το ακριβές diff πριν εφαρμοστεί οτιδήποτε, και το git σου δίνει rollback). Αυτό είναι το εργαλείο που μετατρέπει το «διαχειριζόμαστε μερικά switch» σε «λειτουργούμε έναν στόλο». Ακόμα και για τα μέτρια sites που τρέχουμε, τη μέρα που χρειαστεί να στείλεις ένα fix ασφάλειας σε όλα ταυτόχρονα, θα χαρείς που το config είναι κώδικας.
pip install ansibleansible-galaxy collection install cisco.ios01
Το Ansible χρειάζεται να ξέρει ποιες συσκευές υπάρχουν και πώς να τις φτάσει. Το inventory λιστάρει hosts και groups· το group_vars κρατάει τις ρυθμίσεις σύνδεσης που μοιράζονται όλες οι συσκευές Cisco.
# Ομαδοποίησε τα switch ώστε ένα playbook να στοχεύει «όλα τα switch ταυτόχρονα» [access_switches] sw-01 ansible_host=192.168.99.11 sw-02 ansible_host=192.168.99.12 sw-03 ansible_host=192.168.99.13 [core_switches] core-01 ansible_host=192.168.99.1 [switches:children] access_switches core_switches
ansible_connection: ansible.netcommon.network_cli ansible_network_os: cisco.ios.ios ansible_user: ansible ansible_password: "{{ vault_ios_password }}" # από το Vault (ενότητα 05) ansible_become: true ansible_become_method: enable ansible_become_password: "{{ vault_enable_password }}"
02
Ποτέ μην ξεκινάς αυτοματισμό γράφοντας. Απόδειξε συνδεσιμότητα με ένα read-only run: μάζεψε facts από κάθε συσκευή, και κάνε backup κάθε config — ένα ασφαλές, χρήσιμο πρώτο playbook.
---
- name: Back up all switch configs
hosts: switches
gather_facts: false
tasks:
- name: Grab facts (model, version, uptime)
cisco.ios.ios_facts:
- name: Save running-config to a per-host file
cisco.ios.ios_config:
backup: true
backup_options:
filename: "{{ inventory_hostname }}.cfg"
dir_path: ./backups/
you@laptop:~$ ansible-playbook -i inventory.ini backup.yml PLAY [Back up all switch configs] **** ok: [sw-01] ok: [sw-02] ok: [core-01] ... you@laptop:~$ git add backups/ && git commit -m "nightly config snapshot" # Τώρα κάθε config συσκευής έχει version. Το diff δύο ημερών = «τι άλλαξε».
03
Η καρδιά του: περίγραψε το config που ΘΕΛΕΙΣ, και το Ansible κάνει μόνο τις αλλαγές που χρειάζονται για να φτάσει εκεί. Τρέξ' το δύο φορές και το δεύτερο run αναφέρει "ok" (καμία αλλαγή) — αυτό είναι idempotency, και γι' αυτό είναι ασφαλές να το τρέχεις επαναλαμβανόμενα.
--- - name: Standardize NTP and logging fleet-wide hosts: switches gather_facts: false tasks: - name: Apply the standard management lines cisco.ios.ios_config: lines: - ntp server 0.gr.pool.ntp.org - ntp server 1.gr.pool.ntp.org - logging host 192.168.1.50 - service timestamps log datetime msec localtime save_when: modified # κάνε write mem ΜΟΝΟ αν άλλαξε κάτι
you@laptop:~$ ansible-playbook -i inventory.ini ntp.yml changed: [sw-01] changed: [sw-02] ... ← το πρώτο run ΕΦΑΡΜΟΖΕΙ το config you@laptop:~$ ansible-playbook -i inventory.ini ntp.yml ok: [sw-01] ok: [sw-02] ... ← δεύτερο run: τίποτα να κάνει # Το playbook είναι το επιθυμητό state. Δεν ξαναγράφει τυφλά εντολές — # συγκρίνει και ενεργεί μόνο σε drift. Ασφαλές να τρέχει προγραμματισμένα.
Το ios_config συγκρίνει τα lines σου έναντι του κειμένου running-config. Για εντολές κάτω από γονέα (ένα interface, ένα line vty), πρέπει να δώσεις το πλαίσιο parents:, αλλιώς το Ansible τα εφαρμόζει στο λάθος επίπεδο. Και ταιριάζει ακριβή strings — το ip address 10.0.0.1 255.255.255.0 και το ίδιο με ένα κενό στο τέλος είναι «διαφορετικά». Όταν ένα task συνεχίζει να αναφέρει changed σε κάθε run παρόλο που δεν αλλάζει πραγματικά τίποτα, αυτό είναι η ένδειξη: η γραμμή σου δεν ταιριάζει κειμενικά με αυτό που αποθηκεύει το IOS (το IOS μπορεί να το ξανα-αποδώσει). Χρησιμοποίησε --check --diff για να δεις ακριβώς τι νομίζει το Ansible ότι διαφέρει, και ταίριαξε τη δική του μορφοποίηση του IOS.
04
Η μία πιο σημαντική συνήθεια. Το --check τρέχει ολόκληρο το playbook χωρίς να εφαρμόζει τίποτα και το --diff δείχνει τις ακριβείς γραμμές που θα πρόσθετε ή θα αφαιρούσε. Αυτό είναι το «μέτρα δύο φορές, κόψε μία» του αυτοματισμού δικτύου.
you@laptop:~$ ansible-playbook -i inventory.ini add-vlan.yml --check --diff TASK [Add VLAN 50 everywhere] **** --- before +++ after @@ -12,0 +13,2 @@ +vlan 50 + name IOT changed: [sw-01] changed: [sw-02] ... (check mode — ΤΙΠΟΤΑ δεν εφαρμόστηκε) # Βλέπεις ΑΚΡΙΒΩΣ τι θα άλλαζε σε κάθε συσκευή. Ικανοποιημένος; Άφησε το --check: you@laptop:~$ ansible-playbook -i inventory.ini add-vlan.yml --diff # Ανάπτυξε σταδιακά με --limit για να δοκιμάσεις πρώτα σε μία συσκευή: you@laptop:~$ ansible-playbook -i inventory.ini add-vlan.yml --limit sw-01
Η επαγγελματική αλλαγή στόλου πάει σε τέσσερις ταχύτητες, η καθεμία πιο ασφαλής από την προηγούμενη: (1) --check --diff για preview σε όλα· (2) --limit sw-01 για να εφαρμόσεις σε μία συσκευή-καναρίνι και να την επιβεβαιώσεις στο πραγματικό δίκτυο· (3) εφάρμοσε στις υπόλοιπες· (4) κάνε commit το playbook στο git ως αρχείο. Αν πάει στραβά το βήμα 2, επηρεάζεται μόνο μία συσκευή και τα backups με commit στο git (ενότητα 02) την επαναφέρουν. Έτσι στέλνεις μια αλλαγή σε 20 switch χωρίς το άγχος στις 2 το πρωί — η ίδια πειθαρχία με το post της αναβάθμισης, εφαρμοσμένη στο config.
05
Ποτέ μην κάνεις commit έναν κωδικό συσκευής στο git σε καθαρό κείμενο. Το Ansible Vault κρυπτογραφεί τις ευαίσθητες μεταβλητές ώστε το repo να είναι ασφαλές να αποθηκευτεί και να μοιραστεί, και το playbook τις αποκρυπτογραφεί κατά την εκτέλεση με έναν κωδικό που δίνεις εσύ.
# Δημιούργησε ένα κρυπτογραφημένο αρχείο vars με τους κωδικούς you@laptop:~$ ansible-vault create group_vars/all/vault.yml # (ανοίγει έναν editor· γράφεις:) vault_ios_password: "TheSSHPassword" vault_enable_password: "TheEnableSecret" # Το αρχείο στον δίσκο είναι τώρα κρυπτογραφημένα ακαταλαβίστικα — ασφαλές να γίνει commit στο git. # Τρέξε οποιοδήποτε playbook, δίνοντας τον κωδικό vault για αποκρυπτογράφηση κατά την εκτέλεση: you@laptop:~$ ansible-playbook -i inventory.ini ntp.yml --ask-vault-pass # Καλή πρακτική: SSH KEYS προς τις συσκευές αντί για κωδικούς όπου γίνεται, # και βάλε σε vault μόνο ό,τι πρέπει να είναι μυστικό. Ποτέ κωδικός σε καθαρό κείμενο στο repo.
06
Και τα δύο αυτοματοποιούν, αλλά λύνουν διαφορετικά προβλήματα. Στρέψου στο σωστό.
| EEM (στη συσκευη) | Ansible (εκτος συσκευης) | |
|---|---|---|
| Τρέχει | Στην ίδια τη συσκευή | Από control machine πάνω από SSH |
| Εύρος | Μία συσκευή που αντιδρά στα δικά της γεγονότα | Πολλές συσκευές, οργανωμένη αλλαγή |
| Δουλεύει όταν είναι κάτω το δίκτυο mgmt; | Ναι — είναι τοπικό | Όχι — χρειάζεται προσβασιμότητα |
| Καλύτερο για | Αυτόνομα αντανακλαστικά (ανάκτηση θύρας, καθαρισμός failover) | Συνέπεια, rollout, config-as-code, backups |
| Το state ζει | Στο config της συσκευής | Στο git |
Το Ansible δεν είναι μόνο-Cisco — το ίδιο control machine διαχειρίζεται MikroTik (community.routeros), Linux servers, και cloud σε ένα workflow — και ακριβώς γι' αυτό είναι η σωστή επένδυση για ένα μεικτό κατάστημα σαν αυτά που τρέχουμε. Το RouterOS έχει το δικό του scripting στη συσκευή (το ανάλογο του EEM), αλλά για να στέλνεις μια συνεπή βάση σε Cisco και MikroTik και τους servers, ένα repo Ansible νικά τρία διαφορετικά εργαλεία. Το config-as-code είναι η ίδια ιδέα παντού: το επιθυμητό state είναι κείμενο, ελεγμένο και με version, και το tooling συμφιλιώνει την πραγματικότητα με αυτό.
Συμπερασματα
cisco.ios — τίποτα εγκατεστημένο στα switch. Το config σου γίνεται ελεγμένο YAML με version στο git.ios_facts και ένα playbook backup config πριν γράψεις ποτέ σε συσκευή. Κάνε commit τα backups στο git — ακαριαίο ιστορικό «τι άλλαξε».parents: για εντολές sub-mode, αλλιώς τα tasks αναφέρουν changed για πάντα. Το --diff δείχνει τι νομίζει το Ansible ότι διαφέρει.--limit, μετά εφάρμοσε. Τέσσερις ταχύτητες, η καθεμία πιο ασφαλής από την προηγούμενη.Μόλις διαχειρίζεσαι περισσότερες από λίγες συσκευές στο χέρι, το config drift είναι θέμα χρόνου. Χτίζω config-as-code με Ansible — backups με version, μια συνεπή θωρακισμένη βάση, και rollouts που στέλνεις σε όλο τον στόλο χωρίς να κρατάς την ανάσα σου — σε Cisco, MikroTik, ή συνδυασμό των δύο.
Κλεισε μια Discovery Call →