Да я не про веб-хуки, понятно что они там есть. В EE версии есть поле ввода для хуков, которые потом будут подкладываться на файловую систему. Для каждого проекта.
Там речь идет про хуки, которые можно подложить через веб-интерфейс гитлаба. Иначе, вам надо каждому желающему давать ssh доступ до сервера, что, в реальной жизни, невыполнимо. Ну, или вы обновляете хуки по запросу от пользователей сами.
Запускать ansible внутри контейнера очень даже можно и нужно. Но не для деплоя чего-то внутри, а для CI и тестов. Я тестирую свои публичные роли внутри докера(именно тот кейс, который вам кажется дикостью — полное разворачивание сервиса внутри докера) в travis'е. Закрытые плейбуки тестируются в докере и CD происходит изнутри контейнера.
А вот делать из ansible dockerfile + docker compose сомнительная вещь, согласен с вами.
К примеру, как делать не надо, потому что дебажить сложно, но это самый удобный способ передать в параметр servers нужные данные в том виде, которая она ожидает, но чтобы это была другая переменная:
Лучше всего этот костыль использовать на данных из setup типа ansible_fqdn. Делаешь setup для всех бэкендов и подставляешь их адреса сюда, миную лишнюю переменную.
За два года почти ежедневной работы с ним накопился нехилый опыт прикручивания костылей и использования хитрых способов. Я бы статью написал, только есть одна проблема — для меня все это теперь кажется очевидным и не понятно о чем есть интерес у других почитать.
1. Почти в каждом пункте выводы одинаковые, как под копирку.
2. Картинки с производительностью вообще никак не смог интерпретировать. Текст и картинки не совпадают.
Я для сборки deb пакета настроил Gitlab CI. Пакет собирается в докер раннере, артефакты отдаются в gitlab. Собирается под Ubuntu 12.04, 14.04.
В отсутствии Gitlab CI сделал бы примерно так — sh скрипт запускает docker, собирает пакеты, копирует куда надо по ssh. Для deb-based могу порекомендовать еще посмотреть deb-o-matic.
Плюсую. Особенно напрягает качество плейбука в данной статье. За файл 'ansible/release.yml' отдельно хочется отрывать руки. Если вы сами суть работы с Ansible не понимаете, то, умоляю, не пытайтесь других людей учить плохому.
Если использовать Chef на больших и сложных конфигурациях, когда одна нода зависит от того, какие ноды есть с определенной ролью и еще что-то подобное, то «радость» сразу улетучивается и понимаешь, что надо смотреть в сторону другого инструмента. Сейчас рассматриваем ansible на замену.
Времена, когда Ubuntu «могла быть» хуже Debian давно прошли и Вам настало время забросить этот топор войны.
А то получается, война закончилась, а Вы все поезда под откос пускаете.
Используем 200+ виртуальных и хостовых машин на Ubuntu(10,12,14 lts) и Debian и не находим каких-либо принципиальных отличий, чтобы пересесть только на Debian.
Отличная книга, прочитал за две недели отпуска и остался крайне доволен информацией оттуда.
Да я не про веб-хуки, понятно что они там есть. В EE версии есть поле ввода для хуков, которые потом будут подкладываться на файловую систему. Для каждого проекта.
Там речь идет про хуки, которые можно подложить через веб-интерфейс гитлаба. Иначе, вам надо каждому желающему давать ssh доступ до сервера, что, в реальной жизни, невыполнимо. Ну, или вы обновляете хуки по запросу от пользователей сами.
Вот вам немного репозиториев:
https://github.com/UnderGreen?tab=repositories
Запускать ansible внутри контейнера очень даже можно и нужно. Но не для деплоя чего-то внутри, а для CI и тестов. Я тестирую свои публичные роли внутри докера(именно тот кейс, который вам кажется дикостью — полное разворачивание сервиса внутри докера) в travis'е. Закрытые плейбуки тестируются в докере и CD происходит изнутри контейнера.
А вот делать из ansible dockerfile + docker compose сомнительная вещь, согласен с вами.
Посмотрите обязательно, у нас новые проекты с монструозного Jenkins переезжают в GitlabCI, благо его очень активно пилят в последних версиях.
Ну или про многие фильтры народ вообще не знает, типа default(omit), mandatory или combine.
К примеру, как делать не надо, потому что дебажить сложно, но это самый удобный способ передать в параметр
servers
нужные данные в том виде, которая она ожидает, но чтобы это была другая переменная:Сама переменная:
Лучше всего этот костыль использовать на данных из setup типа ansible_fqdn. Делаешь setup для всех бэкендов и подставляешь их адреса сюда, миную лишнюю переменную.
2. Картинки с производительностью вообще никак не смог интерпретировать. Текст и картинки не совпадают.
В отсутствии Gitlab CI сделал бы примерно так — sh скрипт запускает docker, собирает пакеты, копирует куда надо по ssh. Для deb-based могу порекомендовать еще посмотреть deb-o-matic.
vagrant + lxc plugin = true
Быстро, легко, молодежно.
А то получается, война закончилась, а Вы все поезда под откос пускаете.
Используем 200+ виртуальных и хостовых машин на Ubuntu(10,12,14 lts) и Debian и не находим каких-либо принципиальных отличий, чтобы пересесть только на Debian.
Жмем 12572G и очень быстро мотается ;)