جایگزین CentOS کدام است؟ مقایسه AlmaLinux، Rocky Linux و مسیر مهاجرت 2026

چرا پرونده CentOS برای مدیران سرور بسته شد؟

CentOS Linux سال‌ها نقش «نسخهٔ رایگان RHEL» را بازی می‌کرد: بسته‌ها از کد منبع رد هت بازسازی می‌شد، رفتار سیستم تقریباً یکسان بود و هیچ هزینهٔ اشتراکی پرداخت نمی‌شد. همین ویژگی آن را به انتخاب اول میزبان‌ها، پنل‌های کنترل و تیم‌های زیرساخت تبدیل کرد.

در سال ۲۰۲۰ مسیر پروژه عوض شد. تیم CentOS اعلام کرد تمرکز اصلی روی CentOS Stream خواهد بود؛ نسخه‌ای که بسته‌های آن پیش از RHEL منتشر می‌شوند. با این تغییر، نقش «بازسازی پایدار» حذف شد و پیامد آن برای سرورها روشن بود: CentOS 8 در پایان ۲۰۲۱ و CentOS 7 در ۳۰ ژوئن ۲۰۲۴ به پایان پشتیبانی رسیدند. بعد از این تاریخ، هیچ وصلهٔ امنیتی رسمی برای آن‌ها منتشر نمی‌شود و هر آسیب‌پذیری تازه، بدون اصلاح باقی می‌ماند.

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

سه خانوادهٔ جانشین که باید از هم تفکیک شوند

هر توزیعی که جای CentOS بنشیند در یک دسته قرار نمی‌گیرد. سه مسیر اصلی وجود دارد و انتخاب اشتباه میان آن‌ها معمولاً گران‌تر از انتخاب اشتباه میان اعضای یک خانواده تمام می‌شود.

۱) بازسازی‌های سازگار با RHEL

این گروه همان مدل قدیمی CentOS را ادامه می‌دهند: AlmaLinux و Rocky Linux. هر دو بسته‌های خود را از کد منبع RHEL می‌سازند، چرخهٔ عمر طولانی دارند و ابزارهایی برای مهاجرت درجا ارائه می‌کنند. اگر برنامه‌های شما روی CentOS کامپایل شده‌اند یا پنل کنترلی دارید که فقط توزیع‌های خانوادهٔ رد هت را می‌شناسد، این گروه کم‌دردسرترین گزینه است.

۲) جریان پیوسته: CentOS Stream

Stream یک توزیع کاملاً کارآمد است، اما نقش آن با گذشته فرق دارد. اینجا شما یک نسخهٔ میانی میان فدورا و RHEL را اجرا می‌کنید؛ به‌روزرسانی‌ها زودتر می‌رسند و تغییرات رفتاری بیشتری هم دیده می‌شود. برای تیمی که می‌خواهد نسخهٔ بعدی نرم‌افزارش را پیش از انتشار در RHEL آزمایش کند، Stream عالی است؛ برای سروری که سال‌ها باید بی‌صدا کار کند، مناسب‌ترین انتخاب نیست.

۳) خانوادهٔ دبیان و اوبونتو

بعضی تیم‌ها به‌جای ماندن در خانوادهٔ رد هت، کلاً مهاجرت را به سمت Debian یا Ubuntu LTS می‌برند. این کار در بلندمدت آزادی بیشتری می‌دهد و مخزن بسته‌های بزرگ‌تری در اختیار می‌گذارد، اما هزینهٔ مهاجرت آن بیشتر است: مسیر بسته‌ها، نام سرویس‌ها، تنظیمات فایروال و سبک مدیریت سیستم متفاوت می‌شود.

AlmaLinux در یک نگاه

AlmaLinux توسط بنیادی غيرانتفاعی اداره می‌شود و از ابتدا روی «سازگاری باینری با RHEL» تأکید داشته است. نسخه‌های ۸ و ۹ آن سال‌ها پشتیبانی امنیتی می‌گیرند و نسخهٔ ۱۰ تا میانهٔ ۲۰۳۵ پشتیبانی می‌شود. ابزار ELevate امکان ارتقای درجای خانوادهٔ ۸ به ۹ را فراهم می‌کند و همین موضوع، مسیر مهاجرت را برای سرورهایی که نمی‌توانند نصب تازه انجام دهند کوتاه‌تر می‌کند.

در عمل، AlmaLinux جایی می‌درخشد که یک پنل کنترل یا نرم‌افزار تجاری، فهرست کوتاهی از سیستم‌عامل‌های پشتیبانی‌شده دارد. چون شناسهٔ سیستم و ساختار بسته‌ها همان چیزی است که سازندهٔ نرم‌افزار انتظار دارد، تعداد تغییرهای لازم کمتر می‌شود.

Rocky Linux در یک نگاه

Rocky Linux با هدف ادامهٔ دقیق همان فلسفهٔ CentOS ساخته شد و توسط جامعه‌ای مستقل نگهداری می‌شود. رفتار آن به RHEL بسیار نزدیک است و برای تیم‌هایی که به «بدون غافلگیری» اهمیت می‌دهند انتخاب طبیعی به حساب می‌آید. چرخهٔ پشتیبانی مشابه است و نسخهٔ ۱۰ نیز تا ۲۰۳۵ به‌روزرسانی امنیتی دریافت می‌کند.

تفاوت AlmaLinux و Rocky Linux بیشتر در مدل حاکمیتی، سرعت انتشار وصله‌ها و ابزارهای جانبی است، نه در هستهٔ سیستم. برای اکثر بارهای کاری، هر دو پاسخ درستی هستند؛ تصمیم را باید بر اساس پشتیبانی تجاری، سازگاری با پنل و سیاست سازمانی گرفت.

مقایسهٔ سریع گزینه‌ها

انتخاب بر اساس بار کاری

پیش از هر تصمیمی، فهرست نرم‌افزارهای نصب‌شده را بنویسید و کنار هر مورد بنویسید که سازنده‌اش کدام توزیع‌ها را رسماً تأیید کرده است. این فهرست، در بیشتر پروژه‌ها انتخاب را از حالت سلیقه‌ای خارج می‌کند.

• سرور وب با پنل کنترل: AlmaLinux یا Rocky Linux، هر دو با تأیید سازندهٔ پنل.
• کلاستر کوبرنتیز یا کانتینر: هر دو مناسب؛ در برخی توزیع‌های کوبرنتیز، Rocky رایج‌تر است.
• دیتابیس سنگین: هر دو، مشروط به کرنل و تنظیمات I/O یکسان با محیط آزمون.
• محیط توسعه و آزمون نسخهٔ بعدی: CentOS Stream.
• سازمانی با قرارداد پشتیبانی تجاری اجباری: نسخهٔ تجاری RHEL یا توزیع دارای پشتیبانی رسمی.

نقشهٔ راه مهاجرت کم‌ریسک

گام یک: صورت‌برداری از وضعیت فعلی

فهرست سرویس‌های فعال، نسخهٔ پکیج‌ها، کرون‌جاب‌ها، کاربران، کلیدهای SSH و مسیر بکاپ‌ها را جمع کنید. بدون این فهرست، مهاجرت به یک بازی حافظه تبدیل می‌شود.

گام دو: انتخاب روش

دو مسیر وجود دارد: نصب تازه روی سرور جدید و انتقال داده، یا ارتقای درجا روی همان ماشین. ارتقای درجا سریع‌تر است اما هر خطای پیکربندی را با خود به محیط جدید می‌برد. نصب تازه تمیزتر است و فرصت می‌دهد تنظیمات قدیمی را بازبینی کنید.

گام سه: ساخت محیط موازی

یک سرور آزمایشی با همان نسخهٔ سیستم‌عامل مقصد بسازید و نسخهٔ پشتیبان داده را روی آن بازیابی کنید. تمام سرویس‌ها را بالا بیاورید و رفتار برنامه را با دادهٔ واقعی بسنجید.

گام چهار: آزمون پذیرش

فهرستی از سناریوهای کلیدی بنویسید: ورود کاربر، ثبت سفارش، ارسال ایمیل، اتصال به درگاه پرداخت، اجرای گزارش سنگین. هر سناریو باید در محیط آزمایشی با نتیجهٔ یکسان تکرار شود.

گام پنج: سوئیچ کنترل‌شده

زمان سوئیچ را در ساعت کم‌ترافیک انتخاب کنید، TTL رکوردهای DNS را از چند ساعت قبل پایین بیاورید و مسیر بازگشت را از پیش آماده نگه دارید. اگر شاخص‌های خطا در نیم‌ساعت اول طبیعی بود، کار تمام است؛ اگر نه، بازگشت به نسخهٔ قبلی باید در چند دقیقه ممکن باشد.

گام شش: پاک‌سازی و مستندسازی

سرور قدیمی را چند هفته به حالت خاموش نگه دارید، سپس نسخهٔ سیستم‌عامل، تصمیم‌های گرفته‌شده و تنظیمات ویژهٔ آن را مستند کنید تا مهاجرت بعدی ارزان‌تر شود.

خطاهای رایجی که پروژه را عقب می‌اندازد

نخستین خطا، مهاجرت بدون آزمون پنل کنترل است؛ بسیاری از پنل‌ها به نسخهٔ مشخصی از PHP یا MariaDB وابسته‌اند. دومین خطا، انتقال تنظیمات قدیمی بدون بازبینی است؛ فایل‌های پیکربندی چندساله معمولاً تنظیماتی دارند که امروز ناامن محسوب می‌شوند. سومین خطا، نادیده گرفتن SSL و کلیدهای امنیتی است؛ گواهی‌ها باید در محیط جدید دوباره صادر یا منتقل شوند. چهارمین خطا، نداشتن بکاپ قابل بازیابی در لحظهٔ سوئیچ است.

برنامه‌ریزی بلندمدت

پس از مهاجرت، تاریخ پایان پشتیبانی نسخهٔ انتخابی را در تقویم تیم ثبت کنید. برای خانوادهٔ ۹، افق پشتیبانی تا حدود ۲۰۳۲ و برای خانوادهٔ ۱۰ تا ۲۰۳۵ است. یک بازبینی سالانهٔ نسخهٔ سیستم‌عامل، هزینهٔ مهاجرت‌های اضطراری را حذف می‌کند.

پرسش‌های پرتکرار

آیا می‌توان AlmaLinux و Rocky Linux را در یک کلاستر ترکیب کرد؟

از نظر فنی بله، اما نگهداری دو مسیر وصله در یک کلاستر توصیه نمی‌شود. برای نظم عملیاتی، یک توزیع را انتخاب کنید.

ارتقای درجا از CentOS 7 ممکن است؟

ابزارهایی برای این کار وجود دارد، اما در بیشتر موارد نصب تازه و انتقال داده ریسک کمتری دارد، چون CentOS 7 تفاوت‌های ساختاری زیادی با نسخه‌های امروزی دارد.

آیا پنل کنترل من روی نسخهٔ ۱۰ کار می‌کند؟

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

بدون مهاجرت چه اتفاقی می‌افتد؟

سرور به کار خود ادامه می‌دهد، اما آسیب‌پذیری‌های جدید اصلاح نمی‌شوند و نرم‌افزارهای تازه به‌تدریج نصب نمی‌شوند. این وضعیت تا اولین حادثهٔ جدی پایدار به نظر می‌رسد.

جمع‌بندی

انتخاب جانشین CentOS یک تصمیم دوسطحی است: انتخاب خانواده و انتخاب نسخه. برای بیشتر سرورهای تولیدی، AlmaLinux یا Rocky Linux پاسخ درست است؛ Stream برای آزمایش و مسیرهای غیر رد هت برای تیم‌هایی است که به دنبال تغییر بنیادی‌اند. مهم‌تر از نام توزیع، داشتن فهرست نرم‌افزار، محیط آزمون واقعی و مسیر بازگشت آماده است.