نصب جیرا با داکر برای محیط تست: چیزهایی که مستندات نمی‌گویند

بیشترین ضرری که یک ادمین Jira می‌تواند به سازمانش بزند، تست کردن روی محیط عملیاتی است. «فقط یک Workflow کوچک عوض می‌کنم» تا وقتی خوب است که آن Workflow به شش پروژهٔ دیگر هم وصل باشد.

راه‌حل، یک محیط تست است — و Docker ارزان‌ترین راه ساختنش است. این نوشته دربارهٔ کپی‌کردن دستورات از مستندات نیست؛ دربارهٔ تصمیم‌هایی است که مستندات نمی‌گیرند و شما باید بگیرید.

سه کانتینر، نه یکی

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

کانتینر سوم را خیلی‌ها حذف می‌کنند و بعد تعجب می‌کنند که چرا مشکلات SSL و هدر پروکسی فقط روی عملیاتی ظاهر می‌شود. اگر محیط تست شما پروکسی ندارد، دقیقاً همان دسته مشکلاتی را نمی‌بینید که بیشترین دردسر را می‌سازند — همان‌هایی که در لودبالانسر Jira DC توضیح داده‌ام.

تفاوت حیاتی: نصب در برابر خانه

این تک‌مفهوم، بیشترین سردرگمی را می‌سازد. Jira دو مسیر کاملاً متفاوت دارد:

JIRA_INSTALL = /opt/atlassian/jira
# باینری‌ها، Tomcat، لاگ‌ها
# با هر ارتقا عوض می‌شود — می‌شود دور انداخت

JIRA_HOME = /var/atlassian/application-data/jira
# دیتای شما: پیوست‌ها، ایندکس، افزونه‌ها، تنظیمات
# هرگز نباید از بین برود

قاعدهٔ ساده: JIRA_HOME و دیتای پایگاه داده روی volume نام‌دار. بقیه‌اش دورریختنی است.

نکتهٔ Tomcat 10 که باید بدانید

نسخه‌های جدید Jira روی Tomcat ۱۰.۱ اجرا می‌شوند. یک تغییر رفتاری در این نسخه هست که اگر ندانید، عیب‌یابی را کاملاً منحرف می‌کند: متغیر %D در access log از Tomcat 10 به بعد میکروثانیه است، نه میلی‌ثانیه.

یعنی عدد 250000 که ترسناک به نظر می‌رسد، در واقع ۰.۲۵ ثانیه است. این و بقیهٔ تله‌های لاگ را در Jira کند شده کامل باز کرده‌ام.

برای فعال کردن access log در محیط تست، این را در server.xml داشته باشید — بدون آن، هیچ دید عملکردی ندارید:

<Valve className="org.apache.catalina.valves.AccessLogValve"
       directory="logs"
       prefix="access_log."
       suffix=""
       maxDays="-1"
       pattern="%h %l %u %t &quot;%r&quot; %s %b %D" />

پنج اشتباه رایج

۱. حافظه‌ای که کم است

Jira با تنظیمات پیش‌فرض Docker خفه می‌شود. حداقل واقعی برای یک محیط تست قابل استفاده، حدود دو گیگابایت برای خود Jira است — و اگر افزونه دارید بیشتر. علامتش این است که کانتینر بدون خطای واضح ری‌استارت می‌شود.

۲. نسخهٔ پایگاه دادهٔ ناسازگار

همیشه نسخهٔ PostgreSQL را در تصویر پین کنید، نه latest. اطلسین فهرست نسخه‌های پشتیبانی‌شده دارد و latest می‌تواند یک روز از آن فهرست بیرون بزند — بدون اینکه شما کاری کرده باشید.

۳. کپی‌کردن دیتای عملیاتی بدون پاک‌سازی

این مهم‌ترین نکتهٔ امنیتی این نوشته است. اگر بکاپ عملیاتی را در محیط تست ری‌استور می‌کنید، آن محیط حالا دیتای واقعی دارد: نام کاربران، محتوای Issueها، پیوست‌ها. حداقل کاری که باید بکنید:

• تنظیمات SMTP را خاموش کنید — وگرنه محیط تست به کاربران واقعی ایمیل می‌فرستد
• وب‌هوک‌ها و اتصال‌های خروجی را غیرفعال کنید
• محیط تست را پشت شبکهٔ داخلی نگه دارید، نه روی اینترنت

۴. لاگ‌هایی که نمی‌بینید

لاگ‌های Jira داخل کانتینرند. اگر برایشان راه دسترسی نگذارید، هر بار باید وارد کانتینر شوید. مسیرهای مفید:

# لاگ اصلی
$JIRA_HOME/log/atlassian-jira.log

# access log تامکت
$JIRA_INSTALL/logs/access_log.YYYY-MM-DD

۵. نداشتن مسیر برگشت

ارزش محیط تست به این است که بتوانید خرابش کنید. قبل از هر تست بزرگ، از volumeها یک snapshot بگیرید تا در سی ثانیه به حالت قبل برگردید. اگر برگرداندن محیط تست سخت باشد، کم‌کم دیگر روی آن تست نمی‌کنید — و همان‌جاست که دوباره سراغ محیط عملیاتی می‌روید.

این محیط به چه دردی می‌خورد

• تست ارتقا قبل از انجامش روی عملیاتی
• تست افزونه‌ها — مخصوصاً اثرشان روی سرعت
• تمرین بازیابی از بکاپ (بکاپی که تست نشده، بکاپ نیست)
• تست اسکریپت‌های ScriptRunner که به نسخه حساس‌اند
• بازسازی مشکلی که کاربر گزارش کرده، بدون ریسک

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

جمع‌بندی

یک محیط تست Docker در یک بعدازظهر بالا می‌آید و از آن به بعد، هر تغییر پرریسکی یک بار قبل از عملیاتی امتحان می‌شود. دو چیزی که نباید فراموش شوند: volume برای JIRA_HOME و پایگاه داده، و خاموش‌کردن SMTP اگر دیتای واقعی ری‌استور می‌کنید.

اگر می‌خواهید این محیط برای تیمتان ساخته و مستند شود، پیاده‌سازی و راه‌اندازی Jira شامل همین است.