Какие цели и задачи у Docker в production?

Question

[Евгений]

Всем привет.
Занимаюсь веб разработкой, как написанием кода так и немного администрированием линкусовых серверов.
Слышал и читал много хайпа вокруг докера и вагранта.
Если с вагрантом у меня дружба сложилась, для меня это удобство для локальной разработки. Я могу сделать свой образ с провижен файлом, в которым накачу все что надо для моего веб проекта и юзать эту виртуалку как веб-сервер полностью настроенный как мне надо, и еще и с коллегами им поделиться, чтобы не мучались, то с докером для меня не так всё ясно.
Непонятно каковы реальные цели и задачи докера в продакшене. каков уровень задач?
Хотелось бы услышать ответы кто действительно сам юзает, отзывы, плюсы и минусы, круг задач.
Была идея что можно на несколько серверов (будь то разные проекты или один проект разнесенный по разным серверам накатывать ПО контейнерами, но нет уверенности что это не оверинижиринг, так как в принципе с этим в какой-то мере справится ansible).
Что делаете докером вы?

Answer 1

[DevMan]

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

Comments

[Евгений]

Я это понимаю. Я зачал эту тему, потому как мне хотелось услышать конкретику по задачам в продакшене.

[DevMan]

Евгений: не может быть конкретики поскольку задачи и workflow у всех разные.
например, решил я обновить мускуль - создал контейнер, откатал его на тестовом сервере и закинул на прод, вместо обновления софта самой системы. и таких примеров валом, у кого какая фантазия.

[Евгений]

DevMan: в вашем примере чем контейнер удобнее чем обновить версию мускуля на проде? лишние телодвижения не совершать а положить быстренько то что уже 100% работает и положить это гарантированно без конфликтов, как это порой бывает. когда то одного пакета не хватило, то другой репозиторий старый. сам спросил и похоже что сам ответил)

[DevMan]

Евгений: тем, что:
1. мне не нужно лезть на сервер и обновлять софт.
2. если что-то пойдет не так, я могу элементарно и быстро откатиться назад.
3. на одном сервере я без менингитов могу держать несколько нужных мне версий одного и того же продукта не опасаясь что его обновление заденет смежные приложения.

[DevMan]

Евгений: вы не правильно вопрос здаете)
дело не в лучше/хуже, а в том кому какой подход ближе и удобней и у кого какие потребности.
а вопросы лучше/хуже - из разряда армяне vs грузины, монитор глянцевый vs матовый, наушники закрытые vs открытые, git vs svn, win vs nix и т.д. и т.п.

Answer 2

[Dimonchik]

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

идея проста: процессор, как правило, дешевле памяти, т.к. редко нагружен более 50%, поэтому для кучи проектов дешевле держать один сервер с много памяти, чем несколько серверов (хороший канал, разумеется)

у нас устроено так: nginx на хосте, он же занимается статикой, статика тоже на хосте, а upstream-ы с динамикой (Flask, Django, по-моему bottlepy еще есть) - все в контейнерах, sphinx в контейнере, еще один nginx c сишным демоном тоже в контейнере

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

тут особых наворотов нет - только уверенность в работоспособности других сайтов, если какой-то сложит программер, но вариации могут быть самыми разными - например, nginx с самописными/специфическими модулями в контейнере не ложит остальное, где-то применить Varnish для кеширования, потестить какой-нибудь Aerospike без боязни положить систему и т.п.

Comments

[Dimonchik]

2) для таких проектов держим и сервера и до сих пор гипервизоры, ибо проверено временем, а для стартапа и хипстеров хватает и одной машинки вполне

1) про "дешевле" я не совсем это имел в виду ): в современном софте, только если это не стрим видео, процессор никогда не нагружен сильно - для одной задачи он вполне себе 12-20% максимум - это если траффик на сайт постоянный, а вот память отъедается на раз - все свои кеши держат в памяти - от мускуля до тем более редисов и прочих аэроспайков. Соответственно, проц можно арендовать попроще, но "попроще" - значит меньше ядер, меньше ядер - значит меньше нарезанных виртуалок, и вот Докер как раз позволяет это сглаживать. Хотя в нем тоже можно выставить ресурсы

[Евгений]

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

[Dimonchik]

память
зажал - разжал
ну и код, хоть и virtualenv выручит, но так надежнее

Answer 3

[Алексей Киселев]

Мы используем Docker для установки Java приложений вместе с окружением. В скрипте сборки собирается контейнер из Docker-файла в него ставится все что нужно, запихиваются настройки и само приложение.
Можно вызвать команду deployment-a, если есть настройки доступа к удаленным серверам.
Да, деплоймент упрощается значительно.
Но главная причина по которой мы используем Docker - это возможность зафиксировать окружение. В java многое для этого сделано, легко можно собрать приложение с заданным набором версий библиотек. Но вот отслеживать версии окружения (серверов приложений и т.д.) приходилось ручками или в документации. Что вело к возникновеню понятных проблем. С Docker-ом вся конфигурация описана в файле и лежит в Git и версионируется вместе с приложением.

Comments

[Евгений]

У вас все в одном контенере лежит? или сервисы какие-то отдельно по контейнерам своим разнесены?

[Алексей Киселев]

Под каждый сервис создается свой контейнер. Очень удобно. Можно на одной машине тестировать одновременно разные версии одного сервиса или разные сервисы, тем более что многие не очень требовательны к ресурсам. В production, пока, так не делали, там работает какая-то одна версия.

[O Di]

Алексей Киселев: а как вы осуществляете сборку Maven'ом например?

[Алексей Киселев]

А мы не пользуемся Maven, у нас вся сборка на Ant. Есть вот такой проект (https://github.com/alexec/docker-maven-plugin), правда, когда я на него смотрел, он не работал. Но есть еще варианты плагинов для Maven, например https://github.com/rhuss/docker-maven-plugin (этот не пробовал).

[O Di]

Алексей Киселев: благодарю

Answer 4

[Vladimir Zhurkin]

Docker для удобства тестирования и упаковки приложения (апликации) или ряда приложений в контейнер.
Удобно тем, что вы можете сделать рабочий деплой очень и очень быстро. Если у вас упала одна из машин, выкатили новую , старую убили.
Но это лично мое мнение.

Answer 5

[Виктор Логин]

Кроме всего выше сказанного, Docker облегчает процесс CE/CD. Тот же Ansible может оставить за собой артефакты, которые придется чистить самому, c Docker'ом же такого не произойдет. Плюсь поверх докера можно поднять Kubernetes/Mesos что позволит автоматизировать процесс масштабирования приложений. Опять таки скорость поднятия/удаления контейнера выше по сравнению с аналогичными действиями у полной виртуализации.

Comments

[Евгений]

т.е. вы предлагаете в целом софт держать по контейнерам? слитно ли в одном контейнере или отдельно. или прям еще и ваше приложение в контейнере и так деплоить новые релизы приложения новыми контейнерами?
вы как-то юзаете на продакшене докер или это в теории?

[Виктор Логин]

Мы пару недель как начали переез на Docker. У нас софт разбит по контейнерам, один сервис - один контейнер(от одного до N).
Пока это только на тестовой инфраструктуре, к концу декабря хотим и продакшен переводить. Доставку кода делаем через GitLab CI, при коммите в итоговую ветку собирается свежий Docker image, и обновляем уже запущенные. Сейчас начали Kubernetes пробовать, пока нравиться.

[Евгений]

вы как-то централизованно управляете зоопарком контейнеров?
нет ли проблемы с самой работоспособностью контейнеров как вы мониторите их состояние? не сервиса в контейнере, а самого контейнера.

[Виктор Логин]

Евгений: Да, у нас установлен локальный docker registry в котором храняться наши образы, вида name_server:version_or_tag
С самими контейнерами пока проблем не было, контейнеры еще не мониторим, хотя есть dockerUI для визуализации состояний контейнеров. На данный момент у нас написана служба которая подхватывает запускаемые сервисы и следит за ними, в случае падения sms, email админу.

[Vladimir Zhurkin]

Евгений: В целом так и есть софт в контейнеры. От себя добавлю, что докер просто модная вещь. Мы до сих пор используем OpenVZ со своими скриптами и не видим смыла переходить на докер. Мы больше думаем миграцию в сторону LXC. Еще все в одном openstack , но его поднять и обслуживать не совсем простая задача.

[Николай Ковалев]

Vladimir Zhurkin: модная то она модная, но и полезная же ;) вчера читал вот это: www.slideshare.net/openvz/dmitryguryanov-slides140...

[Vladimir Zhurkin]

Николай Ковалев: Да я не отрицаю. Просто я вижу как с пенной у рта начинают ломать уже построенную и рабочию ни один год архитектуру , ради модного. Докер ради докера утопия, должно быть обоснование.
У нас сейчас идет актвиное обсуждение переползти на LXC c openvz. Сосисочная компания (parallels) просто прошляпила рынок контейнеризации и его занял docker, сейчас они всеми силами пытаются не потерять этот сегмент (мое IMHO) .

[Николай Ковалев]

Vladimir Zhurkin: то что прошляпили, тут вы правы. поэтому и пыжатся со всех сил наверстать упущенное. я вот на центос7 именно с openvz хочу хостинг на продажу мутить )) но если для себя то lxc вполне - для себя родимый велосипед всегда милее ))

Answer 6

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

Использую докер-контейнеры как легковесные виртуалки, которыми куда проще манипулировать. И куда меньше душит жаба для конфигов типа "на этой виртуалке будет работать только nginx, на этой только php-fpm, на этой только postgre, эта будет шарить статические файлы для nginx и php-fpm, тут будет лежать кэш, тут загруженные пользователями файлы, а тут база данных"