Amazon Linux против Ubuntu для Amazon EC2 [закрыто]


56

Я настраиваю свой первый сайт на Amazon EC2 и пытаюсь решить, какой дистрибутив использовать. Я использовал Redhat и CentOS в прошлом, но у меня нет предвзятости в отношении какой-либо системы, я просто хочу использовать то, что лучше (у меня также были частично управляемые серверы в прошлом, поэтому я не делал слишком много серверов) администрация до недавнего времени). Сайт - это просто веб-приложение, написанное на PHP и MongoDB.

Мне нравится идея иметь легковесную ОС, которая описана для Amazon Linux, но я беспокоюсь, что она может пострадать из-за совместимости / обновлений по сравнению с Ubuntu или другими вариантами, когда команды ориентированы исключительно на серверную ОС. Любой совет?

Ответы:


22

Я был в похожей ситуации; полностью управляемый выделенный сервер, LAMP, CentOS. Тогда мы решили перейти на EC2. Кроме того, у меня было очень мало опыта администрирования систем или Linux. У меня почти нулевой опыт работы с Ubuntu, поэтому я не могу говорить о том, что является так называемой лучшей ОС.

Я попробовал несколько готовых AMI с минимальной установкой ОС от Rightscale, Alestic, Scalr и Amazon. Я закончил сборку всех своих собственных AMI поверх Amazon Linux, сначала используя версию 2010.11.01, теперь я перенес все свои собственные AMI в версию Amazon Linux 2011.03.01.

Решение пойти с Amazon Linux AMI против других поставщиков AMI было непростым. Я играл с разными настройками и тестировал их почти месяц, прежде чем принял окончательное решение. В конце концов, поскольку я хотел использовать CentOS, все сводилось к одному. Я подумал, кому лучше знать, какие аппаратные зависимости необходимо включить в ОС, чем те, кто разрабатывал, создавал и обслуживал EC2. Ничего против Правил, Скалера или Алестика.

Шесть месяцев спустя, несмотря на то, что я столкнулся с несколькими трудностями, Linux Amazon был достаточно стабильным. Однако я решил скомпилировать часть программного обеспечения, которое мы используем, из исходного кода (т. Е. Php 5.3, MySQL 5.5 и т. Д.), Потому что столкнулся с проблемой предварительно собранных пакетов, которые Amazon поддерживал в их хранилище пакетов.


44

Amazon Linux - это скользящий дистрибутив, такой как Fedora или Debian Testing (вроде). На мой взгляд, он не подходит ни для какого производственного продукта. Я удивлен, что больше людей не осознают этого. Это означает, что если вы запустили свой экземпляр Amazon Linux, скажем, 450 дней назад и сделали обновление сегодня, вы будете получать обновления из совершенно другого выпуска. Как только новый выпуск сделан, у вас нет времени буфера, вы немедленно начинаете извлекать обновления из нового выпуска. Как вы можете себе представить, это может привести к каскаду зависимостей и может сломать вещи. По этой причине он по своей сути неуправляем. Вы не можете внедрить что-то подобное в политику обновления, если это не является полным беспорядком. Не используйте Amazon Linux для чего-либо серьезного.

Ubuntu LTS является хорошим выбором, как и Debian Stable или CentOS. Все они дают вам много лет обновлений к тому же выпуску.

В Amazon Linux также нет системы отслеживания ошибок , пользователи должны публиковать вопросы на форумах разработчиков AWS, чтобы сообщить об ошибке в пакете! Также нет возможности искать ошибки. Это должно быть наглядным вопросом почти для всех.

Amazon Linux делает очень трудным получение исходных пакетов без необходимости.


2
Это проблема, только если у вас нет тестовой среды для первого обновления.
ceejayoz

3
Ну, вы проголосовали здесь за единственно правильный ответ. Вы не продумываете это до конца. Во-первых, он не дает никакой выгоды по сравнению с другими дистрибутивами, поэтому бессмысленно и контрпродуктивно подвергать себя дополнительным неприятностям. Зачем делать ненужную работу для себя? Во-вторых, вы явно ошибаетесь здесь. Обновление 2013.9 с пакетами от 2015.3 абсолютно безумно. У вас почти нет возможности проверить все, что может сломаться здесь. Большинство людей обходятся этим (как и мы), но невозможно создать и поддерживать политику безопасности с помощью динамического дистрибутива.
figtrap

2
Я не знаю, почему Amazon Linux так популярен, я держу пари, потому что большинство не понимают, что это тестовый дистрибутив. Если вы порекомендуете Fedora для производственного продукта, администраторы будут смеяться над вами. Это именно то, что вы делаете с AMZN Linux. Дело не в том, «если» это решение будет кусать вас в будущем, а в том, когда.
figtrap

3
Нет выгоды? Он выпущен производителем инфраструктуры, на которой он работает. Любые проблемы, связанные с AWS, скорее всего, сначала будут решены в Amazon Linux. Я был очень доволен Amazon Linux, как и многие другие, и у нас не было проблем с ним в обзорах безопасности клиентов (включая очень и очень требовательные финансовые учреждения).
ceejayoz


39

Поскольку этот вопрос был написан, Amazon полностью обновил для Amazon Linux AMI 2011.09 со всеми средствами начальной загрузки для CloudFormation, а также инструментами Amazon.

Кроме того, он включает в себя Nginx и PHP-FPM в yumрепозитории, если вы ищете быстрый и легкий.

Следите за последними выпусками здесь: http://aws.amazon.com/amazon-linux-ami/latest-release-notes/

Также следите за обновлениями безопасности : http://aws.amazon.com/amazon-linux-ami/security-bulletins/

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


4

Если вы уже знакомы с RHEL / CentOS, я бы придерживался этого. Нет лучшего дистрибутива для сервера веб-приложений. Все зависит от того, с какими инструментами и соглашениями вы больше всего знакомы.


Ну, суть в том, что я не привязан ни к одному прямо сейчас и не слишком знаком с любым (но я хотел бы познакомиться).
Джеймс Симпсон

1
Затем попробуйте настроить один из них и посмотреть, что вам больше нравится.
Дмурати

5
Amazon Linux основан на CentOS ( forums.aws.amazon.com/thread.jspa?messageID=245351 ). Таким образом, вы получаете пятистороннюю гонку между тремя разными версиями RHEL (CentOS, Amazon и RHEL) и двумя разными версиями Ubuntu (11.04 и 10.04 LTS). Любой, кто пытается сказать вам, что в этом списке есть только один хороший выбор, пытается вам что-то продать. Тем не менее, для подавляющего большинства серверных применений я бы всерьез рассматривал CentOS, Amazon и Ubuntu Server 10.04 LTS именно в таком порядке.
BMDan

4

Хотя Ubuntu лучше справляется с этими тестами, сами тесты способствуют победе Ubuntu, и различия все равно не кажутся большими.

Недавно я выбрал Amazon Linux в основном из-за автоматических обновлений, а также из-за ошибки Ubuntu AMI, о которой Стивен и Итан сообщили в версии Quora этого вопроса .


Для обсуждения вышеупомянутых тестов: phoronix.com/forums/…
Даниил

0

Если вы хотите быстро познакомиться и любить устанавливать вещи без особого труда, я бы пошел на Ubuntu. Как правило, на живом веб-сервере вы не хотите делать такие вещи! Люди также утверждают, что выбор между RedHat, CentOS и Debian. Специалисты по ядру утверждают, что Ubuntu не подходит для серверных сред, потому что не все полностью защищено и протестировано.

Мой выбор был бы Ubuntu, так как это намного меньше головной боли, я использовал довольно много разных дистрибутивов для веб-серверов, но изменение правил брандмауэра и других вещей может быть намного проще в Ubuntu.

Единственное, что в Ubuntu - это немного более ресурсоемкое использование ресурсов, поэтому CentOS может сэкономить вам несколько долларов в месяц на основе метода ценообразования amazon!


0

В вашем случае знакомство с CentOS / RHEL, вероятно, превосходит любые другие соображения.

Системы, с которыми я работаю, в значительной степени были на грани - новое программное обеспечение с использованием новых технологий и новых версий. Для этого лучше использовать Ubuntu; Я избегаю сборки пакетов из исходного кода, и пакеты в Ubuntu хорошо поддерживаются (конечно, далеко не идеальными), и стандартные репозитории, как правило, содержат то, что нам нужно, и если нет, то репозитории легко доступны. Я, как правило, отстаиваю одну ревизию от последней, поскольку проблемы, как правило, решаются через несколько месяцев.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.