Подходит ли Arch Linux для серверной среды?

Считаете ли вы Arch Linux подходящим для серверной среды? Его модель и простота выпуска релизов кажутся хорошими, потому что после установки вам не нужно переустанавливать, как модель выпуска из других дистрибутивов.

Но что постоянное обновление не вызывает проблем со стабильностью? Arch Linux использует новейшую СТАБИЛЬНУЮ версию программного обеспечения.

Вероятно, самая большая проблема с Arch как серверной операционной системой заключается в том, что неясно, где и когда приложения могут сломаться после обновления. Чаще всего вы должны быть в курсе того, что происходит в вики и на форумах, прежде чем выполнять какие-либо обновления; с Debian и CentOS вы можете быть уверены, что любые обновления не повредят никаким приложениям, поскольку чаще всего обновления, выполняемые в ветви STABLE, будут исправлениями безопасности / ошибок.

Хотя я люблю арку, я бы не стал использовать ее для производственной среды. Прежде всего, в производственной среде нужно что-то стабильное и хорошо протестированное. Кроме того, поскольку он довольно раздетый, вам нужно создавать собственные сценарии или настраивать их вручную (иногда это хорошо, потому что вы точно знаете, что работает в вашей системе, но очень плохо, потому что для его настройки требуется слишком много времени). Кроме того, поскольку он не очень широко используется в рабочих средах, в случае возникновения проблемы вы не найдете поддержку, которую бы вы нашли, если бы вы использовали Debian или Fedora (сообщество Arch великолепно, но, честно говоря, не так велико) как Debian или Fedora)

Подводя итог, я думаю, что это отлично подходит для настольных ПК, но не для производственных сред

Да.

Плюсы:

• действительно минимальная система из коробки, отлично подходит для производительности, особенно на недорогих машинах / VPS. Нет ненужных сервисов - по сравнению с CentOS 7, который запустил несколько сервисов, связанных с ВМ, которые даже не были применимы ко мне, когда я работал на голом железе

• современное программное обеспечение и большие репозитории; Я потерял довольно много времени с CentOS, когда чего-то не было в репозиториях, и я был вынужден либо скомпилировать его из исходного кода, либо установить сторонние RPM / репозитории, а затем оказаться в аду зависимости, потому что эти сторонние RPM были конфликтует с обновлениями из официальных репозиториев.

• systemd, хотя другие дистрибутивы (даже Ubuntu) переключаются на него, так что это не профессионал, а то, чего можно ожидать от любого приличного дистрибутива.

• инструменты настройки сети, которые имеют смысл. Ни настольный сетевой менеджер, ни firewalld (глядя на CentOS / RHEL).

• менеджер пакетов, который делает то, что говорит на жестяной банке. Менеджер пакетов не попытается «помочь» вам, автоматически настроив или запустив службу, которую вы только что установили (смотрите Ubuntu / Debian). Это также быстро, лучше yum, и, возможно, чуть-чуть быстрее, чем apt-get.

• процесс установки, который не заставляет вас использовать какие-либо значения по умолчанию и предлагает много возможностей для настройки - сравните это с CentOS / RHEL, который заставляет вас использовать LVM и подкачку, что не всегда необходимо (почти никогда в моем случае на самом деле)

• /usr/bin/pythonна самом деле это последний Python 3, а не доисторический Python 2.7. Это всегда проблема для меня с большинством других дистрибутивов, и вы не можете легко изменить это (по крайней мере, не для всей системы), так как это сломает многие приложения, которые полагаются на это.

Минусы:

• некоторые обновления требуют ручного вмешательства и могут сломаться. Я рекомендую иметь копию вашей производственной среды в виртуальных машинах и тестировать обновления там, прежде чем развертывать их на реальных серверах.

• нет рабочих настроек по умолчанию. Плохо для людей, которые просто хотят запустить apt-get и установить свой небезопасный стек LAMP по умолчанию, чтобы развернуть свое дрянное уязвимое приложение PHP и загрязнить Интернет. Конечно, это действительно преимущество для серьезных людей, так как оно заставляет вас просматривать файлы конфигурации перед запуском сервиса.

• нет поддержки SELinux. Существует GRSecurity и его RBAC, но вам нужно некоторое время, чтобы привыкнуть к нему и настроить его.

Я бы не согласился с тем, что вы получаете меньше поддержки. Конечно, это правда. Это недостаток? Нет на мой взгляд. В Arch очень мало того, что может сломаться и потребует поддержки от кого-то, кто знаком с Arch. Обычно, если вам нужна поддержка, она понадобится вам для определенного программного обеспечения, и в этом случае вы спросите его разработчиков, и тот факт, что вы используете Arch, становится неактуальным.

Для меня использование Arch намного проще и требует меньше времени, чем использование CentOS и его Networkmanager, firewalld и других ненужных сервисов (их можно отключить, но это уже потраченное время). Кроме того, я знаю все службы, работающие в системе, потому что я бы установил их, никаких хитрых программ, которые не давали бы мне покоя об ошибке и хотели бы позвонить домой, даже если я только что установил систему.

Я бы всегда предложил один из:

• CentOS. Это бесплатный клон RHEL, означающий, что вы получаете очень длительный цикл поддержки (7 лет), в течение которого вы можете получить только исправления безопасности и незначительные улучшения, так что поддерживать исправленную систему очень и очень просто. Кроме того, многие «коммерческие» программы предназначены для RHEL, поэтому их проще устанавливать на CentOS. Недостатки: я предпочитаю apt / dpkg yum / rpm, нелегко запустить на нем передовое программное обеспечение, немного спартанский выбор программного обеспечения

• Ubuntu LTS. На самом деле я до сих пор не использовал его, но он также имеет длинный цикл поддержки, и это Debianish

• Тестирование Debian. Мой любимый дистрибутив Debian, работает очень хорошо, и у него тупо огромный выбор пакетов, который очень хорошо собран. Исправление требует больше времени, но легче установить программное обеспечение (т. Е. Есть больше готовых пакетов).

Я бы посоветовал рассмотреть доводы "за" в использовании Arch Linux для одного из этих трех вариантов и посмотреть, стоит ли оно того.

Я запускаю несколько серверов Archlinux с 2013 года в производственной среде, и это работает как шарм.

Конечно, вы должны убедиться, что обновления идут хорошо, запуская их часто, и всегда проверять страницу archlinux перед обновлением.

Но это все, в итоге у вас будет гораздо больше проблем с обновлением RedHat / CentOS с 6 до 7 (почти невозможно) или SLES / SLED с 11 до 12 и так далее.

У вас постоянно небольшие обновления, которые время от времени вызывают какие-то действия, но у меня никогда не было чего-то большого за последние 5 лет.

Кроме того, вы всегда в курсе, если в ядре, в openssl, в bash или где-то еще есть утечка безопасности, вы получаете обновления в течение нескольких часов, а не дней или месяцев.

Мой Сервер, например, полностью обновлен и защищен от Spectre v1, Spectre v2 и распада, я уверен, что только 1% людей, размещающих здесь, имеют серверы, защищенные от всех трех.

Он быстрый, безопасный, стабильный (!) И у вас есть текущее программное обеспечение, которое избавляет вас от множества проблем.

Я настоятельно рекомендую использовать Archlinux на сервере, но недостатком является то, что вы должны знать, что вы делаете. Вы должны были установить систему LFS хотя бы один раз, чтобы понять основы создания и работы дистрибутива Linux.

Единственной серверной системой, которую я нашел более надежной, чем Archlinux в серверной среде, была Gentoo. В течение 700 дней существовала одна система Gentoo без обновлений, и спустя 1 час эта система была обновлена ​​и работала, единственное время простоя - одна перезагрузка.

Но другие системы, такие как Debian / Ubuntu, RedHat, SUSE, просто полностью облажают вас при обновлении дистрибутива. RedHat даже активно рекомендует вам обновить дистрибутив и рекомендовать его переустановить (согласно официальной документации).

Так что да, RedHat более стабильно обновляется, чем Archlinux, но только потому, что вы не получаете больших обновлений. И когда вы получаете их, вы облажались.

Я бы сказал, да, с оговоркой, вы никогда не должны просто запускать pacman -Syu на производственном сервере и сохранять резервные копии diff-образа системного диска, которые можно перевернуть через файловую систему в случае поломки.

НАМНОГО более пригодный для использования (гораздо меньше веб-сайтов), чем Debian testing / sid. Если вам нужны передовые пакеты и минимальная установка, Arch - лучший дистрибутив для этого, но требует большого комфорта при ручном управлении.

Основное отличие серверных дистрибутивов заключается в том, что вы получаете только обновления для системы безопасности, в то время как на arch вы также получаете основные ревизии пакетов, которые могут сломать вещи.

Если вы хотите сделать Arch подходящим для серверов, все, что вам нужно сделать, это поменять зеркала (место, откуда вы получаете пакеты). Например:

• Зеркала архива: Вы получаете незначительные / основные обновления пакетов в течение первой недели после их выпуска их владельцами.
• manjaro-unstable: То же, что и арочные зеркала, но некоторые пакеты проверяются дважды. Некоторые серьезные ошибки не будут сделаны в производство.
• manjaro-beta: то же самое, что и арочные зеркала, но все пакеты проходят тройную проверку. Большинство серьезных ошибок не попадут в производство.
• manjaro-stable: то же самое, что и арочные зеркала, но пакеты проверяются несколько раз в течение месяцев. Очень маленькие незначительные ошибки делают это в производство.

Точно так же, если вы используете зеркала, специально предназначенные для серверов, где вы получаете только незначительные ревизии, тогда было бы безопасно использовать arch на серверах.