Комментарии 2
С точки зрения реализации основная проблема сводится к обеспечению идемпотентности при создании и удалении review-окружений.
Можно уточнить, что такое «идемпотентность при создании...»? Второе «создание окружения» дает тот же результат, что и первое?
Да, верно.
Нам нужно, чтобы на момент повторного деплоя ревью с нуля (как пример можно взять ситуацию, когда мы перед данным деплоем полностью остановили ревью окружение) у нас гарантированно не было объектов (базы данных, vhost и так далее) из предыдущего деплоя. Именно это и является главной проблемой при реализации — если БД уже существует, то в момент деплоя мы получим ошибку/некорректно созданное окружение. В «обычном» варианте ревью это не проблема — объекты релиза находятся в одном namespace, достаточно полностью удалить namespace. В нашем варианте сложнее, так как еще есть база данных в PostgreSQL и MongoDB + vhost в RabbitMQ на отдельном хосте. Поэтому при повторном деплое должно гарантированно удаляться/создаваться по необходимости.
Нам нужно, чтобы на момент повторного деплоя ревью с нуля (как пример можно взять ситуацию, когда мы перед данным деплоем полностью остановили ревью окружение) у нас гарантированно не было объектов (базы данных, vhost и так далее) из предыдущего деплоя. Именно это и является главной проблемой при реализации — если БД уже существует, то в момент деплоя мы получим ошибку/некорректно созданное окружение. В «обычном» варианте ревью это не проблема — объекты релиза находятся в одном namespace, достаточно полностью удалить namespace. В нашем варианте сложнее, так как еще есть база данных в PostgreSQL и MongoDB + vhost в RabbitMQ на отдельном хосте. Поэтому при повторном деплое должно гарантированно удаляться/создаваться по необходимости.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из жизни с Kubernetes: Как мы выносили СУБД (и не только) из review-окружений в статическое