У меня на работе есть самописная система для управления приложениями. Она заточена под наш продукт, но, мне кажется, должно существовать что-то универсальное.
Что оно умеет:
Задаём env, т.е. где мы всё ставим: dev/uat/prod/etc
Для данного env задаём разные hosts. Скажем, в dev всё ставится на localhost, в prod ставится на кластер из ~сотни машин, и т.п.
Определяем сервисы. Сервис описывает что это вообще такое: mysql, web-server или просто java-процесс.
Определяем на каких хостах какие сервисы запускать, какие порты использовать, какие файловые пути, етс.
Сервисы можно стопать|стартовать|проверять статус|посылать кастомные команды. Например, для данного mysql сервиса можно описать, что нужно применить патчи из такой-то папки. И т.п.
Есть web ui и command-line ui где можно видеть всю эту картину и управлять всем этим делом.
Итог.
С т.з. дева: делаешь checkout исходников, набираешь что-то типа "supertool do-all" и через несколько минут у тебя всё запущено, крутится и вертится. Можно всяко тьюнить: "supertool restart client-db" — перестартует нужный инстанс mysql, скажем.
С т.з. админа: набираешь что-то типа "supertool release-prod" и всё само деплоится, крутится и вертится. И можно всё мониторить — всё ли задеплоилось, где что не запустилось, не соединилось, етс.
Мне удалось нагуглить devops тулзы, типа Chef/Puppet, но я не понимаю как их во время девелопмента использовать. Что ещё бывает в этом мире?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Danchik, Вы писали:
.>>Мне удалось нагуглить devops тулзы, типа Chef/Puppet, но я не понимаю как их во время девелопмента использовать. Что ещё бывает в этом мире? D>Puppet, вроде должен быть то что надо. Для девелопмента хватит masterless — puppet apply
Ок... Допустим. Можешь пнуть в правильном направлении?
Например, мне надо написать сервис, который раз в секунду пишет hello world в некий лог-файл.
Скажем, писать буду на java. Нужно сделать конфигурацию, которая скачивает указанную версию jdk, maven, билдит helloWorld.jar, запускает его передавая параметр имя лог-файла. И два окружения — dev/prod. dev всё делает в текущей папочке localhost, prod ставит на указанный хост, куда-нибудь в /usr/bin, лог пишет в /var/log, прописывает init.d-скрипт.
С чего начать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Скажем, писать буду на java. Нужно сделать конфигурацию, которая скачивает указанную версию jdk, maven, билдит helloWorld.jar, запускает его передавая параметр имя лог-файла. И два окружения — dev/prod. dev всё делает в текущей папочке localhost, prod ставит на указанный хост, куда-нибудь в /usr/bin, лог пишет в /var/log, прописывает init.d-скрипт. .>С чего начать?
Здравствуйте, ., Вы писали:
.>У меня на работе есть самописная система для управления приложениями. Она заточена под наш продукт, но, мне кажется, должно существовать что-то универсальное.
Собственно, это идея http://en.wikipedia.org/wiki/Continuous_integration
.>Мне удалось нагуглить devops тулзы, типа Chef/Puppet, но я не понимаю как их во время девелопмента использовать. Что ещё бывает в этом мире?
TeamCity (универсал без жёсткой специализации)
Jenkins (обычно Android-related)
TFS (комбайн "всё-в-одном", если сидите на Microsoft-технологиях)
Bamboo (если всё на Atlassian-продуктах)
Здравствуйте, Mr.Delphist, Вы писали:
MD> .>У меня на работе есть самописная система для управления приложениями. Она заточена под наш продукт, но, мне кажется, должно существовать что-то универсальное. MD> Собственно, это идея http://en.wikipedia.org/wiki/Continuous_integration
Это не совсем то. Точнее совсем не то. Как ты CI сервер будешь использовать для дев-деплоймента? Скажем, у нас сейчас на компьютере у дева запускается около 40 процессов. Поправил код, набрал команду — всё скомпилировалось, скопировалось куда надо и тут же запустилось — можно смотреть как всё работает целиком. Немного другая конфигурация — те же сервисы запускаются и на проде, только не на одном хосте, а на 50.
Ах, да. Jenkins у нас тоже есть. Он тоже запускает нашу тулзу чтобы развернуть систему на ~30 хостах, и запустить тучу тестов, на ещё ~20 хостах.
Здравствуйте, ., Вы писали:
MD>> Собственно, это идея http://en.wikipedia.org/wiki/Continuous_integration .>Это не совсем то. Точнее совсем не то. Как ты CI сервер будешь использовать для дев-деплоймента?
1) Создать дев-джоб с переменной. На что укажет переменная (//vasya.pupkin или 192.168.10.20), туда и билдим.
2) Поднять локальный CI-сервис
3) Если билд-скрипт позволяет, пускать его локально из командной строки (тогда dev-CI в самом деле не нужен)
Здравствуйте, ., Вы писали:
.>Мне удалось нагуглить devops тулзы, типа Chef/Puppet, но я не понимаю как их во время девелопмента использовать. Что ещё бывает в этом мире?
Во время девелопмента можно использовать vagrant с автоматическим provisioning из Chef/Puppet/Salt/Ansible.
Здравствуйте, Mr.Delphist, Вы писали:
MD>>> Собственно, это идея http://en.wikipedia.org/wiki/Continuous_integration .>>Это не совсем то. Точнее совсем не то. Как ты CI сервер будешь использовать для дев-деплоймента?
MD>1) Создать дев-джоб с переменной. На что укажет переменная (//vasya.pupkin или 192.168.10.20), туда и билдим.
Нужен сервер чтобы сделать локальный деплоймент? Неее.
MD>2) Поднять локальный CI-сервис
Поднимать локальный jeninks? а его настройки откуда брать? Коммитить jenkins в репозиторий с исходниками? Что-то слишком сурово.
Да и вообще jenkins как-то для другого. Как, например, с помощью него перезапустить mysql или web-server?
MD>3) Если билд-скрипт позволяет, пускать его локально из командной строки (тогда dev-CI в самом деле не нужен)
Билд-скрипт не умеет запускать|стопать сервисы и описывать их взаимодействие, да ещё и на множестве хостов в общем случае. Или это будет очень крутой билд-скрипт — да и на чём же опять? Писать тонну шелл-скрипта?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Miroff, Вы писали:
M> .>Мне удалось нагуглить devops тулзы, типа Chef/Puppet, но я не понимаю как их во время девелопмента использовать. Что ещё бывает в этом мире?
M> Во время девелопмента можно использовать vagrant с автоматическим provisioning из Chef/Puppet/Salt/Ansible.
А подробнее? Можно инструкцию для чайников?
Здравствуйте, sergey179, Вы писали:
s> Такое не пойдет ?
s> UrbanCode Deploy http://www-03.ibm.com/software/products/en/ucdep
А ты сам использовал? Каково?
А то у меня аллергия на IBM-софт. Но можно взглянуть, спасибо.
Здравствуйте, ., Вы писали:
MD>>3) Если билд-скрипт позволяет, пускать его локально из командной строки (тогда dev-CI в самом деле не нужен) .>Билд-скрипт не умеет запускать|стопать сервисы и описывать их взаимодействие, да ещё и на множестве хостов в общем случае.
Простите, ЧТО он не умеет?! Обычная командная строка умеет стопать/стартовать IIS, сетевые шары, и т.п. и т.д. Успешно пользуем не первый день. С минимумом сторонних утилит типа sysinternals от Руссиновича или CURL решается 80% деплоймент-задач, для остальных 20% есть предустановленный PowerShell, или можно накатить Python/TCL/любой-скрипт-по-вкусу.
Доменная аутентификация или специальный билд-аккаунт с нетривиальным паролем (иначе первый же бот вас поломает по словарю) решают задачи, связанные со множественностью хостов.
Да, по-первой кажется что это лишняя потеря времени не второстепенную задачу. Но когда всё сделано, любое добавление компонента или хоста делается щёлк! и готово.
Здравствуйте, Miroff, Вы писали:
.>>А подробнее? Можно инструкцию для чайников?
M>http://docs.vagrantup.com/v2/getting-started/
virtual box? А это не слишком ли сурово? Сколько же оно стартовать будет?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>3) Если билд-скрипт позволяет, пускать его локально из командной строки (тогда dev-CI в самом деле не нужен) .>>Билд-скрипт не умеет запускать|стопать сервисы и описывать их взаимодействие, да ещё и на множестве хостов в общем случае.
MD>Простите, ЧТО он не умеет?! Обычная командная строка умеет стопать/стартовать IIS, сетевые шары, и т.п. и т.д. Успешно пользуем не первый день. С минимумом сторонних утилит типа sysinternals от Руссиновича или CURL решается 80% деплоймент-задач, для остальных 20% есть предустановленный PowerShell, или можно накатить Python/TCL/любой-скрипт-по-вкусу.
MD>Доменная аутентификация или специальный билд-аккаунт с нетривиальным паролем (иначе первый же бот вас поломает по словарю) решают задачи, связанные со множественностью хостов.
MD>Да, по-первой кажется что это лишняя потеря времени не второстепенную задачу. Но когда всё сделано, любое добавление компонента или хоста делается щёлк! и готово.
Ну понятно. У нас уже есть всё это доморощенное. Я надеялся, что есть какое-то готовое достаточно универсальное решение.
Скажем, я вижу это как-то так. Описываем сервисы:
service ClientDb
{
type: database
vendor: mysql
version: 5.6.11
}
service ClientService
{
type: java-application
jdk: 1.8
jar: client-service.jar
jvm-args: -Xmx1024M
version: 3.5.6
requires: ClientDb, SmtpServer
}
service ClientWebUi
{
type: webapp
war: client.war
version: 6.73
requires: ClientService
}
А дальше всё рабоает само — при запуске всё проверяется, скачивается, устанавливается, апдейтится, соединяется друг с другом, и т.п. Предоставляет интерфейс чтобы посмотреть что где и как запустилось, кнопочки чтобы перезапустить сервис и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>А ты сам использовал? Каково? .>А то у меня аллергия на IBM-софт. Но можно взглянуть, спасибо.
Нативного IBM софта как такового давно уже нет (если не брать Cobol compiler и всякий Z/OS). В основном весь софт от компаний, купленных IBM-ом. UrbanCode купили не так давно и еще не все заменено индусами...
