Ха-ха, про лобзик лесорубу — это шикарно. Спасибо за коментарий!
В докере достаточно проблематично запускать виртуальные машины, поэтому интеграционное тестирование такого масштаба врятли будет изолированным (в статье мы, кстати, тоже отказались от изоляции при интеграционном тестировании). Этапы же сборки/билда самого софта — могут быть абсолютно изолированными, если вы можете запустить их в Docker контейнере.
В целом, я думаю Вы со мной согласитесь, не бывает софта на все случаи жизни. Drone CI — не исключение. Перед тем как начать использовать нужно попробовать и оценить применимость для конкретного софта, окружения и решаемой задачи.
Мы Drone CI не продаем, просто поделились опытом, который нам показался интерестным и необычным, и попытались убрать боль адаптации для тех, кому данное решение подходит.
Jenkins — не буду утверждать на 100%, но скорее всего нет.
Мы используем Drone несколько месяцев и на сегодняшний день наша сборка очень простая: запустить тесты, сбилдить и запаблишь в регистри десяток контэйнеров, запустить Ansible скрипт, отправить нотификацию в слак. С более сложными сборками опыта нету, но, как мне кажется проблем не должно возникнуть. Drone, в целом, стимулирует делать сложное простым.
Под windows действительно не работает. Попытки были, но они явно не в фокусе разработчиков.
Да, не вижу тут проблем. Либо через matrix builds, либо просто два отдельных шага.
Нет, такой возможности нету, но если есть сильная нужда — то отчет можно построить напрямую из PostreSQL, разобравшись в SQL схеме Drone CI.
Да, абсолютно. Можно жить и без --build, но у нас это часто приводило к станностям в работе приложения. Обновил проект, забыл запустить с --build. Мы измеряли, у нас разница с --build и без --build всего несколько секунд, что не существенно, особенно с учетом того, что проект рестартуется максимум два раза в день. Проект в целом запускается с --build за секунд 5-10 (2 базы данных, 6 сервисов), не более того. Если запускается дольше, есть вероятность, что Dockerfile не совсем корректно построен. Несколько самых популярных ошибки из нашей практики:
Сторонние зависимости должны идти в начале докера. Они меняются редко и не будут перестраиваться каждый раз, при изменении кода приложения.
Копирование файлов, в которых описаны сторонние зависимости должно идти отдельным шагом, что бы при каждом запуске они не ставились заново. В примере ниже, сразу происходит копирование package.json (зависимости для Node.js приложения), а лишь потом происходит установка зависимостей. Если package.json не меняется — то и зависимости не будут ставиться заново.
На рабочих окружениях, код не копируется в Docker, а добавляется как volume.
FROM node:6.3
EXPOSE 8082
COPY package.json /app/
RUN cd /app && \
npm install --quiet
WORKDIR /app
По поводу сборки у нас подход похожий, но немного на стероидах. Поделюсь этим в отдельной статье.
Уменьшение кирпичиков при развертывании — это как глоток свежего воздуха, морозным зимним утром.
Чтобы избежать мучений с закончившимся местом на диске — используем, в основном, Amazon S3. Для разного рода временных файлов — используем volumes и храним на хосте.
Самый дешевый вариант, который достаточно долго использовал для разных, в том числе и своих проектов — это Digital Ocean дроплет за $5 в месяц. Вполне достаточно для старта большинства приложений. Можно увеличивать размер сервера по необходимости. Amazon, Google Cloud — предлагают хорошую интергацию с их сервисами. Позволяют сместить фокус с работы над инфраструктурой на работу над приложением путем больших затрат. Тут все индивидуально.
Мне кажется, что все же крутой инвестор не самая большая проблема :)
Использую OSX, т.е. локально Docker запускается в виртуальной машине, но это происходит "за ширмой" и не доставляется проблем. Когда использовал Linux, докер запускался непосредственно на физической машине.
Если Вы имели ввиду, как мы запускаем докер в "production" окружениях — то там да, виртуальные машины (Amazon, Google Cloud, Digital Ocean).
Если вы говорите о локальной среде, мне не совсем понятно, зачем запускать сервисы на разных ip. При развертывании проблемы DNS (service discovery) уже решены за счет других сторонних инструментов: Mesos/Marathon, Kubernetes, Consul, Swarm. Осталось выбрать :)
Я тоже не верю в silver bullet, но, увы, выбирать приходится. У меня станные ощущения вызывает любой новый инструмент. Так и не разобрался хорошо это или плохо :) Пару лет иcпользую экслюзивно докер для развертывания приложений, в которых учавствовал. Попробую поделиться своими мыслями, но перед этим спешу поделиться несколькими фактами и наблюдениями:
Первое приложение в докере задеплоил в начале 2015 (версия докера 1.5, потом обновили до 1.6). Никаких проблем по вине докера не возникало. Недавно обновили проект до последней версии — по прежнему все отлично. Сильных изменений изменений с точки зрения приложения не было.
В средине 2015 довелось работать над приложением побольше. Разворачивали Mesos, Marathon, все таски в докерах. 20+ различных сервисов, 60+ контэйнеров в кластере. 1.5 года — не одной проблемы с докером, больше с мезосом возились, но это отдельная история.
В команде ребята работают OSX, Ubuntu & Arch Linux — тут никаких проблем не возникало.
Участвовал в гибридных проектах, где часть приложения написанна на .Net, а вторая на Node.js/Java. Для таких проектов docker-compose был просто спасением. Не было нужды писать гайды. Просто docker-compose up и спокойно продолжаем писать на любимом .NET.
До появления докера, активно использовал Vagrant для тех же целей — было не так весело.
Теперь мысли:
Разница окружений (window, linux, osx). Докер ипользует внутренние фишки ядра линукса (cgroups, cnames) — отсюда и нужна запускать виртуальную машинну в бэкраунде. Не так уж и страшно.
Microsoft поверил в докер и два года работала с командой Docker, чтобы сделать нативную поддержку на Windows Server 2016. Они верят, должны ли мы? :)
Docker-compose действительно менял свой синтаксис — ничего от вас не утаить :). Но это все во благо прогресса. Главное, что это изменение прошло фактически безболезненно. Один раз обновил — и забыл. Радикальных изменений, как, например, в Angular.JS не было :)
Не имею опыта использования docker-compose для развертывания и не вижу в этом большого смысла, так как на серверах все же вещи обстоят несколько иначе. Для этого уже есть целый зоопарк хороших инструментов: Mesos, Kubernetes, Swarm, Amazon ECS. Конечно, хотелось бы "Вжух, вжух и в продакшен", но так точно не получится.
Amazon, Azure, Google Cloud — все предлагают свои "container service". Docker уже стал дефакто стандартом.
Несомненно, перед выбором любого инструмента, нужно оценивать его сильные и слабые стороны и решать для себя использовать или нет. На сегодняшний день, для простого запуска сложных проектов в рамках большой, распределенной команды — docker-compose мне кажется лучшим вариантом. Но это, всего лишь мое мнение :)
Чтобы в дочернем конфиге изменить параметр, не обрабатываемый в шаблоне — придется модифицировать шаблон. В итоге он может превратиться в монстра с кучей if — else для всех возможных вариантов конфигурации.
Да, согласен, но таких примеров как правило мало, за два года использования не один setty шаблон не превратился в монстра. Да и к тому же для таких вещей, где не просто меняется какое-то значение, а добавляется, удаляется какая то секция, меняется структура дочернего конфига, причём координально для разных конфигураций — «web config transformation» отлично подходит. А один-два if, только украшают шаблон конфига.
Копирования здесь нет, это как раз типичное переопределение нужного.
В данном случае нам нужно переопределить только значение строки подключения. Программисты педанты по своей натуре, и всегда ищут пути как сделать красивше чем есть.
Об этом я не спорю. Я просто намекаю, что надо понимать границы и осмысленность применимости всех инструментов.
Уж очень тонкие намёки, не понял так сразу. Абсолютно с Вами согласен. Просто было желание поделится подходом, который мы используем на многих проектах, и у которого есть свои плюсы и «области применения». Setty естественно не для всех.
В Setty вам достаточно поменять значение в своём конфиге. И согласитесть, что бы поменять строку подключения к БД на свою локальную — вы не будете писать трансформацию и создавать новую среду, вы просто поменяте(а потом возможно забудете вернуть перед комитом (я по себе сужу)). Setty и трансформации отлично сочитаются.
Setty не мешает использовать web.config transforms.
И как они сочитается.
Setty генерирует конфиг с помощью шаблона и настроек типа ключ/значение перед каждым билдом. В то время как трансформация происходит на этапе паблишинга или веб деплоймента
Так есть возможность добавлять различную логику в конфиге. См. пример об отправке почты из введения.
Это вот этот:
К примеру, на локальных машинах разработчиков отправленная почта должна сохранятся на диске, в то время как на тестовом сервере почта должна отправлятся с использованием сервиса отправки почты.
Так это типичная ситуация «конфиг на среду», никакой логики.
Да, согласен, не доработал пример. Исправлюсь.
К примеру, на локальных машинах разработчиков отправленная почта должна сохранятся на диске, в то время как на тестовом сервере почта должна отправлятся с использованием сервиса отправки почты. А разработчик «Айвано» занимающийся интеграцией с сервисом отправки почты, используя тестовый логин/пароль заказчика, с ограничением в 20 писем в день, проверяет отправляется ли всё-таки почта и смотрит, что бы в письмах не было ошибок. Разработчик «Кристо», написавший модуль для сжатия запросов, проверяет корректно ли работает ajax и проводит нагрузочное тестирование.
Вообщем таких примеров, когда разработчику нужна полная свобода при настройке приложения, можно привести много. При этом всегда помнить о том, что эти изменения нужно не закомитить они не хотят, а если и хотят, то обязательно забудут.
И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…
То что? У нас это прекрасно разруливается через config transforms.
И ладно бы это, еще ведь есть трансформы в веб-деплое.
Да, вполне себе рулится, добавлением нового конфига для трансформации и копированием половины одинаковых настроек, вместо того что бы держать все настройки в одном месте, и переопределять только одну, нужную для опрепедлённой конфигурации.
Этим я не хочу сказать, что я ярый противник «config transforms». Вполне себе нормальная вещь, имеющая право на существование и, возможно, подходящая для многих проектов. В то же время не лишённая «недостатков»… Setty пытается решить некоторые из них.
Setty работает подобным образом. Но при добавлении каких то общих настроек в систему вам не нужно будет их копировать в свой личный конфиг, так как вы просто добавляете настройки в конфиг верхнего уровня и они автоматически становятся доступны для всех. А если нужно поменять эту настройку — Вы просто копируете её в свой конфиг и меняете. Так же если использовать setty, Вы продолжаете работать с *.config файлами и читать настройки привычным образом. В дополнение, при развёртывании вам нужно будет изменить db.properties файл, и все эти изменения останутся на сервере (что не всегда возможно, если использовать appharbor к примеру). Setty позволяет хранить настройки для всех конфигураций в системе контроля версий.
Вообщем смысл тот же, но Setty добавляет немного автоматизации и опять же пару плюшек…
Отличный вопрос!
Простой ответ — setty удобнее и имеет несколько дополнительных плюшек.
Более развёрнутый:
1. Setty не мешает использовать web.config transforms.
2. Setty позволяет использовать одни и теже настройки для разных конфигов в солюшене (или вообще для разных проектов на одном компьютере, по принципу иерархических конфигов).
3. Так есть возможность добавлять различную логику в конфиге. См. пример об отправке почты из введения.
4. Если разработчик хочет поменять какие то настройки для его локальной машины ему гораздо проще создать личный конфиг и делать там всё что ему захочется. Не уверен возможно ли это сделать с web.config transforms, так как там вы всегда завязаны на на определённую build configuration(debug, release, etc.). Создавать новую build configuration то же не вариант, так как вам всё время придётся переключаться на её после того, как вы забираете последнюю версии с репозитория, ибо все работают в debug…
5. И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…
Демагогия получается. Сборкой называется:
Судя по википедии, сборка (build) состоит из:
получение исходного кода из репозитория;
сборка проекта;
выполнение тестов;
развёртывание готового проекта;
отправка отчетов.
Ха-ха, про лобзик лесорубу — это шикарно. Спасибо за коментарий!
В докере достаточно проблематично запускать виртуальные машины, поэтому интеграционное тестирование такого масштаба врятли будет изолированным (в статье мы, кстати, тоже отказались от изоляции при интеграционном тестировании). Этапы же сборки/билда самого софта — могут быть абсолютно изолированными, если вы можете запустить их в Docker контейнере.
В целом, я думаю Вы со мной согласитесь, не бывает софта на все случаи жизни. Drone CI — не исключение. Перед тем как начать использовать нужно попробовать и оценить применимость для конкретного софта, окружения и решаемой задачи.
Мы Drone CI не продаем, просто поделились опытом, который нам показался интерестным и необычным, и попытались убрать боль адаптации для тех, кому данное решение подходит.
Минималистичней Drone CI интерфейса не встречал. Он выполняет всего несколько функций:
Вот скриншот. Ой, кажется нада срочно чинить тесты :)
Да, абсолютно. Можно жить и без --build, но у нас это часто приводило к станностям в работе приложения. Обновил проект, забыл запустить с --build. Мы измеряли, у нас разница с
--buildи без--buildвсего несколько секунд, что не существенно, особенно с учетом того, что проект рестартуется максимум два раза в день. Проект в целом запускается с --build за секунд 5-10 (2 базы данных, 6 сервисов), не более того. Если запускается дольше, есть вероятность, что Dockerfile не совсем корректно построен. Несколько самых популярных ошибки из нашей практики:По поводу сборки у нас подход похожий, но немного на стероидах. Поделюсь этим в отдельной статье.
Уменьшение кирпичиков при развертывании — это как глоток свежего воздуха, морозным зимним утром.
Чтобы избежать мучений с закончившимся местом на диске — используем, в основном, Amazon S3. Для разного рода временных файлов — используем volumes и храним на хосте.
Самый дешевый вариант, который достаточно долго использовал для разных, в том числе и своих проектов — это Digital Ocean дроплет за $5 в месяц. Вполне достаточно для старта большинства приложений. Можно увеличивать размер сервера по необходимости. Amazon, Google Cloud — предлагают хорошую интергацию с их сервисами. Позволяют сместить фокус с работы над инфраструктурой на работу над приложением путем больших затрат. Тут все индивидуально.
Мне кажется, что все же крутой инвестор не самая большая проблема :)
Использую OSX, т.е. локально Docker запускается в виртуальной машине, но это происходит "за ширмой" и не доставляется проблем. Когда использовал Linux, докер запускался непосредственно на физической машине.
Если Вы имели ввиду, как мы запускаем докер в "production" окружениях — то там да, виртуальные машины (Amazon, Google Cloud, Digital Ocean).
Если вы говорите о локальной среде, мне не совсем понятно, зачем запускать сервисы на разных ip. При развертывании проблемы DNS (service discovery) уже решены за счет других сторонних инструментов: Mesos/Marathon, Kubernetes, Consul, Swarm. Осталось выбрать :)
Я тоже не верю в silver bullet, но, увы, выбирать приходится. У меня станные ощущения вызывает любой новый инструмент. Так и не разобрался хорошо это или плохо :) Пару лет иcпользую экслюзивно докер для развертывания приложений, в которых учавствовал. Попробую поделиться своими мыслями, но перед этим спешу поделиться несколькими фактами и наблюдениями:
docker-compose upи спокойно продолжаем писать на любимом .NET.Теперь мысли:
Несомненно, перед выбором любого инструмента, нужно оценивать его сильные и слабые стороны и решать для себя использовать или нет. На сегодняшний день, для простого запуска сложных проектов в рамках большой, распределенной команды — docker-compose мне кажется лучшим вариантом. Но это, всего лишь мое мнение :)
Да, согласен, но таких примеров как правило мало, за два года использования не один setty шаблон не превратился в монстра. Да и к тому же для таких вещей, где не просто меняется какое-то значение, а добавляется, удаляется какая то секция, меняется структура дочернего конфига, причём координально для разных конфигураций — «web config transformation» отлично подходит. А один-два if, только украшают шаблон конфига.
В данном случае нам нужно переопределить только значение строки подключения. Программисты педанты по своей натуре, и всегда ищут пути как сделать красивше чем есть.
Уж очень тонкие намёки, не понял так сразу. Абсолютно с Вами согласен. Просто было желание поделится подходом, который мы используем на многих проектах, и у которого есть свои плюсы и «области применения». Setty естественно не для всех.
Возможно.
Ну скажем, для того что бы поменять строку подключения к БД для продакшена вам нужна трансформация вроде этой:
В Setty вам достаточно поменять значение в своём конфиге. И согласитесть, что бы поменять строку подключения к БД на свою локальную — вы не будете писать трансформацию и создавать новую среду, вы просто поменяте(а потом возможно забудете вернуть перед комитом (я по себе сужу)). Setty и трансформации отлично сочитаются.
XML-Document-Transform(судя по схеме для трансформации).Setty генерирует конфиг с помощью шаблона и настроек типа ключ/значение перед каждым билдом. В то время как трансформация происходит на этапе паблишинга или веб деплоймента
Да, согласен, не доработал пример. Исправлюсь.
К примеру, на локальных машинах разработчиков отправленная почта должна сохранятся на диске, в то время как на тестовом сервере почта должна отправлятся с использованием сервиса отправки почты. А разработчик «Айвано» занимающийся интеграцией с сервисом отправки почты, используя тестовый логин/пароль заказчика, с ограничением в 20 писем в день, проверяет отправляется ли всё-таки почта и смотрит, что бы в письмах не было ошибок. Разработчик «Кристо», написавший модуль для сжатия запросов, проверяет корректно ли работает ajax и проводит нагрузочное тестирование.
Вообщем таких примеров, когда разработчику нужна полная свобода при настройке приложения, можно привести много. При этом всегда помнить о том, что эти изменения нужно не закомитить они не хотят, а если и хотят, то обязательно забудут.
Да, вполне себе рулится, добавлением нового конфига для трансформации и копированием половины одинаковых настроек, вместо того что бы держать все настройки в одном месте, и переопределять только одну, нужную для опрепедлённой конфигурации.
Этим я не хочу сказать, что я ярый противник «config transforms». Вполне себе нормальная вещь, имеющая право на существование и, возможно, подходящая для многих проектов. В то же время не лишённая «недостатков»… Setty пытается решить некоторые из них.
Setty работает подобным образом. Но при добавлении каких то общих настроек в систему вам не нужно будет их копировать в свой личный конфиг, так как вы просто добавляете настройки в конфиг верхнего уровня и они автоматически становятся доступны для всех. А если нужно поменять эту настройку — Вы просто копируете её в свой конфиг и меняете. Так же если использовать setty, Вы продолжаете работать с *.config файлами и читать настройки привычным образом. В дополнение, при развёртывании вам нужно будет изменить
db.propertiesфайл, и все эти изменения останутся на сервере (что не всегда возможно, если использовать appharbor к примеру). Setty позволяет хранить настройки для всех конфигураций в системе контроля версий.Вообщем смысл тот же, но Setty добавляет немного автоматизации и опять же пару плюшек…
Простой ответ — setty удобнее и имеет несколько дополнительных плюшек.
Более развёрнутый:
1. Setty не мешает использовать web.config transforms.
2. Setty позволяет использовать одни и теже настройки для разных конфигов в солюшене (или вообще для разных проектов на одном компьютере, по принципу иерархических конфигов).
3. Так есть возможность добавлять различную логику в конфиге. См. пример об отправке почты из введения.
4. Если разработчик хочет поменять какие то настройки для его локальной машины ему гораздо проще создать личный конфиг и делать там всё что ему захочется. Не уверен возможно ли это сделать с web.config transforms, так как там вы всегда завязаны на на определённую build configuration(debug, release, etc.). Создавать новую build configuration то же не вариант, так как вам всё время придётся переключаться на её после того, как вы забираете последнюю версии с репозитория, ибо все работают в debug…
5. И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…