Комментарии 44
Мне кажется, что для работы с такими связками сервисов типа nginx+php-fpm или подобного имеет смысл использовать docker-compose. Пишется простенький yaml-файл, затем
docker-compose up
, и всё, сервисы запущены и соединены.+6
Я не хочу загромождать тему. Будет и про mysql, и про compose.
0
Не получится ли с такой мелкой нарезкой на серии повторение проблем документации на докер — попали на страницу из гугла, увидели простейший пример, скопипастили, а до docker-compose и data volumes так и не добрались никогда?
+5
Что делать, habrahabr не позволяет структурировать материал. Здесь много чего не хватает.
Читайте на gitbooks
Читайте на gitbooks
-1
Можно делать в каждом посте оглавление вручную — так, например, оформлена серия постов про vim-библиотеку юзера Delphinum.
+1
Вот если взялись объяснять технологию, то хотя бы best practices прочитайте. Не нужно ничего копировать в контейнер, нужно создавать Dockerfile. Не нужно монтировать директорию $(pwd), нужно создавать data volume container. И про docker-compose вам правильно написали.
+4
«Не читал, но осуждаю» :) Прошлая статья серии — об этом.
-2
У вас ссылка «начало» ведет на другую статью, а на вот эту habrahabr.ru/post/267451 вообще невозможно попасть. К сожалению, у меня не так много времени, что отлеживать все ваши публикации. И если вы знаете, что так делать нельзя, то зачем пишите? Или вот там же пишите про композицию. И как вы её в докере будете делать, эту композицию?
+1
Самый странный способ неправильного использования docker, что я видел. Я бы не называл это «рецептом Docker» но анти-рецептом. Вместо вменяемого создания Dockerfile автор всю кастомизацию стандартных контейнеров делает через volumes. То, что после этого контейнер будет прибит гвоздями к именно этому хосту видимо его не волнует. Причина этих странных телодвижений видимо должна быть понятна из habrahabr.ru/post/267451, но я не в состоянии ее понять. Единственное, что я смог там увидеть, это ошибочная уверенность автора в том, что при обычном, вменяемом использовании контейнеров и расширения иx функциональности для себя конвенциональными способами, надо «заплатить за хранение на Docker Hub».
+7
Способ полностью противоречит документации. Нет никакой ложки.
1. Официальные образы docker — аналог rpm/dev, собирать приложение в одном образе с runtime — аналогично сборке php, nginx, mysql и приложения в одном rpm. Сделать можно, но никто так не делает.
PHP, Nginx, MySQL удобно ставить из официальных репозиториев, и подключать свои конфиги, чтобы этот официальный пакет без проблем обновить. Аналогично, я хочу ничего трогать в официальных образах.
2. Когда мы собрали свой образ, мы можем сделать или save, или push. Если сделать save образу, созданному на базе nginx — дамп будет весить пару сотен мегабайт. Раздавать это в команде некомфортно. Если мы делаем push — мы выкладываем наш код всему миру, что для серьезных проектов недопустимо.
Третьего способа передать наш образ на другой компьютер не существует. Ошибочность, к сожалению, не у меня.
1. Официальные образы docker — аналог rpm/dev, собирать приложение в одном образе с runtime — аналогично сборке php, nginx, mysql и приложения в одном rpm. Сделать можно, но никто так не делает.
PHP, Nginx, MySQL удобно ставить из официальных репозиториев, и подключать свои конфиги, чтобы этот официальный пакет без проблем обновить. Аналогично, я хочу ничего трогать в официальных образах.
2. Когда мы собрали свой образ, мы можем сделать или save, или push. Если сделать save образу, созданному на базе nginx — дамп будет весить пару сотен мегабайт. Раздавать это в команде некомфортно. Если мы делаем push — мы выкладываем наш код всему миру, что для серьезных проектов недопустимо.
Третьего способа передать наш образ на другой компьютер не существует. Ошибочность, к сожалению, не у меня.
-4
А теперь как оно на самом деле:
1. Официальные образы это всего лишь образы, никакой особой мистики в них нет. Они могут кому-то подойти «как-есть», кому-то послужить базовыми а кому-то как источник информации о том, как сделать нечто свое из них.
2. Когда мы собрали свой образ то ему можно сделать push. Но его вовсе не обязательно делать в публичный или даже приватный docker hub. Поднимаем docker-registry и пушим туда, как все нормальные люди, которым надо приватный репозиторий для докера.
3. Кроме того, когда сборка включает в себя все, что надо и Dockerfile является тем, чем он обычно является, ничего не мешает раздавать не образ, но именно этот самый Dockerfile с тем, что надо для его сборки. Это прекрасно сохраняется в любой системе контроля версий.
1. Официальные образы это всего лишь образы, никакой особой мистики в них нет. Они могут кому-то подойти «как-есть», кому-то послужить базовыми а кому-то как источник информации о том, как сделать нечто свое из них.
2. Когда мы собрали свой образ то ему можно сделать push. Но его вовсе не обязательно делать в публичный или даже приватный docker hub. Поднимаем docker-registry и пушим туда, как все нормальные люди, которым надо приватный репозиторий для докера.
3. Кроме того, когда сборка включает в себя все, что надо и Dockerfile является тем, чем он обычно является, ничего не мешает раздавать не образ, но именно этот самый Dockerfile с тем, что надо для его сборки. Это прекрасно сохраняется в любой системе контроля версий.
+5
1. аналогично rpm и deb. Кто-то собирает свои пакеты, кто-то ставит официальные. Собирайте, поддерживайте свои, я не против.
2. приватный репозиторий сделать можно, но надо заплатить :) О том и речь. У нас же не магазин на битриксе, а несколько микросервисов, и каждому нужен репозиторий. Мы же облачное масштабируемое приложение обсуждаем?
3. Да, можно поднять registry. Можно настроить Vagrant. Можно работать образами виртуальных машин и забыть про docker.
Я не проповедь читаю ;)
2. приватный репозиторий сделать можно, но надо заплатить :) О том и речь. У нас же не магазин на битриксе, а несколько микросервисов, и каждому нужен репозиторий. Мы же облачное масштабируемое приложение обсуждаем?
3. Да, можно поднять registry. Можно настроить Vagrant. Можно работать образами виртуальных машин и забыть про docker.
Я не проповедь читаю ;)
-3
Я дал ссылку на docker-registry, за него не надо ничего платить. То, что вы показали это их сервис для корпораций. По моей ссылке есть простая и ясная инструкция, как поднять registry у себя. Ну вот еще одна, которая прямо так и называется «Deploying a registry server».
И при чем тут «когда приложение в hub»? Что мешает сделать build без хаба из своих исходных Dockerfile?
И при чем тут «когда приложение в hub»? Что мешает сделать build без хаба из своих исходных Dockerfile?
+5
хмм, это как минимум «неспортивно» редактировать свой ответ после того, как на него пришел комментарий. Я даже удивлен что хабр такое позволяет. И нет, «и каждому нужен репозиторий» это ерунда. Ну на самом деле, стоит почитать про docker registry а не придумывать себе что оно такое и станет понятно, что он нужен один, а не на приложение.
+2
Я не состязаюсь, простите, но мне все равно прав я или нет. Если у вас есть вопрос — я могу пояснить. Могу забить :)
Эта заметка не про registry, не про compose, не про swarm. Могу написать о registry отдельную заметку.
Эта заметка не про registry, не про compose, не про swarm. Могу написать о registry отдельную заметку.
-5
у меня нет вопросов и я знаю ответы. Единственная цель моих комментариев это оградить незрелые в докер умы, от вредных советов.
+3
лучше всего — напишите свою статью как правильно и запостите здесь ссылку на нее
-5
лучше всего вы не пишите, а идите читайте доки, думайте мозгом, набивайте шишки на реальных задачах, пробуйте и иксперементируйте, и избавляйтесь от своего чсв (я слышал что выкидывание макбука в окно неплохо помогает). Потому как уже и сказал umputun для неопытного ваши статьи сделают только плохо, для тех кто разобрался неплохое развлечение их почитать но не более того.
+1
Сделать build из своих исходных Dockerfile на другом компьютере мешает необходимость дополнительных телодвижений: или передавать отдельно свое приложение, или поднимать registry, или платить.
-2
Каких таких телодвижений?
0
Вы предложили настраивать и поддерживать внутренний registry. Это значит, что надо решать проблему SPOF этого registry, а именно: организовывать бекап его данных, мониторить, делать репликацию, чтобы не останавливать выкладки. Нужны все обычные телодвижения для дополнительного сервиса в полноценной инфраструктуре.
-2
Достаточно навести порядок с версиями (читай — системами контроля версий) и даже если вы «потеряли» свой registry, то восстановить его не проблема.
Да и вообще, вся соль докера в том, что даже бэкап реестра билдов (ежели таков необходим) вам провернуть очень просто.
Можно вопрос, а вы программист?
Да и вообще, вся соль докера в том, что даже бэкап реестра билдов (ежели таков необходим) вам провернуть очень просто.
Можно вопрос, а вы программист?
+3
докер регистри (или distrubution нынче) поднимается все в том же контейнере, дата волумы бэкапятся на раз, а в силу распределенного характера можно и вовсе бэкапы не делать, так как даже если что-то слетит, просто можно с серверов где эти образы задеплоены попушить обратно в докер дистрибьюшен. Собственно так же как и с git.
Расходы на поддержание инфраструктуры для докера в принципе не особо велики, по сравнению с профитом который он дает.
Расходы на поддержание инфраструктуры для докера в принципе не особо велики, по сравнению с профитом который он дает.
+1
И все же. Что конкретно вам мешает?
Сделать build из своих исходных Dockerfile на другом компьютере мешает необходимость дополнительных телодвижений
0
Необходимость передавать на другой компьютер отдельно Dockerfile и само приложение. Я предпочитаю передавать один маленький .tar.xz, и из него одной командой разворачивать работающую систему с базой, веб-сервером, runtime, библиотеками и конфигами.
0
Почему, если так не хочется поднимать registry, не использовать docker save/load и при этом все-таки делать кастомизацию через Dockerfile (который можно версионировать)? Проблема в размере?
0
Я правильно понимаю что вы используете Docker исключительно для dev окружения, то есть вы не билдите контейнеры и не деплоите их на сервер… то есть… это такая вот странная замена Vagrant? Зачем вам докер тогда? С тем же успехом можно было бы взять vagrant + ansible и вышло бы удобнее в плане поддержки. Весь профит докера в управлении инфрастуктурой, версионизации, возможность уже проверенную на стэйджинге инфрастуктуру без изменений и быстро выкатить на прод например. А с таким подходом этот профит теряется. А что до разработчиков, те из них что сидят на маках будут слегка грустить, ибо что бы добиться производительности файловой системы нормальной приходится много поплясать с бубном для того что бы настроить хотя бы NFS.
0
Знаете, docker начал использовать совсем недавно, собрал на его основе среду для сборки деб-пакетов. Главное, но не единственное, конечно же, что понял из штудирования информации за десяток часов: «Use DOCKERFILE, Luke»
Всё то, что Вы делаете (docker cp, docker foobar |, docker foobar >) как то вызывает вопрос: мы одну литературу читали?
Судя по комментариям, не просто так у меня возникают такие вопросы. Рейтинга статей тоже символизирует. Про обещанную оркестрацию в гитбуке ничего не нашёл.
Всё то, что Вы делаете (docker cp, docker foobar |, docker foobar >) как то вызывает вопрос: мы одну литературу читали?
Судя по комментариям, не просто так у меня возникают такие вопросы. Рейтинга статей тоже символизирует. Про обещанную оркестрацию в гитбуке ничего не нашёл.
+2
Господа, это оригинальное исследование с фатальным недостатком. Похоже, оно рвет шаблоны — вы привыкли делать иначе :)
Мой алгоритм работает, и он удобен.
Буду рад если вы опишите недостатки не новизны восприятия информации, а технические.
Мой алгоритм работает, и он удобен.
Буду рад если вы опишите недостатки не новизны восприятия информации, а технические.
-3
оно рвет шаблоны
Да нет, я так тоже делал, когда я только только разбирался с докером. Это особенно удобно когда докер используется частично.
недостатки не новизны восприятия информации, а технические
Даже с применением docker-compose сильно усложняется деплоймент. что бы было проще подменять на сервере контейнеры можно конечно замутить data-волумы для кода и конфигов, но это сильно усложнит docker-compose. С Dockerfile и регистри/дистрибьюшен что бы задеплоиться мне надо только сделать pull на сервере и подменить контейнеры на новые, благо docker-compose это уже умеет относительно удобно делать.
Из недостатков… был у меня проектик с вендорной утилиткой для обработки видео, которая собиралась через раз. С вашим подходом докер мне никак не поможет, с Dockerfile я могу сборку запихнуть туда, и как только у меня контейнер собрался и работает, повесить на него стабильный тег и больше не беспокоиться о том что оно может отвалиться из-за другой версии библиотеки и т.д.
+2
Эта дискуссия повторяет холивары десятилетней давности относительно официальных репозиториев пакетов, собственных репозиториев, сборки софта из исходников, и смешанных вариантов по типу gentoo :)
Каждому свое.
Ни в коем случае я не против распространения своих утилит вместе с библиотеками в образах. Я это делаю.
Безусловно, registry — это удобно, и, возможно, я в будущем напишу об этом. Вряд ли опубликую здесь при подобной доброжелательности аудитории :)
При желании можно обойтись и без него, и без composer. Единого православного способа не существует.
Каждому свое.
Ни в коем случае я не против распространения своих утилит вместе с библиотеками в образах. Я это делаю.
Безусловно, registry — это удобно, и, возможно, я в будущем напишу об этом. Вряд ли опубликую здесь при подобной доброжелательности аудитории :)
При желании можно обойтись и без него, и без composer. Единого православного способа не существует.
0
К слову, для деплоймента приложения, структуры СУБД и конфигов нужен только один образ в виде одного небольшого .tar.xz-файла. Все разворачивается из него и compose-конфига одной единственной командой.
При этом, можно подменять модули на лету — php, python, nginx, перепрыгивать с mariadb на percona, развернуть локально репликацию, и откатиться при сбое. Удобно для stage и разработки.
Да, админам это не нужно, это ломает привычный development-deployment cycle. Мне так удобно.
При этом, можно подменять модули на лету — php, python, nginx, перепрыгивать с mariadb на percona, развернуть локально репликацию, и откатиться при сбое. Удобно для stage и разработки.
Да, админам это не нужно, это ломает привычный development-deployment cycle. Мне так удобно.
-1
банальное распространение изменений. Что мне делать на кластере из 20 машин с Вашими знаниями о том, как менять контейнеры?
Именно в этом месте DOCKERFILE является логичным применением. А то, что предлагаете Вы — весьма, весьма оригинальным
А рвёт оно не шаблоны, а здравый смысл, превращая докер в… во что, кстати? =) Чего Вы вообще добивались в своём оригинальном исследовании? Поиск нестнадартных подходов? Удалось. Но «нестандартный» != «жизнеспособный»
Именно в этом месте DOCKERFILE является логичным применением. А то, что предлагаете Вы — весьма, весьма оригинальным
решением.
А рвёт оно не шаблоны, а здравый смысл, превращая докер в… во что, кстати? =) Чего Вы вообще добивались в своём оригинальном исследовании? Поиск нестнадартных подходов? Удалось. Но «нестандартный» != «жизнеспособный»
Вот ещё один нестандартный подход
-1
Тема сисиек не раскрыта :) Поменьше аргументов, побольше картинок! И котиков, котики хороши на любую тему.
-2
Если серьезно, ответ такой.
Разложить сервисы на группу серверов так, чтобы с фронта автоматом резолвилась база, и при failover переключался мастер, как это умеет compose локально, не выйдет. Ip надо прописывать ручками — как минимум, в конфиге swarm. Серебрянная пуля отменяется, Dokcerfile и registry ничем не помогут. Когда мы выкладываем на кластер, нам в обоих случаях нужны дополнительные инструменты и ручная настройка.
Разложить сервисы на группу серверов так, чтобы с фронта автоматом резолвилась база, и при failover переключался мастер, как это умеет compose локально, не выйдет. Ip надо прописывать ручками — как минимум, в конфиге swarm. Серебрянная пуля отменяется, Dokcerfile и registry ничем не помогут. Когда мы выкладываем на кластер, нам в обоих случаях нужны дополнительные инструменты и ручная настройка.
0
habrahabr.ru/info/help/rules, правило 2:
Хабрахабр — не ЖЖ и не центр мирового кросспостинга. Не нужно копировать публикации из других блогов и сайтов, указывая, что ранее они были опубликованы в другом месте.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рецепты Docker: Monkey patch, часть третья