Как стать автором
Обновить

Эволюция процесса деплоя в проекте

Время на прочтение13 мин
Количество просмотров19K
Всего голосов 27: ↑22 и ↓5+17
Комментарии20

Комментарии 20

FTP/SFTP, rsync, git pull… Интересно, старые добрые пакетные менеджеры уже не в моде?

И еще не понятно: такая большая часть статьи посвящена Ansible и Chef, но это же, как вы сами пишете, только менеджеры конфигурации. А статья называется «деплой», и это подразумевает нечто большее, разве не так? Прежде чем что-то конфигурировать, это что-то нужно еще собрать/скомпилировать (возможно, стоило бы получше раскрыть тему CI и build-серверов?) и как-нибудь красиво доставить на сервер (например, упомянутыми выше менеджерами пакетов).
Используем Puppet, однако деплой(нагруженной и сложной системы как вы выразились) происходит sh скриптами с библиотеками.Спорный момент на тему инструментов.Спасибо за статью)
Согласен, интересно было б почитать и про CI и build-сервера. Хотя статья «Эволюция процесса деплоя в проекте», может не доэволюционировали пока :)

и как-нибудь красиво доставить на сервер


Посмотрите еще в сторону packer.io и terraform. Как по мне интересный подход к деплою :)
Посмотрите еще в сторону packer.io и terraform
Посмотрел. Я правильно понял, что там используется, если можно так выразиться, императивный подход? Т.е. есть некий скрипт, который ходит по списку серверов и закачивает на них новый образ?

Почему мне нравится использование нативных пакетных менеджеров, что они позволяют создавать более декларативную конфигурацию. Представьте, что у вас есть некий небольшой кластер, в котором сисадмин Вася на время вынул сервер, чтобы с ним поиграться (заменить там что-нибудь и т.д.), а вы об этом не знали, и начали свой деплой. Недостучавшись до этого сервера ваш скрипт, скорее всего, просто забьет на него и пойдет по списку дальше. В случае же пакетов вы просто загружаете новый билд в репозиторий, откуда новая версия (при правильной настройке) сама, рано или поздно, расползется по кластеру. Единственная проблема, это если у вас зоопарк типа Debian, CentOS и т.д. Хотя на Debian можно поставить RPM, а на CentOS DEB, но я так не люблю.
сама, рано или поздно, расползется по кластеру.


Я вам точно не скажу сейчас, просто не на моем проекте сейчас но с packer'ом и terraform тоже можна похожие вещи делать. У нас есть проект где packer создает image для google compute engine с уже готовым к работе проектом. В google compute инстансы создаються из последнего собраного image (не надо вам парится тогда и о том где rpm а где deb).

Terraform`мом можна описать как всю инфраструктуру поднять ( какие прокинуть порты, настроить load balancer и тд) Довольно акуратно и просто, плюс видиш сходу изменения с эволюцией проекта со временем (Infrastructure as a Code)

На проекте которым я сейчас занимаюсь, описано 3 инстанса в связке packer и terraform на aws. Кстати подход к деплою у нас — immutable server (у ребят с google compute тоже). Суть immutable deploy в том, что на сервере ничего не менять, а когда доступная новая версия, убирать инстанс со старой кодовой базой на новую. (Хотя я вполне подозреваю что вы знакомы с этим подходом) Как плюс можна довольно легко поднять зеркально новую групу серверов и потестировать самому все а потом переключить Load balancer на новую групу, и если что то не так переключить обратно (blue/green deployment кажеться). Можна сохранять версии images которые создал packer и опять же пересобирать как хочеш.

Кстати packer спокойно собирает и пресловутым Docker так что, как билдить решать вам самим =)
Я, лично, только начал с ними работать, перенимаю опыт у ребят с другой команды но перспективы радуют.
Потом все это можна и под СІ подогнать.

Думаю потом если все пойдет ок то можно будет и статейку оформить, хехе :)

P.S: простите за плохой руский :(
Для меня деплой — это, скорее меньшее. Ансибль подготавливает среду для депплоя, грубо, ставит и конфигурит демоны по команде. А за деплой отвечают другие инструменты
Столь приличная по размеру статья про деплой и ни слова про контейнеры? Хммм

А где Docker?
Зачем вообще Vagrant если есть Docker?
Где оркестрация контейнеров? Балансировка контейнеров?
staging, testing, production, a/b?
Или я попал во вневременную дыру и читаю статью из 2007 года а не 2017?

не все то конейнеры, что в продакшене :)
для докера необходимо вводить stateless и желательно ci&cd, а как уже заметили выше, этот момент пропущен
Извините, но Docker не замена Vagrant

Для того что написано в статье (тестирования chef кукбуков) можно обойтись kitchen + docker. Так что в полне себе замена.

А почему и нет? Если речь о локальной разработке, то вполне можна взять docker image с Ubuntu(как пример) установить локально ssh и необходимие зависимости (php/python/java/nginx/apache/mysql ....) прокинуть порт и потом через volume залинковать проект в контейнер. Сумарно он будет быстрей Vagrant (но далеко не везде, на том же маке Vagrant иногда шустрей)

P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
ошибся веткой
А почему и нет? Если речь о локальной разработке, то вполне можна взять docker image с Ubuntu(как пример) установить локально ssh и необходимие зависимости (php/python/java/nginx/apache/mysql ....) прокинуть порт и потом через volume залинковать проект в контейнер. Сумарно он будет быстрей Vagrant (но далеко не везде, на том же маке Vagrant иногда шустрей)

P.S: Vagrant может под капотом работать с докером: https://www.vagrantup.com/docs/docker/
на том же маке Vagrant иногда шустрей
На Маках вроде нет нативного докера, в фоне загружается виртуальная машина с Linux.
НЛО прилетело и опубликовало эту надпись здесь
странно в докладе про деплой ни одного слова про capistrano
более того если большая часть доклада про деплой с помощью ansible то было-бы логично упомянуть ansistrano

Если ansible неделя, chef — недели, то puppet — это месяцы. Особенно если с нуля строить.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий