Введение
Разработка программного обеспечения — это быстроразвивающаяся и конкурентная область. Более быстрый выпуск продуктов для пользователей даст вам преимущество перед конкурентами. С другой стороны, существуют передовые отраслевые практики, которые помогают компаниям конкурировать на равных.
Непрерывная интеграция и непрерывное развертывание (CI/CD) — это пример стратегии, которая использует передовые отраслевые практики, чтобы дать компаниям преимущество в этой конкурентной борьбе.
GitHub, веб-репозиторий с инструментом контроля версий Git, позволяет разработчикам, инженерам и архитекторам программного обеспечения внедрять CI/CD. Непрерывное развертывание (CD) — это практика автоматизации сборок, тестирования и развертывания. Непрерывная интеграция (CI) позволяет многим людям совместно работать над одним проектом и проверять работоспособность кода, не беспокоясь о конфликтах слияния.
GitHub Actions позволяют нам описывать шаги, которые автоматизируют сборку, тестирование и развертывание.
В этом руководстве вы узнаете, как настроить непрерывную интеграцию с помощью GitHub Actions. Мы начнем с настройки репозитория Git для размещения нашего кода. Затем мы настроим процесс GitHub CI для отслеживания изменений в нашем коде, запуска CI-раннера для выполнения тестов, сборки и развертывания нашего приложения на сервере Ubuntu 22.04 под управлением Nginx.
Предварительные требования
Для выполнения этого руководства вам понадобится следующее:
-
Сервер под управлением Ubuntu 22.04. Вы можете использовать это руководство для первоначальной настройки сервера Ubuntu, добавления пользователя без прав root, и включения брандмауэра UFW в Ubuntu.
-
Вам понадобится установленный на сервере Node.js, желательно версии 14 и выше. У нас есть руководство по установке Node.js на Ubuntu.
-
Вам понадобится установленное серверное ПО Nginx. У нас есть руководство по установке Nginx на сервере под управлением Ubuntu.
-
Вам понадобятся Docker и Docker Compose, установленные на вашей локальной машине для запуска изолированной среды разработки. Пожалуйста, следуйте нашему руководству, чтобы узнать, как установить и использовать Docker в облаке.
Теперь, когда у нас есть все необходимое, давайте начнем.
Шаг 1. Клонирование репозитория проекта.
Мы будем базировать это руководство на Reactjs, декларативной библиотеке JavaScript для создания пользовательских интерфейсов. Если вы хотите настроить новый проект с нуля, вы можете использовать этот ресурс по настройке приложения React. Для краткости мы будем использовать клон этого репозитория React.js, который мы уже настроили на GitHub.
Приложение, которое мы клонируем, представляет собой простое приложение React с react-router 6 и тестом, выполненным с помощью React Testing Library, которая предоставляет нам методы для доступа к DOM.
Чтобы клонировать репозиторий, нажмите на зеленую кнопку и скопируйте URL-адрес.
Откройте терминал в вашей рабочей области и выполните команду ниже, чтобы клонировать приложение:
|
1 |
git clone git@github.com:EspiraMarvin/cicd-tut.git |
После клонирования репозитория перейдите в каталог проекта:
|
1 |
cd cicd-tut |
Запустите команду docker-compose up, чтобы собрать и запустить приложение:
|
1 |
docker-compose up --build --force-recreate |
Когда процесс завершится, перейдите по адресу http://localhost:3000
Вы должны увидеть что-то похожее на это:
Шаг 2. Понимание файла Node.js.yml.
На этом шаге мы определим директивы в YAML-файле GitHub, чтобы понять, что происходит. В репозитории есть каталог .github/workflows, который содержит node.js.yml файл, содержащий шаги рабочего процесса, которые выполняют раннеры GitHub после того, как вы отправите изменения в свой репозиторий кода на GitHub. YAML синтаксис используется для написания рабочих процессов для GitHub Actions. Файлы YAML заканчиваются расширением yaml или yml.
Откройте node.js.yml файл, он должен выглядеть следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
name: cicd-tut on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: # Тип раннера, на котором будет выполняться задача runs-on: self-hosted strategy: matrix: node-version: [16.x] # Шаги представляют собой последовательность задач, которые будут выполнены в рамках задачи steps: - name: 'checkout' uses: actions/checkout@v3 - name: 'setup node actions' uses: actions/setup-node@v3 with: node-version: "16" cache: 'npm' - run: npm i - run: npm test - run: npm run build # - run: cp -r ~/actions-runner/cicd-react/react-tut-test/react-tut-test/build /var/www/react-cicd |
На момент написания этого руководства мы использовали версию 16 Node.js 16. Теперь давайте разберемся в рабочем процессе GitHub Actions:
-
name
name: cicd-tut
Имя вашего рабочего процесса, это имя будет отображаться в вашем репозитории Actions вкладке.
-
on
|
1 2 3 4 5 |
on: push: branches: [ "main" ] pull_request: branches: [ "main" ] |
on используется для определения событий. События могут автоматически запускать рабочий процесс или планироваться на более позднее время. События могут быть одиночными или множественными, вы также можете указать выполнение рабочего процесса для конкретных веток, тегов или файлов. Это работает как фильтр.
В нашем YAML-файле мы определяем несколько автоматических событий, а именно:
-
Событие push запускается, когда код отправляется в репозиторий
-
Событие pull_request запускается при создании пулл-реквеста в ветку main.
Мы указываем имя ветки main, чтобы ограничить выполнение рабочего процесса только этой веткой. Мы также можем указать ветки, которые следует игнорировать, используя флаг ! перед именем ветки.
-
jobs
Рабочий процесс по сути состоит из одной или нескольких задач. Эти задачи выполняются последовательно от первой до последней.
|
1 2 3 4 |
jobs: build: # The type of runner that the job will run on runs-on: self-hosted |
Каждая задача выполняется в среде раннера, указанной в runs-on. Вы можете выбрать запуск задач либо на раннерах GitHub, обозначаемых как ubuntu-latest, либо на self-hosted раннере, обозначаемом как self-hosted. Ваш выбор будет зависеть от количества необходимых вам задач. С собственными раннерами у вас будет больше гибкости и контроля над ресурсами.
На следующем шаге мы сначала запустим наши задачи на раннерах GitHub, а затем настроим собственный раннер GitHub на нашем собственном сервере.
-
strategy
Стратегия позволяет использовать переменные в определении одной задачи для автоматического создания нескольких запусков задач на основе комбинаций переменных.
В нашем YAML-файле у нас есть одна переменная для node-version, но если мы добавим еще одну для Node.js версии 18, например так: node-version: [16.x, 18.x], то матричная стратегия создаст 2 запуска задач для нашего приложения React для версий Node.js 16 и 18.
|
1 2 3 |
strategy: matrix: node-version: [16.x] |
-
steps
Шаги — это последовательность задач, из которых состоит работа. Шаги могут запускать команды, настраивать задачи, запускать экшены в вашем публичном репозитории или экшены, опубликованные в реестре Docker.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
steps: - name: 'checkout' uses: actions/checkout@v3 - name: 'setup node actions' uses: actions/setup-node@v3 with: node-version: "16" cache: 'npm' - run: npm i - run: npm test - run: npm run build |
Шаг имеет имя. Хотя оно необязательно, вы можете использовать его, чтобы указать простое имя для вашего шага, которое будет отображаться на GitHub.
В шаге вы можете выбрать действие для запуска в вашей задаче, действия можно использовать повторно. Версии действия указываются при его определении, это важно, так как предотвращает сбой вашего рабочего процесса, когда владелец действия публикует обновление.
В приведенном выше фрагменте кода checkout@v3 — это пример действия с указанной версией 3. Это действие извлекает ваш репозиторий, чтобы ваш рабочий процесс мог получить к нему доступ.
Некоторые действия, такие как actions/setup-node@v3 выше, имеют входные параметры, обозначаемые с помощью ключевого слова with, действия по настройке node требуют версии node 16 и кэширования npm.
-
run
Это действие запускает программы командной строки с использованием оболочки операционной системы.
В приведенном выше файле YAML у нас есть три команды, все они будут запущены с использованием одной и той же оболочки в среде раннера.
-
Первая команда npm i устанавливает все зависимости, необходимые для нашего приложения React.
-
Вторая npm test, запускает написанный нами тест. Тест ожидает, что текст learn react будет отображен на главной странице.
-
Наконец, npm run build команда создает каталог сборки с продакшн-сборкой нашего приложения. Позже мы будем использовать этот каталог сборки в нашем блоке сервера Nginx.
Шаг 3. Тестирование GitHub CI с помощью GitHub Runners.
На этом шаге мы протестируем процесс непрерывной интеграции с помощью раннеров GitHub. Начните с открытия файла node.js.yml. Измените тип раннера, на котором будут запускаться действия, на ubuntu-latest. Цель этого — проверить, отлично ли работает рабочий процесс GitHub на раннерах GitHub, прежде чем настраивать наши собственные локальные раннеры (self-hosted).
|
1 2 3 |
jobs: build: runs-on: ubuntu-latest |
Создайте новый репозиторий в своем аккаунте GitHub. Прежде чем продолжить, вернитесь в каталог вашей рабочей области и удалите каталог .git, если вы его не видите, проверьте скрытые файлы. Вы можете использовать следующую команду в терминале, чтобы удалить этот каталог:
|
1 |
rm -rf .git |
Теперь вы можете добавить все файлы вашего проекта с помощью git add, закоммитить и отправить их в свой репозиторий. Если вы застряли, используйте это руководство по подключению папки вашего проекта к репозиторию GitHub который вы создали выше.
Когда закончите, нажмите на вкладку Code в вашем репозитории, и вы увидите маленькую оранжевую точку рядом с общим количеством коммитов. При нажатии на нее откроется модальное окно, похожее на приведенное ниже, указывающее, что ваш рабочий процесс поставлен в очередь:
Now click the Details link on the modal or go to the Actions, вы увидите каждый шаг рабочего процесса node.js.yml, выполняемый раннерами GitHub:
В случае успеха перейдите на вкладку Actions, она должна выглядеть следующим образом:
Вот и все, маленькая оранжевая точка на нашей вкладке Code теперь должна стать зеленой галочкой. Раннер GitHub успешно собрал наше приложение.
Now, let’s go a step further and change the build environment to use GitHub self-hosted runners in our own инфраструктуре серверов Ubuntu.
Шаг 4. Настройка рабочего процесса GitHub для использования локального раннера.
Прежде чем устанавливать локальный раннер на наш сервер, давайте вернемся в нашу рабочую область и отредактируем файл рабочего процесса node.js.yml для запуска на локальных раннерах GitHub.
|
1 2 3 |
jobs: build: runs-on: self-hosted |
На этом этапе, когда вы закоммитите изменения, задача будет поставлена в очередь, так как локальный раннер еще не определен.
В вашем репозитории перейдите на вкладку
Settings, на левой боковой панели нажмите
Actions, затем нажмите
Runners:
Нажмите New self-hosted runner, и выберите Linux в качестве операционной системы.
Вы увидите инструкции, показывающие, как скачать раннер и установить его на свой сервер.
Шаг 5. Установка и настройка локального раннера GitHub на нашем сервере.
На этом шаге мы настроим собственный (self-hosted) раннер GitHub. Собственный раннер — это система, которая может развертывать и управлять выполнением задач из GitHub Actions на веб-сайте GitHub. Одним из преимуществ собственного раннера перед раннером, размещенным на GitHub, является гибкость. Он предлагает больше контроля над операционной системой, аппаратным обеспечением и другими инструментами, которые можно настроить в соответствии с потребностями вашего приложения.
Собственные раннеры могут быть добавлены на различных уровнях, таких как:
-
Раннеры уровня репозитория, они предназначены для одного репозитория.
-
Раннеры уровня организации, они могут обрабатывать задачи для нескольких репозиториев в организации.
-
Раннеры уровня предприятия (Enterprise), которые могут быть назначены нескольким организациям.
Чтобы продолжить, войдите на свой сервер по SSH:
|
1 |
ssh username@server_ip |
Перейдите в свой домашний каталог с помощью команды:
|
1 |
cd ~ |
Затем создайте каталог с именем action-runners и перейдите в него:
|
1 |
mkdir actions-runner && cd actions-runner |
Затем загрузите последнюю версию пакета раннера:
|
1 |
curl -o actions-runner-linux-x64-2.298.2.tar.gz -L https://github.com/actions/runner/releases/download/v2.298.2/actions-runner-linux-x64-2.298.2.tar.gz |
Затем распакуйте загруженный пакет с помощью команды:
|
1 |
tar xzf ./actions-runner-linux-x64-2.298.2.tar.gz |
Вернитесь в свой репозиторий, на вкладке Settings на левой боковой панели нажмите Actions, затем Runners, как мы это делали на Step 4.
Вы увидите команду, содержащую токен, который связывает ваш собственный раннер с вашим репозиторием GitHub. Находясь в каталоге, в который вы распаковали код раннера GitHub, используйте указанную команду для привязки вашего раннера, например:
|
1 |
./config.sh --url https://github.com/EspiraMarvin/react-tut-test --token XXXXXXXXXXXXXXXXXXXXXXXXXXX |
Авторизация должна пройти успешно:
Нажмите Enter для выбора группы раннеров по умолчанию (Default).
Затем введите имя для вашего раннера, например, my-runner, и нажмите Enter.
Нажмите Enter, чтобы пропустить добавление дополнительных меток. Вы должны увидеть сообщение об успешном завершении, как на скриншоте ниже:
Введите имя вашего рабочего каталога, например, react-cicd, все должно пройти успешно с текстом settings saved.
Наконец, запустите ./run.sh, должно отобразиться Connected to Github:
Но это не работает в фоновом режиме. Если мы введем ctrl+c в нашем терминале, раннер остановится. Нам нужно заменить его службой .svc.sh чтобы раннер работал как служба, и мы могли продолжать взаимодействовать с ним.
Остановите раннер с помощью ctrl+c. Вы можете установить службу .svc.sh выполнив команду:
|
1 |
sudo ./svc.sh install |
После установки запустите службу с помощью команды:
|
1 |
sudo ./svc.sh start |
Это должно пройти успешно, показывая active (running).
Чтобы подтвердить, что служба svc.sh запущена и работает, выполните команду:
|
1 |
sudo ./svc/sh status |
На этом этапе любой рабочий процесс, который мог находиться в очереди в ожидании собственного раннера, должен успешно запуститься. Вы также можете отредактировать файл и протестировать работу. Например, измените файл О компании.tsx, закоммитьте и отправьте изменения (push) — собственный раннер успешно выполнит задачу.
Шаг 6. Настройка серверного блока Nginx
На этом шаге мы настроим серверный блок в Nginx для просмотра сборки нашего приложения React. У нас есть руководство по Настройке серверных блоков Nginx, которое может оказаться вам полезным.
Ниже приведен пример серверного блока, используемого в этом руководстве:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
server { listen 80; listen [::]:80; server_name react.test; root /var/www/react-cicd/build; index index.html index.htm index.nginx-debian.html; add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff"; charset utf-8; location / { try_files $uri $uri/ =404; } } |
Вы создадите файл конфигурации серверного блока Nginx внутри директории /etc/nginx/sites-available .
Откройте файл конфигурации серверного блока вашего сайта в редакторе nano с помощью команды:
|
1 |
sudo nano /etc/nginx/sites-available/react-cicd |
Скопируйте блок сервера, приведенный выше, измените его в соответствии с путями к вашим директориям и вставьте в открытый файл. Когда закончите редактирование, нажмите ctrl+x, затем нажмите y и enter для сохранения и выхода.
После сохранения создайте символическую ссылку для конфигурации серверного блока react-cicd из /etc/nginx/sites-available в /etc/nginx/sites-enabled, выполнив команду:
|
1 |
sudo ln -s /etc/nginx/sites-available/react-cicd /etc/nginx/sites-enabled/ |
Чтобы изменения вступили в силу, необходимо перезапустить Nginx. Однако перед перезапуском службы Nginx проверьте правильность конфигурации Nginx, выполнив команду:
|
1 |
sudo nginx -t |
Если конфигурация верна, тест должен пройти успешно.
Обратите внимание на значение директивы server_name “ react.test ” в блоке сервера? Вам нужно будет добавить это значение в файл hosts на вашей локальной машине. Это позволит вам открыть приложение в браузере. Этот шаг необходим только для виртуальных доменов, используемых в локальных средах разработки. Если у вас есть зарегистрированное доменное имя, привязанное к публичному IP-адресу вашего сервера, то доменное имя уже должно быть доступно в вашем браузере.
На локальной машине откройте файл hosts с помощью команды:
|
1 |
sudo nano /etc/hosts |
Внутри файла hosts добавьте IP-адрес вашего сервера, например, 127.0.0.1, а затем ваше виртуальное доменное имя.
Пример показан ниже. Затем закройте файл и сохраните:
|
1 |
192.168.3.123 react.test |
Вернувшись на сервер, внутри директории /var/www создайте новую директорию (вы можете назвать ее react-cicd), выполнив:
|
1 |
mkdir react-cicd |
На этом этапе мы раскомментируем последнюю команду в файле node.js.yml .
Эта команда копирует папку сборки нашего React-приложения из места, которое мы указали в качестве рабочей папки внутри директории actions-runner на предыдущем шаге 5.
, и помещает папку public в директорию /var/www/react-cicd .
Теперь серверный блок может получить доступ к нашему приложению и отобразить его в браузере.
Наконец, перезапустите службу Nginx с помощью команды:
|
1 |
sudo service nginx restart |
Теперь вы можете внести изменения в файл О компании.tsx, затем закоммитить и отправить изменения в ваш репозиторий. После успешной сборки вы увидите собранную версию вашего React-приложения по адресу http://react.test или по указанному вами доменному имени. Избегайте редактирования элемента href в файле Home.tsx, так как это может привести к сбою уже написанного теста. Вкладка Actions в вашем репозитории также должна показывать завершенную сборку задачи.
Заключение
Непрерывная интеграция с Github Actions дает множество преимуществ, включая удобство для разработчиков, помощь в непрерывном тестировании, упрощение совместной работы в больших командах, сокращение времени разработки, быстрый выпуск новых функций, обратную связь в реальном времени и удовлетворенность клиентов, что дает вам преимущество перед конкурентами. Чтобы закрепить эти знания, вы также можете узнать о настройке конвейеров непрерывной интеграции (CI) GitLab на Ubuntu. и использовании самостоятельно управляемого экземпляра GitLab для размещения ваших Docker-образов и запуска приватных сборок.
Приятной работы!
Комментарии
Комментариев пока нет. Будьте первым.