Как правильно деплоить?

Добрый день.

Интересует несколько вопросов касаемо правильного деплоя.

У меня есть Yii2 проект, поднятый и локально разрабатываемый на Docker.
При этом все изменения пушатся в репозиторий на GitLab.
Пришла пора опубликовать его на сервере, но синхронизировать код с опр. веткой на GitLab с запуском консольных команд для миграций.

Перед настройкой .gitlab-ci.yml надо подготовить окружение:

1. Docker: у меня пока только docker-compose для dev разработки, необходимо понять, каким он должен быть для prod:
  • Надо удалить из prod volumes? В том числе для composer cache?
  • Какая network в prod должна быть?
  • Environments перенести из .env файла? Или вообще секретные ключи хранить в GitLab?
  • restart: always для каждого контейнера? Или при настройки бесшовного деплоя могут возникнуть проблемы?


2. База данных
  • Нужен ли для базы данных отдельный сервер с настройкой VPN-туннеля, чтобы доступ к ней был только для деплой-сервера и опр. IP?
  • Если да, то можно ли поднять базу данных в Docker? Лень настраивать MySQL ручками. Или будут проблемы с VPN-туннелем из-за Docker прослойки?


3. Прочее
  • Как лучше деплоить? Поднять GitLab runner на деплой-сервере либо через SSH копировать?
  • Есть какие-то нюансы в настройки nginx-конфигов для prod?


Любые советы по подготовке проекта к деплою будут очень кстати! Хочу все сделать грамотно

Заранее спасибо!
  • Вопрос задан
  • 760 просмотров
Решения вопроса 1
amark
@amark
rush less, feel more
привет.
Пойдем не по порядку.

Первое – БД
Для чего выносят на отдельный сервер? Делается это, как правило, когда первоначальный сервер не тянет из-за большого количества запросов к БД. У вас сейчас такая ситуация? Да – выносить на отдельный сервер. Нет – оставить сервера в покое.

VPN – тоже оставьте в покое. Если надо выносить БД в отдельный сервер, то тогда иногда имеет смысл закрыть внешку и оставить только VPN.

Docker – докер на проде? У вас точно такой серьезный ресурс, что нужно поднимать в день по несколько VDS и нужен докер? Когда на локале докер еще можно понять – удобство и без мусора. Но на проде? Или есть лишние деньги/ресурсы?
Похоже, что докер тоже стоит оставить только на локале и в покое.

Секретные ключи – это вообще никогда нельзя хранить в репозитории. Иногда можно использовать компромисс – зашифрованные файлы. Но тут нельзя быть в покое и следует всё проверить несколько раз.

минутка занимательной теории:
Как работает деплой? (пример из жизни в очень общих чертах для понимания принципиальной схемы)

Разработчик отправляет пуш в гит. После этого гит кидает оповещение в CI&CD-сервис.
CI&CD-сервис запускает свой процесс, согласно описанному в запушеной ветке протоколу (конфиг сервиса).

Обычно, порядок действий в CI&CD-сервисе такой:
– поднимается контейнер с ОС
– в контейнере разворачивается репо
– подтягиваются все зависимости, настраивается окружение, поднимается база с сидами.
– накатываеются миграции
– прогоняются тесты

Далее запускается скрипт деплоя:
– репо заливается на сервер, например, с помощью rsync или другого инструмента (в этом месте мы используем зашифрованные приватные ключи для доступа к конечному серверу)
– на сервере запускается рутина обновления (например, накатить миграции, обновить конфиги, перезагрузить сервисы)

По окончанию приходит уведомление о статусе. Например в слак.

Все счастливы, разработчик отмечает успех (или устраняет результаты безуспешных тестов).

P.S. Если у вас возникают эти вопросы, то, похоже, вы не DevOps'или раньше.
И это не предмет для обиды или оскорбления, а, наоборот, предмет для размышления над сложностью решений. Сейчас создается впечатление, что вы хотите стрельнуть себе в колено, причем из дробовика.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
dyuriev
@dyuriev
A posteriori
модное слово "Деплой" - это по сути автоматизация рутинных действий

  1. выпишите список команд и условий, как бы вы делали это все вручную
  2. попейте чая, отвлекитесь
  3. свежим взглядом найдите места, которые можно улучшить
  4. улучшите


поздравляю, у вас готов алгоритм пайплайна для вашего проекта.

PS: докер для "деплоя" не всегда обязателен
Ответ написан
SayMAN83
@SayMAN83
Работаю в IT
1. >Какая network в prod должна быть?
Работая на поддрежке в одном банке(ТОП10) каждая среда (тест/препрод/ПРОД) находились в разных изолированных друг от друга подсетях. Среда подразумевала связанный контур - фронт-шина-бэкенд-БД в одной подсети.
В других банках подсетями не заморачивались. Так же в крупной компании, где я сейчас работаю так же нет изоляции между системами.
2.1 Зачем вам VPN и весь этот геморой?
2.2 БД в докере... На мой взгляд, так себе решение. Хотя смотря что за БД и какая на ней нагрузка. У нас продуктовая БД вообще как отдельная инфраструктура и серваки там овердохера RAM.
3. Для "деплоя" рассмотрите вариант с артефактами в gitlab. По крайней мере я так сделал на своем проекте. Сборка у меня происходит на одном серваке, а деплой на другом. При этом не надо заниматься онанизмом с копированием между серваками.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
04 дек. 2020, в 10:20
20000 руб./за проект
04 дек. 2020, в 09:56
12000 руб./за проект
04 дек. 2020, в 08:53
10000 руб./за проект