Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Деплой на PaaS (Heroku, Render) дает нам представление того, как организовать его самостоятельно, на свой сервер. В общем случае, процесс выглядит так:

2 <ol><li>Клонирование репозитория</li>

3 <li>Сборка проекта. В нашем случае установка зависимостей</li>

4 <li>Доставка на сервера. У нас пока один сервер</li>

5 <li>Остановка старой версии и запуск новой</li>

6 </ol>С точки зрения 12 факторов, важно разделять<a>процесс сборки и релиза</a>. Представьте что у нас 10 машин. Если мы начнем клонировать репозиторий на каждую из машин и выполнять там сборку, то получим множество неудобств:

7 <ol><li>Если сборка пройдет неуспешно, то мы просто потратим ресурсы серверов впустую.</li>

8 <li>Скачивание зависимостей это трафик, который стоит денег. Умножаем вес зависимостей на количество серверов.</li>

9 <li>В случае отката на предыдущую версию, придется долго ждать пока заново выполнится сборка. Проблема даже с одним сервером.</li>

10 </ol>Сборка, обычно, выполняется отдельно от релиза. Чаще всего ей занимается CI, который, после выполнения всех проверок, формирует какой-то артефакт: пакет под операционную систему (например deb), архив, Docker-образ. Последний стал стандартом де-факто. Все так или иначе переехали на Docker.

11 Разберем, как организовать сборку через CI, для любого проекта на примере<a>devops-example-app</a>

12 <h2>Сборка</h2>

13 Первым делом, нужно создатьDockerfileи добавить туда все шаги для подготовки приложения. Обычно это делается так, гуглится статья (<a>официальные примеры</a>), в которой упаковывается приложение на том же фреймворке и дальше методом проб и ошибок этот процесс повторяется, до тех пор, пока локально получится собрать образ, запустить его и увидеть готовое приложение. Для нашего приложенияDockerfileвыглядит так:

14 КогдаDockerfileготов, а образ собирается и запускается, пора создать аккаунт на<a>Docker Hub</a>. Внутри добавляется репозиторий для хранения нашего Docker-образа, и, наконец, выполняется docker push. Так мы получаем образ, готовый для деплоя.

15 Остается последний шаг - автоматизация сборки с помощью<a>Github Actions</a>. Причем она будет практически идентичная для всех проектов, которые собираются с помощью Docker независимо от стека.

16 В этом workflow собирается образ с тегомlatest, который обновляется после каждого коммита и успешного прохождения тестов. При таком подходе будет невозможно узнать какая прямо сейчас версия на продакшене и, что совсем плохо, будет невозможно откатиться на другую версию, если что-то пойдет не так. Поэтому помимо образаlatest, который полезен для постоянного тестирования процесса сборки, нужен отдельный workflow, в котором готовятся образы с тегами под каждую версию.

17 Такой workflow запускается не на коммиты, а на создание тега в git. Этот же тег затем используется и для Docker-образа. Ниже пример обновленного workflow, который нам подходит:

18 Запуск проверок дляlatestне нужен, так как он уже был проверен во время сборки по коммиту. Это сэкономит время на сборку.

19 В этой системе есть один момент, который нужно учитывать. Создавать тег можно только тогда, когда выполнится сборкаlatest. Иначе этот воркфлоу сделает тег из старого образа. Обойти это ограничение можно автоматическим созданием тега во время пуша в git-репозиторий.