در این مقاله به بررسی مفهوم و شیوه‌ی استفاده از route در پلتفرم ابری آروان و هم‌چنین اجزای سازنده یک route و چگونگی تعریف هریک از آن‌ها پرداخته می‌شود.
پیش‌نیازهای استفاده از route در پلتفرم ابری آروان
تنها پیش نیاز استفاه از این سیستم، داشتن حساب کاربری ابر آروان و دسترسی به پلتفرم ابری آروان است. بنابراین به سایت ابر آروان به نشانی arvancloud.com بروید و یک حساب کاربری بسازید یا اگر از پیش حساب کاربری دارید، وارد آن شوید. سپس به بخش پروفایل بروید و در سربرگ 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-mn1.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-mn1.arvan.run nginx-service <all> edge/Allow Noneدر خروجی بالا، NAME مشخصکنندهی نام route و HOST/PORT مشخصکنندهی دامنه route است. PATH مشخصکنندهی مسیری است که ترافیک سمت آن هدایت می‌شود (این موضوع در این مقاله پوشش داده نشده و در مقالات آینده به آن خواهیم پرداخت). SERVICES مشخصکنندهی نام serviceای است که ترافیک به آن ارسال می‌شود. PORT مشخصکنندهی پورت مربوط به SERVICEای است که ترافیک به آن هدایت می‌شود. TERMINATION مشخصکنندهی نوع terminationای است که در route مشخص شده است. در مورد WILDCARD در مقالات آینده صحبت خواهد شد.
نام دامنه‌ی route
همان‌طور که گفته شد، route به وسیله‌ی نام دامنه، امکان ارتباط با podها را از خارج از کلاستر فراهم می‌کند. در حال حاضر تنها می‌توان از دامنه‌های پیش‌فرض پلتفرم ابری آروان استفاده کرد. شیوه‌ی تعریف این دامنه‌ها به شکل زیر است.
[app name]-[project name].apps.ir-thr-mn1.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 مراجعه کنید. این مقاله از مراجع زیر اقتباس شده است.
