Вокруг постоянно говорят про Docker. Я знаю что вы отвечаете: «Это что-то про контейнеры, виртуализацию, облака», «У нас все и так работает», «Это все баловство», «Он не запустится на нашем старом ядре линукса», «Точно так же можно подготовить образ для облака и запустить его», «Можно просто настроить LXC, chroot или AppArmor». Вы знаете, что он вам не нужен. Очередная модная штука. В конце концов, просто лень разбираться. Но любопытно! Тогда, читайте. Это серия из шести заметок.
Если вы не слышали о контейнерах в Линуксе, вот список страниц, которые надо прочитать, чтобы понимать о чем речь:
Поставьте Docker, он небольшой. Для Windows и Mac можно просто поставить Toolbox: www.docker.com/toolbox. Создавать виртуальную машину и настраивать лучше из командной строки, а не через графическую обертку. Прочитайте несколько уроков из мануала. Здесь я пишу о том, чего в документации нет.
Вот какой у меня линукс:
Запускаю CentOS:
Docker — это не chroot, их функционал частично совпадает. Это не система безопасности вроде AppArmor. Docker использует те же контейнеры, что и LXC, но интересен он не контейнерами. Docker — это ничего из того, что я думал о нем до того, как прочитал документацию.
То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.
Регулярно возникает вопрос, является ли конфигурация nginx частью веб-приложения. Системные администраторы спорят с разработчиками. Но недавно в мире появились devops и захотели вместо последовательно-процедурного вызова команд из bash думать привычным OOP. Docker дает инкапсуляцию, наследование и полиморфизм компонентам системы, таким как база данных и данные. Это значит, что можно провести декомпозицию всей информационной системы, выделить приложение, web-сервер, базу данных, системные библиотеки, рабочие данные в независимые компоненты, внедрять зависимости из конфигов, и заставить все это работать одной группой, одинаково на разных компьютерах.
Такой подход можно использовать, чтобы снизить потери рабочего времени дорогих front-end разработчиков на настройку базы данных и Nginx. Чтобы уйти от vendor lock-in. Не обломаться когда openssl на сервере не поддерживает cipher, используемый в API госучреждения. Чтобы приложение работало независимо от версии PHP или Python на сервере заказчика. Создавать open source не только в виде кода, но и настройкой пакетов из нескольких приложений, написанных на разных языках, работающих на разных слоях OSI.
Итак, я открыл docs.docker.com/mac/started, поставил Docker, выполнил несколько упражнений, и почувствовал, что меня держат за дурачка-двоечника, которого боятся перегрузить информацией. Первый вопрос: куда это чертов докер поставился, где лежат его файлы, в каком формате, как оно все устроено? Ответы здесь: blog.thoward37.me/articles/where-are-docker-images-stored
Если вкратце, для для работы с файловой системой Docker использует один из драйверов, обычно это AUFS, и все файлы контейнеров лежат в /var/lib/docker/aufs/diff/. В /var/lib/docker/containers/ служебная информация, а не сами файлы контейнеров.
Образы — это как классы в коде. Контейнеры — как объекты, созданные из классов. Основное отличие — контейнер можно закомитить и сделать из него образ. Образы состоят из так называемых слоев, слои — это папки, которые лежат в /var/lib/docker/aufs/diff/. Обычно образы приложений наследуют какие-то готовые официальные системные образы. Когда Docker скачивает образ, ему нужны только те слои, которых у него нет.
Например, скачаю я официальный образ nginx: hub.docker.com/r/library/nginx/tags
Пишут, что образ nginx 1.9.4 размером 52 мб, а по факту, у меня скачается всего 3 мб. Это потому, что nginx собран на образе debian:jessie, который у меня «Already exists». Есть много образов на базе Ubuntu. Конечно, стоит собирать свою систему из образов с одним предком.
Контейнеры исполняются механизмом ядра под названием Cgroups. Служба docker запускает контейнер по команде, полученной от клиентского приложения (например, docker), и останавливает его когда в контейнере освобождается поток стандартного ввода-вывода. Поэтому в конфигурации Nginx для Docker пишут:
Когда работа контейнера заканчивается, он не удаляется, если это не указать специально. Каждый за$ пуск контейнера командой docker run image_name без параметров --name или --rm создает новый контейнер с уникальным идентификатором, который остается в системе до удаления. Так что Docker — система, склонная к замусориванию. Имена контейнеров в системе уникальны. Рекомендую присваивать имя каждому создаваемому постоянному контейнеру, а контейнеры, в которых не нужно сохранять данные, рекомендую создавать с параметром --rm. Контейнеры создаются командами docker run и docker create. Посмотреть список всех существующих в системе контейнеров можно командой docker ps -a.
Соответственно, Docker может и зависнуть. Если вы дали команду скачать образ, единственный способ прервать процесс скачивания — перезапустить службу. Авторы уже давно обсуждают что с этим делать, но воз и ныне там.
Например, в версии 1.8.1 есть воспроизводимая проблема:
Нажимаю Ctrl-C, затем сразу запускаю скачивание повторно.
Картина Репина «Приплыли». То есть, зависли. Надо перезапустить демон.
Бывает, что демон docker не хочет умирать самостоятельно и не освобождает порт, а init-скрипт пограничные случаи еще не отрабатывает. Так что не забывайте проверять sudo /etc/init.d/docker status, sudo netstat -ntpl, доставайте бубен и танцуйте.
Еще надо помнить, что порядок операторов для команды docker имеет значение. Если написать docker create nginx --name=nginx, --name=nginx будет считаться командой, которую надо выполнить в контейнере, а не именем контейнера.
Теперь вам будет проще разбираться с официальной документацией.
Продолжение: habrahabr.ru/post/267451 и habrahabr.ru/post/267455
Если вы не слышали о контейнерах в Линуксе, вот список страниц, которые надо прочитать, чтобы понимать о чем речь:
- en.wikipedia.org/wiki/LXC
- en.wikipedia.org/wiki/UnionFS
- habrahabr.ru/post/253877
- www.docker.com/whatisdocker
Поставьте Docker, он небольшой. Для Windows и Mac можно просто поставить Toolbox: www.docker.com/toolbox. Создавать виртуальную машину и настраивать лучше из командной строки, а не через графическую обертку. Прочитайте несколько уроков из мануала. Здесь я пишу о том, чего в документации нет.
Docker — это не виртуализация.
Вот какой у меня линукс:
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-15-generic x86_64)
Last login: Tue Aug 18 00:43:50 2015 from 192.168.48.1
gri@ubuntu:~$ uname -a
Linux ubuntu 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/ Linux
gri@ubuntu:~$ free -h
total used free shared buffers cached
Mem: 976M 866M 109M 11M 110M 514M
-/+ buffers/cache: 241M 735M
Swap: 1.0G 1.0M 1.0G
Запускаю CentOS:
gri@ubuntu:~$ docker run -ti centos
[root@301fc721eeb9 /]# uname -a
Linux 301fc721eeb9 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@301fc721eeb9 /]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@301fc721eeb9 /]# free -h
total used free shared buff/cache available
Mem: 976M 85M 100M 12M 790M 677M
Swap: 1.0G 1.0M 1.0G
Docker — это не chroot, их функционал частично совпадает. Это не система безопасности вроде AppArmor. Docker использует те же контейнеры, что и LXC, но интересен он не контейнерами. Docker — это ничего из того, что я думал о нем до того, как прочитал документацию.
То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.
Docker — это инструмент объекто-ориентированного проектирования
Регулярно возникает вопрос, является ли конфигурация nginx частью веб-приложения. Системные администраторы спорят с разработчиками. Но недавно в мире появились devops и захотели вместо последовательно-процедурного вызова команд из bash думать привычным OOP. Docker дает инкапсуляцию, наследование и полиморфизм компонентам системы, таким как база данных и данные. Это значит, что можно провести декомпозицию всей информационной системы, выделить приложение, web-сервер, базу данных, системные библиотеки, рабочие данные в независимые компоненты, внедрять зависимости из конфигов, и заставить все это работать одной группой, одинаково на разных компьютерах.
Такой подход можно использовать, чтобы снизить потери рабочего времени дорогих front-end разработчиков на настройку базы данных и Nginx. Чтобы уйти от vendor lock-in. Не обломаться когда openssl на сервере не поддерживает cipher, используемый в API госучреждения. Чтобы приложение работало независимо от версии PHP или Python на сервере заказчика. Создавать open source не только в виде кода, но и настройкой пакетов из нескольких приложений, написанных на разных языках, работающих на разных слоях OSI.
Начало
Итак, я открыл docs.docker.com/mac/started, поставил Docker, выполнил несколько упражнений, и почувствовал, что меня держат за дурачка-двоечника, которого боятся перегрузить информацией. Первый вопрос: куда это чертов докер поставился, где лежат его файлы, в каком формате, как оно все устроено? Ответы здесь: blog.thoward37.me/articles/where-are-docker-images-stored
Если вкратце, для для работы с файловой системой Docker использует один из драйверов, обычно это AUFS, и все файлы контейнеров лежат в /var/lib/docker/aufs/diff/. В /var/lib/docker/containers/ служебная информация, а не сами файлы контейнеров.
Образы — это как классы в коде. Контейнеры — как объекты, созданные из классов. Основное отличие — контейнер можно закомитить и сделать из него образ. Образы состоят из так называемых слоев, слои — это папки, которые лежат в /var/lib/docker/aufs/diff/. Обычно образы приложений наследуют какие-то готовые официальные системные образы. Когда Docker скачивает образ, ему нужны только те слои, которых у него нет.
Например, скачаю я официальный образ nginx: hub.docker.com/r/library/nginx/tags
docker@dev:~$ docker pull nginx
latest: Pulling from nginx
aface2a79f55: Pull complete
72b67c8ad0ca: Downloading [=============> ] 883.6 kB/3.386 MB
9108e25be489: Download complete
902b87aaaec9: Already exists
9a61b6b1315e: Already exists
Пишут, что образ nginx 1.9.4 размером 52 мб, а по факту, у меня скачается всего 3 мб. Это потому, что nginx собран на образе debian:jessie, который у меня «Already exists». Есть много образов на базе Ubuntu. Конечно, стоит собирать свою систему из образов с одним предком.
Docker не исполняет контейнеры, а управляет ими
Контейнеры исполняются механизмом ядра под названием Cgroups. Служба docker запускает контейнер по команде, полученной от клиентского приложения (например, docker), и останавливает его когда в контейнере освобождается поток стандартного ввода-вывода. Поэтому в конфигурации Nginx для Docker пишут:
Be sure to include daemon off; in your custom configuration to ensure that Nginx stays in the foreground so that Docker can track the process properly (otherwise your container will stop immediately after
starting)!
Когда работа контейнера заканчивается, он не удаляется, если это не указать специально. Каждый за$ пуск контейнера командой docker run image_name без параметров --name или --rm создает новый контейнер с уникальным идентификатором, который остается в системе до удаления. Так что Docker — система, склонная к замусориванию. Имена контейнеров в системе уникальны. Рекомендую присваивать имя каждому создаваемому постоянному контейнеру, а контейнеры, в которых не нужно сохранять данные, рекомендую создавать с параметром --rm. Контейнеры создаются командами docker run и docker create. Посмотреть список всех существующих в системе контейнеров можно командой docker ps -a.
Docker — это клиент-серверная системная служба
Соответственно, Docker может и зависнуть. Если вы дали команду скачать образ, единственный способ прервать процесс скачивания — перезапустить службу. Авторы уже давно обсуждают что с этим делать, но воз и ныне там.
Например, в версии 1.8.1 есть воспроизводимая проблема:
docker@dev:~$ docker pull debian
Using default tag: latest
latest: Pulling from library/debian
2c49f83e0b13: Downloading [===================> ] 19.89 MB/51.37 MB
Нажимаю Ctrl-C, затем сразу запускаю скачивание повторно.
docker@dev:~$ docker pull debian
Using default tag: latest
Картина Репина «Приплыли». То есть, зависли. Надо перезапустить демон.
docker@dev:~$ sudo /etc/init.d/docker restart
Need TLS certs for dev,127.0.0.1,10.0.2.15,192.168.99.104
-------------------
docker@dev:~$ sudo /etc/init.d/docker status
Docker daemon is running
docker@dev:~$ docker pull debian
Using default tag: latest
latest: Pulling from library/debian
...
Status: Downloaded newer image for debian:latest
Бывает, что демон docker не хочет умирать самостоятельно и не освобождает порт, а init-скрипт пограничные случаи еще не отрабатывает. Так что не забывайте проверять sudo /etc/init.d/docker status, sudo netstat -ntpl, доставайте бубен и танцуйте.
Еще надо помнить, что порядок операторов для команды docker имеет значение. Если написать docker create nginx --name=nginx, --name=nginx будет считаться командой, которую надо выполнить в контейнере, а не именем контейнера.
Теперь вам будет проще разбираться с официальной документацией.
Продолжение: habrahabr.ru/post/267451 и habrahabr.ru/post/267455
Комментарии (99)
LighteR
22.09.2015 18:24+1То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.
А с чего вы взяли что пользователи разные?
kekekeks
29.09.2015 13:38-1В каждом контейнере свои /etc/passwd и /etc/group. Ну и права все локальны для контейнера.
LighteR
30.09.2015 01:07Ну и что с того, что там свой /etc/passwd? username содержащийся в /etc/passwd не более чем алиас к uid'у (аналогично и с группами), и username никак не участвует в пермишенах, для этого используется исключительно uid.
LighteR
30.09.2015 12:56Создайте в хост-системе пользователя foo c uid'ом 42, внутри контейнера создайте пользователя bar с таким же uid'ом и запустите из под него какой-либо процесс, затем в хост системе посмотрите список процессов, вы удивитесь, но с точки зрения хост-системы процесс будет запущен под пользователем foo.
BeLove
22.09.2015 20:57А расскажите про хранение файлов. Везде пишут — что они должны удаляться после остановки контейнера (и нужно создавать общую папку с хостом). Но я чекнул, создал файл, стопнул, стартанул — все на месте.
aml
22.09.2015 21:47+1При остановке контейнера данные не стираются. При полном удалении (а это вам нужно например, чтобы софт обновить) они теряются. Поэтому те файлы и каталоги, которые должны не теряться, надо при запуске контейнера монтировать с хост-системы как volumes.
nazarpc
22.09.2015 22:08При удалении, не остановке. Почитайте про data-only контейнеры и volumes, там есть некоторые нюансы, так же в документации вполне не плохо об этом написано.
К тому же в новых версиях Docker есть драйвера файловых систем, то есть можно делать распределённое хранение данных да и вообще много чего в этом роде.
alterpub
28.09.2015 12:27Я наткнулся на то что docker stop, осталяет данные; docker kill — убивает, если сделать docker commit, то docker kill уже не испортит данные.
Но правильнее поднимать контейнер без изменяемых данных, т.е. все что изменяется по уму маунтить из хост-системы.LighteR
29.09.2015 13:12+1Разница между docker stop и docker kill только в том, что stop посылает сначала SIGTERM, а потом SIGKILL (если процесс не остановился за указанное время), а kill сразу посылает SIGKILL. С данными это вообще никак не связано.
alterpub
29.09.2015 21:15-2Лучше быть практиком, чем теортериком, попробуй и удивишься
после docker kill, запустившийся контейнер будет пустым, после docker stop перезапущенный контейнер будет содержать изменения
grossws
29.09.2015 22:50У меня и в теории, и на практике docker kill не убивает fs контейнера. Если у вас это случается, то пишите багрепорт.
shuron
23.09.2015 00:11+2Очень понравился весь абзац включая заголовок
Docker — это инструмент объекто-ориентированного проектирования
Хотелось бы детальнее эту тему проработать?
Вы где-то наткнулись на это? Есть источник на английском? Или сами так придумали?
grossws
24.09.2015 02:03Если вкратце, у Docker несколько драйверов для работы с файловой системой, обычно это AUFS, и все файлы контейнеров лежат в /var/lib/docker/aufs/diff/. В /var/lib/docker/containers/ служебная информация, а не сами файлы контейнеров.
Давно не используется по умолчанию. Используется devicemapper + lvm thin pool.
Вообще по бэкендам хранилища у меня впечатления смешанные:
— dm — иногда не удаляет какие-то куски, имеет неприятное свойство постепенно раздуваться без возможности вернуть место (т. к. использует sparse файлы);
— dm с выделенными разделами под данные и мета — аналогично предыдущему, только не на loop-девайсах, а на реальных дисках;
— btrfs — имеет свойство внезапно заканчиваться место (особенно, если не прочитать заранее, как она обслуживается);
— overlayfs с ядра 3.18 (бэкпортированно 3.10 в centos7) — на docker 1.7 выглядит дико нестабильно, оверлеи не всегда отмонтируются корректно и т. п.
Сейчас использую btrfs, хотя и несколько опасаюсь. Стандартные volumes не использую, только bind. Прошло чуть меньше года, всё работает нормально, но btrfs требует периодического обслуживания.
grossws
24.09.2015 02:08Контейнеры исполняются механизмом ядра под названием Cgroups. Служба docker запускает контейнер по команде, полученной от клиентского приложения (например, docker), и останавливает его когда в контейнере освобождается поток стандартного ввода-вывода.
Процесс в контейнере исполняется, как любой другой процесс в linux. Другое дело, что для контейнера создаются нужные namespaces (netns, utsname, pid, ipc), а также создаются и конфигурируются контрольные группы (cgroups), которые ограничивают потребление ресурсов, управляют шедулингом и т. п.
grossws
24.09.2015 02:11+1Соответственно, Docker может и зависнуть. Если вы дали команду скачать образ, единственный способ прервать процесс скачивания — перезапустить службу. Авторы уже давно обсуждают что с этим делать, но воз и ныне там.
После нажатия ctrl+c у вас отваливается клиент к докеру, т. к. словил SIGHUP. Образ продолжает качаться. И, если вы пытаетесь запустить docker pull того же образа повторно, то он будет висеть в ожидании, пока сервер не скачает этот образ по команде, полученной при предыдущем запуске docker pull.
mafonya
29.09.2015 17:10Был на нескольких митапах Гугла, по теме их Google Cloud Platform. Так вот они говорят, что у них давно все только на контейнерах работает и настаивают на том, что Kubernetes это все, что нужно.
По большому счету идея не новая, но хорошо, что buzz расходится и все больше компаний используют технологии контейнеров.
icCE
Ох, в общем как и на недавней конференции events.yandex.ru/events/yagosti/19-september-2015-linux, вы меня не убидили в нужности докера. Особенно если есть уже инфраструктура на OpenVZ/LXC.
В некоторых моментах пслд намного удобнее, например при работе с сетью. Проект Criu приносит свои плюшки. Можно сказать, что OpenVZ просто опоздал с такими модными плюшками как Docker Hub и DockerFile.
Если поднимать с 0, возможно удобно, если уже все готово — то просто модное веяние.
Antti
Разница в том, что OpenVZ/LXC и их друзья — это для сисадминов, а docker и всякие kubernetes — для программистов/dev-ops.
В первом случае — оперируют понятием сервера, контейнера, в другом — архитектурой приложений, платформой для запуска приложений, то есть еще больше абстрагируются от физических серверов/систем.
То чем заняты админы openvz/lxc, в docker дается практически задаром, это как раньше админили физические серверы в серверной, настраивали каждый кто как мог, а сейчас — все автоматически, «в облаках».
icCE
Я бы с вами согласился, если бы докер мог использовать минимальное окружение для запуска приложения. По сути он так может и были тут уже статьи по минимальному докеру, но дается это тяжело.
еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки.
Сильно они опоздали и с открытием ядра итд итп.
JC_Piligrim
> еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки. Сильно они опоздали и с открытием ядра итд итп.
А вот я не считаю, что они «просто» опоздали. Похоже, что если бы не докер, то хрен бы они почесались, чтобы сделать всем нам лучше. Хоть какая-то оживлённая конкуренция появилась. Веет от этой истории теми же мотивами, по которым Microsoft (как и любая другая — компания по выжиманию денег откуда только можно) открыла .NET и сделала полноценную шаровую версию Visual Studio (!). Никто не хочет умирать, когда можно жить и зарабатывать.
icCE
Они там закапались с переносом функций из своего ядра в ванильное. По сути LXC и Docker используют общие наработки.
OpenVZ как по мне вообще держится на двух людях, на Павле и Кирилле.
amarao
Программисты абстрагируются-абстрагируются, абстрагируются-абстрагируются, а потом внезапно продакшен и со всем этим г-ном должны разбираться как раз сисадмины. А оно к продакшену не готово «как миллион пакетов в секунду через интерфейс пришло?» «а откуда столько зомби в системе?», а программистам пофигу, потому что у них объектное проектирование и проблемы негров их не волнуют, а они все д'Артаньяны с докером, а вокруг ужасные сисадмины со своим противным LXC, лучше докер, потому что «у меня на ноутбуке всё работает, как же оно может не работать на ферме из сотни серверов под нагрузкой?».
Ну и в финале «а как сделать так, чтобы данные из postgres не терялись при остановке контейнера?». В продакшене. Месяца через 4 после запуска.
VolCh
Или замечательные сисадмины создают новый голый виртуальный сервер (или несколько) для продакшена из своих заготовок, дают ужасным программистам рут доступ и говорят «как хотите так и обеспечивайте разворачивание и обновление среды исполнения, самого приложения и его баз, хоть по F5 в mc копируйте, только скажите можно ли снэпшоты снимать для бэкапов, а если нельзя, то расскажите как консистентные бэкапы делать».
Ingtar
А с докером такого не будет?
VolCh
Будет. Но ручками ужасным программистам только докер установить нужно будет.
lazycoder
Какие программисты — такие и проблемы. Если у человека не возникает вопроса о том, где хранятся файлы базы из контейнера, то это не проблема докера, так ведь?
Как раз для таких людей существует куча проектов, типа этого: github.com/sameersbn/docker-postgresql, там есть специальный раздел Persistence.
Простота использования, конечно, развращает, но это не значит, что нужно теперь пользоваться чем-то более замороченным, чтобы дисциплинировало. Нужно просто вопрос изучить. И когда он изучен, то при помощи современных сервисов можно сисадмина вообще исключить из цикла проектирования и поддержки инфраструктуры, во всяком случае до тех пор, пока она достаточно тривиальна.
VolCh
Прежде всего вопрос «а где хранятся файлы базы» должен возникать у админа, чтобы хотя бы бэкапы делать.
Ingtar
Пока что из опыта (не очень большого)
— Нужно выкатить в продакшен вот это!
— А как тут…
— У нас сроки горят, нужно сейчас!
— Да, но ведь…
— Все согласовано и утверждено, ты хочешь сейчас все отметить, сорвать, убытки…
— …
И получается что через 4 месяца я сижу и думаю, как бы это все выкаченное хоть как-то привести в нормальный вид без простоев и ошибок
amarao
А программисты как раз хорошие — им алгоритмы придумывать, а не вопросы персистентности данных решать.
Таким образом, продакшен из кода — это большей частью забота devops-админов и программистов, специализирующихся на software engineering. Но в этом случае devops админы хотят иметь нормальные среды выполнения и поменьше докеризмов.
bhavenger
Зачем вообще постгрес держать в контейнере? В чем глубинный смысл? Версию бд все-равно без танцев с бубном не обновить.
amarao
Потому что программистам всё нравится держать в докере, а если решения по деплою оказываются целиком у программистов, то на выходе мы получаем вот такое. Или даже хуже. (Я не на программистов гоню, просто это не совсем их работа).
shuron
О DevOps слышали?
amarao
Слышал и по жизни занимаюсь. Повторю: это не работа программистов. Кооперация — да. «Свалить на программистов» — нет.
shuron
Кто на кого сваливает в контексте DevOps. Поясните?
shuron
Потомучто когда вы начнаете работать с контенерами это левел 0.
Левел 1 это конда вы отдате контейнер облаку и оно сомо знает где его запустить и к чему подвязать…
В контеэнрном облаке, нет других сущностей просто…
shuron
Ну и что минус. За грамматику? Блин пардон транслитом пишу...:(
bhavenger
Если у вас НЕ высоконагруженный сервис — вы конечно можете отдать весь low-level на откуп «контейнерному облаку».
Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
VolCh
Кто «мы» должны это понимать? Прикладные разработчики, системные администраторы, мифические девопс-инженеры?
bhavenger
Тот, кто отвечает за работу приложения в продуктивной среде.
Как эта роль называется в конкретной компании\команде — не суть важно.
Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.
VolCh
На практике (да и в теории) это минимум две роли: админ не может отвечать за ошибки разработчика (например, синтаксические), а разработчик не может отвечать за ошибки админа (например, «планомерно» закончилось место на дисках).
По многолетнему опыту в средне-мелком бизнисе, как минимум один из них должен вникать в нюансы деятельности другого.
shuron
Обозначьте теорию о котой пишите…
Еще раз в этом треде
habrahabr.ru/post/267441/?reply_to=8592751#comment_8591771
О DevOps не слышали?
VolCh
Например, общероссийские классификаторы должностей и занятий.
Слышали — где-то там в крупных ИТ-компаниях. Речь же о мелко-средних не ИТ-компаниях.
shuron
Культура DevOps не особо привязана к размеру компаний. Она больше привязана к Agile. И эта тематика скорее в мелких и средних компаниях на западе фрсируется… Большие (не считаем Гугл и Фейсбук — у них думаю все нормально) не дотепали по мнигим причинам…
У меня западный бекграунд в IT
VolCh
Может у меня неправильное представление о DevOps, но как-то слабо представляю, что в средней компании человек на 300-500, среди которых айтишников человек пять, край — десять, будет пара людей, выделенных на техническое обслуживание процессов разработки и доставки.
shuron
Скорее всего не верное представление…
Дело не втом что кто-то выделено…
Первым делом это преодаление барьра между Опс и Дев который образовался из-за всех этих ролей в энтерпрайз деве…
Дело не в том что какие-то новые задачи… А в организации команд по решению этих задачь…
Тоесть если есть 10 айтишников то они не будут поделены функцонльно на команды Операйшнс/ Девелоперс/Тестерс.
А ориентированынно на Клиента, тоесть например:
Команда 1 (Продукт «електронный огурец»)
— 2 бывших бекэкнд кодера
— 1 бывший фрондэдшик
— 2 бывших админа…
— 1 бывший тестировщик…
-Команда 2 (Продукт «електронный огурец»)
Сервис «Все для клиента»
-3 бывших девелопера
-1 бывший админ
-1 продавец
-1 чувак разбирающийся в аналах домены.
Это не значит что фрондэщик начинает настраивать сеть постоянно… Но это может вполне означать что он начнет сам статический контент выкатывать и конфигурить лоадбэленсер к примеру…
И т.д. коммуникация совсем другая… И видимость… Вдруг выясняется что то что считал обязательным админ совершенно не интересно девелоперам и клиенту а и т.д. очень мощно может поменять Time To Market
Ведь заданиай не изменились и человеческие ресурсы не изменились…
Просто меняется их организация вокруг целей… а этим приоритеты и качество…
P.S. Комманда 2 — это уже может быть даже из Customer Oriented Development
shuron
Мы на прошлой неделе решили полностью расформировать (по мне так уж давно) команду админов, они интгрируйтуся сейчас активно в Продакт-Команды…
Компашка 50 человек. Из них 25 ДевОпс-ников :) ).
Ingtar
Из опыта в меньшей группе (5 человек), могу сказать что получилась у нас фигня.
shuron
Бывает… :)
У нас чуваки из совка удаленно работали, работали… Так и не вьехали что такое agile.
В итоге закрыли этот бранжн нафиг… Несмотря на «дешевизну» раб силы…
shuron
x
shuron
Простите, но вы похоже не близки к теме просто…
Действительно высоконагруженые сервисы без облака нынче не мыслимы…
Контейнеры вам никак не мешают понимать что-то… ;)))
И да вам совершенно не нужно строить «сложные сервисы». Они ничем не оправданы. Очень похоже на Accidential complexity
С чего вы это взяли? Бред же… Это уже давно стандарт ;)
bhavenger
Если вы внимательно прочитаете мой коммент — вы не найдете противоречий со своим.
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Я все правильно понимаю?
shuron
Именно! Точно так. ;)
bhavenger
И это вполне себе коммерческое облако и я тоже могу прийти со своим контейнером — и мне будет всё тоже самое?
Можете подсказать название этого облака?
shuron
Да любое… Если все в коробке то к примеру
cloud.google.com/container-engine
www.tutum.co
Но (ИМХО) пока лучше инвестировать немного самому…
Это несложно, но надо проникнутся…
Начать надо с распределенной конфиги и сервис-дискавери… В этом плане офигеннен Consul habrahabr.ru/post/266139
Если клауд не предлагает достаточный лоадбэленсер создате свой «умный» контейнер который слушает такие эвенты…
И т.д. В начале вам скедулер может и не нужен будет.
Но поидее лучше сразу делать… тут много вариантов… опенсорсных
Поидее github.com/kubernetes/kubernetes уже все что нужно интегрированно приносит с собой…
Но иногда имеет смысл итеративо посторить фичи
Вот тут была серия про эти дела к примеру
habrahabr.ru/post/262397
bhavenger
Я вас к тому и веду. ВНЕЗАПНО выясняется, что для того, чтобы облако это умело — системным инженерам нужно позаботиться о паре _небольших_ вещей. Сервис дискавери, распределенные конфиги, автоматика переключения, автоматика деплоя, работа с лоад балансером, очередями. Репликация, бэкапы, отказоустойчивость на уровне датацентров.
Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
shuron
«системным инженерам» у нас к примру роли такой нет ;)
Да не нужно вам ни очем заботится… Это же фетишь вы сами или ваша огранизация придумала. Это я вам проилюстрировал миграшн сценарий что-бы вы не выпускали ничего из рук если вам очень хочется… ;)
Берите Контейнер-Энжин Кибернетовскую и вперед… все из коробки ;)
cloud.google.com/container-engine
bhavenger
Ну вот например настройка лоад-балансера в container-engine — https://cloud.google.com/container-engine/docs/tutorials/http-balancer.
Нет здесь сценария
Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
shuron
Что вас смущаесть что Лоадбэлэнсеру надо дать конфигу что бы он знал какие сервесы включать в лоадбеленсинг?
Аннотировать лейблами приритете сервицсов к ресусрасм типа ram, cpu, ssd, кастом?
Опишите ваш сценарий.
shuron
Да причем тут это вы каждый раз что-то новое вбрасываете к вашему начальному вопросу
Вы инициально спросили зачем в контенер пихать БД… Я вам обьяснил что это может вполне иметь смысл и обьясняется не только «модой» на докер.
То что Докер не панацея и так понятно.
VolCh
Перенести на другой хост с минимумом танцев?
bhavenger
В случае с бд — минимум танцев — это реплика на другой хост с последующим переключением. Докер тут не нужен от слова «совсем».
Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
VolCh
Реальная практика — 50% запросов на реплику фэйловерятся на мастер из-за запаздывания больше 1 секунды — бизнес-требование. В случае падения сервера БД контейнеры (не важно по какой технологии) позволяют переключиться на новый инстанс на другой железке «одним кликом» или одним скриптом какого-нибудь заббикса, гарантируя (в разумных пределах) что клиенты не заметят переключения.
Слабо представляю проблемы, которые могут возникнуть при увеличении доступных физических ресурсов. Можно хоть пару примеров?
Ну да, абсолютной изоляции вроде никто не может обеспечить. Но кто обеспечивает лучшую за ту же цену?
bhavenger
По-прежнему не понимаю, как у вас контейнеризация позволяет быстро менять железные хосты под бд. Но предположу.
Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
Если я ошибаюсь — то поясните пожалуйста, интересно.
Два кейса из тестовой инфраструктуры:
Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.
Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
vektory79
Как уже отметили выше, Docker — инструмент разработки в первую очередь. Т.е. вместо инсталлятора/архива с приложением и длинной документацией по настройке и запуску, админ получает от разработчика уже полностью готовый к запуску образ. Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
И да, это не в коей мере не замена OpenVZ/LXC. Они могут даже сожительствовать в ряде случаев.
past
Это все супер. Одного не могу понять, как это все обновлять?
auine
Через Docker Hub. Докачиваются новые слои или обновленные, и готово.
Ingtar
А можно мне на примере?
Вот у меня есть три полноценных контейнера с php+php-fpm, mysql и rabbitmq + поверх этого живет нормальный железный сервер с nginx (фронт)
Если мне нужно это все поднять докером, и потом обновлять по мере необходимости.
Первоначальная настройка понятно — машина с php+php-fpm, mysql, rabbit, все настроили, пошли данные.
Mysql и rabbitmq мы не будем обновлять скорее всего никогда, там данные внутри. Они же потеряются при обновлении докер контейнера?
Обновление пхп — собрали образ, задеплоили в репозиторий, оттуда на хост.
Все верно?
nazarpc
Не совсем, это будут отдельные контейнеры, и настройка будет скорее всего в самом образе контейнера, либо автоматически при первом запуске, то есть всё автоматизируется по максимуму.
Вот посмотрите как у меня сделано: github.com/nazar-pc/docker-webserver
Там только один data-only контейнер, остальные все stateless приложения, к которым подключается data-only контейнер чисто для данных. Скачиваете новые образы, и за несколько секунд перезапускаете всё с теми же данными, но более новыми версиями приложений.
Обновления PHP, MySQL/MariaDB и многих других можно вообще получить практически даром, в Docker Hub есть официальные образы, если вы наследуете свои образы от их образов — то с легкостью можно настроить триггеры, которые при обновлении официальных образов запустят сборку ваших. То есть вам останется только загрузить новый непосредственно у себя на сервере (что тоже можно автоматизировать).
past
Отличный репозиторий, многое прояснилось. Подскажите как зайти по ссш, пхпадмин? Как сменить пароли?
nazarpc
Там есть информация в readme.
Вкратце:
SSH — добавляете ключ как написано в readme, парольный вход отключен
PhpMyAdmin — пользователь root, пароль в /data/mysql/root_password, генерируется случайный при первом запуске.
Так что никаких паролей из коробки захардкоренных нет, все Dockerfile открыты, сборки образов автоматизированы и отражают состояние репозитория.
VolCh
А подразумевается, что это всё на одном хосте будет крутится? Я как раз в изучении докера на этом споткнулся — локально всё работает связно, а вот с деплоем хотя бы БД на отдельный хост непонятно как быть.
grossws
Посмотрите на flannel/weave — они реализуют оверлейную сеть. Насколько всё хорошо/плохо с производительностью — хз.
Flannel, например умеет как энкапсулировать в udp (т. е. трафик гонится через usespace), так и в vxlan (тогда в user space только control plane, а данные летят, как максимум в kernel space или вообще обрабатываются аппаратно, если сетевуха поддерживает).
nazarpc
Есть Docker Swarm — с его помощью целый кластер машин с Docker выглядит как один Docker хост, а сами контейнеры запускаются там, где есть нужные ресурсы.
Есть flocker — это отдельный драйвер для томов Docker, поддерживает миграции и многие другие вещи.
В следующей версии зарелизится продвинутая сетевая подсистема, где тоже нативно и легко будут строиться оверлейные и сторонние сети как flocker для томов с данными, только для самой сети, пока система линков не настолько гибкая.
В целом всё очень неплохо, а инструментов появляется всё больше и больше.
Есть ещё kubernetes, но для меня он пока слишком замороченный, там более продвинутое управление квотами в рамках кластера.
kekekeks
Берёте Dockerfile, меняеете версии зависимостей, пересобираете образ. Всё. Относительно mysql/rabbitmq — используйте специальные образы, которые хранят данные вне контейнера, в подключаемой директории хоста.
grossws
То говно, которое впилили для официальных образов — пшик.
grossws
Судя по тому, что обсуждается в registry api v2, возможно, станет получше. Ещё подробно не разглядывал. По первому впечатлению, appc и rkt повлиял на них сугубо положительно.
auine
Что значит плохой совет лол. Это так работает докер. С безопастностью у него все отлично. Большинство контейнеров запускается без бинда на внешние порты, и общаться могут только с линкованными к ним контейнерами по этому этот рут внутри, как-то побоку. Если вы не способны обеспечить свою сеть безопастностью, итс ё фолл))
grossws
Контейнеры по умолчанию имеют доступ наружу. Через nat с docker0, если что.
Не говоря уже о том, что namespaces пока активно развиваются c ~2008 года и уязвимостей в ядре может быть выше крыши (на некоторые баги в ядре, касающиеся netns я уже нарывался на centos6 и centos7).
Ещё забавно, большое количество контейнеров, требующих прокидывание /var/run/docker.sock внутрь контейнера, что, очевидно, даёт права на запуск любых контейнеров.
grossws
Ещё, о птичках: CVE-2015-3629:
SamDark
Разработчика тыкать палочкой. Это не для продуктов. Это для бессрочных проектов с штатом.
icCE
Можно сделать свой собственный dockerhub и поддерживать обновление. Это несомненно плюс.
В OpenVz есть механизм забора image, но его надо допиливать руками.
icCE
>Т.е. вместо инсталлятора/архива с приложением и длинной документацией по настройке и запуску, админ получает от разработчика уже >полностью готовый к запуску образ.
В OPenvz/lxc неожиданно образы.
>Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
Ну не сразу, надо поставить docker.
Собсвтенно после установки openvz, вы так же можете сразу использовать контейнер с вашим ПО.
Да бы не схватить кучу минусов, я не имею ничего против докера. Наоборот это хорошо и отлично, что он поднял много шума вокруг виртуализации и вообще в тренде. Я реально хочу понять, как оно в моем случаи поможет жить?
DockerHUB? я не использую публичные вещи, я старпер и все передпочитаю делать руками сам. Я не знаю, что и кто там приготовил в image.
DockerFile? Отлично, я это все так же решаю ansible/chef/puppet.
Единственный плюс, это свежие ядро и все в ядре в отличие от openvz. Но можно смотреть и на LXC, правда с урезанным функционалом.
То, что openvz может в себе запускать докер через костыли, прекрасно.
PerlPower
Тоже не могу понять в чем причина популярности докера. Вот если бы только 3-5 человек взяли и написали почему им было плохо, и почему докер сделал им хорошо. И желательно чтобы было указано какой размер команды. И насколько сложен проект.
vektory79
Возможно вам сюда
vektory79
Ну что-ж значит за вас можно порадоваться. А нам не хватило. По этой причине вынуждены искать более гибкие решения. Вот сейчас пытаемся приспособить докер и он нам пока нравится гораздо больше.
В подробности вдаваться нет необходимости, т.к. всё очень похоже на то, что было озвучено в докладе, ссылку на который привёл чуть ниже.
grossws
Я с нетерпением жду стабилизации appc+rkt. Товарищи из CoreOS сразу пошли от проблем докера, которые вскрылись в процессе его эксплуатации. И они, конечно, положительно влияют на docker наличием реальной и ощутимой конкуренции. Не в обиду openvz, но у docker'а в плане UX для разработчика всё куда приятнее.
vektory79
Это да. Если речь идёт об исключительно админских задачах (установка и настройка стороннего софта), то разницу сложно так просто заметить. Но если нужно разрабатывать и поставлять собственный продукт, особенно на большое количество целевых серверов, то OpenVZ — это даже не смешно…
У нас тех поддержка уже на 20 клиентах начала потихоньку захлёбываться, а это только начало. Так что сейчас стараемся поскорее разобраться с докером. Да он не без недостатков. Но, всё же, гораздо удобнее под наши задачи.
amarao
А этот образ кроме того, как запускаться, ещё и работать нормально умеет?
VolCh
А что имеете в виду под «нормально»?
amarao
Полный список будет весьма значительным, но если утрировать, то на уровне того, что получается после apt-get install и настройки для обычного софта из состава дистрибутива.
VolCh
Грубо говоря, сам образ и есть указание на официальный образ дистрибутива (типа partner-images.canonical.com/core/trusty/current/ubuntu-trusty-core-cloudimg-amd64-root.tar.gz), последовательности apt-get (или make ) исполняемых после его разворачивания, и указаний дефолтных точек входа и выхода — томов, портов и т. п.
Или вы про саму libcontainer и его обвязку?
В любом случае, конечно, будут новые баги по сравнению с официальным дистрибутивом развернутым на голом железе, но вот если сравнивать с другими технологиями виртуализации, то их количество должно быть одного порядка.
alterpub
Тут есть один маленький, но очень неганивный нюанс, часто девелоперы думают что они знают как должно работать на уровне системы то или иное, но на самом деле это совсем не так, в результате к контейнеру, который пришел от разрабов доверенности у хорошего админа должно быть чуть менее чем 0, поэтому выкатывать в продакшен что-то что пришло от разрабов в готовом контейнере я бы не рискнул никогда. Без обид, но практика показывает что это правда.
vektory79
Ну практика вообще очень разнообразная вещь.
У нас получается так, что полной и исчерпывающей компетенции нету ни у тех ни у других. Кто-то знает одно, кто-то другое. И нужно обеспечить возможность, чтобы каждый мог крутить свои ручки.
И ещё: если между админами и разработчиками не налажен диалог, то тогда не спасёт вообще ничего. Всегда нужно согласовывать свои действия. А если попытаться свалить ответственность за всю настройку на кого-то одного, то получается ерунда.
alterpub
Я не совсем об этом, коммуникации это хорошо, но вот разрабы передают контейнер, в нем есть какое-то ПО, это ПО это не обязательное веб-проект на пхп, это может быть томкат, где гарантия что в нем все верно настроено? Это может быть не веб вообще, а еще это ПО может зависить от системных настроек(ядро, лимиты и т.п.), т.е. в принципе какая бы хорошая коммуникация не была, но в продакшен выкатывать проект от людей, которые не понимают бОльшей части нюансов не стоит.
В тоже время контейнеры на стендах и в разработке должны быть очень хороши.
Мне, например, контейнеры сильно помогли в сборках deb пакетов, если надо убедиться что пакет ставится со всеми нужными зависимостями на голую ОС, то это идеальный вариант, просто запускаешь Dockerfile, правишь пакет и запускаешь снова, быстро и просто.
С другой стороны можно некоторые вещи делать наоборот, например админ собирает контейнер с системой, содержащей нужные настройки и передает разрабам, а они свой проект запускают уже внутри. при таком раскладе они будут тестировать ПО в окружении идентичному боевому.
vektory79
Во-о-от! А если ещё вспомнить про то, что докер может наследовать одни образы от других. То и получается следующая картина:
Каждый делает свою работу. И всем хорошо.
Ingtar
Уж не знаю, вы это были или нет, но с кем-то я соглашался на этой встрече по поводу мыслей о докере, что все хорошо в меру :)
icCE
Скорее всего я :)