Понимаю, что вопрос из области брюнетки vs блондинки, но всеже.
Сейчас вся инфраструктура поднята на debian 7. В данный момент хочется мигрировать либо на Debian 8, либо на Ubuntu(естественно актуальный LTS).
Последние годы пытался юзать Ubuntu на десктопе - остались крайне неприятные впечатления о стабильности(но может это собственная криворукость, хотя общался с системой в режиме "домохозяйки").
Какие видятся плюсы Ubuntu - значительно быстрее обновляются различные пакеты.
Плюсы Debian - за "годы" показала себя как очень стабильная система. На Debian новые пакеты получал всегда ставив всякие dotdeb(php), некоторые ПО принципиально пакетами не поставишь (nginx с недефолтными модулями).
Сейчас всю инфраструктуру планируем делать на Docker контейнерах, управлять всем через Ansible(уже протестировали эту связку на небольшой нагрузке на Debian 8 - "вроде работает").
Имеет какое-либо значение выбор системы в рамках задачи?
Тоесть причина миграции на убунту только наличие свежих пакетов? Есть чёткое правило - использовать надо ту операционную систему в которой лучше всего разбираешься. Посмотрите в сторону других дистрибутивов, потому что разницы особой между двумя вышеперчисленными почти нет.
Сам использую Gentoo, много лет, доволен и глаза не красные:)
Пользователь: у меня были сервера с Fedora 6 и Fedora 9 (или что-то вроде того), миграции были странным занятием, после этого решил что так дело не пойдёт. Теперь обновляю всё что нужно когда хочется, а не когда "берём и заменяем всё с коробкой". Debian пару раз пробовал использовать на ноуте с liveCD... это конечно боль, но просто потому что не привычная система. Сразу не хватает USE флагов для полного контроля происходящего.
Oleg Shevelev: какой парк серверов на генту? ичо делают? пищат и все портят? не ради подьебать а ради разобраться потому что хочу убунту на арч мигрировать как раз по причине роллинг релизов
Михаил: Для меня более важно то количество лет что я использую Gentoo (а их уже примерно с десяток), опыт ручной миграции между версиями EAPI, поддержка локального оверлея и сборки специфического софта путём написания ebuild (но на самом деле это приходилось делать редко).
В сферу специфики моей работы более пяти одновременно живущих серверов в личном пользовании у меня, обычно, не бывает, по этому автоматизированные сборки через Ansible и прочее не делаю.
Есть список USE флагов которые набираются постепенно, список особенностей которые надо учитывать при установки того или иного софта, по этому новая сборка, как правило, проходит очень просто в фоне и без дополнительного софта.
Сервера при этом универсальные, от типичных DNS и Web-сервера до OCR распознования, WebSockets и прочих сетевых многопоточных приложений.
Чего-то сильно высоконаргурежнного на них никогда не бывает, по этому тюнить под отдачу большого количества видео или большего числа одновременных соединений пока было без надобности, всё и так работает очень хорошо.
В планах уменьшить размер stage3 и перенести его на полностью ручное обновление через единый git сервер. Это нужно для:
1. уменьшения размера занимаемого операционкой в принципе
2. исключения совсем редко используемого софта
3. исключения используемого софта, но от которого можно отказаться
4. сборки для запуска исключительно Golang приложений без прочего стека, возможно кроме ядра, небольшой обвязки и стопки Golang приложений там больше ничего и не останется
Сделайте на ubuntu cat /etc/debian_version - там обычно написано sid. sid соответствует пакетам из unstable репозитория debian. Ну тут и объясняется выбор Debian или Ubuntu - хотите unstable пакеты - Ubuntu. Хотите stable - ставьте Debian Stable.
Debian. Ubuntu использует самые свежие версии пакетов (не помню "маркировку" репозитария), но Debian использует только линейку Stable, что означает, что у вас не будет проблем с ПО.
Пользователь: Ну, о "не будет проблем" сказано алллегорически. Само-собой, немного утрировано. Идеально работать не может ни что. Тем более, что существуют конфликты с другим ПО, с железом (точнее, с его драйверами). Всё это очевидно.
sim3x: да вот хотя бы про эту habrahabr.ru/company/hexlet/blog/248519
Или про то что LXC, как и OpenVZ ещё год назал не умел правильно разделять IOPS к доступу к дисковой подсистеме и проблемы в одном контейнере убивали весь сервер целиком, а не только конкретный изолированный участок.
Или, опять таки, слишком большой размер что бы запустить одно приложение или целую пачку по отдельности.
Или проблемы с латенси в сетевом стеке между докерами на одной физической машине.
Или ещё ворох того что можно поискать, как в сети так и самостоятельно.
Докер крут тем что даёт возможность людям думать ещё меньше чем обычно, а думать никто не любит. Но как технология, конечно, крута... но не понацея. По этому и хочется услышать реальный фидбек от использования CoreOS везде и всюду... как много докер-контейнеров вам приходится из-за этого запускать на одном сервере, используете ли вы по контейнеру на каждый сервис или объединяете сервисы группами что бы поместить в один контейнер? Как справляетесь с междокерной интеграцией?:) Что делаете если докер контейнеру в пределах сервера тесно и его надо перенести? Ещё можно вопросов можно придумать и ответы на которые хотелось бы получить:)
