Комментарии 40
Интересная штука! Как считаете, есть смысл писать подобные приложения на python\golang ?
Я, например, написал пару ролей, первая configurator делает то же самое с папками, файлами, конфигами.
Вторая docker ставит докер и docker-compose, если они не установлены, и управляет контейнерами.
В одном Ansible-репозитории можно держать все нужные настройки для того или иного хоста разработчика или тестировщика, и/или продакшена, и с помощью Ansible это можно натравить на много хостов сразу, или просто на локалхост.
Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю
Во-вторых, не знаю как вторая версия ансибла, но первая была почти всегда чуть менее чем стабильно. дебажить и подгадывать какие таски или плейбуки запилить… то еще удовольствие.
Правда, всё выше сказанное, не про замену сабжа этого поста на ансибл, а просто про ансибл.
Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю
Используйте теги и будет счастье! --tags='docker-orchestrate', --skip-tags='ssl' например.
Во-вторых, не знаю как вторая версия ансибла, но первая была почти всегда чуть менее чем стабильно. дебажить и подгадывать какие таски или плейбуки запилить… то еще удовольствие.
Согласен полностью, в свое время просто исплевался, работало нестабильно. Сейчас вроде более-менее устаканилось все.
имхо, от тэгов как правило все только усугубляется. по крайней мере это все сложно использовать если не заворачивать в зонтичные скрипты\бинари\пакетные_операции.
Сам по себе ансибл — очень крутая штука. просто кривая обучения слегка недружелюбна )))
Мне кажется подход
git clone
make более привычен.
Удаленная установка на машину разработчика — возможно это удобно в офисе.
Удаленная установка на машину разработчика — возможно это удобно в офисе.
Да, а еще и на тест-сервер, и на прод-сервер.
Мсье знает толк в извращениях…
А, кстати, как делаете для разработчиков? Через docker-machine? У меня docker-machine для parallels как-то толком не завелся в свое время, пользуюсь vagrant-ом.
Наш образ внутри компании немного отличается, но тем не менее суть ясна — там находятся все нужные для работы инструменты. Вот этот образ и разворачиваем разработчику через Ansible, он выгружает туда код из IDE, и запускает сборку (скрипт для сборки проекта находится в самом проекте).
Ну а продакшен отличается, есть образы-сборщики и Докерфайл для продакшен-сборки. Образ-сборщик поднимается, в нем настроен Docker-in-Docker, и собирает проект, создает продакшен-имадж, который потом разворачивается для тестировщиков и далее, через Ansible.
Подробнее про andyceo/phpdevenv уже отвечал здесь
Если есть еще вопросы, отвечу.
Не, понятно, что можно запустить в parallels линукс, а внутри него уже запускать докеры, но оверхедненько выходит, ноутбук то не резиновый…
Аналогично, я тоже имел ввиду про git clone на машине разработчика.
А если это открытый проект или нет просто доступа к машине разработчика, он удаленный.
docker-project используется, что бы развернуть приложение из нескольких репозиториев и собрать его.
Получается привычный, классический флоу:
git clone
make
и работает
Когда тебе что-то разворачивают на машине. Это ненужная зависимость от людей.
Установить себе на машину нужную версию docker/compose обычно люди могут без проблем.
Если не могут, сами тогда Ансибл уже в помошь, но на уровне установки рантайма, а не самого приложения.
Собирать проект в продакшен докер файле тоже не лучший вариант.
Лучше разделять процессы сборки и упаковки, что бы не тянуть утилиты разработчика в продакшен.
Как из микросервис из репозитория в продакшен — это отдельный процесс опять же.
почему бы вам не сделать контейнер для вашего docker-project
Благодаря mount не требуется пересборка контейнера в случае обновления исходников.
submodule позволяет логически связать версии микросервисов.
И не нужно писать своих скриптов
Мы используем Ansible для провижена серверов, которые образуют облако Mesos/Marathon.
А оркестирует контейнеры уже соотвественно Marathon.
С содержимым Dockerfile эта часть вообще уже никак не связана (как и docker-project). Контейнер проектируется максимально закрытым и условно не важно, где и кто его запускает.
Я не занимаюсь администрированием, Ansible в случае выпадения сервера может автоматом перекинуть контейнеры на другой более свободный сервер?
У нас эта задачу решает Marathon.
Опять же, это не значит вы делаете неправильно. У нас разные проекты, нагрузка и вводные.
Вообще, работающих решений обычно несколько, и что из них лучшее зависит не только от задачи но и исполнителя.
Но как вы собираете приложение в этом случае?
Мы например какраз делаем docker-project build — он собирает фронтенд, запускает композер и т.д. не собирая имиджи
Это прям наш юзкейс вы описали.
Перед деплоем либо идет работа с индивидуальным приложением — тут все стандартно.
Либо если надо собрать все имиджи разом это уже может сделать docker-compose.
git submodule — очень не удобны в работе, по крайне мере нам.
Которое потом упаковывается в имидж если нужно. Укаковка в имидж это отдельный, независимый этап.
Если интересно раскажу подробнее.
У нас есть базовый имидж в котром установлен рнр с нужными настройками.
От базового имиджа наследуюется билд имидж — в который добавляеются nvm, grunt, composer и т.д.
при сборке приложения (не путаь со сборкой имиджа)
1 вызывается просто make (через тот же docker-project build)
2 который запускает билд контейнер с подмонтированым кодом, где идет его сборка. — запускается composer и т.д.
3 Билд контейнер сам выключается
4 имеем папки с собраным приложением
6 если мы в дев среде — эти папки напрямую подмонтированы в уже работющие контейнеры и их обновлять каждый раз не надо.
если мы делаем имиджи для продакшена, то начинаем сборку имиджей, докер-композером или индивидуально.
Базовый имидж обеспечивает соотвествие среды билда и работы, а так же ускоряет развертывание имиджа в продакшене.
В продакшене используется mesos, marathon, consul, поэтому тут уже нужны собраные имиджи, без монтирования.
Если что-то не очень хорошо описал, спрашивайте, буду рад помочь.
Я сам пытался подобный флоу реализовать, но столкнулся проблемой, что если в composer.json/package.json/… указаны в зависимостях приватные git-репозитории, то composer/npm install очень сложно заставить отработать без помещения приватных ключей в билд-контейнер.
Во-вторых, проблемы с распределенными окружениями — монтирование работает только если и клиент, и демон на одном хосте запускаются. Со swarm-кластерами или просто с удаленными docker-хостами не работает.
Ещё вариант передавать значения через переменные окружения или билд-параметры, но везде пишут, что не безопасно. Вообще интересная ситуация с секретами в докере — везде в доках пишут в описании разных возможностей «не рекомендуется для передачи секретов», а рекомендуемого способа нет.
сам билд (compose update, npm install) под чем-то более ограниченным.
Так именно для установки зависимостей эти ключи прежде всего и нужны. Клон как раз можно сделать на хосте, клиент передаст серверу или кластеру COPY/ADD с клиентского компа и проблем нет. Но вот установить зависимости так уже проблематично. Одно дело иметь на клиентском хосте git, а совсем другое — развёрнутое билд-окружение.
Я говорю о монтировании ключей исключительно в билдер-контейнер. Можно в сворме билдить, конечно, но пока такой юз-кейз не придумал еще.
Я тоже о нём. Но даже без сворма, докер-демон может крутится на виртуалке (например через docker-engine) и пробрасывать локальные файлы и через виртуалку, и через контейнер ещё сложнее.
Но лично я категорически против того, чтобы приватные ключи покидали мой хост.
Само покидание может не особо критично для меня лично, но при условии гарантий, что нигде их в открытом виде не хранится. В переменных же они, не сильно утрируя, всему миру видны, как минимум, всё время работы контейнера, если специальных мер не принимать по ограничению времени доступности. Но это лишь ограничение будет, но не исключение.
Но тут, кажется, уже в другом заковыка: чтобы установить эти приватные пакеты, вам придется дать ключ установщику, а в этот момент вы ему не доверяете — чужие пакеты, скрипты да хуки… и тут ваш ключ утекает. Мне кажется, тут разве что свой пакетный прокси в соседнем контейнере поднять — вот ему ключи и дать, а билд-контейнер будет с этим прокси общаться — по внутренней сети и без аутентификации.
Ну вот как-то так проблема и решается. Разные варианты использования ssh-аgent, монтирования SSH_AUTH_SOCK в контейнер, контейнеры/сервисы с хранилищами ключей, как отдающие сами ключи (может быть генерируя одноразовые), так и проксирующие запросы, как с аутентификацией (хотя бы по IP), так и без неё. Но все (из тех, что я нашёд) либо имеют ограничения по применению (типа клиент и демон должны быть на одном хосте), либо содержат прорехи в безопасности мало отличимые от простого копирования ключа в контейнер (так же не рекомендуются в манах докера).
Лично для меня как пользователя такой связки никаких проблем нет, все прозрачно монтируется.
Да, докер-машина, конечно. Были проблемы с монтированием того же ~/.ssh/id_rsa с правами 400 в контейнер через виртуалку, когда все три пользователя (локальный, докер-демона в виртуалке и процеса в контейнере разные и не руты).
1 Они привязаны к конкретному коммиту и именение любого из модулей вызывает необходимость коммита в проджект репозиторий
2 Не все разработчики знают, как с ними работать = больше стоимость разработки
есть еще git subtree с приблизтельно темиже проблемами.
Я не рассматриваю проект репозиторий, как мета приложение, это скорее среда разработки.
Она не должна меняться если происходят внутренние изменения в микросервисах.
Управление Docker проектом со множеством git репозиториев