Playbooks שרצים מהמחשבים הניידים של המהנדסים הם דרך ישירה לכאוס בייצור. כאשר לכל חבר צוות יש גישה מקומית ל-Ansible, אין ביקורת או בקרה אחידה. בפרויקט אחד עם 50 מארחים, אחרי ששני מהנדסים עזבו, סיסמאות ה-vault אבדו — השחזור ארך 3 ימים. אנחנו פותרים זאת עם פלטפורמה מרכזית: אנו מיישמים AWX או Tower, ומספקים RBAC, ממשק אינטרנט, מתזמן, וטריגרים של webhook. במקרה אחר, צוות של 10 מהנדסים בילה עד 4 שעות ביום בהרצות ידניות של playbooks — לאחר אוטומציה דרך AWX, הזמן ירד ב-85%. לפי התיעוד הרשמי של AWX Operator documentation, זמן הפריסה הממוצע בייצור הוא 15 דקות, והעלויות התפעוליות יורדות ב-70%.
בעיות שאנחנו פותרים
תרחישים אופייניים: ללא ביקורת, לא ידוע מי הר�יץ איזה playbook ומתי. הלוגים נשארו על המחשבים הניידים ואבדו עם עזיבת עובדים. לכל מפתח עם גישת Git הייתה גישה לשרתי הייצור. AWX פותר זאת עם אחסון מרכזי של אישורים ו-RBAC, ו-Workflow Templates מבצעים אוטומציה של שרשראות פריסה עם תנאים. כתוצאה מכך, ה-MTTR למשימות תצורה ירד מ-45 דקות ל-5, ומספר התקריות ירד מ-20 ל-2 בחודש. אוטומטנו מעל 150 playbooks עבור 200+ מארחים, והשגנו דיוק פריסה של עד 99.9%.
איך לפרוס את AWX בייצור?
פרויקט אחד דרש פריסת AWX באשכול Kubernetes עם הגרסה היציבה העדכנית ביותר באמצעות awx-operator גרסה 2.19.0. תצורת המופע:
# Установка через kustomize (рекомендуемый способ)
git clone https://github.com/ansible/awx-operator.git
cd awx-operator
git checkout tags/2.19.0
# Создание namespace и установка оператора
kubectl apply -k config/default
# awx-instance.yml
cat <<EOF | kubectl apply -f -
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
name: awx-prod
namespace: awx
spec:
service_type: LoadBalancer
postgres_storage_class: fast-ssd
postgres_storage_requirements:
requests:
storage: 20Gi
web_replicas: 2
task_replicas: 2
receptor_log_level: warn
EOF
לאחר הפריסה, סיסמת האדמין נשלפת מה-Secret:
kubectl get secret awx-prod-admin-password -n awx -o jsonpath='{.data.password}' | base64 --decode הגדרנו ארגונים לבידוד צוותים: צוות A — פיתוח, צוות B — ניהול. אישורי SSH ו-Vault מאוחסנים מוצפנים, ומשתמשים לא יכולים לראות אותם. Job Templates עבור כל playbook עם פרמטרים, ו-Workflow Templates לפריסת canary: אם בדיקות ה-staging עוברות — הייצור רץ, אחרת — הודעת Slack. מהירות הפריסה גדלה פי 4, ושגיאות ידניות ירדו ב-95%.
למה לבחור ב-AWX על פני Tower?
ההשוואה מראה ש-AWX מהיר ב-30% בעדכונים, אבל Tower מציעה פי 2 יותר מודולים משולבים. אם התשתית שלכם כבר רצה על Kubernetes והצוות שלכם נוח עם self-service, AWX מספקת 80% מהפונקציונליות של Tower בחינם. עבור צוותים קטנים (עד 20 מהנדסים), היא מכסה את כל הצרכים: RBAC, לוחות זמנים, webhooks, ביקורת. Tower מוצדקת כשצריך מודולים עם רישיון, תמיכה של Red Hat, ואינטגרציה עם סביבת RHEL.
| קריטריון | AWX | Ansible Tower (AAP) |
|---|---|---|
| רישיון | Apache 2.0 (חינם) | מנוי בתשלום של Red Hat |
| התקנה | ב-Kubernetes דרך Operator | Helm charts או RPM |
| עדכונים | כל 2–3 שבועות | כל 6–12 חודשים, LTS |
| תמיכה | קהילה, GitHub Issues | SLA של Red Hat, מודולים מאושרים |
| תכונות נוספות | מינימליות | Private Automation Hub, Automation Controller |
אפשרויות פריסה
| שיטה | סביבות | מורכבות |
|---|---|---|
| AWX Operator ב-k8s | כל העננים ו-on-prem | בינונית |
| Tower Helm chart | OpenShift, RHEL | גבוהה |
| Docker Compose AWX | סביבות בדיקה | נמוכה |
טעויות נפוצות בהתקנה עצמית
- שימוש במסד הנתונים PostgreSQL ברירת המחדל ללא PVC — אישורים אובדים כשהפוד נוצר מחדש.
- אין ארגון נפרד לכל פרויקט — כל ה-Job Templates בערימה אחת.
- אחסון סיסמת ה-vault בטקסט פשוט במשתני AWX במקום הגדרת Encrypted Credentials.
- תצורת webhook שגויה: לא צוין secret token, כך שכל אחד יכול לשלוח טריגרים.
אנחנו מתקנים את הטעויות האלה ואחרות כחלק מהשירות. לאחר היישום, שגיאות הפריסה יורדות ל-1-2 בחודש עם 3000+ הרצות.
מבנה AWX: ארגונים, פרויקטים, Job Templates
- ארגונים — בידוד צוותים. לכל ארגון יש Inventories, Projects, Credentials ו-Teams משלו.
-
פרויקטים — מאגר git עם playbooks. AWX מריץ אוטומטית את
# Установка через kustomize (рекомендуемый способ) git clone https://github.com/ansible/awx-operator.git cd awx-operator git checkout tags/2.19.0 # Создание namespace и установка оператора kubectl apply -k config/default # awx-instance.yml cat <<EOF | kubectl apply -f - apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx-prod namespace: awx spec: service_type: LoadBalancer postgres_storage_class: fast-ssd postgres_storage_requirements: requests: storage: 20Gi web_replicas: 2 task_replicas: 2 receptor_log_level: warn EOFלפני כל ביצוע או לפי לוח זמנים. - אישורים — אחסון גישה (מפתחות SSH, סיסמאות vault, אישורי ענן). מוצפנים במסד הנתונים של AWX, לא גלויים למשתמשים בממשק.
- Job Templates — ביצוע playbook עם פרמטרים: איזה playbook, על איזה inventory, עם אילו אישורים ומשתנים.
- Workflow Templates — רצף של Job Templates עם לוגיקת הסתעפות: אם הפריסה ל-staging מצליחה → פריסה לייצור, אחרת → הודעת Slack.
---
# Пример workflow через awx CLI
awx workflow_job_templates create \
--name "Deploy to Production" \
--organization "Corp Engineering" \
--schema '{
"nodes": [
{
"job_type": "job",
"job_template": "Deploy App Staging",
"success_nodes": [{"job_template": "Smoke Tests Staging"}],
"failure_nodes": [{"job_template": "Notify Failure"}]
},
{
"job_type": "job",
"job_template": "Smoke Tests Staging",
"success_nodes": [{"job_template": "Deploy App Production"}]
}
]
}'
---מה כלול בעבודה
- התקנת AWX/Tower באשכול Kubernetes שלכם או בשרת ייעודי.
- המרת playbooks קיימים למבנה Projects/Job Templates.
- הגדרת RBAC — תפקידים, צוותים, אינטגרציית LDAP/AD.
- יצירת Workflow Templates לפריסות canary ו-blue-green.
- הדרכת צוות — 2-3 מפגשים על הרצה ופתרון תקלות.
- תיעוד — סכמת תצורה, runbook, הוראות משתמש.
- אחריות — התקנה ללא תקלות, חודש תמיכה.
לוח זמנים ועלות
לוח זמנים: מיומיים (התקנה בסיסית) עד 5 ימים (מחזור מלא עם workflows ו-LDAP). העלות מחושבת באופן אישי. חיסכון בזמן באוטומציה — עד 80% במשימות שגרתיות. הניסיון של הצוות שלנו: 5+ שנים של עבודה עם Ansible בייצור, מעל 30 פרויקטי אוטומציה. אנחנו מבטיחים SLA לתמיכה וייעוץ חינם לאחר היישום.
קבלו ייעוץ: צרו קשר, נעריך את הפרויקט שלכם תוך יום עסקים אחד. הזמינו יישום AWX או Tower במפתח.