در این مقاله
برنامه Spring Boot شما روی سیستم توسعه اجرا می‌شود، به دیتابیس وصل است و APIها پاسخ می‌دهند. بعد از انتقال به سرور، کانتینر بالا می‌آید ولی درخواست‌ها به آن نمی‌رسند؛ یا برنامه هنگام شروع دوباره راه‌اندازی می‌شود. برای دیپلوی spring boot باید Image، تنظیمات محیط، حافظه JVM، بررسی سلامت و مسیر ترافیک با هم سازگار باشند. ابتدا مشخص کنید می‌خواهید این اجزا را در کلاستر خودتان مدیریت کنید یا اجرای برنامه را به یک هاست جاوا مانند پاستا بسپارید. مسئولیت شما در این دو مسیر متفاوت است.
برای دیپلوی spring boot از کجا شروع کنید؟
یک Image قابل‌اجرا بسازید، تنظیمات حساس را بیرون آن نگه دارید و منابع و Health Check را تنظیم کنید. در Kubernetes، معمولاً Deployment اجرای Podها را مدیریت میکند و Service مسیر دسترسی به آن‌ها را فراهم میکند. Pod واحد اجرای برنامه در کلاستر است. مستندات Deployment، مستندات Service
اگر نمی‌خواهید عملیات کلاستر را بر عهده بگیرید، در پاستا پروژه را وارد می‌کنید، نتیجه تشخیص Build را بررسی می‌کنید و تنظیمات اجرا را مشخص می‌کنید. زیرساخت آن مبتنی بر Kubernetes است، ولی این به معنی دسترسی مستقیم شما به مدیریت کلاستر نیست.
در هر دو مسیر، برنامه باید مستقل از سیستم توسعه اجرا شود.
مدیریت مستقیم کلاستر یا استفاده از هاست جاوا؟
معیار تصمیم، میزان کنترلی است که لازم دارید:
|
نیاز شما |
مسیر مناسب‌تر |
|
کنترل مستقیم Manifestها و تنظیمات کلاستر |
Kubernetes تحت مدیریت خودتان |
|
انتشار برنامه با مشاهده Build، لاگ و وضعیت اجرا |
بررسی مسیر پاستا |
|
وابستگی به تنظیمات ویژه شبکه یا دسترسی سطح میزبان |
بررسی فنی پیش از انتخاب پلتفرم |
مدیریت مستقیم، مسئولیت Registry، دسترسی‌ها، شبکه، نگهداری کلاستر و پاسخ به اختلال را به تیم شما اضافه میکند. پاستا بخشی از Build و عملیات روزمره را مدیریت میکند؛ رفع اشکال کد، انتخاب منابع و سازگاری تغییرات دیتابیس همچنان بر عهده شماست.
پیش از Build، برنامه را از محیط توسعه جدا کنید
نسخه Java پروژه را از تنظیمات Build مشخص کنید و Runtime سازگار انتخاب کنید. برنامه نباید به مسیر فایل، پروفایل IDE یا رمز ذخیره‌شده روی لپ‌تاپ وابسته باشد.
Spring Boot از تنظیمات بیرونی، از جمله متغیر محیطی، پشتیبانی میکند. برای اتصال دیتابیس، تنظیمات SPRING_DATASOURCE_URL، SPRING_DATASOURCE_USERNAME و SPRING_DATASOURCE_PASSWORD را می‌توانید بیرون Image تأمین کنید. رمز را از مسیر Secret وارد کنید؛ آن را در Dockerfile، Repository یا دستور ترمینال ننویسید. مستندات تنظیمات بیرونی Spring Boot
در مسیر داکر Spring، خروجی Build باید JAR اجرایی و Image شامل Runtime سازگار باشد. ساخت لایه‌ای Image می‌تواند استفاده مجدد از لایه‌های وابستگی را بهتر کند، ولی پیش‌نیاز اولین استقرار نیست. راهنمای رسمی Dockerfile در Spring Boot
راهنمای داخلی «Dockerfile چیست و چگونه بنویسیم، با نمونه‌های آماده» در همین مرحله قرار می‌گیرد.
دسترسی محیط Build به وابستگی‌های Maven یا Gradle و Image پایه را بررسی کنید. موفقیت Build روی لپ‌تاپ، دسترسی شبکه مقصد را اثبات نمیکند. اگر دریافت وابستگی متوقف شد، آدرس منبع، DNS و دسترسی همان محیط را بررسی کنید.
سلامت برنامه و حافظه JVM را صریح تنظیم کنید
Health Check وضعیت برنامه را بررسی میکند؛ زنده‌بودن پردازش کافی نیست.
با افزودن وابستگی spring-boot-starter-actuator می‌توانید مسیرهای سلامت Spring Boot را استفاده کنید. در نمونه زیر فرض می‌کنیم تنظیمات امنیتی برنامه اجازه دسترسی Probeها به این مسیرها را می‌دهد:
server:
port: 8080
management:
endpoints:
web:
exposure:
include: health
endpoint:
health:
probes:
enabled: true
show-details: never
این یک مثال فرضی با پورت انتخابی است. آن را با تنظیمات برنامه ادغام کنید. پس از اجرا، مسیرهای /actuator/health/liveness و /actuator/health/readiness باید قابل بررسی باشند. اگر پاسخ مناسب ندارند، وابستگی Actuator، مسیر پایه و قواعد Spring Security را بررسی کنید. مستندات Actuator
در تنظیم JVM کانتینر، Heap را برابر کل حافظه مجاز نگذارید. JVM برای Metaspace، حافظه Threadها و بافرها هم حافظه مصرف میکند. گزینه -Xmx سقف Heap است، نه کل مصرف پردازش. مستندات JVM
Request در زمان‌بندی Pod نقش دارد؛ Limit سقف مصرف منبع را اعمال میکند. افزایش حافظه جای بررسی مصرف واقعی را نمی‌گیرد. مدیریت منابع در Kubernetes
راهنمای داخلی «Resource Request و Limit، تنظیم درست منابع کانتینر» باید در این بخش لینک شود.
نمونه استقرار را در محیط آزمایشی اجرا کنید
نمونه زیر برای کلاستری است که خودتان مدیریت می‌کنید؛ دستور استقرار در پاستا نیست.
تمام نام‌ها، ظرفیت‌ها، پورت‌ها و زمان‌های Manifest مثال فرضی هستند. آدرس Image را با Image واقعی و قابل‌دسترسی خودتان جایگزین کنید. برای اجرا، به Namespace آزمایشی موجود با نام spring-demo، دسترسی معتبر kubectl و Image آماده نیاز دارید.
فایل k8s.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: spring-demo
spec:
replicas: 1
selector:
matchLabels:
app: spring-demo
template:
metadata:
labels:
app: spring-demo
spec:
containers:
- name: app
image: registry.example.com/team/spring-demo:demo
ports:
- name: http
containerPort: 8080
env:
- name: JAVA_TOOL_OPTIONS
value: "-Xmx256m"
resources:
requests:
cpu: "250m"
memory: "384Mi"
limits:
cpu: "1"
memory: "512Mi"
startupProbe:
httpGet:
path: /actuator/health/liveness
port: http
periodSeconds: 5
failureThreshold: 60
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: http
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: http
---
apiVersion: v1
kind: Service
metadata:
name: spring-demo
spec:
selector:
app: spring-demo
ports:
- name: http
port: 8080
targetPort: http
Startup Probe به برنامه فرصت شروع می‌دهد؛ تا موفق‌شدن آن، بررسی‌های Liveness و Readiness آغاز نمی‌شوند. شکست Readiness نمونه را از دریافت ترافیک Service کنار می‌گذارد؛ شکست مداوم Liveness می‌تواند کانتینر را دوباره راه‌اندازی کند. سلامت دیتابیس را بی‌دلیل وارد Liveness نکنید. راهنمای Probeهای Kubernetes
ابتدا Context فعال را بررسی کنید، سپس فایل را اعمال کنید:
kubectl config current-context
kubectl --namespace spring-demo apply -f k8s.yaml
kubectl --namespace spring-demo rollout status deployment/spring-demo
دستور اول مقصد فعلی را نشان می‌دهد. پیش از apply مطمئن شوید همین محیط آزمایشی مدنظر شماست. این دستور منابع فایل را ایجاد یا به‌روزرسانی میکند؛ اجرای دوباره فایل بدون تغییر معمولاً استقرار تازه‌ای ایجاد نمیکند. rollout status فقط پیشرفت را بررسی میکند.
انتظار دارید Deployment آماده شود. این وضعیت، دسترسی عمومی را ثابت نمیکند: Service نمونه داخلی است و انتشار اینترنتی به مسیر ورودی و TLS نیاز دارد.
راهنمای داخلی «Ingress و Load Balancer، راهنمای عملی مسیریابی ترافیک» به این مرحله مربوط است.
همین مسیر در پاستا چگونه شروع می‌شود؟
در کنسول پاستا، پروژه را از Repository گیت، پوشه یا ZIP، Dockerfile یا Image عمومی وارد کنید. اتصال GitHub و GitLab پشتیبانی می‌شود. پیش از ساخت، نتیجه تشخیص پروژه و روش Build را بررسی و در صورت ناسازگاری اصلاح کنید.
متغیرهای محیطی، Secret، منابع و Health Check را تنظیم کنید. سپس وضعیت استقرار و لاگ را ببینید. اگر Build موفق بود ولی سرویس آماده نشد، تنظیمات Runtime را بررسی کنید؛ تکرار Build بدون تغییر، علت را برطرف نمیکند.
اپلیکیشن آماده می‌تواند آدرس HTTPS روی دامنه پاستا دریافت کند؛ دامنه شخصی هم قابل اتصال است. یک مسیر واقعی API و اتصال دیتابیس را آزمایش کنید. نمایش صفحه اولیه کافی نیست.
پیش از ساخت، هزینه تومانی اپلیکیشن، دیتابیس و ذخیره‌سازی را بررسی کنید. منابع ماهانه پیش از ساخت شارژ میشوند؛ ایجاد منبع PAYG به حداقل موجودی تنظیم‌شده نیاز دارد. پلن‌ها، ظرفیت‌ها و گزینه‌های دیتابیس را در کنسول ببینید.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.