поэтому в соответсвии с идеологией докера делают так

1) 1 приложение, 1 репа, докерфайл, докеригнор-файл внутри. Сборка создает образ с приложением и энтрипойтом для запуска. 2) отдельная репа со скриптами деплоя, которая содержит параметры\связи\логику\порядок запуска для каждого контейнера

@amdmax в вольюмах только код приложение. Приложение написано на интерпритерованном языке. Интерпретатор и веб-сервер подключены как отдельные контейнеры

нет вам смысла докер юзать

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

@amdmax так почему нет смысла? Я буду получать все выше перечислимые преимущества, разве нет? Да и ещё можно добавить 4. Одинаковая среда при разработке и на продакшн

монтируешь код извне = теряется иммутабельность, основное преимущество контейнеров

проблему опиши еще раз. что у тебя есть, что хочешь получить, что не работает.

@zelenin изначально вопрос был следующий "Да. У меня есть два репо: 1. my-docker - там файл compose.yml, dockerfile, etc, 2. my-app - там код моего приложения. я хочу, на серваке запустить приложение. Я делаю, что-то вроде git clone —recursive my-docker cd my-docker docker-compose up Если я добавлю репо my-app как субмодуль гита, то git clone —recursive скачает его тоже в папку my-docker/my-app. Вроде все отлично, но есть неудобство. Нужно будет каждый раз коммитить в репо с приложением my-app, а потом в репо my-docker принимать этот коммит. Может есть какой-то более удобный вариант, кто как делает?" Но потом перешел в примерно следующее. "Почему нет смысла использовать docker, если работаешь с интерпретируемыми языками и используешь примерно следующий воркфлов http://pastebin.com/THLH8Edw ?"

этот воркфлоу не имеет смысла

сложи докерфайл в основной репо

во-первых нет смысла в разных репо держать, если билдишь зависимо друг от друга

сложи докерфайл в основной репо

да

сложи докерфайл в основной репо

по 3му кругу )

тебе по третьему кругу объясняют, что ты переусложнил свой вокркфлоу и так никто не делает

"Если все запихнуть в одну репу, то не будет каши? На практике у меня пока что нет опыта, пытаюсь вот свое приложение первый раз докеризировать. Хочу узнать best-practice. Слышал, что разделять вроде правильно. Ибо у меня могут быть (пока такого нет) несколько модулей. Например backend rest, frontend, auth-service. Они могут быть в разных репо. Да и в my-docker будет много независимых папок вроде данных mysql, redis, elasticsearch, папка с релизами. Они хоть и под игнором, но все же нафиг они там?"

разделять правильно для образов, используемых отдельно. для локального композ тебе разделять не надо

@zelenin ок, тогда в каком образе хранить compose.yml? Если у меня могут быть несколько реп, как я описал выше

"Если все запихнуть в одну репу, то не будет каши? На практике у меня пока что нет опыта, пытаюсь вот свое приложение первый раз докеризировать. Хочу узнать best-practice. Слышал, что разделять вроде правильно. Ибо у меня могут быть (пока такого нет) несколько модулей. Например backend rest, frontend, auth-service. Они могут быть в разных репо. Да и в my-docker будет много независимых папок вроде данных mysql, redis, elasticsearch, папка с релизами. Они хоть и под игнором, но все же нафиг они там?"

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

для каждого приложения - свой докерфайл в своем репо

тебе по третьему кругу объясняют, что ты переусложнил свой вокркфлоу и так никто не делает

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

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

потому что держать докерфал отдельно от кода приложения бессмысленно

@zelenin ок, тогда в каком образе хранить compose.yml? Если у меня могут быть несколько реп, как я описал выше

храни все в одном

"Если все запихнуть в одну репу, то не будет каши? На практике у меня пока что нет опыта, пытаюсь вот свое приложение первый раз докеризировать. Хочу узнать best-practice. Слышал, что разделять вроде правильно. Ибо у меня могут быть (пока такого нет) несколько модулей. Например backend rest, frontend, auth-service. Они могут быть в разных репо. Да и в my-docker будет много независимых папок вроде данных mysql, redis, elasticsearch, папка с релизами. Они хоть и под игнором, но все же нафиг они там?"

ты хотел узнать best practice )

в ответ получил от 4 людей одинаковое мнение о том, как надо. а то, как сделано у тебя - излишне сложно и "так никто не делает" )

Свою ошибку в том, что я складывал docker файлы не в репы проектов, к которым они относятся, я понял. Спасибо.

но почему делать вот так плохо https://www.airpair.com/docker/posts/efficiant-development-workfow-using-git-submodules-and-docker-compose ?)))

Ну, во первых, девелопмент воркфлоу направлен на уменьшение гемороя разраба, к продакшну он напрямую никакого отношения не имеет.

и Amine Mouafik (CTO at Continuous Software Co. Ltd, автор статьи) вроде так делает😊

но почему делать вот так плохо https://www.airpair.com/docker/posts/efficiant-development-workfow-using-git-submodules-and-docker-compose ?)))

а вопрос почему - связан именно с идеологией докера. "Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект". Тот кейс, который у тебя показан, нарушает это условие. т.к. приложения каждый раз будут разными

Ну как минимум они теряют возможность разрабатывать поделчючаемые модули для ноды

Нада запрегать компанию "best cto" и стать там cto

что неминуемо приводит меня к мысли что чувак не сталкивался с реальностью, или что они реально этим не пользуются, или что они любят боль и страдание

И потом любой херней людям мозг выносить )

Нада запрегать компанию "best cto" и стать там cto

Давай, будет красиво :()

сорри, но мне кажется я ещё больше запутался, чем перед тем как заходил в комнату😊 Если не сложно может тогда кто-то накидать, как должно быть докеризировано приложение и как оно должно подыматься на сервере, если у меня есть 3 репо: 1. restfull-api (nodejs) 2. cabinet (frontend, js) 3. player (js)

апи - микросервисы или один апп?

Котаны, а расскажите за безумное. Смотрите, у меня есть пайплайн по сборке контейнеров с софтом. Где сама сборка софта тоже в контейнере. Во время сборки, условный maven качает тысячи говна. Можно _на этапе сборки_ примонтировать некую папку в контейнер?

один апп

чтобы оно сразу скачивало всё в маунт

сорри, но мне кажется я ещё больше запутался, чем перед тем как заходил в комнату😊 Если не сложно может тогда кто-то накидать, как должно быть докеризировано приложение и как оно должно подыматься на сервере, если у меня есть 3 репо: 1. restfull-api (nodejs) 2. cabinet (frontend, js) 3. player (js)

в чем разница между 2 и3?

чтобы оно сразу скачивало всё в маунт

нет

но можно это кешировать

У меня сейчас base-image всё "закэшировано"

но очень утомляет их руками пересобирать

кого? зачем руками?

ну, допустим, они разрабатываются отдельными командами

и лежат в отдельных репо

кого? зачем руками?

базовые образы, не автоматизировано потому што

но очень утомляет их руками пересобирать

ну да дергать CI раз в период )

и лежат в отдельных репо

я хочу понять как оно пото взаимодействует

Дак вот же, я добрался до момент, когда надо автоматизировать и подумал, может можно проще

чем CI с периодами

базовые образы, не автоматизировано потому што

у меня эти кеш-слои с модулями автоматов сбрасываются когда меняется сосоав модулей

я не знаю как делается в мавене, но скорее всего они прописаны в файле, да?

никак не взаимодействуют. Допустим если пользователь зайдет по url /cabinet , то попадет в кабинет, а если в /player, то в player)))

А кто занимается проксированием этого?

Вся проблема с этим понимаем "где хранить докер файлы" от того, что докер дал compose но не объяснил что есть концепция service и application(набор service) или наоборот если хотите.

точнее объяснил, но не так яро как все остальное )

вот жеж http://collabnix.com/archives/1934

@NordLuf nginx

ну тогда у тебя по контейнеру на кабинет и плеер которые стучатся к апи. 3 контейнера

если они лежат в отдельных репо = разные контейнеры из разных образов

а если в одном - то организоввывать надо не докер

@NordLuf пока понятно. Потом я создам новое репо с docker-compose. docker-compose.yml будет тянуть image-ы из сырцов репо. Верно?

в идеале бы да

в смысле - в идеале он из будет тянуть из регистри

ок, дальше я все это сделал. запустил на серваке docker-compose up. Все работает. Если кто-то сделает коммит в какое-то репо. Как мне потом на сервак задеплоить?

пересобрать образ через CI (в идеале), прогнать тесты, задеплоить блюгрином

ок, дальше я все это сделал. запустил на серваке docker-compose up. Все работает. Если кто-то сделает коммит в какое-то репо. Как мне потом на сервак задеплоить?

сбощик качает последнюю репу, запускает докер билд и получает новый образ с новым приложением. Далее его пушит в регистри

и дергает задачу деплоя )

пересобрать образ через CI (в идеале), прогнать тесты, задеплоить блюгрином

да

сорри за нубский вопрос, но что за блюгрин?

http://martinfowler.com/bliki/BlueGreenDeployment.html

но разработчика это же сложнее? Например, каким образом разработчик может делать изменения в ide и смореть результат, который отработал в докере без пересобрания образа?

это уже процесс разработки - и тут схема маунтить папки с хоста вполне себе роляет

понял, спасибо

а зачем тут на 9 шагу прописано volumes: - .:/code, если в dockerfile есть ADD . /code/ ? https://docs.docker.com/compose/django/

https://docs.docker.com/compose/django/