values.yaml سفارشیبرای نصب Camunda Platform 8 (یا Camunda 7) روی Kubernetes با استفاده از Helm، می‌تونیم از قالب YAML استفاده کنیم، ولی قبلش پیشنهاد می‌کنم مراحل رو به ترتیب زیر انجام بدی. در اینجا از Camunda 8 و Helm Chart رسمی استفاده می‌کنیم.
نصب شده بودن Kubernetes (مثلاً با K3s, Minikube, Kind یا روی کلاود)
نصب Helm
دسترسی به اینترنت (برای کشیدن ایمیج‌ها)
فضای کافی (Camunda نیاز به Elasticsearch و دیگر سرویس‌ها داره)
helm repo add camunda https://helm.camunda.io
helm repo update
values.yaml سفارشیمحتوای ساده برای camunda-values.yaml (برای تست):
global:
identity:
auth:
enabled: false # غیرفعال کردن احراز هویت برای تست
connectors:
enabled: false
zeebe:
enabled: true
replicas: 1
elasticsearch:
enabled: true
replicas: 1
operate:
enabled: true
tasklist:
enabled: true
identity:
enabled: false # چون auth خاموشه
optimize:
enabled: false
ingress:
enabled: true
className: "nginx"
operate:
enabled: true
path: /
host: camunda.local
⚠️ توجه: برای استفاده از ingress باید ingress controller مثل NGINX رو نصب داشته باشی.
helm install camunda camunda/camunda-platform -f camunda-values.yaml
اگه از Minikube استفاده می‌کنی:
minikube tunnel
یا اگه ingress نداری، می‌تونی با port-forward هم وصل شی:
kubectl port-forward svc/camunda-operate 8080:80
سپس برو به:
http://localhost:8080
Camunda 8 شامل سرویس‌هایی مثل Zeebe, Operate, Tasklist, Identity و ... است.
برای محیط production حتماً باید auth فعال باشه.
به طور پیش‌فرض از PostgreSQL استفاده می‌کنه، ولی می‌تونی تنظیمات دیتابیس رو هم در values.yaml تغییر بدی.
خیلی خوب! اگر بخوای Camunda Platform (نسخه 8 یا 7) رو روی Kubernetes بدون Helm نصب کنی، باید به صورت مستقیم فایل‌های YAML مورد نیاز برای دیپلوی کردن سرویس‌ها، دیپلویمنت‌ها، سرویس‌اکانت‌ها، کانفیگ‌مپ‌ها، و دیگر اجزا رو بنویسی یا از فایل‌های رسمی استفاده کنی.
در ادامه، من مراحل نصب Camunda Platform 8 بدون Helm رو برات کامل می‌نویسم، بر پایه YAML استاندارد.
Camunda تیم رسمی‌اش یک ریپازیتوری برای نصب بدون Helm آماده کرده به نام:
برای نصب بدون Helm، از مسیر زیر فایل‌های YAML را می‌گیریم:
git clone https://github.com/camunda/camunda-platform.git
cd camunda-platform
cd platform/base
در این مسیر، فایل‌هایی مانند زیر را خواهید دید:
zeebe/
operate/
tasklist/
identity/
elasticsearch/
ingress/
kubectl apply -k elasticsearch/kustomize
یا به صورت مستقیم:
kubectl apply -f elasticsearch/base/
kubectl apply -f zeebe/base/
kubectl apply -f operate/base/
kubectl apply -f tasklist/base/
kubectl apply -f identity/base/
در صورت نیاز می‌تونی فقط بخشی از این سرویس‌ها رو نصب کنی.
اگر NGINX Ingress Controller داری:
kubectl apply -f ingress/base/
یا می‌تونی دستی NodePort استفاده کنی:
apiVersion: v1
kind: Service
metadata:
name: camunda-operate
spec:
type: NodePort
selector:
app: operate
ports:
- port: 80
targetPort: 8080
nodePort: 30080
Operate: http://<NodeIP>:30080
Tasklist: مشابه بالا با پورت دیگر
Identity: اگر نصب شده باشد، باید auth را نیز پیکربندی کنی
| ماژول | نیاز به چیست | آدرس فایل YAML |
|---|---|---|
| Elasticsearch | الزامی برای Zeebe | elasticsearch/base/ |
| Zeebe | هسته پردازش | zeebe/base/ |
| Operate | رابط مانیتورینگ | operate/base/ |
| Tasklist | رابط کاربر | tasklist/base/ |
| Identity | سیستم احراز هویت | identity/base/ |
| Ingress | برای دسترسی آسان | ingress/base/ |
چهار موردی که نام بردی (BPMN، DMN، Form، CMMN) همگی از مفاهیم و استانداردهای مرتبط با مدلسازی فرآیندهای کسب‌وکار هستند که به‌ویژه در چارچوب‌هایی مانند Camunda یا دیگر موتورهای گردش کار (Workflow Engines) استفاده می‌شن. حالا بریم دونه‌دونه توضیح بدیم:
چی هست؟
یک استاندارد گرافیکی برای مدلسازی فرآیندهای کسب‌وکار.
چه کاری می‌کنه؟
با استفاده از اشکال خاص (دایره‌ها، مستطیل‌ها، لوزی‌ها و ...) جریان فرآیندها، وظایف، تصمیم‌ها، رویدادها، و مسیرهای موازی یا شرطی در یک فرآیند کاری نشون داده می‌شن.
مثال کاربردی:
مدل کردن روند درخواست مرخصی در یک سازمان، از پر کردن فرم تا تایید مدیر.
چی هست؟
یک استاندارد برای مدلسازی تصمیم‌گیری‌های تکرارشونده یا پیچیده در کسب‌وکار.
چه کاری می‌کنه؟
جدول‌های تصمیم (Decision Tables) طراحی می‌کنی تا تصمیم‌ها از منطق تجاری جدا بشن و بتونی اونها رو مستقل از کد، نگهداری و تغییر بدی.
مثال کاربردی:
تصمیم‌گیری برای اعطای وام بر اساس امتیاز اعتباری، درآمد، و سن.
چی هست؟
رابط گرافیکی‌ای که کاربر می‌تونه داده‌هاش رو وارد کنه تا فرآیند شروع یا ادامه پیدا کنه.
چه کاری می‌کنه؟
فرم‌ها معمولا به گره‌های کار انسانی در BPMN متصل می‌شن و اطلاعات ورودی از کاربر گرفته می‌شن (مثلاً درخواست خرید، تایید مدیر، ثبت گزارش و...).
مثال کاربردی:
فرم ثبت درخواست مرخصی که کارمند پر می‌کنه.
چی هست؟
یک استاندارد برای مدلسازی فرآیندهای غیرخطی و منعطف که از قبل قابل پیش‌بینی نیستن.
چه کاری می‌کنه؟
برای مواقعی که جریان کار بسته یا ترتیبی مشخص نداره. در CMMN می‌تونی بر اساس وقایع تصمیم بگیری چه کارهایی فعال یا غیر فعال بشن.
مثال کاربردی:
رسیدگی به شکایت مشتری؛ ممکنه نیاز به بررسی‌های مختلف و تصمیم‌گیری‌های متغیر در طول زمان داشته باشه.
| مفهوم | نوع کاربرد | ویژگی کلیدی |
|---|---|---|
| BPMN | فرآیندهای ترتیبی و خطی | جریان مشخص و گام‌به‌گام |
| DMN | منطق تصمیم‌گیری | جداول تصمیم‌گیری شفاف |
| Form | تعامل با کاربر | ورود/نمایش داده‌ها |
| CMMN | فرآیندهای غیرخطی و انعطاف‌پذیر | عکس‌العمل به رخدادها و انتخاب مسیر در حین اجرا |
اگه دوست داری با نمودار یا مثال واقعی هم نشون بدم، خوشحال می‌شم برات طراحی کنم.
مقایسه‌ی چهار سیستم مطرح در حوزه‌ی مدیریت فرآیندهای کسب‌وکار (BPMS) یعنی:
🔸 Oracle BPM Suite
🔸 Flowable
🔸 Camunda
🔸 Bizagi
به‌صورت جدولی، همراه با نکات کلیدی:
| ویژگی | Oracle BPM Suite | Flowable | Camunda | Bizagi |
|---|---|---|---|---|
| نوع | تجاری / Enterprise | متن‌باز + تجاری | متن‌باز + تجاری | تجاری (نسخه رایگان محدود) |
| BPMN پشتیبانی | کامل | کامل | کامل | کامل |
| DMN پشتیبانی | بله | بله | بله | بله (محدود) |
| CMMN پشتیبانی | بله | بله | بله | خیر |
| Form Builder | پیچیده و قدرتمند | ساده ولی قابل استفاده | متوسط (پلاگین‌پذیر) | بسیار قدرتمند و کاربرپسند |
| مدیریت کاربر و نقش‌ها | یکپارچه با Oracle Identity | یکپارچه‌پذیر با LDAP | بله | بله |
| انعطاف در توسعه | محدود به فناوری‌های Oracle | بالا (Java, Spring) | بالا (Java, REST, Plugins) | پایین (متمرکز بر کاربر نهایی) |
| مناسب برای | سازمان‌های بزرگ دولتی / مالی | توسعه‌دهندگان فنی | پروژه‌های نیمه‌سفارشی / برنامه‌نویسی‌محور | کسب‌وکارهایی که ابزار گرافیکی می‌خواهند |
| گزارش‌گیری و آنالیز | قدرتمند | نیاز به توسعه یا ابزار جانبی | متوسط تا خوب | بسیار خوب |
| Open Source؟ | ❌ | ✅ | ✅ | ❌ (نسخه رایگان دارد) |
| پشتیبانی ابری | Oracle Cloud | قابل استقرار بر هر ابر | بله (SaaS / Self-hosted) | بله (Bizagi Cloud) |
راهکار Enterprise-level با یکپارچگی عمیق با سایر ابزارهای Oracle.
مناسب برای سازمان‌های بزرگ با زیرساخت Oracle.
منحنی یادگیری بالا و هزینه‌بر.
از دل Activiti منشعب شده؛ سبک، مدرن، با قابلیت کاستوم‌سازی زیاد.
پشتیبانی همزمان از BPMN + DMN + CMMN.
بسیار مناسب برای توسعه‌دهندگان جاوا و پروژه‌های انعطاف‌پذیر.
محبوب‌ترین BPMS متن‌باز در دنیا.
جامعه فعال و اکوسیستم گسترده (Camunda Platform 7/8).
فرم‌ساز و ابزارهای گرافیکی ضعیف‌تر از Bizagi، ولی توسعه‌پذیر و APIمحور.
فوق‌العاده در طراحی گرافیکی و تجربه کاربر.
بدون نیاز جدی به برنامه‌نویسی برای طراحی فرآیندها.
برای کاربر نهایی مناسب‌تر از تیم فنی.
نسخه رایگان آن محدود است.
| نیاز شما | پیشنهاد مناسب |
|---|---|
| پروژه‌های بزرگ، یکپارچه با Oracle | Oracle BPM Suite |
| پروژه‌های فنی با توسعه سفارشی | Flowable یا Camunda |
| پروژه‌های نیازمند سرعت طراحی، بدون کدنویسی زیاد | Bizagi |
| ترکیب توسعه و مقیاس‌پذیری و انعطاف | Camunda |
اگه بگی چه نوع سازمان یا پروژه‌ای مدنظرت هست، می‌تونم دقیق‌تر راهنمایی‌ات کنم که کدوم مناسب‌تره.
پاسخ کوتاه:
✅ Flowable سبک‌تر از Camunda است.
| ویژگی | Flowable | Camunda |
|---|---|---|
| حجم اولیه نصب | بسیار سبک | کمی سنگین‌تر |
| نیازمندی‌های سیستمی | حداقل منابع برای اجرا | منابع بیشتر (به‌ویژه Camunda 8 که مبتنی بر Zeebe است) |
| مدل اجرا | جاوا-بیس، ماژولار | جاوا-بیس، ولی با ابزارها و کامپوننت‌های بیشتر |
| سرعت راه‌اندازی | بالا | متوسط |
| پیاده‌سازی در اپلیکیشن‌های کوچک یا میکروسرویس | عالی | مناسب، ولی با توجه به نوع نسخه انتخابی |
| زیرساخت | سبک و ساده برای جاسازی (embedded) | قابل جاسازی، اما در نسخه‌های جدید پیچیده‌تر (Camunda 8) |
اگر منظور از "سبک‌تر" اجرای ساده در محیطی با منابع کم (مثل سرور توسعه، تست، یا edge) است، Flowable به دلیل ماژولار بودن و طراحی مینیمال‌تر گزینه بهتریه.
اگر از نسخه Camunda 7 استفاده کنی، اونم هنوز قابل جاسازی و نسبتاً سبک هست. ولی Camunda 8 که معماری microservices + Zeebe + Kafka داره، خیلی سنگین‌تر از Flowable هست.
| سناریو | انتخاب مناسب‌تر |
|---|---|
| اجرای سریع، مصرف منابع پایین، جاسازی در اپ | Flowable |
| ویژگی‌های مدیریتی و گرافیکی بیشتر، نیاز به اکوسیستم قدرتمند | Camunda (ترجیحاً نسخه 7) |
اگه خواستی راه‌اندازی ساده‌ی یکی‌شون رو برات با داکر یا spring boot آماده کنم، فقط بگو 👌
حتماً! بذار هر کدوم از این سه‌تا مفهوم رو جدا و ساده توضیح بدم و بعدش بگم چطور به هم ربط پیدا می‌کنن، به‌ویژه توی context سیستم‌هایی مثل Camunda 8.
چی هست؟
معماری نرم‌افزاری که در اون یک سیستم بزرگ به مجموعه‌ای از سرویس‌های کوچیک و مستقل تقسیم می‌شه.
ویژگی‌ها:
هر سرویس یک مسئولیت مشخص داره (مثل auth، پرداخت، گزارش‌گیری)
سرویس‌ها به‌صورت مستقل deploy و scale می‌شن
معمولاً از REST API یا messaging برای ارتباط استفاده می‌کنن
مزیت:
مقیاس‌پذیری بالا، توسعه مستقل، خطایابی راحت‌تر
چی هست؟
موتور workflow جدیدی که توسط تیم Camunda ساخته شده برای پردازش بسیار مقیاس‌پذیر و event-driven فرآیندهای کاری.
چه فرقی با Camunda 7 داره؟
Camunda 7 از موتور سنتی (thread-based) استفاده می‌کنه، ولی Zeebe کاملاً event-based و توزیع‌شده هست.
مزیت‌ها:
مناسب برای معماری میکروسرویس
مقیاس‌پذیر با queueها و رویدادها
Native پشتیبانی از BPMN
نقشش:
Zeebe به عنوان هسته‌ی پردازشگر فرآیندها در Camunda 8 عمل می‌کنه.
چی هست؟
یک سیستم صف‌بندی پیام (message broker) و publish/subscribe با کارایی بالا که توسط Apache توسعه داده شده.
چه کاری می‌کنه؟
سرویس‌ها می‌تونن پیام بفرستن یا گوش بدن. برای مثال:
سرویس A یک پیام (event) منتشر می‌کنه، سرویس B اون رو دریافت و پردازش می‌کنه.
چرا توی میکروسرویس‌ها مهمه؟
چون اجازه می‌ده سرویس‌ها بدون اتصال مستقیم، از طریق event با هم حرف بزنن → loose coupling
در معماری Camunda 8:
میکروسرویس‌ها فرآیندها و وظایف مشخصی رو انجام می‌دن (مثلاً پرداخت یا ارسال ایمیل).
Zeebe به عنوان workflow engine، فرآیند کلی کسب‌وکار رو مدیریت می‌کنه (مثلاً: سفارش ثبت شد → پرداخت → ارسال کالا).
ارتباط بین Zeebe و میکروسرویس‌ها از طریق Kafka (یا gRPC، یا REST) انجام می‌شه. Kafka کمک می‌کنه تا رویدادها به شکل real-time و بدون وابستگی شدید بین سرویس‌ها رد و بدل بشن.
فرآیند سفارش آنلاین:
کاربر سفارش می‌ذاره → میره توی Zeebe به عنوان یک فرآیند جدید.
Zeebe می‌گه: مرحله اول "بررسی موجودی" → سرویس Inventory اجرا می‌شه.
وقتی بررسی تموم شد، از طریق Kafka پیام ارسال می‌شه → مرحله بعدی: پرداخت.
سرویس Payment اجرا می‌شه و بعدش نوبت ارسال کالا می‌رسه.
تمام مراحل توسط Zeebe مدیریت و Kafka برای تبادل پیام بین سرویس‌ها استفاده می‌شه.
اگه خواستی یه دیاگرام ساده از این معماری برات بکشم یا نمونه داکر‌فایل‌هاش رو آماده کنم، فقط بگو 👌
اجرای نمونه‌ی Camunda Platform 8 روی Kubernetes چند روش داره، ولی یکی از بهترین و سریع‌ترین راه‌ها استفاده از Helm chart رسمی هست.
در ادامه یک راهنمای گام‌به‌گام ساده و کاربردی برات آوردم که با ابزارهایی مثل kubectl, helm, و یک کلاستر K8s (مثل Minikube، Kind، یا EKS / GKE) بتونی Camunda 8 رو بالا بیاری.
✅ نصب شده:
kubectl
helm (نسخه 3 به بالا)
یک کلاستر Kubernetes فعال (مثل Minikube یا Kind یا Cloud-based)
دسترسی به اینترنت برای نصب ایمیج‌ها
helm repo add camunda https://helm.camunda.io
helm repo update
helm install camunda camunda/camunda-platform \
--namespace camunda \
--create-namespace
این دستور همه اجزای Camunda 8 رو در فضای نام
camundaنصب می‌کنه.
kubectl get all -n camunda
شامل:
Zeebe Broker
Zeebe Gateway
Operate (مدیریت فرآیندها)
Tasklist (نمایش وظایف)
Identity (مدیریت کاربران)
Optimize (تحلیل فرآیندها)
اگر از Minikube استفاده می‌کنی، از این دستور استفاده کن:
minikube service operate -n camunda
یا برای همه سرویس‌ها:
kubectl port-forward svc/operate 8080:80 -n camunda
kubectl port-forward svc/identity 8081:80 -n camunda
kubectl port-forward svc/tasklist 8082:80 -n camunda
برای ورود به Camunda Identity:
Username: demo
Password: demo
می‌تونی با استفاده از فایل‌های values.yaml تنظیمات رو شخصی‌سازی کنی (مثلاً غیرفعال کردن Optimize یا استفاده از external DB).
نسخه community با Helm بسیار مناسب برای تست و توسعه‌ست. در پروژه‌های Production پیشنهاد می‌شه از تنظیمات مقاوم‌سازی استفاده بشه.
برای توسعه در حالت local بدون Kubernetes هم می‌تونی از Docker Compose استفاده کنی (اگر خواستی فایلش رو می‌فرستم).
اگه بخوای من می‌تونم:
🔧 فایل config سفارشی (values.yaml) برات بسازم،
یا نسخه‌ای سبک‌شده فقط با Zeebe و Operate برات آماده کنم.