Επίσημες πιστοποιήσεις: Ansible
Ημερομηνία: 15 Ιουλίου 2026 Πηγή: https://www.redhat.com/en/services/certifications
Αυτό το έγγραφο αντιστοιχίζει το workshop με τις επίσημες διαδρομές πιστοποίησης της Red Hat. Δεν επινοεί εξετάσεις και δεν αντιγράφει πραγματικές ερωτήσεις εξετάσεων.
1. Επίσημη πηγή
Εμβάθυνση και παράδειγμα υποβολής για: Επίσημη πηγή
Μια πλήρης εξέταση αυτής της ενότητας περιλαμβάνει τόσο τεχνικό τεχνούργημα όσο και σύντομη εξήγηση του πεδίου. Το τεχνούργημα μπορεί να είναι inventory, playbook, role, template, αρχείο Vault με υποδειγματικές τιμές, ρύθμιση CI ή αρχείο evidence. Η εξήγηση αναφέρει γιατί επιλέχθηκε αυτή η διαδρομή και ποια εναλλακτική απορρίφθηκε συνειδητά.
| Μέρος υποβολής | Περιεχόμενο | Ελάχιστη ποιότητα |
|---|---|---|
| περιγραφή στόχου | τι πρέπει να ισχύει μετά την εκτέλεση | μετρήσιμο, χωρίς κρυφές παραδοχές |
| evidence πεδίου εφαρμογής | ποιοι hosts επηρεάζονται | αποτέλεσμα --list-hosts ή inventory graph |
| υλοποίηση | ποια αρχεία άλλαξαν | μικρά YAML αρχεία που ελέγχονται εύκολα |
| επικύρωση | πώς έγινε ο έλεγχος | syntax check, check mode, diff, πραγματική και δεύτερη εκτέλεση |
| απόφαση κινδύνου | τι μπορεί να πάει στραβά | δικαιώματα, secrets, εξωτερικές εξαρτήσεις και rollback |
Ελάχιστα τεχνουργήματα για: Επίσημη πηγή
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Για roles ή collections, η δομή επεκτείνεται:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Προσδοκίες αξιολόγησης για: Επίσημη πηγή
Μια λύση κατάλληλη για review πρέπει να γίνεται κατανοητή και από άτομα που δεν την εκτέλεσαν. Screenshots ή αποτελέσματα terminal χωρίς σχόλια δεν αρκούν. Καλό evidence καταγράφει context, εντολή, σχετικό αποτέλεσμα και αξιολόγηση. Αν ένα module συμπεριφέρεται διαφορετικά στο check mode, αυτός ο περιορισμός τεκμηριώνεται ρητά.
Μεταφορά σε πραγματικές ομάδες
Σε ομάδα, η ενότητα συνδέεται με code review, branch rules, CI, ownership των roles, release notes και λειτουργική έγκριση. Η χρήση που προσεγγίζει production τεκμηριώνει επίσης owner, maintenance window, monitoring, alerting και κριτήρια rollback.
Πρακτική σημασία της ενότητας
Η ενότητα δεν είναι απλός ορισμός. Στο workshop επαληθεύεται με συγκεκριμένη ροή: επιθεωρήστε το inventory, αποδείξτε τους hosts στόχου, ελέγξτε το playbook, προσομοιώστε την αλλαγή, εκτελέστε την, αξιολογήστε δεύτερη εκτέλεση και τεκμηριώστε το cleanup. Έτσι φαίνεται αν το Ansible μοντελοποιεί πράγματι την επιθυμητή κατάσταση ή απλώς εκτελεί επιτυχώς μια εντολή μία φορά.
| Ερώτηση review | Αναμενόμενη απάντηση |
|---|---|
| Ποιοι hosts επηρεάζονται; | Pattern, group, --limit και αποτέλεσμα inventory τεκμηριώνονται. |
| Ποιες πηγές δεδομένων ισχύουν; | group_vars, host_vars, defaults, extra vars και facts είναι γνωστά. |
| Ποια δικαιώματα απαιτούνται; | Το become ορίζεται κοντά στο task και αιτιολογείται μόνο όπου χρειάζονται πράγματι αυξημένα δικαιώματα. |
| Πώς αποδεικνύεται η επιτυχία; | Υπάρχουν syntax check, check mode, diff, play recap και δεύτερη εκτέλεση. |
Ενδεικτική ροή για: Επίσημη πηγή
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Η ροή είναι σκόπιμα πλήρης. Σε πραγματικές ομάδες ορισμένα βήματα αυτοματοποιούνται, αλλά δεν παραλείπονται. Το CI μπορεί να εκτελεί syntax checks και linting· το domain review για το πεδίο εφαρμογής, τα δικαιώματα, τις ροές secrets και τον κίνδυνο rollout παραμένει ανθρώπινη εργασία μηχανικής.
Κριτήρια review για: Επίσημη πηγή
- Το inventory και τα patterns είναι πιο περιορισμένα από το
all, εκτός αν υπάρχει τεκμηριωμένος λόγος. - Προτιμώνται modules από
ansible.builtinή ελεγμένες collections. - Τα shell ή command tasks περιλαμβάνουν
changed_when,failed_whenή σαφή αιτιολόγηση. - Οι variables τοποθετούνται προβλέψιμα και δεν αλληλοκαλύπτονται απροσδόκητα.
- Τα secrets δεν εμφανίζονται ως plaintext, σε diffs, debug tasks ή CI logs.
- Το playbook εκτελείται επανειλημμένα χωρίς περιττές αλλαγές.
- Τεκμηριώνεται cleanup, fix-forward ή ελεγχόμενη αποδοχή της επιθυμητής κατάστασης.
Συνήθεις αποτυχίες για: Επίσημη πηγή
| Αποτυχία | Αιτία | Διάγνωση |
|---|---|---|
| στοχεύονται λάθος hosts | παρανόηση pattern ή inventory | --list-hosts, ansible-inventory --host |
unreachable |
πρόβλημα SSH, χρήστη, Python ή δικτύου | -vvvv, δοκιμή SSH, inventory variables |
| απροσδόκητη αλλαγή | μη idempotent module ή λανθασμένη πηγή δεδομένων | δεύτερη εκτέλεση, diff, έλεγχος variables |
| διαρροή secret | debug, diff ή log χωρίς σωστό περιορισμό | έλεγχος no_log, Vault, CI artifacts |
| handler δεν εκτελείται | απουσία αποτελέσματος changed ή λάθος όνομα handler |
επιθεώρηση αποτελέσματος task και ονόματος handler |
Σημείωση λειτουργίας για: Επίσημη πηγή
Για χρήση που προσεγγίζει production, το lab πρέπει να γίνει runbook. Το runbook αναφέρει συστήματα στόχου, owners, προαπαιτούμενα, stop criteria, αναμενόμενη διάρκεια, επικύρωση, monitoring και cleanup. Χωρίς αυτά, ένα playbook είναι εκτελέσιμο αλλά όχι λειτουργικά ώριμο.
Η αυθεντική πηγή είναι η σελίδα πιστοποιήσεων της Red Hat. Εκεί συντηρούνται τα επίπεδα, τα προαπαιτούμενα, οι εξετάσεις και οι διαδρομές.
2. Τρέχουσες διαδρομές σχετικές με το Ansible
Εμβάθυνση και παράδειγμα υποβολής για: Τρέχουσες διαδρομές σχετικές με το Ansible
Μια πλήρης εξέταση αυτής της ενότητας περιλαμβάνει τόσο τεχνικό τεχνούργημα όσο και σύντομη εξήγηση του πεδίου. Το τεχνούργημα μπορεί να είναι inventory, playbook, role, template, αρχείο Vault με υποδειγματικές τιμές, ρύθμιση CI ή αρχείο evidence. Η εξήγηση αναφέρει γιατί επιλέχθηκε αυτή η διαδρομή και ποια εναλλακτική απορρίφθηκε συνειδητά.
| Μέρος υποβολής | Περιεχόμενο | Ελάχιστη ποιότητα |
|---|---|---|
| περιγραφή στόχου | τι πρέπει να ισχύει μετά την εκτέλεση | μετρήσιμο, χωρίς κρυφές παραδοχές |
| evidence πεδίου εφαρμογής | ποιοι hosts επηρεάζονται | αποτέλεσμα --list-hosts ή inventory graph |
| υλοποίηση | ποια αρχεία άλλαξαν | μικρά YAML αρχεία που ελέγχονται εύκολα |
| επικύρωση | πώς έγινε ο έλεγχος | syntax check, check mode, diff, πραγματική και δεύτερη εκτέλεση |
| απόφαση κινδύνου | τι μπορεί να πάει στραβά | δικαιώματα, secrets, εξωτερικές εξαρτήσεις και rollback |
Ελάχιστα τεχνουργήματα για: Τρέχουσες διαδρομές σχετικές με το Ansible
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Για roles ή collections, η δομή επεκτείνεται:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Προσδοκίες αξιολόγησης για: Τρέχουσες διαδρομές σχετικές με το Ansible
Μια λύση κατάλληλη για review πρέπει να γίνεται κατανοητή και από άτομα που δεν την εκτέλεσαν. Screenshots ή αποτελέσματα terminal χωρίς σχόλια δεν αρκούν. Καλό evidence καταγράφει context, εντολή, σχετικό αποτέλεσμα και αξιολόγηση. Αν ένα module συμπεριφέρεται διαφορετικά στο check mode, αυτός ο περιορισμός τεκμηριώνεται ρητά.
Μεταφορά σε πραγματικές ομάδες
Σε ομάδα, η ενότητα συνδέεται με code review, branch rules, CI, ownership των roles, release notes και λειτουργική έγκριση. Η χρήση που προσεγγίζει production τεκμηριώνει επίσης owner, maintenance window, monitoring, alerting και κριτήρια rollback.
Πρακτική σημασία της ενότητας
Η ενότητα δεν είναι απλός ορισμός. Στο workshop επαληθεύεται με συγκεκριμένη ροή: επιθεωρήστε το inventory, αποδείξτε τους hosts στόχου, ελέγξτε το playbook, προσομοιώστε την αλλαγή, εκτελέστε την, αξιολογήστε δεύτερη εκτέλεση και τεκμηριώστε το cleanup. Έτσι φαίνεται αν το Ansible μοντελοποιεί πράγματι την επιθυμητή κατάσταση ή απλώς εκτελεί επιτυχώς μια εντολή μία φορά.
| Ερώτηση review | Αναμενόμενη απάντηση |
|---|---|
| Ποιοι hosts επηρεάζονται; | Pattern, group, --limit και αποτέλεσμα inventory τεκμηριώνονται. |
| Ποιες πηγές δεδομένων ισχύουν; | group_vars, host_vars, defaults, extra vars και facts είναι γνωστά. |
| Ποια δικαιώματα απαιτούνται; | Το become ορίζεται κοντά στο task και αιτιολογείται μόνο όπου χρειάζονται πράγματι αυξημένα δικαιώματα. |
| Πώς αποδεικνύεται η επιτυχία; | Υπάρχουν syntax check, check mode, diff, play recap και δεύτερη εκτέλεση. |
Ενδεικτική ροή για: Τρέχουσες διαδρομές σχετικές με το Ansible
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Η ροή είναι σκόπιμα πλήρης. Σε πραγματικές ομάδες ορισμένα βήματα αυτοματοποιούνται, αλλά δεν παραλείπονται. Το CI μπορεί να εκτελεί syntax checks και linting· το domain review για το πεδίο εφαρμογής, τα δικαιώματα, τις ροές secrets και τον κίνδυνο rollout παραμένει ανθρώπινη εργασία μηχανικής.
Κριτήρια review για: Τρέχουσες διαδρομές σχετικές με το Ansible
- Το inventory και τα patterns είναι πιο περιορισμένα από το
all, εκτός αν υπάρχει τεκμηριωμένος λόγος. - Προτιμώνται modules από
ansible.builtinή ελεγμένες collections. - Τα shell ή command tasks περιλαμβάνουν
changed_when,failed_whenή σαφή αιτιολόγηση. - Οι variables τοποθετούνται προβλέψιμα και δεν αλληλοκαλύπτονται απροσδόκητα.
- Τα secrets δεν εμφανίζονται ως plaintext, σε diffs, debug tasks ή CI logs.
- Το playbook εκτελείται επανειλημμένα χωρίς περιττές αλλαγές.
- Τεκμηριώνεται cleanup, fix-forward ή ελεγχόμενη αποδοχή της επιθυμητής κατάστασης.
Συνήθεις αποτυχίες για: Τρέχουσες διαδρομές σχετικές με το Ansible
| Αποτυχία | Αιτία | Διάγνωση |
|---|---|---|
| στοχεύονται λάθος hosts | παρανόηση pattern ή inventory | --list-hosts, ansible-inventory --host |
unreachable |
πρόβλημα SSH, χρήστη, Python ή δικτύου | -vvvv, δοκιμή SSH, inventory variables |
| απροσδόκητη αλλαγή | μη idempotent module ή λανθασμένη πηγή δεδομένων | δεύτερη εκτέλεση, diff, έλεγχος variables |
| διαρροή secret | debug, diff ή log χωρίς σωστό περιορισμό | έλεγχος no_log, Vault, CI artifacts |
| handler δεν εκτελείται | απουσία αποτελέσματος changed ή λάθος όνομα handler |
επιθεώρηση αποτελέσματος task και ονόματος handler |
Σημείωση λειτουργίας για: Τρέχουσες διαδρομές σχετικές με το Ansible
Για χρήση που προσεγγίζει production, το lab πρέπει να γίνει runbook. Το runbook αναφέρει συστήματα στόχου, owners, προαπαιτούμενα, stop criteria, αναμενόμενη διάρκεια, επικύρωση, monitoring και cleanup. Χωρίς αυτά, ένα playbook είναι εκτελέσιμο αλλά όχι λειτουργικά ώριμο.
Η σελίδα της Red Hat απαριθμεί, μεταξύ άλλων, τα εξής σχετικά με το Ansible:
| Διαδρομή | Απαιτήσεις σύμφωνα με την επίσημη σελίδα |
|---|---|
| Red Hat Certified Systems Administrator στη διαδρομή Ansible | EX200: Red Hat Certified System Administrator exam |
| Red Hat Certified Engineer in Ansible | EX200 και EX294: Red Hat Certified Advanced System Administrator in Ansible exam |
| Ansible Specialist | EX374, EX417, EX457 ή EX467 |
| Red Hat Certified Architect in Ansible | EX200, EX294 και τουλάχιστον τρεις εξετάσεις specialist στον τομέα Ansible |
Αναφερόμενες εξετάσεις specialist:
- EX374: Red Hat Certified Specialist in Developing Automation with Ansible Automation Platform exam
- EX417: Red Hat Certified Specialist in Microsoft Windows Automation with Ansible exam
- EX457: Red Hat Certified Specialist in Ansible Network Automation exam
- EX467: Red Hat Certified Specialist in Managing Automation with Ansible Automation Platform exam
3. Αντιστοίχιση με το workshop
Εμβάθυνση και παράδειγμα υποβολής για: Αντιστοίχιση με το workshop
Μια πλήρης εξέταση αυτής της ενότητας περιλαμβάνει τόσο τεχνικό τεχνούργημα όσο και σύντομη εξήγηση του πεδίου. Το τεχνούργημα μπορεί να είναι inventory, playbook, role, template, αρχείο Vault με υποδειγματικές τιμές, ρύθμιση CI ή αρχείο evidence. Η εξήγηση αναφέρει γιατί επιλέχθηκε αυτή η διαδρομή και ποια εναλλακτική απορρίφθηκε συνειδητά.
| Μέρος υποβολής | Περιεχόμενο | Ελάχιστη ποιότητα |
|---|---|---|
| περιγραφή στόχου | τι πρέπει να ισχύει μετά την εκτέλεση | μετρήσιμο, χωρίς κρυφές παραδοχές |
| evidence πεδίου εφαρμογής | ποιοι hosts επηρεάζονται | αποτέλεσμα --list-hosts ή inventory graph |
| υλοποίηση | ποια αρχεία άλλαξαν | μικρά YAML αρχεία που ελέγχονται εύκολα |
| επικύρωση | πώς έγινε ο έλεγχος | syntax check, check mode, diff, πραγματική και δεύτερη εκτέλεση |
| απόφαση κινδύνου | τι μπορεί να πάει στραβά | δικαιώματα, secrets, εξωτερικές εξαρτήσεις και rollback |
Ελάχιστα τεχνουργήματα για: Αντιστοίχιση με το workshop
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Για roles ή collections, η δομή επεκτείνεται:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Προσδοκίες αξιολόγησης για: Αντιστοίχιση με το workshop
Μια λύση κατάλληλη για review πρέπει να γίνεται κατανοητή και από άτομα που δεν την εκτέλεσαν. Screenshots ή αποτελέσματα terminal χωρίς σχόλια δεν αρκούν. Καλό evidence καταγράφει context, εντολή, σχετικό αποτέλεσμα και αξιολόγηση. Αν ένα module συμπεριφέρεται διαφορετικά στο check mode, αυτός ο περιορισμός τεκμηριώνεται ρητά.
Μεταφορά σε πραγματικές ομάδες
Σε ομάδα, η ενότητα συνδέεται με code review, branch rules, CI, ownership των roles, release notes και λειτουργική έγκριση. Η χρήση που προσεγγίζει production τεκμηριώνει επίσης owner, maintenance window, monitoring, alerting και κριτήρια rollback.
Πρακτική σημασία της ενότητας
Η ενότητα δεν είναι απλός ορισμός. Στο workshop επαληθεύεται με συγκεκριμένη ροή: επιθεωρήστε το inventory, αποδείξτε τους hosts στόχου, ελέγξτε το playbook, προσομοιώστε την αλλαγή, εκτελέστε την, αξιολογήστε δεύτερη εκτέλεση και τεκμηριώστε το cleanup. Έτσι φαίνεται αν το Ansible μοντελοποιεί πράγματι την επιθυμητή κατάσταση ή απλώς εκτελεί επιτυχώς μια εντολή μία φορά.
| Ερώτηση review | Αναμενόμενη απάντηση |
|---|---|
| Ποιοι hosts επηρεάζονται; | Pattern, group, --limit και αποτέλεσμα inventory τεκμηριώνονται. |
| Ποιες πηγές δεδομένων ισχύουν; | group_vars, host_vars, defaults, extra vars και facts είναι γνωστά. |
| Ποια δικαιώματα απαιτούνται; | Το become ορίζεται κοντά στο task και αιτιολογείται μόνο όπου χρειάζονται πράγματι αυξημένα δικαιώματα. |
| Πώς αποδεικνύεται η επιτυχία; | Υπάρχουν syntax check, check mode, diff, play recap και δεύτερη εκτέλεση. |
Ενδεικτική ροή για: Αντιστοίχιση με το workshop
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Η ροή είναι σκόπιμα πλήρης. Σε πραγματικές ομάδες ορισμένα βήματα αυτοματοποιούνται, αλλά δεν παραλείπονται. Το CI μπορεί να εκτελεί syntax checks και linting· το domain review για το πεδίο εφαρμογής, τα δικαιώματα, τις ροές secrets και τον κίνδυνο rollout παραμένει ανθρώπινη εργασία μηχανικής.
Κριτήρια review για: Αντιστοίχιση με το workshop
- Το inventory και τα patterns είναι πιο περιορισμένα από το
all, εκτός αν υπάρχει τεκμηριωμένος λόγος. - Προτιμώνται modules από
ansible.builtinή ελεγμένες collections. - Τα shell ή command tasks περιλαμβάνουν
changed_when,failed_whenή σαφή αιτιολόγηση. - Οι variables τοποθετούνται προβλέψιμα και δεν αλληλοκαλύπτονται απροσδόκητα.
- Τα secrets δεν εμφανίζονται ως plaintext, σε diffs, debug tasks ή CI logs.
- Το playbook εκτελείται επανειλημμένα χωρίς περιττές αλλαγές.
- Τεκμηριώνεται cleanup, fix-forward ή ελεγχόμενη αποδοχή της επιθυμητής κατάστασης.
Συνήθεις αποτυχίες για: Αντιστοίχιση με το workshop
| Αποτυχία | Αιτία | Διάγνωση |
|---|---|---|
| στοχεύονται λάθος hosts | παρανόηση pattern ή inventory | --list-hosts, ansible-inventory --host |
unreachable |
πρόβλημα SSH, χρήστη, Python ή δικτύου | -vvvv, δοκιμή SSH, inventory variables |
| απροσδόκητη αλλαγή | μη idempotent module ή λανθασμένη πηγή δεδομένων | δεύτερη εκτέλεση, diff, έλεγχος variables |
| διαρροή secret | debug, diff ή log χωρίς σωστό περιορισμό | έλεγχος no_log, Vault, CI artifacts |
| handler δεν εκτελείται | απουσία αποτελέσματος changed ή λάθος όνομα handler |
επιθεώρηση αποτελέσματος task και ονόματος handler |
Σημείωση λειτουργίας για: Αντιστοίχιση με το workshop
Για χρήση που προσεγγίζει production, το lab πρέπει να γίνει runbook. Το runbook αναφέρει συστήματα στόχου, owners, προαπαιτούμενα, stop criteria, αναμενόμενη διάρκεια, επικύρωση, monitoring και cleanup. Χωρίς αυτά, ένα playbook είναι εκτελέσιμο αλλά όχι λειτουργικά ώριμο.
| Πεδίο workshop | Σχετικές δεξιότητες |
|---|---|
| Fundamentals | Inventory, playbooks, modules, idempotence, diagnostics |
| Intermediate | Variables, facts, templates, roles, includes, βασικές αρχές Vault |
| Professional | Collections, CI, orchestration, πολλά inventories, εισαγωγή σε Controller/AWX |
| Advanced + Security | Least privilege, ροές secrets, supply chain, execution environments, security review |
4. Προετοιμασία χωρίς ερωτήσεις εξετάσεων
Εμβάθυνση και παράδειγμα υποβολής για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
Μια πλήρης εξέταση αυτής της ενότητας περιλαμβάνει τόσο τεχνικό τεχνούργημα όσο και σύντομη εξήγηση του πεδίου. Το τεχνούργημα μπορεί να είναι inventory, playbook, role, template, αρχείο Vault με υποδειγματικές τιμές, ρύθμιση CI ή αρχείο evidence. Η εξήγηση αναφέρει γιατί επιλέχθηκε αυτή η διαδρομή και ποια εναλλακτική απορρίφθηκε συνειδητά.
| Μέρος υποβολής | Περιεχόμενο | Ελάχιστη ποιότητα |
|---|---|---|
| περιγραφή στόχου | τι πρέπει να ισχύει μετά την εκτέλεση | μετρήσιμο, χωρίς κρυφές παραδοχές |
| evidence πεδίου εφαρμογής | ποιοι hosts επηρεάζονται | αποτέλεσμα --list-hosts ή inventory graph |
| υλοποίηση | ποια αρχεία άλλαξαν | μικρά YAML αρχεία που ελέγχονται εύκολα |
| επικύρωση | πώς έγινε ο έλεγχος | syntax check, check mode, diff, πραγματική και δεύτερη εκτέλεση |
| απόφαση κινδύνου | τι μπορεί να πάει στραβά | δικαιώματα, secrets, εξωτερικές εξαρτήσεις και rollback |
Ελάχιστα τεχνουργήματα για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Για roles ή collections, η δομή επεκτείνεται:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Προσδοκίες αξιολόγησης για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
Μια λύση κατάλληλη για review πρέπει να γίνεται κατανοητή και από άτομα που δεν την εκτέλεσαν. Screenshots ή αποτελέσματα terminal χωρίς σχόλια δεν αρκούν. Καλό evidence καταγράφει context, εντολή, σχετικό αποτέλεσμα και αξιολόγηση. Αν ένα module συμπεριφέρεται διαφορετικά στο check mode, αυτός ο περιορισμός τεκμηριώνεται ρητά.
Μεταφορά σε πραγματικές ομάδες
Σε ομάδα, η ενότητα συνδέεται με code review, branch rules, CI, ownership των roles, release notes και λειτουργική έγκριση. Η χρήση που προσεγγίζει production τεκμηριώνει επίσης owner, maintenance window, monitoring, alerting και κριτήρια rollback.
Πρακτική σημασία της ενότητας
Η ενότητα δεν είναι απλός ορισμός. Στο workshop επαληθεύεται με συγκεκριμένη ροή: επιθεωρήστε το inventory, αποδείξτε τους hosts στόχου, ελέγξτε το playbook, προσομοιώστε την αλλαγή, εκτελέστε την, αξιολογήστε δεύτερη εκτέλεση και τεκμηριώστε το cleanup. Έτσι φαίνεται αν το Ansible μοντελοποιεί πράγματι την επιθυμητή κατάσταση ή απλώς εκτελεί επιτυχώς μια εντολή μία φορά.
| Ερώτηση review | Αναμενόμενη απάντηση |
|---|---|
| Ποιοι hosts επηρεάζονται; | Pattern, group, --limit και αποτέλεσμα inventory τεκμηριώνονται. |
| Ποιες πηγές δεδομένων ισχύουν; | group_vars, host_vars, defaults, extra vars και facts είναι γνωστά. |
| Ποια δικαιώματα απαιτούνται; | Το become ορίζεται κοντά στο task και αιτιολογείται μόνο όπου χρειάζονται πράγματι αυξημένα δικαιώματα. |
| Πώς αποδεικνύεται η επιτυχία; | Υπάρχουν syntax check, check mode, diff, play recap και δεύτερη εκτέλεση. |
Ενδεικτική ροή για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Η ροή είναι σκόπιμα πλήρης. Σε πραγματικές ομάδες ορισμένα βήματα αυτοματοποιούνται, αλλά δεν παραλείπονται. Το CI μπορεί να εκτελεί syntax checks και linting· το domain review για το πεδίο εφαρμογής, τα δικαιώματα, τις ροές secrets και τον κίνδυνο rollout παραμένει ανθρώπινη εργασία μηχανικής.
Κριτήρια review για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
- Το inventory και τα patterns είναι πιο περιορισμένα από το
all, εκτός αν υπάρχει τεκμηριωμένος λόγος. - Προτιμώνται modules από
ansible.builtinή ελεγμένες collections. - Τα shell ή command tasks περιλαμβάνουν
changed_when,failed_whenή σαφή αιτιολόγηση. - Οι variables τοποθετούνται προβλέψιμα και δεν αλληλοκαλύπτονται απροσδόκητα.
- Τα secrets δεν εμφανίζονται ως plaintext, σε diffs, debug tasks ή CI logs.
- Το playbook εκτελείται επανειλημμένα χωρίς περιττές αλλαγές.
- Τεκμηριώνεται cleanup, fix-forward ή ελεγχόμενη αποδοχή της επιθυμητής κατάστασης.
Συνήθεις αποτυχίες για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
| Αποτυχία | Αιτία | Διάγνωση |
|---|---|---|
| στοχεύονται λάθος hosts | παρανόηση pattern ή inventory | --list-hosts, ansible-inventory --host |
unreachable |
πρόβλημα SSH, χρήστη, Python ή δικτύου | -vvvv, δοκιμή SSH, inventory variables |
| απροσδόκητη αλλαγή | μη idempotent module ή λανθασμένη πηγή δεδομένων | δεύτερη εκτέλεση, diff, έλεγχος variables |
| διαρροή secret | debug, diff ή log χωρίς σωστό περιορισμό | έλεγχος no_log, Vault, CI artifacts |
| handler δεν εκτελείται | απουσία αποτελέσματος changed ή λάθος όνομα handler |
επιθεώρηση αποτελέσματος task και ονόματος handler |
Σημείωση λειτουργίας για: Προετοιμασία χωρίς ερωτήσεις εξετάσεων
Για χρήση που προσεγγίζει production, το lab πρέπει να γίνει runbook. Το runbook αναφέρει συστήματα στόχου, owners, προαπαιτούμενα, stop criteria, αναμενόμενη διάρκεια, επικύρωση, monitoring και cleanup. Χωρίς αυτά, ένα playbook είναι εκτελέσιμο αλλά όχι λειτουργικά ώριμο.
Το workshop προετοιμάζει με έννοιες, labs και δυνατότητα review. Δεν περιέχει πραγματικές ερωτήσεις εξετάσεων. Καλή προετοιμασία σημαίνει να εκτελείτε μόνοι σας τις εργασίες, να αναλύετε τις αποτυχίες και να τεκμηριώνετε καθαρά το evidence.
5. Όρια
Εμβάθυνση και παράδειγμα υποβολής για: Όρια
Μια πλήρης εξέταση αυτής της ενότητας περιλαμβάνει τόσο τεχνικό τεχνούργημα όσο και σύντομη εξήγηση του πεδίου. Το τεχνούργημα μπορεί να είναι inventory, playbook, role, template, αρχείο Vault με υποδειγματικές τιμές, ρύθμιση CI ή αρχείο evidence. Η εξήγηση αναφέρει γιατί επιλέχθηκε αυτή η διαδρομή και ποια εναλλακτική απορρίφθηκε συνειδητά.
| Μέρος υποβολής | Περιεχόμενο | Ελάχιστη ποιότητα |
|---|---|---|
| περιγραφή στόχου | τι πρέπει να ισχύει μετά την εκτέλεση | μετρήσιμο, χωρίς κρυφές παραδοχές |
| evidence πεδίου εφαρμογής | ποιοι hosts επηρεάζονται | αποτέλεσμα --list-hosts ή inventory graph |
| υλοποίηση | ποια αρχεία άλλαξαν | μικρά YAML αρχεία που ελέγχονται εύκολα |
| επικύρωση | πώς έγινε ο έλεγχος | syntax check, check mode, diff, πραγματική και δεύτερη εκτέλεση |
| απόφαση κινδύνου | τι μπορεί να πάει στραβά | δικαιώματα, secrets, εξωτερικές εξαρτήσεις και rollback |
Ελάχιστα τεχνουργήματα για: Όρια
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Για roles ή collections, η δομή επεκτείνεται:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Προσδοκίες αξιολόγησης για: Όρια
Μια λύση κατάλληλη για review πρέπει να γίνεται κατανοητή και από άτομα που δεν την εκτέλεσαν. Screenshots ή αποτελέσματα terminal χωρίς σχόλια δεν αρκούν. Καλό evidence καταγράφει context, εντολή, σχετικό αποτέλεσμα και αξιολόγηση. Αν ένα module συμπεριφέρεται διαφορετικά στο check mode, αυτός ο περιορισμός τεκμηριώνεται ρητά.
Μεταφορά σε πραγματικές ομάδες
Σε ομάδα, η ενότητα συνδέεται με code review, branch rules, CI, ownership των roles, release notes και λειτουργική έγκριση. Η χρήση που προσεγγίζει production τεκμηριώνει επίσης owner, maintenance window, monitoring, alerting και κριτήρια rollback.
Πρακτική σημασία της ενότητας
Η ενότητα δεν είναι απλός ορισμός. Στο workshop επαληθεύεται με συγκεκριμένη ροή: επιθεωρήστε το inventory, αποδείξτε τους hosts στόχου, ελέγξτε το playbook, προσομοιώστε την αλλαγή, εκτελέστε την, αξιολογήστε δεύτερη εκτέλεση και τεκμηριώστε το cleanup. Έτσι φαίνεται αν το Ansible μοντελοποιεί πράγματι την επιθυμητή κατάσταση ή απλώς εκτελεί επιτυχώς μια εντολή μία φορά.
| Ερώτηση review | Αναμενόμενη απάντηση |
|---|---|
| Ποιοι hosts επηρεάζονται; | Pattern, group, --limit και αποτέλεσμα inventory τεκμηριώνονται. |
| Ποιες πηγές δεδομένων ισχύουν; | group_vars, host_vars, defaults, extra vars και facts είναι γνωστά. |
| Ποια δικαιώματα απαιτούνται; | Το become ορίζεται κοντά στο task και αιτιολογείται μόνο όπου χρειάζονται πράγματι αυξημένα δικαιώματα. |
| Πώς αποδεικνύεται η επιτυχία; | Υπάρχουν syntax check, check mode, diff, play recap και δεύτερη εκτέλεση. |
Ενδεικτική ροή για: Όρια
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Η ροή είναι σκόπιμα πλήρης. Σε πραγματικές ομάδες ορισμένα βήματα αυτοματοποιούνται, αλλά δεν παραλείπονται. Το CI μπορεί να εκτελεί syntax checks και linting· το domain review για το πεδίο εφαρμογής, τα δικαιώματα, τις ροές secrets και τον κίνδυνο rollout παραμένει ανθρώπινη εργασία μηχανικής.
Κριτήρια review για: Όρια
- Το inventory και τα patterns είναι πιο περιορισμένα από το
all, εκτός αν υπάρχει τεκμηριωμένος λόγος. - Προτιμώνται modules από
ansible.builtinή ελεγμένες collections. - Τα shell ή command tasks περιλαμβάνουν
changed_when,failed_whenή σαφή αιτιολόγηση. - Οι variables τοποθετούνται προβλέψιμα και δεν αλληλοκαλύπτονται απροσδόκητα.
- Τα secrets δεν εμφανίζονται ως plaintext, σε diffs, debug tasks ή CI logs.
- Το playbook εκτελείται επανειλημμένα χωρίς περιττές αλλαγές.
- Τεκμηριώνεται cleanup, fix-forward ή ελεγχόμενη αποδοχή της επιθυμητής κατάστασης.
Συνήθεις αποτυχίες για: Όρια
| Αποτυχία | Αιτία | Διάγνωση |
|---|---|---|
| στοχεύονται λάθος hosts | παρανόηση pattern ή inventory | --list-hosts, ansible-inventory --host |
unreachable |
πρόβλημα SSH, χρήστη, Python ή δικτύου | -vvvv, δοκιμή SSH, inventory variables |
| απροσδόκητη αλλαγή | μη idempotent module ή λανθασμένη πηγή δεδομένων | δεύτερη εκτέλεση, diff, έλεγχος variables |
| διαρροή secret | debug, diff ή log χωρίς σωστό περιορισμό | έλεγχος no_log, Vault, CI artifacts |
| handler δεν εκτελείται | απουσία αποτελέσματος changed ή λάθος όνομα handler |
επιθεώρηση αποτελέσματος task και ονόματος handler |
Σημείωση λειτουργίας για: Όρια
Για χρήση που προσεγγίζει production, το lab πρέπει να γίνει runbook. Το runbook αναφέρει συστήματα στόχου, owners, προαπαιτούμενα, stop criteria, αναμενόμενη διάρκεια, επικύρωση, monitoring και cleanup. Χωρίς αυτά, ένα playbook είναι εκτελέσιμο αλλά όχι λειτουργικά ώριμο.
Ελέγχετε πάντα την επίσημη σελίδα πριν από την κράτηση, επειδή ονόματα, εκδόσεις, διαδρομές και blueprints μπορεί να αλλάξουν.