در این آموزش مدیریت دامنه پشت CDN را با API نسخه ۲.۱ خودکار می‌کنیم: توکن و شناسه‌ی فضای کاری را آماده می‌کنیم، کانفیگ دامنه را با GET دریافت می‌کنیم و دیواره آتش (Firewall) همان دامنه را با PATCH به‌روز می‌کنیم.

اگر به‌روزرسانی را با kubectl می‌خواهیم، آموزش مدیریت دامنه خود را با Kubectl خودکار کنید را دنبال می‌کنیم.

مرجع کامل مسیرها و فیلدها: CDN and DNS (v2.1). برای پاک‌سازی کش با API، پاکسازی کش دامنه (Purge) با API را دنبال می‌کنیم.


پیش‌نیازها

  • دامنه یا زیردامنه پشت CDN ستون — آموزش‌ها
  • دسترسی به پنل اوشن برای ساخت توکن و دریافت WorkspaceUUID
  • امکان اجرای دستور CURL

مراحل

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

امنیت توکن

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

  1. از فضاهای کاری مقدار شناسه‌ی فضای کاری (WorkspaceUUID) مورد نظر را کپی می‌کنیم.
  2. ابتدا فهرست CDNهای متناظر با دامنه‌ها را دریافت می‌کنیم:
curl -sS -X GET \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<WorkspaceUUID>/cdns" \
  -H "Authorization: Bearer <TOKEN>"
  1. با نگاه به فیلد spec.hostname آیتم‌های لیست دریافتی، دامنه موردنظر را پیدا کرده فیلد metadata.name ردیف متناظر با آن کپی می‌کنیم و به شکل زیر امکان دریافت تک CDN متناظر با دامنه مهیا می‌باشد:
curl -sS -X GET \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<WorkspaceUUID>/cdns/<NAME>" \
  -H "Authorization: Bearer <TOKEN>"

پارامتر <NAME>

<Name> همان metadata.name آبجکت CDN است، نه لزوما نام دامنه.

  1. دیواره آتش (Firewall) را فعال و یک قانون Rate Limit نمونه برای درخواست‌هایی که بات شناخته‌شده نیستند اضافه می‌کنیم.

مهم برای Production

حتما قبل از اعمال در Production، نرخ و شروط را متناسب با نیاز خود تنظیم و آزمایش می‌کنیم.

curl -sS -X PATCH \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<WorkspaceUUID>/cdns/<NAME>" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/merge-patch+json" \
  -d '{
    "spec": {
      "firewall": {
        "enabled": true,
        "rules": [
          {
            "name": "ratelimit-1",
            "enabled": true,
            "constraints": [
              [
                {
                  "type": "known_bots",
                  "known_bots": {
                    "expected": "false",
                    "operator": "equals"
                  }
                }
              ]
            ],
            "action": {
              "type": "ratelimit",
              "ratelimit": {
                "algorithm": "fixed_window",
                "rate": 100,
                "period": 60,
                "penalty_period": 1,
                "identifier": {
                  "type": "ip"
                },
                "statusCode": "429",
                "validationStatusCode": "412"
              }
            }
          }
        ]
      }
    }
  }'

merge-patch

برای PATCH جزیی از Content-Type: application/merge-patch+json استفاده می‌کنیم تا فقط بخش اعلام‌شده عوض شود. منطق constraints در منطق شروط DNF و عملیات‌ها در تنظیمات دیواره آتش (Firewall) است.

بازنویسی قوانین

این نمونه کل spec.firewall.rules را با قوانین مشخص شده جایگزین می‌کند. اگر قوانین دیگری داریم، آن‌ها را هم در همان آرایه نگه می‌داریم یا ابتدا با GET وضعیت فعلی را می‌خوانیم و ادغام می‌کنیم.


بررسی صحت

  • دوباره همان CDN را با GET می‌خوانیم؛ در spec.firewall باید enabled: true و قانون ratelimit-1 دیده شود.
  • کد پاسخ PATCH و GET نباید 401 / 403 باشد؛ در غیر این صورت توکن و نقش را بررسی می‌کنیم.
  • چند دقیقه برای انتشار روی لبه‌ها صبر می‌کنیم؛ در صورت نیاز در مشاهده لحظه‌ای لاگ درخواست‌ها فیلدهای fw_rule_name و fw_blocked را برای ترافیک تست بررسی می‌کنیم.
  • اگر کد پاسخ 404 دریافت کردیم، مقدار <NAME> را بررسی می‌کنیم تا از انتخاب صحیح آن اطمینان حاصل کنیم.

ادامه مسیر