Можно ли использовать собственный репозитории вместо контейнеров Docker?

Question

[Вадим Ремин]

Добрый день,
я новичок в мире Linux. Вчера прослушал лекцию о контейнерах Docker и о том как легко можно с помощью них делать развертку на продакшен и тестирование. Docker решает задачу: перенести программу и её окружение на другой компьютер.
К преимуществам docker перед другими способами тестирования и развертывания относят:
1) Мгновенное создание необходимого окружения на любой linux/osX машине.
Контраргумент, тестирование: Если у вас сервера куда вы хотите устанавливать софт работают под определенным дистрибутивом (например Ubuntu), то, скорее всего, вы перед внедрением окончательное тестирование и подготовку к развертыванию будете делать на машине с аналогичным дистрибутивом (или на виртуалке).
Контраргумент, развертывание: При работе контейнера тратятся вычислительные ресурсы на обслуживание ядра прописанного в контейнере. Да и зачем собирать контейнер на дистрибутиве отличном от того который уже есть на сервере.
2) Инкапсуляция (если так можно выразится) всего, что работает в контейнере: процессы, память и др.
Контраргумент: Для чего нужно увеличивать вертикальное количество слоев в сервере, который должен выполнять и так в большинстве случаев только одну функцию. Зачем нужна инкапсуляция в капсуле? В высоконагруженных системах (100 и более серверов) может понадобится ставить на один физический сервер несколько независимых систем с разным окружением?
3) Беспроблемный перенос всех зависимостей.
Контраргумент: Ок, если мы предполагаем, что зависимости скачиваемые из репозиториев могут изменить свой код и поведение без изменения номера версии или пропасть. Как вариант можно сделать свой локальный репозиторий и иметь все в одном месте раздавая по сети, зачем плодить эти огромные контейнеры и запускать их как виртуалки (по сути) на каждом сервере? Все зависимости мы можем прописать в конфигурационном файле пакета.

Просьба подтвердить или опровергнуть эти тезисы. Если я мыслю совершенно неправильно, прошу простить, со всеми перечисленными технологиями никогда не работал, но собираюсь, и хочу понять что и как нужно правильно использовать.
Заранее спасибо!

Answer 1

[Кирилл]

там все относительно просто:
1 контейнеры потребляют очень мало ресурсов, контейнеры используют ядро хост-машины
2 так и есть, тот же гугл с его borg'ом, яндекс с cocaine идут путем когда уже не считаются машины в штуках, а воспринимаются как единое целое вычислительное пространство "в попугаях", сервера выпускаются все более мощные, старые остаются, вот по ним (в зависимости от того сколько машины этих "попугаев" тянет) и можно раскидать разные приложения, с контейнерами это удобно
3 как и в 2, - да на одном сервере могут "крутиться" разные приложения, т.к. можно "уплотнять" ресурсы, в том же гугле принцип использовать железяку на 100%

К плюсам докера можно отнести то, что у него достаточно удачный API, который позволяет поверх него легко написать "управлялку" контейнерами, да и "оркестрацию/дискавери" сервисов набросать

Если есть задача запускать на сервере только какое-то определенное прложение (например интернет-магазин на php/python/go etc...) для "личных" или "корпоративных" целей то докер тут не особо нужен

Comments

[Вадим Ремин]

Спасибо за понятный ответ!

Answer 2

[Владимир Чернышев]

1.1 и частично 1.2: Зачастую тупо не знаешь под какой осью твой софт будет работать, даже если он чисто внутренний для компании. Даже (или особенно?) если сервер в компании единственный, админ может решить его обновить из-за критической уязвимости или для установки какого-то другого софта.

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

2. Редкость, по-моему, сейчас когда один физический сервис выполняет ровно одну функцию. Да и раньше как-то не практиковалось, по-моему. Контейнеризация позволяет чётко выделять сервисы и изолировать их друг от друга куда меньшими ресурсами чем виртуализация, как при разработке и деплое, так и в рантайме.

3. Зависимости разных процессов не будут конфликтовать друг с другом. Какой-нибудь унаследованный софт будет работать под уже неподдерживаемым дистром, и тут же будет работать софт, использующий самые последние версии каких-то библиотек.

Answer 3

[Vaavaan]

Если у вас сервера куда вы хотите устанавливать софт работают под определенным дистрибутивом (например Ubuntu), то, скорее всего, вы перед внедрением окончательное тестирование и подготовку к развертыванию будете делать на машине с аналогичным дистрибутивом (или на виртуалке).

Чего это?
Вы же про Докер пишете. Не надо с ним этого.
Можешь хоть под Window сидеть хоть под MacOSX хоть под RedHat
Внутри Докера у тебя будет то, что нужно.

При работе контейнера тратятся вычислительные ресурсы на обслуживание ядра прописанного в контейнере. Да и зачем собирать контейнер на дистрибутиве отличном от того который уже есть на сервере.

Слазите в исходники ядра и посмотрите. Там несколько десятков ассебмлерных команд это "затормаживают". Подсказать сколько в секунду таких команд на процессоре 2,5 ГГц или сами догадаетесь?

Собирать контейнер нужно на том, который тебе нужен для работы.
Идея контейнеров в том, что тебе плевать на то, что снаружи контейнера.

Для чего нужно увеличивать вертикальное количество слоев в сервере, который должен выполнять и так в большинстве случаев только одну функцию. Зачем нужна инкапсуляция в капсуле? В высоконагруженных системах (100 и более серверов) может понадобится ставить на один физический сервер несколько независимых систем с разным окружением?

Сервер не выполняет одну функцию с этой точки зрения.
Там есть контрольные сервисы - в своем контейнере.
Там есть основных парочка минимум - для надежности и зелено-голубого деплоя.
Там есть балансировщик между этими двумя.
И это по минимуму.

А сейчас пошла тенденция - сервисы автоматически размещаются по серверам, максимально уплотняя. Нет никакой гарантии что на этом железе будет работать 1 большой или 20 маленьких сервисов и что это сохранится после перезагрузки сервера.

Зачем ставить другую ОС? Как правило не ставят. В конейнере всегда одна. Но если захотят - поставят другую. И благодаря контейнерам ты этого и не заметишь.
Очередная ОС займет всего то +50 мегабайтов.

Ок, если мы предполагаем, что зависимости скачиваемые из репозиториев могут изменить свой код и поведение без изменения номера версии или пропасть. Как вариант можно сделать свой локальный репозиторий и иметь все в одном месте раздавая по сети, зачем плодить эти огромные контейнеры и запускать их как виртуалки (по сути) на каждом сервере? Все зависимости мы можем прописать в конфигурационном файле пакета.

Некоторые зависимости противоречивы. Нельзя одновременно поставить. На голую ОС.
А в разные контейнеры - можно.