استفاده از Route در کانتینر ابری آروان

در این مقاله به بررسی مفهوم و شیوه‌ی استفاده از Route در سکوی ابری آروان و هم‌چنین اجزای سازنده یک Route  و چگونگی تعریف هریک از آن‌ها پرداخته می‌شود.

پیش‌نیازهای استفاده از Route در سکوی ابری آروان

تنها پیش نیاز استفاه از این سیستم، داشتن حساب کاربری ابر آروان و دسترسی به سکوی ابری آروان است. بنابراین به سایت ابر آروان به نشانی arvancloud.ir بروید و یک حساب کاربری بسازید یا اگر از پیش حساب کاربری دارید، وارد آن شوید. سپس به بخش پروفایل بروید و در سربرگ API KEYS برای خود یک API KEY جدید بسازید و آن را در جایی ذخیره کنید.

برای انجام مراحل این مقاله نیاز است از Command Line ابر آروان استفاده کنید. پس از دانلود خط فرمان (در صورت نیاز آن را در PATH خود قرار دهید) با کمک دستور زیر در آن لاگین کنید.

arvan login

سپس API KEY که از سایت دریافت کردید در اینجا کپی کنید.

Route چیست؟

Route یکی از اجزای اصلی و پرکاربرد در سکوی ابری آروان است که به کاربر امکان ارسال درخواست به Podهای خود را، از خارج از سکوی ابری آروان می‌دهد.
پس از توسعه‌ی برنامه و ساخت  Deployment و ایجاد Service در سکوی ابری آروان، نیاز است تا از خارج از سکوی ابری، درخواست‌ها به برنامه ارسال شوند. Route این ارتباط را میان دنیای خارج و سکوی ابری، با کمک نام دامنه، ایجاد می‌کند.

Route تنها درخواست‌های HTTP و HTTPS را می‌پذیرد. این درخواست‌ها از دامنه به Route می‌رسند، سپس Route این درخواست ها را به Serviceای که مشخص شده ارسال می‌کند. هم‌چنین شما می‌توانید با ارایه‌ی گواهینامه‌ی TLS به Route، ترافیک‌های HTTPS را به‌وسیله‌ی آن مدیریت و این بار را از برنامه خود حذف، و منابع کمتری مصرف کنید.

ساخت Route

برای ساخت Route، باید اطلاعات مورد نیاز را در قالب yaml در یک فایل وارد و سپس با Command Line آن را به سکوی ابری آروان ارایه کنید. در ادامه نمونه‌ای ساده از یک Route برای یک سرویس nginx (که در مقالات پیشین، Deployment و Service برای آن ایجاد شد) آورده شده و هریک از بخش‌های آن توضیح داده شده است.

apiVersion: v1
kind: Route
metadata:
  name: nginx-route 
spec:
  host: nginx-example-project.apps.ir-thr-at1.arvan.run
  to:
    kind: Service
    name: nginx-service
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Allow
  port:
    targetPort: http

نکته: توجه کنید که Indentation در فایل‌های YAML مهم است و کوچک‌ترین جابه‌جایی می‌تواند سبب برگرداندن خطا و یا تنظیمات ناخواسته شود.

در ادامه فیلدهای مربوطه توضیح داده می‌شود.

• kind: مشخص‌کننده‌ی نوع ماهیت است. این فیلد می‌تواند مقادیری مانند:‌ Pod، Route، Service، StatefulSet و … داشته باشد. در این نمونه، هدف تعریف Route است بنابراین، مقدار آن Route مشخص شده است.
• name: مشخص‌کننده‌ی نام Route است.
• host: مشخص‌کننده‌ی دامنه‌ای است که از آن می‌توان از خارج از سکوی ابری آروان درخواست‌ها را به Route ارسال کرد.
• to: مشخص‌کننده‌ی موجودیتی است که باید درخواست‌ها به سمت آن هدایت شود. در این نمونه درخواست‌ها به Service مربوط به nginx که در مقالات قبل ساخته شده ارسال می‌شود.
• tls: در این بخش اطلاعات لازم برای TLS Termination قرار می‌گیرد.
• tls.termination: این فیلد مشخص می‌کند که شیوه‌ی Termination به چه شکل باشد. مقادیر مجاز برای این فیلد edge، passthrough و reencrypt هستند که در بخش‌های بعدی توضیح داده شده‌اند.
• tls.insecureEdgeTerminationPolicy: به‌شکل پیش‌فرض اجازه‌ی عبور ترافیک ناامن (http) داده نمی‌شود. با قرار دادن spec.tls.insecureEdgeTerminationPolicy برابر با Allow، ترافیک‌های ناامن نیز اجازه‌ی عبور از route را خواهند داشت. مقادیر دیگر این فیلد برابر با none (جهت عدم اجازه عبور ترافیک HTTP) و Redirect ( برای Redirect کردن ترافیک HTTP به HTTPS)‌ است.
• port.targetPort: توجه داشته باشید که Route می‌تواند ترافیک را تنها به یک Port تعریف شده در Service ارسال کند. به طور پیش‌فرض، Route ترافیک را به Portای ارسال می‌کند که در تعریف Service زودتر تعریف شده باشد. اگر نیازمند ارسال ترافیک به Port خاصی از سرویس باشید، از این فیلد برای اختصاص Port برای ارسال ترافیک می‌توانید استفاده کنید.

خطوط بالا را در یک فایل به نام nginx-route.yaml وارد و ذخیره کنید. سپس در Command Line با دستور زیر، Route خود را به سکوی ابری آروان ارایه کنید.

arvan paas apply -f nginx-route.yaml

با دستور زیر می‌توانید از وضعیت Route خود و اجرای آن روی سکوی ابری آروان آگاه شوید.

arvan paas get route

خروجی مشابه زیر خواهد بود:

$ arvan paas get route                                                                                         
NAME         HOST/PORT                             PATH   SERVICES         PORT      TERMINATION   WILDCARD
nginx-route  nginx-example-project.apps.ir-thr-at1.arvan.run        nginx-service    <all>     edge/Allow    None

در خروجی بالا، NAME مشخص‌کننده‌ی نام Route و HOST/PORT مشخص‌کننده‌ی دامنه Route است. PATH مشخص‌کننده‌ی مسیری است که ترافیک سمت آن هدایت می‌شود. SERVICES مشخص‌کننده‌ی نام Serviceای است که ترافیک به آن ارسال می‌شود. PORT مشخص‌کننده‌ی پورت مربوط به SERVICEای است که ترافیک به آن هدایت می‌شود. TERMINATION مشخص‌کننده‌‌ی نوع Terminationای است که در Route مشخص شده است.

نام دامنه‌ی Route

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

[app name]-[project name].apps.ir-thr-at1.arvan.run

نخست، در قسمت اول نام دلخواه خود (برای مثال نام برنامه) را قرار دهید و پس از آن با یک “-” فاصله نام پروژه خود را قرار دهید. توجه کنید که نام پروژه اجباری است.

TLS Termination

همان‌گونه گفته شد، فیلد spec.tls.termination می‌تواند سه مقدار reencrypt، passthrough و edge را داشته باشد. در ادامه هر یک توضیح داده خواهد شد.

Edge

اگر از دامنه‌ی‌ پیش‌فرض سکوی ابری آروان استفاده می‌کنید، از این نوع استفاده کنید. در این حالت، مدیریت ترافیک encrypt شده به‌وسیله‌ی TLS، در سمت Route و به‌وسیله‌ی سکوی ابری آروان انجام می‌شود و از route تا pod شما، ترافیک به شکل http ارسال می‌شود. در این حالت بار ناشی از https از روی podهای شما برداشته و منابع کمتری استفاده می‌شود.

اگر از دامنه‌ی سکوی ابری آروان استفاده می‌کنید نیازی به ارایه‌ی Certificate به Route نیست. هم‌چنین، شما ‌می‌توانید از دامنه‌ی خود استفاده کنید. و هم‌چنان از مزیت Edge Termination نیز بهره‌مند شوید. (از آنجا که در این حالت نیز دامنه‌ی شما از CDN آروان استفاده می کند، هم‌چنان نیازی به ارایه Certificate نیست.)
در حالت کلی کافی است certificate، ca certificate و private key را به Route ارایه کنید . همانند نمونه‌ی زیر:

apiVersion: v1
kind: Route
metadata:
  name: route-edge-secured
spec:
  host: www.example.com
  to:
    kind: Service
    name: service-name
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

reencrypt

در این حالت ابتدا یک‌بار در Route، عمل TLS Termination انجام می‌شود و سپس ترافیک مجدد به‌وسیله‌ی Route، در اصطلاح Encrypt شده و به Service و پس از آن به Podها ارسال می‌شود و Pod باید دوباره عمل Termination را اجرا کند. در چنین حالتی، ترافیک حتا درون سکوی ابری آروان نیز به‌شکل رمز شده است. در این شرایط باید ca certificate برای وب سرور داخلی (درون Pod مقصد) نیز به Route ارایه شود. سایر مقادیر مانند حالت Edge است. همانند نمونه‌ی زیر:

apiVersion: v1
kind: Route
metadata:
  name: route-pt-secured
spec:
  host: www.example.com
  to:
    kind: Service
    name: service-name
  tls:
    termination: reencrypt
    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

passthrough

در این حالت ترافیک مستقیم به سمت Service و پس از آن به Pod مقصد ارسال می‌شود و Route هیچ‌گونه عمل Termination را روی ترافیک انجام نمی‌دهد. در این حالت ترافیک به‌شکل Encrypt شده به برنامه شما ارسال می‌شود و مراحل رمزگشایی ترافیک HTTPS باید به‌وسیله‌ی برنامه‌ی شما مدیریت شود. توجه کنید که در این حالت، مقدار فیلد spec.tls.insecureEdgeTerminationPolicy تنها می‌تواند برابر مقادیر none و redirect باشد. نمونه‌ی زیر، نشان‌دهنده‌ی این حالت است:

apiVersion: v1
kind: Route
metadata:
  name: route-passthrough-secured
spec:
  host: www.example.com
  to:
    kind: Service
    name: service-name
  tls:
    termination: passthrough

برای کسب اطلاعات بیش‌تر می‌توانید به مستندات OKD مراجعه کنید.