Jenkins؛ سرور CI/CD اختصاصی شما در تهران

کارهایی که تیم‌ها معمولاً در هفتهٔ اول به Jenkins می‌سپارند:

پس از روشن‌شدن سرور، اسکریپت نصب ما Java 21 نسخهٔ headless را از مخزن Ubuntu نصب می‌کند (اگر در دسترس نباشد Java 17)، مخزن رسمی نسخهٔ پایدار Jenkins یعنی شاخهٔ LTS را با کلید امضای خودش اضافه می‌کند و بستهٔ jenkins را نصب و به‌صورت سرویس systemd فعال می‌کند. سپس منتظر می‌ماند تا Jenkins بالا بیاید و رمز اولیهٔ مدیر ساخته شود.

در پایان، قانون ورودی پورت ۸۰۸۰ در فایروال سرور اضافه و فایروال فعال می‌شود؛ یعنی از بیرون فقط همین پورت برای Jenkins باز است و هر پورت دیگری را که لازم دارید خودتان از تب فایروال سرور اضافه می‌کنید. اطلاعات ورود در تب «اپلیکیشن» صفحهٔ سرور نمایش داده می‌شود.

برای نصب Jenkins مبلغی جدا دریافت نمی‌کنیم و خود Jenkins هم رایگان است. هنگام ساخت سرور هزینهٔ ساعت اول پلن از کیف پول کم می‌شود و پس از آن هر ساعت؛ هر وقت سرور را حذف کنید، محاسبه متوقف می‌شود. چون Jenkins با Java اجرا می‌شود و حافظهٔ قابل‌توجهی می‌گیرد، این اپلیکیشن فقط روی پلن standard و بالاتر قابل انتخاب است.

اندازهٔ مناسب بیشتر به build‌ها بستگی دارد تا خود Jenkins. اگر Jenkins فقط هماهنگ‌کننده است و build‌ها روی agent جدا اجرا می‌شوند، standard کافی است. اگر کامپایل و تست روی همین سرور انجام می‌شود، plus یا pro زمان build را کوتاه‌تر و خطای کمبود حافظه را نادر می‌کند. برای جمع‌زدن هزینهٔ چند سرور از ماشین‌حساب هزینه استفاده کنید.

هر ابزار CI برای نوع خاصی از تیم ساخته شده است. این جدول تفاوت‌های عملی را نشان می‌دهد:

کل مسیر از پنل و مرورگر انجام می‌شود:

Jenkins به کد، secret‌ها و سرورهای تولید شما دسترسی دارد؛ پس هدف جذابی برای نفوذ است. اولین قدم این است که بعد از ویزارد راه‌اندازی هیچ حساب مشترکی نماند: برای هر نفر کاربر جدا بسازید و در Manage Jenkins → Security استراتژی مجوز را طوری تنظیم کنید که کاربران ناشناس هیچ دسترسی نداشته باشند. رمزها و کلیدهای SSH را فقط در بخش Credentials نگه دارید و هرگز داخل Jenkinsfile ننویسید.

پنل پیش‌فرض روی http باز است. برای کار واقعی، روی سرور یک nginx بگذارید که پورت ۸۰ را به 127.0.0.1:8080 برساند، پورت ۸۰ را در فایروال شبکه یا تب فایروال سرور باز کنید و زیردامنه‌ای مثل ci.example.com را در مدیریت DNS پشت پروکسی لبه قرار دهید تا اتصال با گواهی SSL رمزگذاری شود. بعد از آن می‌توانید قانون پورت ۸۰۸۰ را به IP دفتر محدود کنید.

افزونه‌ها بزرگ‌ترین منبع آسیب‌پذیری Jenkins هستند. فقط افزونه‌هایی را نصب کنید که لازم دارید، هشدارهای امنیتی صفحهٔ مدیریت را جدی بگیرید و Jenkins را با apt به‌روز نگه دارید.

همهٔ وضعیت Jenkins در یک پوشه است: /var/lib/jenkins. فایل‌های config.xml، تعریف jobها، افزونه‌ها، credential‌های رمزگذاری‌شده و تاریخچهٔ build‌ها همین‌جا هستند. ساده‌ترین بکاپ، بکاپ کامل سرور از تب بکاپ پنل است که دستی و هر وقت بخواهید ساخته می‌شود و فضای آن ساعتی ۲ تومان به ازای هر گیگابایت حساب می‌شود؛ جزئیات در صفحهٔ پشتیبان‌گیری. پیش از هر به‌روزرسانی بزرگ یک نسخه بگیرید.

برای انتقال از Jenkins دیگری، سرویس را در مبدأ متوقف کنید، پوشهٔ JENKINS_HOME را بدون workspace فشرده کنید و روی سرور جدید در /var/lib/jenkins باز کنید، مالکیت فایل‌ها را به کاربر jenkins برگردانید و سرویس را راه بیندازید. نسخهٔ Jenkins مقصد نباید از مبدأ قدیمی‌تر باشد. خروجی‌های بزرگ build را هم می‌توانید در فضای ذخیره‌سازی ابری نگه دارید تا دیسک سرور پر نشود.

از سمت ما: نصب یک‌کلیک فقط هستهٔ Jenkins و Java را نصب می‌کند؛ افزونه، Docker‏، agent و تنظیم HTTPS با شماست. سرور تک‌نودی است و دسترس‌پذیری بالا یا failover خودکار برای Jenkins ارائه نمی‌شود. بکاپ خودکار زمان‌بندی‌شده هم برای سرورهای ابری فعال نیست و نسخهٔ پشتیبان را خودتان می‌سازید.

از سمت Jenkins: پیکربندی‌هایی که فقط از رابط وب ساخته می‌شوند به‌مرور قابل ردیابی نیستند؛ تا جایی که می‌شود pipeline‌ها را در Jenkinsfile و داخل مخزن نگه دارید. پلن‌های سرور ابری GPU ندارند، پس build‌های وابسته به GPU را باید جای دیگری اجرا کنید.