Развёртка приложения Next.js с GitLab CI/CD и Docker на Ubuntu 22.04

hddnsk

6 лет назад

Зачастую приходится запускать проект на каком-нибудь сервере: проверка функционирования системы перед сдачей, показ заказчику, или просто посмотреть на поведение в WEB. Причина может быть любой.

И вот, каждый раз выгружая изменения через «Remote Host» в WebStorm, или через git, вконец задолбашись колупаться с SSH удалённого сервера в терминале, ты придёшь к мысли: «А можно чтобы мои изменения разворачивались сами?».

Здесь вы найдете самое простейшее руководство о развёртывании приложения на примере GitLab CI/CD + Docker + Next.js.

Проверим наш проект

Представим что у нас уже есть проект. Мы знаем команды запуска, сборки, работы dev-режима, и спокойно себе работаем с приложением у себя на компьютере.

Next.js по умолчанию имеет команды:

next dev - режим разработки
next build - сборка проекта перед запуском
next start - собственно запуск
next lint - запуск Linter для проверки кода

В примере воспользуемся командами build и start, и если ты ничего не менял в config-файлах, то еще и порт 3000.

Представим что мы уже умеем работать с git и успешно смогли залить проект в GitLab.

Возможно в будущем напишу статью как работать с git, но мы здесь не об этом.

Настройка Docker

Можно задаться вопросом: «на кой хрен он нам нужен»?

Очень часто на предоставляемом сервере уже есть какое-то ПО, и дабы зависимости от вашего проекта не задели кого-то еще, программисты придумали много классных (и ппц каких сложных) инструментов облегчающих жизнь обывателю. Один из них — Docker.

Как конь в вакууме, Docker в контейнерах собирает нужную в себе изолированную среду для приложений. Вообще для любых. PHP версии 5.2 с MySQL 4.1 для проекта доставшегося по наследству от бабки? Легко!

Весь этот цирк с конями будет вариться в своём мирке, не мешая при этом работе сервера. Вот так вот.

Создаём в корне проекта файл с именем Dockerfile. Да, без каких-либо расширений. Прям так.

# Указываем нужное ПО. В данном случае NODE версии LTS сборки ALPINE
FROM node:lts-alpine

# Создаём папку где будем временно хранить исходники
RUN mkdir -p /usr/src/frontend
WORKDIR /usr/src/frontend

# Копируем файлы
COPY . .

# Устанавливаем зависимости и собираем проект
RUN npm install
RUN npm run build

# Указываем что будет использоваться порт 3000
EXPOSE 3000

# Запускаем проект
CMD [ "npm", "run", "start" ]

В официальной документации команд намного больше, как и вариаций их использования. Напомню: статья для ознакомления с самой темой и на какие-то медали она не претендует.

Настройка GitLab CI/CD

Не долго думая создаём ещё один файл .gitlab-ci.yml

image: docker:latest

services:
  - docker:dind

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - docker build -t app/frontend .
    - docker rm frontend --force || true
    - docker run -d -p 3000:3000 --rm --name frontend app/frontend
    - echo "y" | docker system prune
  only:
    - main

В конце данного конфига говорим Docker‘у:

Создай сборку контейнера с названием app/frontend.
Останови все старые контейнеры с именем frontend, либо пропусти шаг.
Запусти собранный контейнер app/frontend под именем frontend с использованием порта 3000.
Удаляем старые неиспользуемые образы.
Работаем только с кодом из ветки main.

Имена и порт можно прописать абсолютно любые.

Прекрасно! Оба выше-созданных файла отправляем на git.

Настраиваем сервер

А вот и самый главный театр абсурда. Прописывать команды нужно аккуратно и желательно заранее подготовится прочитав всю статью.

За пример берём сервер на Ubuntu 22.04. В CentOS и прочих Rocky Linux вместо apt используем yum или dnf.

Лучший облачный сервер с SSD за 50 секунд! Низкие цены как с ежемесячной оплатой, так и почасовой. Для своих проектов использую только его .

Устанавливаем Docker

Все действия производятся НЕ ИЗ ПОД ПОЛЬЗОВАТЕЛЯ ROOT!

Существует классический вариант установки который вы можете посмотреть на официальном сайте Docker.com, и вот новичкам советую туда даже украдкой не заглядывать. Даже на огонёк. Воспользуемся лучше snap:

sudo apt update && sudo apt upgrade -y
sudo apt install snapd

Как установится snap, ставим сам Docker:

sudo snap install docker

Если появляется ошибка Mount snap «docker» (15067) (snap «docker» assumes unsupported features: snapd2.59 (try to update snapd and refresh the core snap)), то пишем:

sudo snap install core

После установки выдадим ему права от текущего пользователя:

sudo groupadd docker
sudo usermod -aG docker $USER

Перезагружаем сервер любым способом. Например:

sudo reboot

Устанавливаем GitLab CI/CD

Данный шаг чуть-чуть сложнее. Танцы с бубном отсутствуют, но будь аккуратней.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

На этом месте возможно зависнет в ожидании пароля. Вводим его и жмакаем ENTER.

sudo apt-get install gitlab-runner
sudo gitlab-runner start

Установили? Хорошо, регистрируем pipeline:

sudo gitlab-runner register

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
# Если у тебя не свой личный gitlab с пасьянсом и доменом, то просто жмём ENTER

Please enter the gitlab-ci token for this runner:

На этом шаге стоит остановиться. Токен можно получить выполнив следующие действия:

Открываем страницу проекта на GitLab.
Слева ищем Settings — CI/CD.
Находим Runners и жмём Expand.
В развернувшимся блоке прямо под надписью And this registration token: копируем сам токен и вставляем его прямо в терминал.

Please enter the gitlab-ci description for this runner:
# Указываем что за runner мы тут вообще запускаем. Следуя примеру статьи, пиши frontend-web

Please enter the gitlab-ci tags for this runner (comma separated):
# Пропускаем нажатием ENTER

Please enter the executor: ssh, virtualbox, kubernetes, docker, docker-ssh, shell, docker+machine, docker-ssh+machine, custom, parallels:
# Пишем shell

Вуаля! Вы великолепны!

Работа напильником

Осталось буквально три команды и включение одной галочки. Первая выдаёт необходимые права Docker и Gitlab-Runner:

sudo usermod -aG docker gitlab-runner

А вторая добавляет GitLab Runner в sudoers-лист:

sudo nano /etc/sudoers

Открывается редактор, листаем в самый-самый низ до упора и добавляем следующую строчку:

gitlab-runner ALL=(ALL) NOPASSWD: ALL

Ctrl + X, Y, Enter. В общем, сохраняем документ.

sudo gitlab-runner restart
# Перезапускаем runner

Открываем страницу где брали токен. Под ним должен появится пункт Available specific runners. Жмём на иконку с карандашиком и ставим галочку на Run untagged jobs.

Вы снова великолепны! Поздравляю!

Куда смотреть дальше?

На этом шаге уже запущен в работу свой pipeline и можно отслеживать как развёртывается приложение.

Где смотреть? А я щас скажу:

На странице проекта слева ищем пункт CI/CD — Pipelines.
Выбираем самый первый пункт из списка, нажав на кнопку в столбце Status.
Внизу видим все стадии. Если делали как в примере, то у вас только Deploy. Жмём на него.
Здесь проходит процесс установки и отладки при ошибках.

Если вдруг что-то пойдет не так, на третьем шаге из списка выше GitLab сообщит в чём проблема. При успешном выполнении сборки в статусе будет написано passed.

Тестируем приложение! Открытием адреса http://ip_адрес_сервера:3000/ получаем райское наслаждение, ощущение всевластия и вкус свежего Kilkenny прямиком из Ирландии.

Заключение

Простейший пример использования данной связи ПО облегчит жизнь не только с личным сервером 2-ядра-2-гига, но и админам инфраструктуры, к которым рано или поздно придется лезть ручками.

Данным процессом мы сокращаем тонну времени, ведь лучше оное потратить на чтение форума по MODX, чтение новостей из Telegram, или вообще на создание крафтого пива из твоих старых носков.

А теперь представь сколько всего можно сделать: добавить тесты в приложение, прогнать их в отдельной стадии CI/CD и в случае ошибок остановить процесс, получив при этом уведомление на почту.

Всё зависит только от твоей фантазии и/или потребностей.