راه‌اندازی HashiCorp Nomad روی سرور مجازی و اختصاصی: جایگزین ساده‌تر Kubernetes برای ارکستراسیون کانتینر

کوبرنتیز قدرتمند است، اما نصب و نگهداریش برای یک تیم کوچک یا یک پروژه با چند سرویس زیاد پیچیده به نظر می‌رسد. HashiCorp Nomad همان کار ارکستراسیون کانتینر را با یک باینری تنها انجام می‌دهد و نصبش روی یک سرور مجازی معمولی چند دقیقه طول می‌کشد. در این مقاله راه‌اندازی Nomad روی سرور مجازی را از صفر تا اجرای اولین Job و ساخت یک کلاستر چندگره‌ای جلو می‌بریم.

Nomad چیست و چه فرقی با Kubernetes دارد؟

Nomad محصول HashiCorp است و کارش زمان‌بندی (scheduling) و اجرای برنامه‌ها روی یک گروه سرور است؛ چه برنامه داکرایز شده باشد، چه یک باینری ساده یا یک اسکریپت جاوا. برخلاف کوبرنتیز که از چند کامپوننت جداگانه (etcd، kube-apiserver، kubelet، kube-proxy، scheduler و controller-manager) ساخته شده، Nomad یک باینری Go با وزن چند ده مگابایت است که همان فایل هم روی سرور و هم روی کلاینت اجرا می‌شود.

این یعنی نصب، آپدیت و دیباگ کردنش ساده‌تر است. در عوض بعضی قابلیت‌های آماده کوبرنتیز مثل Ingress Controller یا Service Mesh پیشرفته را ندارد؛ برای این‌ها باید Consul یا یک ابزار جداگانه کنارش اضافه کنید. همین تنوع درایورها (exec، java، qemu) باعث می‌شود Nomad علاوه بر سرویس‌های داکرایز شده، برای اجرای job‌های batch یا یک GitLab Runner خودمیزبان برای CI/CD هم گزینهٔ مناسبی باشد.

مقایسه Nomad و Kubernetes

قبل از شروع نصب، بهتر است بدانید کدام ابزار برای چه نوع پروژه‌ای ساخته شده.

ویژگی	Nomad	Kubernetes
تعداد کامپوننت اصلی	یک باینری (agent)	چند کامپوننت جدا (etcd، API server، kubelet و...)
نصب روی یک سرور تک‌نفره	چند دقیقه، یک فایل کانفیگ	معمولا با ابزاری مثل kubeadm یا k3s
پشتیبانی از بار غیرکانتینری	دارد (exec، java، qemu)	فقط کانتینر و چند driver محدود
Service Mesh و Ingress آماده	باید Consul و Traefik یا Fabio اضافه شود	با Ingress Controller و افزونه‌های رسمی در دسترس‌تر
منحنی یادگیری برای تیم کوچک	کم	بیشتر
اندازه اکوسیستم و تعداد افزونه	محدودتر	بسیار بزرگ‌تر

اگر تیم‌تان چند نفره است و روی چند سرویس داکری کار می‌کنید، Nomad معمولا کافی است. اگر پروژه بزرگ‌تر می‌شود و به اتوماسیون پیشرفته شبکه یا یک اکوسیستم افزونه بزرگ نیاز دارید، مهاجرت بعدی به کوبرنتیز هم راحت است چون هر دو از ایمیج داکر استفاده می‌کنند.

پیش‌نیازهای نصب Nomad

برای تست و یادگیری، یک سرور مجازی با ۱ vCPU و ۱ تا ۲ گیگابایت رم کافی است. برای یک کلاستر واقعی که چند سرویس تولیدی روی آن اجرا می‌شود، حداقل ۲ vCPU و ۴ گیگابایت رم برای هر گره پیشنهاد می‌شود. سیستم‌عامل می‌تواند اوبونتو ۲۲.۰۴ یا ۲۴.۰۴، دبیان ۱۲ یا هر توزیع لینوکسی با systemd باشد. اگر از درایور داکر استفاده می‌کنید، Docker هم باید قبل از Nomad روی همان سرور نصب شده باشد؛ برای مدیریت گرافیکی کانتینرها بعدا می‌توانید Portainer را هم کنارش راه‌اندازی کنید.

نصب Nomad روی یک سرور تک‌گره

اول باینری را دانلود کنید (نسخه را از صفحه releases.hashicorp.com چک کنید و همیشه آخرین نسخه پایدار را بگیرید):

wget https://releases.hashicorp.com/nomad/1.8.4/nomad_1.8.4_linux_amd64.zip
unzip nomad_1.8.4_linux_amd64.zip
sudo mv nomad /usr/local/bin/
nomad version

فایل کانفیگ را در /etc/nomad.d/nomad.hcl بسازید:

data_dir  = "/opt/nomad/data"
bind_addr = "0.0.0.0"

server {
  enabled          = true
  bootstrap_expect = 1
}

client {
  enabled = true
}

bootstrap_expect=1 فقط برای تست روی یک سرور تنها است؛ در بخش کلاستر چندگره‌ای این عدد را به ۳ تغییر می‌دهیم.

سرویس systemd را در /etc/systemd/system/nomad.service بسازید:

[Unit]
Description=Nomad Agent
After=network-online.target

[Service]
ExecStart=/usr/local/bin/nomad agent -config=/etc/nomad.d
Restart=on-failure

[Install]
WantedBy=multi-user.target

سپس:

sudo systemctl daemon-reload
sudo systemctl enable --now nomad
nomad node status
nomad server members

اگر هر دو دستور آخر خروجی بدون خطا دادند، Nomad آماده است.

اجرای اولین Job روی Nomad

یک فایل به نام example.nomad.hcl بسازید که یک nginx ساده را با درایور داکر اجرا می‌کند:

job "example" {
  datacenters = ["dc1"]

  group "web" {
    count = 1

    network {
      port "http" {
        static = 8080
        to     = 80
      }
    }

    task "nginx" {
      driver = "docker"

      config {
        image = "nginx:alpine"
        ports = ["http"]
      }

      resources {
        cpu    = 200
        memory = 128
      }
    }
  }
}

اجرا و بررسی:

nomad job run example.nomad.hcl
nomad job status example
nomad alloc logs <alloc-id>
curl http://<ip-سرور>:8080

اگر صفحه خوش‌آمدگویی nginx باز شد، اولین Job‌تان روی Nomad در حال اجراست.

ساخت کلاستر چند‌گره‌ای Nomad

برای یک محیط تولیدی واقعی، یک سرور تنها کافی نیست؛ نیاز به حداقل ۳ گره سرور (server) دارید تا الگوریتم Raft بتواند رای‌گیری انجام دهد و اگر یک گره خاموش شد، کلاستر از کار نیفتد. تعداد سرورها را همیشه فرد انتخاب کنید (۳ یا ۵).

روی هر سرور، کانفیگ را به این شکل تغییر دهید:

server {
  enabled          = true
  bootstrap_expect = 3
}

server_join {
  retry_join = ["10.0.0.11", "10.0.0.12", "10.0.0.13"]
}

گره‌های client که بار کاری (job) را اجرا می‌کنند، جدا از سرورها تعریف می‌شوند و فقط باید آدرس سرورها را بشناسند:

client {
  enabled = true
  servers = ["10.0.0.11:4647", "10.0.0.12:4647", "10.0.0.13:4647"]
}

جدا کردن نقش server و client باعث می‌شود رای‌گیری کلاستر درگیر بار واقعی اپلیکیشن نشود. برای کشف سرویس بین گره‌ها می‌توانید Consul را هم اضافه کنید، اما برای یک کلاستر کوچک با چند سرور مشخص، لیست IP ثابت در retry_join کافی است.

سرور مجازی یا سرور اختصاصی، کدام را انتخاب کنیم؟

برای تست و یادگیری، سرور مجازی ارزان‌ترین راه شروع است؛ حتی می‌توانید چند سرور مجازی را فقط برای چند ساعت تست کلاستر روشن کنید و بعد خاموش کنید. برای بار تولیدی با مصرف CPU پیوسته و بالا، یا سرویس‌هایی که به منابع ثابت و بدون اشتراک با همسایه نیاز دارند، سرور اختصاصی گزینه مطمئن‌تری است چون منابعش با سرورهای دیگر تقسیم نمی‌شود. برای مقایسهٔ کامل‌تر این دو گزینه، راهنمای سرور مجازی یا سرور اختصاصی را هم بخوانید.

نکات امنیتی و نگهداری کلاستر

• پورت‌های 4646 (HTTP API و رابط وب)، 4647 (RPC بین گره‌ها) و 4648 (gossip) را فقط برای شبکه داخلی یا IPهای مشخص باز کنید، نه برای کل اینترنت.
• در محیط تولیدی، سیستم ACL را فعال کنید (acl { enabled=true }) تا هر تیم فقط به job‌های خودش دسترسی داشته باشد.
• اگر گره‌ها روی شبکه عمومی یا دیتاسنترهای جدا از هم هستند، TLS را برای ترافیک RPC و gossip فعال کنید.
• پوشه data_dir روی سرورها شامل داده Raft است؛ بکاپ منظم از آن بگیرید.
• وضعیت کلاستر را با nomad server members و nomad node status دوره‌ای چک کنید، و اگر نیاز به مانیتورینگ دقیق‌تر دارید، endpoint متریک /v1/metrics را به Prometheus و Grafana وصل کنید.

جمع‌بندی

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

سؤالات متداول

آیا Nomad رایگان است؟ نسخه اصلی Nomad متن‌باز و رایگان است. HashiCorp یک نسخه Enterprise هم با قابلیت‌های اضافه برای تیم‌های بزرگ دارد، اما برای اکثر پروژه‌ها نسخه رایگان کافی است.

آیا Nomad می‌تواند به‌جای Consul هم کار کند؟ نه کاملا. Nomad کارش زمان‌بندی و اجرای job است؛ Consul کشف سرویس و شبکه بین سرویس‌ها را مدیریت می‌کند. این دو معمولا کنار هم استفاده می‌شوند، ولی برای یک کلاستر کوچک می‌توان بدون Consul هم شروع کرد.

برای یک پروژه کوچک، Nomad بهتر است یا Docker Compose؟ اگر همه چیز روی یک سرور اجرا می‌شود و نیازی به جابه‌جایی خودکار بین چند سرور نیست، Docker Compose ساده‌تر است. وقتی باید چند سرور را مدیریت کنید یا بخواهید سرویس‌ها خودکار بین گره‌ها جابه‌جا شوند، Nomad گزینه بهتری است.

آیا می‌توان بعدا از Nomad به Kubernetes مهاجرت کرد؟ بله. چون هر دو از ایمیج داکر استفاده می‌کنند، مهاجرت ایمیج‌ها ساده است؛ فقط تعریف job باید به فرمت YAML کوبرنتیز بازنویسی شود، اما لایه اپلیکیشن معمولا بدون تغییر باقی می‌ماند.