زیرساخت کلودی و DevOps

زیرساخت خودمان را خودمان اداره می‌کنیم و بیشترِ صلاحیت ما برای اداره کردن زیرساخت شما از همین‌جا می‌آید. سرور عملیاتی ما ده‌ها کانتینر را اجرا می‌کند: بک‌اند و فرانت‌اند FanDesk، Mobile Master، Probe361، EnergyFile و همین سایت، به‌علاوهٔ MongoDB، PostgreSQL، Redis، پایگاه دادهٔ برداری Qdrant و یک مجموعهٔ کامل مانیتورینگ. برای این کار از Kubernetes استفاده نمی‌کنیم و فکر می‌کنیم بیشتر شرکت‌هایی در اندازهٔ ما یا شما هم به آن نیاز ندارند. Docker Compose، یک reverse proxy خوب و نظم در استقرار و پشتیبان‌گیری کار را خیلی جلو می‌برد.

این خدمت برای چه کسانی است

سازمان‌هایی که می‌خواهند نرم‌افزارشان روی سرورهایی باشد که خودشان کنترلش می‌کنند؛ یک سرور مجازی اجاره‌ای، رکی در ساختمان خودشان یا شبکه‌ای بدون دسترسی به اینترنت. همین‌طور تیم‌هایی که وضعیت فعلی‌شان «یک سرور است که کسی سال‌ها پیش تنظیمش کرده»: کار می‌کند، کسی جرئت دست زدن به آن را ندارد و هر ری‌استارت یعنی چند دقیقه خطا برای کاربران.

روند کار

1. بررسی وضعیت فعلی. سرویس‌ها، پایگاه‌های داده، محل نگهداری رمزها، روش استقرار و اینکه از چه چیزی نسخهٔ پشتیبان گرفته می‌شود. اغلب اولین یافته این است که نسخهٔ پشتیبان هیچ‌وقت بازیابی نشده.
2. کانتینری‌سازی. هر سرویس یک Dockerfile و جایی در فایل Compose می‌گیرد، با health check، محدودیت حافظه و سیاست ری‌استارت. تنظیمات به فایل‌های محیطی منتقل می‌شود که وارد git نمی‌شوند.
3. مسیریابی و TLS. Traefik جلوی همه قرار می‌گیرد، کانتینرها را از روی برچسب‌ها پیدا می‌کند و گواهی‌ها را خودکار مدیریت می‌کند. هر جا منطقی باشد، پشت Cloudflare.
4. مانیتورینگ، لاگ و پشتیبان‌گیری. متریک و داشبورد، لاگ کانتینرها در یک جای قابل جست‌وجو، بررسی دسترس‌پذیری از بیرون و نسخهٔ پشتیبان شبانه که روی یک ماشین دوم کپی می‌شود.
5. اسکریپت استقرار و تحویل. استقرار اسکریپت‌شده و تکرارپذیر و یک راهنمای عملیاتی کوتاه: چطور مستقر کنیم، چطور برگردیم، چطور بازیابی کنیم.

پشته‌ای که واقعاً استفاده می‌کنیم

Docker و Docker Compose برای همهٔ سرویس‌ها. Traefik به‌عنوان reverse proxy با گواهی Let's Encrypt. Prometheus متریک‌های میزبان و هر کانتینر را از node-exporter و cAdvisor جمع می‌کند و Grafana نمایششان می‌دهد. Promtail لاگ کانتینرها را به Loki می‌فرستد، که فقط وقتی خوب کار می‌کند که برنامه‌ها روی stdout لاگ بنویسند؛ درسی که بعد از گم شدن لاگ‌های nginx درست در لحظهٔ نیاز یاد گرفتیم و درباره‌اش نوشتیم. Uptime Kuma همهٔ دامنه‌های عمومی را از طریق HTTPS بررسی می‌کند. CI روی GitHub Actions اجرا می‌شود، از جمله یک runner روی سرور خودمان که تمرین بازیابی هفتگی را انجام می‌دهد.

نمونه‌هایی از زیرساخت خودمان

استقرار blue-green. دستور ساده docker compose up -d کانتینر قدیمی را قبل از آماده شدن کانتینر جدید متوقف می‌کند و Traefik در همان چند ثانیه خطا برمی‌گرداند. اسکریپت استقرار ما کانتینر جدید را کنار قدیمی بالا می‌آورد، صبر می‌کند تا health check آن سالم گزارش شود (Traefik از همان لحظه به آن ترافیک می‌فرستد)، قدیمی را حذف می‌کند و جدید را به جای آن نام‌گذاری می‌کند. اگر کانتینر جدید هیچ‌وقت سالم نشود، حذف می‌شود و قدیمی به کارش ادامه می‌دهد. چیزی خراب نمی‌شود.

سروری بدون اینترنت. یکی از مقصدهای استقرار ما دسترسی به اینترنت و registry ندارد و پشت یک jump host است. ایمیج‌ها را سمت خودمان می‌سازیم و با docker save و docker load از طریق SSH منتقل می‌کنیم و بعد با همان اسکریپت blue-green جایگزین می‌کنیم. Probe361 و EnergyFile آنجا اجرا می‌شوند.

پشتیبانی که بازیابی می‌شود. برای Mobile Master یک کار شبانه از MongoDB نسخه می‌گیرد، فایل را بررسی می‌کند، روی سرور دیگری کپی می‌کند و checksum دو طرف را مقایسه می‌کند. هفته‌ای یک بار CI آخرین نسخه را در یک پایگاه دادهٔ موقت بازیابی می‌کند و مجموعه‌ها و تعداد اسناد را می‌سنجد. نسخهٔ پشتیبانی که کسی بازیابی‌اش نکرده، فقط یک امید است.

FanMail، سرویس ایمیل self-hosted ما که روی Stalwart Mail Server ساخته شده، هم با همین روش اجرا می‌شود.

مطالعهٔ بیشتر

• لاگ کانتینر باید روی stdout باشد، نه در فایل
• زیرساخت Docker پشت CMS خودمیزبان ما

پرسش‌های متداول

از Kubernetes استفاده می‌کنید؟

به‌طور پیش‌فرض نه. برای چند سرور، Docker Compose همراه با Traefik ساده‌تر اجرا می‌شود و راحت‌تر تحویل داده می‌شود. اگر از قبل Kubernetes دارید یا واقعاً به زمان‌بندی چندگره‌ای نیاز دارید، درباره‌اش صحبت می‌کنیم، ولی فقط چون مد است اضافه‌اش نمی‌کنیم.

روی سرور بدون اینترنت هم مستقر می‌کنید؟

بله، همین حالا این کار را می‌کنیم. ایمیج‌ها جای دیگری ساخته می‌شوند و از طریق SSH منتقل می‌شوند؛ ایمیج‌های پایه هم همین‌طور، پس سرور مقصد هیچ‌وقت به registry نیاز ندارد.

استقرار بدون قطعی در عمل یعنی چه؟

نسخهٔ جدید کنار نسخهٔ قدیمی بالا می‌آید و نسخهٔ قدیمی فقط وقتی حذف می‌شود که جدید health check را رد کند. کاربران در یک استقرار معمولی خطا نمی‌بینند و اگر استقرار شکست بخورد، نسخهٔ قبلی همچنان اجرا می‌ماند.

با کدام ارائه‌دهندهٔ ابری کار می‌کنید؟

هر ارائه‌دهنده‌ای که سرور مجازی لینوکس بدهد، یا سخت‌افزار خودتان. زیرساخت ما به سرویس‌های مدیریت‌شدهٔ یک ابر خاص وابسته نیست و جابه‌جایی بین ارائه‌دهنده‌ها را خیلی ساده‌تر می‌کند.

نسخه‌های پشتیبان چطور تست می‌شوند؟

با بازیابی زمان‌بندی‌شده در یک پایگاه دادهٔ موقت و بررسی چیزی که برگشته. اگر تمرین شکست بخورد، همان هفته می‌فهمیم، نه روزی که به نسخهٔ پشتیبان نیاز داریم.

می‌توانید سرور فعلی ما را تحویل بگیرید؟

بله. معمولاً با بررسی و یک نسخهٔ پشتیبان تأییدشده شروع می‌کنیم و بعد سرویس‌ها را یکی‌یکی کانتینری می‌کنیم تا لازم نباشد همه‌چیز یک‌جا از کار بیفتد.