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

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

Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов.


Да разве? В release notes пишут что парарллелизм есть давно.
Каюсь, не углядел за развитием cap (видимо я давно им раздосадован). В ансибл, однако, параллелизм это поведение по умолчанию, без конструкций вроде on :all, in: :parallel
Для rolling update сомнительное преимущество. Но если админ локалхоста, то нормально.
Параметр serial в настройках плейбука можно указать единожды и наслаждаться выкатыванием релизов с комфортным вам размером пачки (можно даже в процентах указать).
Так же интересной для такого варианта, является настройка max_fail_percentage, которая прекратит деплой немедленно, если релиз завалился на определенном количестве хостов.

docs.ansible.com/ansible/playbooks_delegation.html
Я понимаю что можно это и ансиблом сделать, суть не в этом. Суть в том что это не преимущество для системы деплоя.
Хорошая статья!

Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения.

Почему нельзя? Можно создать сколько угодно окружений для развертывания, указав для них в настройках существующий :rails_env

Кстати, не заметил у вас ansible-задачи для rollback'а приложения, думаю стоит добавить упоминание о нем в статье
Написал про роллбек в заключении статьи. Спасибо!
Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.

В каком месте в капистране вообще связь с рельсами???
cap install в пустой папке и указать нужные гит-репо адрес / ветки / итд

Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.

Можно просто не использовать плагины, а фигачить код вручную

Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Никто не запрещает деплоить капистараной что угодно. Сделать пулл и запустить баш-команду можно для любой технологии
Ваш вариант, конечно рабочий, но его принято считать экзотичным.
Более того, с помощью cap можно деплоить что-то в чем вообще нет руби.
Но как по мне — при таком варианте капистрано деградирует до rake + SSHKit.
Да и еще я замечу, что практика «держать только development, test и production окружения» хороша, только в случае наличия только трех этих окружений.
При появлении стейжа, должен появится новый rails-env

По поводу капистраны в случае использования «хорошей практики» — добавить новый стейдж в капистрану, и в стейдже написать «set :rails_env, 'super-stage'»
А вот я против выделения stage как отдельного, отличного от production, окружения, как по концептуальным, так и по практическим причинам.
Ведь стейдж по-сути что? Это сервер для тестирования кода, в окружении максимально близком к продакшену. А значит, добавление нового rails-окружения вносит дополнительные различия между стейджем и продакшеном, что негативно для самой идеи стеджа, не говоря о том, что всегда можно что-то упустить из виду в конфигурации нескольких окружений и получить ошибку на проде, после успешного тестирования кода на стейдже.
github.com/ansistrano/deploy — тут люди замутили капистрано на ансибле, и про ролбэк они не забыли.
Плюсую. Особенно напрягает качество плейбука в данной статье. За файл 'ansible/release.yml' отдельно хочется отрывать руки. Если вы сами суть работы с Ansible не понимаете, то, умоляю, не пытайтесь других людей учить плохому.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории