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