شروع کار

پیش از آن‌که اولین استقرار را انجام دهید، سه چیز باید سر جای خود باشد: دسترسی به مخزن، یک محیط Staging که آینه‌ی محیط عملیاتی باشد، و یک مسیر مشخص برای بازگشت. این سند همان سه مورد را پوشش می‌دهد.

پیش‌نیازها

ابزارهایی که در همه‌ی مثال‌های این مستندات فرض شده‌اند روی ماشین شما نصب است:

اولین ورود

پس از دریافت دعوت‌نامه، پیکربندی دسترسی خوشه را با ابزار داخلی بگیرید. توکن روی دیسک ذخیره می‌شود و پس از دوازده ساعت منقضی می‌گردد.

mizban auth login --org acme
mizban cluster use production
kubectl get nodes -o wide

اگر خروجی دستور سوم خالی بود، مشکل از دسترسی RBAC شماست و نه از خوشه. با تیم پلتفرم تماس بگیرید تا نقش شما را بررسی کند.

ساختار Namespace

هر تیم دقیقاً یک Namespace برای هر محیط دارد. نام‌گذاری از الگوی <team>-<env> پیروی می‌کند و انحراف از آن باعث می‌شود سیاست‌های شبکه به‌درستی اعمال نشوند.

apiVersion: v1
kind: Namespace
metadata:
  name: payments-production
  labels:
    app.kubernetes.io/part-of: payments
    mizban.io/environment: production
    mizban.io/oncall-rotation: payments-primary

اولین استقرار

استقرار همیشه از شاخه‌ی اصلی و از طریق خط لوله انجام می‌شود. kubectl apply دستی روی محیط عملیاتی توسط سیاست‌های Gatekeeper رد می‌شود.

اگر برای رفع یک حادثه مجبور شدید سیاست را دور بزنید، این کار مجاز است — اما باید ظرف بیست‌وچهار ساعت به‌صورت یک Merge Request مستند شود. زیرساختی که فقط در ذهن یک نفر وجود دارد، زیرساخت نیست.

قدم بعدی

سند «کالبدشکافی خط لوله» توضیح می‌دهد که میان git push و رسیدن ترافیک به نسخه‌ی جدید، دقیقاً چه اتفاقی می‌افتد.