دیپلوی وردپرس روی کوبرنتیز؛ کی ارزش دارد و چگونه

فروشگاه وردپرسی شما در کمپین‌ها کند می‌شود، هر انتشار قالب یا افزونه ریسک دارد و تیم برای مدیریت بکاپ، دیتابیس و سرور وقت زیادی صرف می‌کند. در این وضعیت، اجرای وردپرس روی Kubernetes وسوسه‌کننده است. ولی اضافه‌کردن Kubernetes به یک سایت کم‌ترافیک معمولاً مسئله را حل نمی‌کند؛ فقط یک لایه عملیاتی دیگر می‌سازد.

«وردپرس کوبرنتیز» زمانی ارزش بررسی دارد که بار سایت متغیر باشد، فرایند انتشار قابل‌تکرار بخواهید یا چند سرویس جانبی را کنار وردپرس اجرا کنید. پیش از مهاجرت باید تکلیف دیتابیس، فایل‌های آپلودی، Session، کش و بکاپ روشن باشد.

پاسخ سریع: آیا وردپرس را روی Kubernetes ببریم؟

اگر سایت یا فروشگاه شما بار قابل پیش‌بینی دارد و هاست فعلی نیازهای عملکردی و عملیاتی‌اش را پوشش می‌دهد، مهاجرت به Kubernetes احتمالاً توجیه ندارد. هاست وردپرس ابری یا یک ماشین مجازی با تنظیمات مناسب، ساده‌تر نگهداری می‌شود.

Kubernetes زمانی ارزش پیدا می‌کند که یکی از این نیازها واقعی باشد:

• افزایش و کاهش ظرفیت وب در واکنش به بار

• استقرار قابل‌تکرار از Repository یا Image

• جداسازی محیط آزمایش و Production

• مشاهده وضعیت اجرا، Health Check و لاگ‌ها

• اجرای Worker، Cron یا سرویس‌های مکمل کنار وردپرس

• استانداردسازی عملیات چند اپلیکیشن در یک تیم

قدم بعدی، ساخت کلاستر نیست. ابتدا وردپرس را به سه بخش مستقل تقسیم کنید: کانتینر وب، دیتابیس و داده‌های ماندگار. تا وقتی این مرزها مشخص نباشند، چند Replica هم سایت را واقعاً مقیاس‌پذیر نمی‌کند.

مدل ذهنی درست برای وردپرس کوبرنتیز چیست؟

وردپرس فقط یک Process وب نیست. برای طراحی استقرار باید اجزای آن را جدا ببینید:

جزء	محل مناسب	نکته عملیاتی
کد وردپرس، قالب و افزونه	Image کانتینر	تغییرات با Build و انتشار نسخه جدید اعمال شوند
فایل‌های wp-content/uploads	فضای ذخیره‌سازی پایدار یا Object Storage سازگار	به فایل‌سیستم موقت Pod وابسته نباشند
MySQL یا MariaDB	دیتابیس مدیریت‌شده یا سرویس Stateful با عملیات مستقل	بکاپ و بازیابی آن از Deployment وردپرس جداست
Secretها	Secret Manager یا سازوکار Secret پلتفرم	رمز دیتابیس وارد Repository یا Image نشود
کش	کش داخلی یا سرویس جداگانه مانند Redis	کش محلی هر Pod بین Replicaها مشترک نیست
ورودی وب	Ingress، Load Balancer یا لایه دامنه پلتفرم	TLS، دامنه و Health Check در این بخش مدیریت می‌شوند

Pod واحد اجرای موقتی است. اگر کلاستر آن را جایگزین کند، فایل‌های لایه داخلی کانتینر ممکن است از بین بروند. پیش از انتقال فایل‌های واقعی، راهنمای «Persistent Volume: چرا دیتای کانتینر شما پاک می‌شود» را بخوانید.

چه زمانی Kubernetes انتخاب نامناسبی است؟

اگر تیم شما کسی را برای نگهداری Manifestها، مانیتورینگ، به‌روزرسانی Image و بازیابی خرابی ندارد، مدیریت مستقیم Kubernetes هزینه عملیاتی ایجاد می‌کند. خود Kubernetes مسئول امنیت قالب، صحت افزونه‌ها، بکاپ دیتابیس یا سازگاری نسخه PHP نیست.

این ابزار جای بهینه‌سازی اپلیکیشن را هم نمی‌گیرد. Query کند، افزونه سنگین یا صفحه‌ای که Cache نمی‌شود، با اضافه‌کردن Pod اصلاح نمی‌شود. گاهی بهینه‌کردن Query، فعال‌کردن Page Cache یا استفاده از CDN از مهاجرت کامل مؤثرتر است.

مقیاس افقی نیز برای هر وردپرسی آماده نیست. چند Pod باید به فایل‌های یکسان دسترسی سازگار داشته باشند و داده ضروری را فقط روی دیسک محلی نگه ندارند. اگر StorageClass فقط الگوی دسترسی تک‌نویسنده را پشتیبانی کند، ممکن است نتوانید همان Volume را به چند Pod متصل کنید.

معماری پایه را چگونه آماده کنیم؟

پیش از نوشتن Manifest، به این پرسش‌ها پاسخ دهید:

1. Image وردپرس چگونه ساخته و نسخه‌گذاری می‌شود؟

2. آیا قالب و افزونه‌ها داخل Image قرار می‌گیرند یا هنگام اجرا تغییر می‌کنند؟

3. فایل‌های آپلودی کجا می‌مانند؟

4. چه کسی مسئول بکاپ، به‌روزرسانی و بازیابی دیتابیس است؟

5. Secretها از چه مسیر امنی وارد Runtime می‌شوند؟

6. Health Check کدام مسیر را بررسی می‌کند؟

7. نسخه خراب چگونه به نسخه قبلی برمی‌گردد؟

برای Production، قالب و افزونه‌های تأییدشده را داخل Image قرار دهید. نصب دستی افزونه روی یک Pod باعث می‌شود Pod جایگزین‌شده یا Replica جدید همان وضعیت را نداشته باشد.

دیتابیس را نیز از Deployment وردپرس جدا کنید. راهنمای «راه‌اندازی MySQL و MariaDB برای اپلیکیشن ابری» معیارهای اتصال، نگهداری و انتخاب سرویس دیتابیس را توضیح می‌دهد.

یک Manifest حداقلی وردپرس چه شکلی دارد؟

نمونه زیر یک «مثال فرضی» برای استقرار تک‌Replica است. Image را با Image تست‌شده پروژه خود جایگزین کنید. Secret با نام wordpress-secrets نیز باید بیرون از Repository و از مسیر امن کلاستر یا پلتفرم ساخته شود.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wordpress-uploads
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
        - name: wordpress
          image: registry.example.com/wordpress:release
          ports:
            - containerPort: 80
          env:
            - name: WORDPRESS_DB_HOST
              valueFrom:
                secretKeyRef:
                  name: wordpress-secrets
                  key: db-host
            - name: WORDPRESS_DB_NAME
              valueFrom:
                secretKeyRef:
                  name: wordpress-secrets
                  key: db-name
            - name: WORDPRESS_DB_USER
              valueFrom:
                secretKeyRef:
                  name: wordpress-secrets
                  key: db-user
            - name: WORDPRESS_DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: wordpress-secrets
                  key: db-password
          readinessProbe:
            httpGet:
              path: /wp-login.php
              port: 80
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
          volumeMounts:
            - name: uploads
              mountPath: /var/www/html/wp-content/uploads
      volumes:
        - name: uploads
          persistentVolumeClaim:
            claimName: wordpress-uploads
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  selector:
    app: wordpress
  ports:
    - port: 80
      targetPort: 80

مقادیر Storage و Resource در این مثال فرضی‌اند و باید پس از مشاهده مصرف واقعی انتخاب شوند. پیش از اجرا نیز مطمئن شوید StorageClass پیش‌فرض وجود دارد و ReadWriteOnce با محل اجرای Pod سازگار است.

پس از ذخیره فایل با نام wordpress.yaml، این دستور منابع را ایجاد می‌کند یا تعریف موجود را با فایل هماهنگ می‌سازد:

kubectl apply -f wordpress.yaml

اجرای دوباره دستور، Manifest را دوباره اعمال می‌کند و داده Volume را حذف نمی‌کند. سپس وضعیت را بررسی کنید:

kubectl get pods,pvc,svc
kubectl rollout status deployment/wordpress

Pod باید Ready، وضعیت PVC برابر Bound و Service ساخته شده باشد. اگر چنین نبود، پیش از اتصال دامنه Eventها و لاگ‌های همان Pod را بررسی کنید.

مقیاس وردپرس فقط با زیادکردن Replica حل نمی‌شود

Horizontal Pod Autoscaler یا HPA تعداد Replicaها را بر اساس Metricهایی مانند مصرف CPU تغییر می‌دهد. برای این کار، هر کانتینر باید Resource Request داشته باشد و سیستم جمع‌آوری Metric فعال باشد.

پیش از فعال‌کردن HPA این موارد را آزمایش کنید:

• هر Replica به نسخه یکسان قالب و افزونه دسترسی دارد.

• فایل آپلودشده از همه Replicaها دیده می‌شود.

• Session یا سبد خرید به حافظه محلی یک Pod وابسته نیست.

• Cron وردپرس با اضافه‌شدن Replicaها چند بار اجرا نمی‌شود.

• دیتابیس توان پاسخ‌گویی به Connectionهای بیشتر را دارد.

• Readiness Probe، Pod ناآماده را از مسیر ترافیک خارج می‌کند.

جزئیات انتخاب Metric و رفتار افزایش ظرفیت را در «Autoscaling و HPA: مقیاس خودکار بر اساس بار» بررسی کنید. مقیاس خودکار و محدودیت‌های آن به پلن و تنظیمات جاری پلتفرم وابسته‌اند؛ وضعیت قابل‌خرید را در منبع زنده ببینید.

وردپرس پرترافیک خود را روی پاستا مقیاس‌پذیر کنید
مسیر Build، استقرار، دیسک، دیتابیس و مشاهده وضعیت سرویس را در یک جریان قابل‌پیگیری مدیریت کنید.
شروع بررسی استقرار

پاستا کدام بخش مسیر را ساده می‌کند؟

پاستا روی زیرساخت مبتنی بر Kubernetes اجرا می‌شود، ولی کاربر برای هر استقرار مستقیماً کلاستر و Manifestها را مدیریت نمی‌کند. می‌توانید پروژه را از Repository گیت، Dockerfile، Docker Compose، Docker Image عمومی، فایل ZIP یا قالب آماده وارد کنید.

در پروژه Docker Compose چندسرویسی، پاستا می‌تواند سرویس‌ها را جدا کند و برای دیتابیس‌های پشتیبانی‌شده، دیتابیس مدیریت‌شده پیشنهاد دهد. پیش از Build، نتیجه تشخیص را بازبینی کنید؛ به‌خصوص مسیر Volume، متغیرهای محیطی و سرویس دیتابیس.

مسیر معمول برای وردپرس چنین است:

1. منبع پروژه یا Image را انتخاب کنید.

2. تشخیص Dockerfile یا Compose را پیش از Build بازبینی کنید.

3. رمز دیتابیس را به‌صورت Secret و تنظیمات غیرحساس را به‌صورت متغیر محیطی ثبت کنید.

4. برای wp-content/uploads دیسک پایدار تعریف کنید.

5. دیتابیس مدیریت‌شده سازگار را از میان گزینه‌های فعال ناحیه انتخاب کنید.

6. Build و استقرار را از جریان وضعیت دنبال کنید.

7. آدرس HTTPS پاستا را آزمایش و سپس دامنه شخصی را متصل کنید.

8. Health Check، لاگ، بکاپ و اعلان‌ها را پیش از انتقال ترافیک بررسی کنید.

این مسیر برای تیمی مناسب است که نتیجه Kubernetes را می‌خواهد، نه مسئولیت اداره کلاستر را. اگر به CRD اختصاصی، کنترل مستقیم Nodeها یا تنظیمات خاص شبکه و Storage نیاز دارید، PaaS ممکن است کنترل کافی ندهد.

خطاهای رایج را چگونه تشخیص دهیم؟

Pod اجرا می‌شود، اما وردپرس به دیتابیس وصل نمی‌شود

• آنچه کاربر می‌بیند: صفحه نصب وردپرس، خطای اتصال در رابط وب یا Restartشدن کانتینر پس از شروع.

• علت‌های محتمل و تأییدشده: مقدار نادرست Host، نام دیتابیس، نام کاربری یا رمز؛ در دسترس نبودن شبکه؛ آماده‌نبودن دیتابیس.

• روش تشخیص: وضعیت دیتابیس و Secretهای متصل را بدون نمایش مقدار Secret بررسی کنید؛ سپس لاگ وردپرس و امکان برقراری Connection از محیط سرویس را بسنجید.

• اقدام بعدی: تنظیم اشتباه را از مسیر Secret یا متغیر محیطی اصلاح کنید. رمز را داخل Manifest یا Repository ننویسید.

• آیا داده کاربر در خطر است؟ معمولاً خیر، مگر اینکه وردپرس به دیتابیس اشتباه متصل شده یا عملیات مهاجرت ناقص مانده باشد.

پس از Redeploy، فایل‌های آپلودی دیده نمی‌شوند

• آنچه کاربر می‌بیند: رکورد رسانه در دیتابیس وجود دارد، ولی تصویر یا فایل باز نمی‌شود.

• علت‌های محتمل و تأییدشده: مسیر uploads روی فایل‌سیستم موقت کانتینر بوده، Volume در مسیر دیگری Mount شده یا نسخه جدید مسیر متفاوتی دارد.

• روش تشخیص: Mount Path و PVC متصل را با مسیر آپلود وردپرس مقایسه و وجود فایل را روی فضای پایدار بررسی کنید.

• اقدام بعدی: پیش از تغییر مسیر، از داده موجود بکاپ بگیرید؛ سپس Volume را روی مسیر صحیح Mount و فایل‌ها را از منبع معتبر بازیابی کنید.

• آیا داده کاربر در خطر است؟ بله. اگر فایل فقط داخل کانتینر حذف‌شده بوده باشد، ممکن است قابل بازیابی نباشد.

Replica جدید Ready نمی‌شود یا رفتار کاربران ناپایدار است

• آنچه کاربر می‌بیند: بخشی از درخواست‌ها موفق‌اند و بخشی خطا دارند، فایل تازه فقط از بعضی درخواست‌ها دیده می‌شود یا Login پایدار نیست.

• علت‌های محتمل و تأییدشده: اشتراک‌نداشتن فایل‌ها، Session محلی، تفاوت نسخه Image یا ناسازگاری Access Mode دیسک با چند Replica.

• روش تشخیص: نسخه Image، Mountها و متغیرهای هر Pod را مقایسه کنید؛ درخواست آزمایشی را بین Replicaها تکرار و وضعیت Readiness را بررسی کنید.

• اقدام بعدی: تا رفع وابستگی‌های محلی، تعداد Replica را افزایش ندهید. ذخیره‌سازی مشترک یا Object Storage و Session خارجی را مطابق معماری پروژه تنظیم کنید.

• آیا داده کاربر در خطر است؟ احتمال ناسازگاری فایل یا Session وجود دارد. پیش از تغییر Storage از فایل‌ها و دیتابیس بکاپ بگیرید.

چک‌لیست پیش از انتقال ترافیک واقعی

• Image وردپرس با Tag یا Digest مشخص و قابل بازگشت منتشر شده است.

• قالب و افزونه‌ها روی Pod زنده به‌صورت دستی تغییر نمی‌کنند.

• wp-content/uploads روی فضای پایدار تأییدشده قرار دارد.

• Secretهای دیتابیس داخل Git، Dockerfile و تاریخچه Command نیستند.

• بازیابی بکاپ دیتابیس و فایل‌ها در محیط غیرProduction آزمایش شده است.

• Resource Request بر اساس مصرف مشاهده‌شده تنظیم شده است.

• Readiness Probe هنگام قطع دیتابیس یا آماده‌نبودن وردپرس آزمایش شده است.

• رفتار Login، سبد خرید، Cache و Cron با چند Replica بررسی شده است.

• محدودیت Access Mode دیسک پیش از فعال‌کردن HPA مشخص شده است.

• دامنه و HTTPS پیش از تغییر نهایی DNS آزمایش شده‌اند.

• مسئول اقدام هنگام شکست Build یا استقرار مشخص است.

• قیمت، ظرفیت، ناحیه و قابلیت‌های پلن از صفحه زنده بررسی شده‌اند.

  نتیجه تصمیم

  وردپرس روی Kubernetes زمانی انتخاب قابل‌دفاعی است که به انتشار تکرارپذیر، مدیریت بار متغیر یا هماهنگی چند سرویس نیاز داشته باشید. برای میزبانی یک سایت عادی، پیچیدگی آن احتمالاً بازدهی ندارد.

  پیش از مهاجرت، وردپرس را Stateless کنید، فایل و دیتابیس را از Pod جدا نگه دارید و بازیابی بکاپ را آزمایش کنید. اگر نمی‌خواهید کلاستر و Manifestها را اداره کنید، مسیر پاستا را با پروژه آزمایشی و داده غیرحساس بسنجید؛ سپس هزینه و محدودیت پلن فعال را از منبع زنده بررسی کنید.