Но данные так или иначе будут в одном дата-центре / зоне доступности и всегда будет вероятность их уничтожения. К тому же у низкой цены и "безлимитного" тарифного плана для частников есть свои подводные камни — за мелкий прайс никто не будет гарантировать ни сколь-либо высокой SLA, ни возможности восстановить данные после сбоя, так как подразумевается, что в таком сервисе хранят личные данные обычных люди, да и "мужик всё стерпит".
Допустим, случится какой-то фатальный сбой дисковой подсистемы СХД в котором хранились данные с вашего аккаунта. Восстановят данные Н-дневной давности (если восстановят) и скажут что сделали что могли (и это будет правдой). Лучше хранить данные на двух ДЦ сразу, чем несколько копий в одном.
А вот я против выделения stage как отдельного, отличного от production, окружения, как по концептуальным, так и по практическим причинам.
Ведь стейдж по-сути что? Это сервер для тестирования кода, в окружении максимально близком к продакшену. А значит, добавление нового rails-окружения вносит дополнительные различия между стейджем и продакшеном, что негативно для самой идеи стеджа, не говоря о том, что всегда можно что-то упустить из виду в конфигурации нескольких окружений и получить ошибку на проде, после успешного тестирования кода на стейдже.
Параметр serial в настройках плейбука можно указать единожды и наслаждаться выкатыванием релизов с комфортным вам размером пачки (можно даже в процентах указать).
Так же интересной для такого варианта, является настройка max_fail_percentage, которая прекратит деплой немедленно, если релиз завалился на определенном количестве хостов.
Ваш вариант, конечно рабочий, но его принято считать экзотичным.
Более того, с помощью cap можно деплоить что-то в чем вообще нет руби.
Но как по мне — при таком варианте капистрано деградирует до rake + SSHKit.
Каюсь, не углядел за развитием cap (видимо я давно им раздосадован). В ансибл, однако, параллелизм это поведение по умолчанию, без конструкций вроде on :all, in: :parallel
Допустим, случится какой-то фатальный сбой дисковой подсистемы СХД в котором хранились данные с вашего аккаунта. Восстановят данные Н-дневной давности (если восстановят) и скажут что сделали что могли (и это будет правдой). Лучше хранить данные на двух ДЦ сразу, чем несколько копий в одном.
Ведь стейдж по-сути что? Это сервер для тестирования кода, в окружении максимально близком к продакшену. А значит, добавление нового rails-окружения вносит дополнительные различия между стейджем и продакшеном, что негативно для самой идеи стеджа, не говоря о том, что всегда можно что-то упустить из виду в конфигурации нескольких окружений и получить ошибку на проде, после успешного тестирования кода на стейдже.
Так же интересной для такого варианта, является настройка max_fail_percentage, которая прекратит деплой немедленно, если релиз завалился на определенном количестве хостов.
docs.ansible.com/ansible/playbooks_delegation.html
Более того, с помощью cap можно деплоить что-то в чем вообще нет руби.
Но как по мне — при таком варианте капистрано деградирует до rake + SSHKit.