Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов.
Да разве? В release notes пишут что парарллелизм есть давно.
Каюсь, не углядел за развитием cap (видимо я давно им раздосадован). В ансибл, однако, параллелизм это поведение по умолчанию, без конструкций вроде on :all, in: :parallel
Для rolling update сомнительное преимущество. Но если админ локалхоста, то нормально.
Параметр serial в настройках плейбука можно указать единожды и наслаждаться выкатыванием релизов с комфортным вам размером пачки (можно даже в процентах указать).
Так же интересной для такого варианта, является настройка max_fail_percentage, которая прекратит деплой немедленно, если релиз завалился на определенном количестве хостов.
docs.ansible.com/ansible/playbooks_delegation.html
Так же интересной для такого варианта, является настройка max_fail_percentage, которая прекратит деплой немедленно, если релиз завалился на определенном количестве хостов.
docs.ansible.com/ansible/playbooks_delegation.html
Хорошая статья!
Почему нельзя? Можно создать сколько угодно окружений для развертывания, указав для них в настройках существующий :rails_env
Кстати, не заметил у вас ansible-задачи для rollback'а приложения, думаю стоит добавить упоминание о нем в статье
Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения.
Почему нельзя? Можно создать сколько угодно окружений для развертывания, указав для них в настройках существующий :rails_env
Кстати, не заметил у вас ansible-задачи для rollback'а приложения, думаю стоит добавить упоминание о нем в статье
Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
В каком месте в капистране вообще связь с рельсами???
cap install
в пустой папке и указать нужные гит-репо адрес / ветки / итдПлагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
Можно просто не использовать плагины, а фигачить код вручную
Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.
Никто не запрещает деплоить капистараной что угодно. Сделать пулл и запустить баш-команду можно для любой технологии
Ваш вариант, конечно рабочий, но его принято считать экзотичным.
Более того, с помощью cap можно деплоить что-то в чем вообще нет руби.
Но как по мне — при таком варианте капистрано деградирует до rake + SSHKit.
Более того, с помощью cap можно деплоить что-то в чем вообще нет руби.
Но как по мне — при таком варианте капистрано деградирует до rake + SSHKit.
Да и еще я замечу, что практика «держать только development, test и production окружения» хороша, только в случае наличия только трех этих окружений.
При появлении стейжа, должен появится новый rails-env
По поводу капистраны в случае использования «хорошей практики» — добавить новый стейдж в капистрану, и в стейдже написать «set :rails_env, 'super-stage'»
При появлении стейжа, должен появится новый rails-env
По поводу капистраны в случае использования «хорошей практики» — добавить новый стейдж в капистрану, и в стейдже написать «set :rails_env, 'super-stage'»
А вот я против выделения stage как отдельного, отличного от production, окружения, как по концептуальным, так и по практическим причинам.
Ведь стейдж по-сути что? Это сервер для тестирования кода, в окружении максимально близком к продакшену. А значит, добавление нового rails-окружения вносит дополнительные различия между стейджем и продакшеном, что негативно для самой идеи стеджа, не говоря о том, что всегда можно что-то упустить из виду в конфигурации нескольких окружений и получить ошибку на проде, после успешного тестирования кода на стейдже.
Ведь стейдж по-сути что? Это сервер для тестирования кода, в окружении максимально близком к продакшену. А значит, добавление нового rails-окружения вносит дополнительные различия между стейджем и продакшеном, что негативно для самой идеи стеджа, не говоря о том, что всегда можно что-то упустить из виду в конфигурации нескольких окружений и получить ошибку на проде, после успешного тестирования кода на стейдже.
github.com/ansistrano/deploy — тут люди замутили капистрано на ансибле, и про ролбэк они не забыли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ansible и Rails — гибкая замена Capistrano с сохранением знакомого комфорта