Статья также доступна на украинском (перейти к просмотру).

Содержание:

• Исходные положения
• Компоненты GitHub Actions и их взаимодействие
  • Рабочие процессы
  • События
  • Задание
  • Действия/a>
  • Средства выполнения
  • Взаимодействие компонентов
• Создание и развертывание PHP-проекта в Службе приложений Azure в режиме CD непрерывного развертывания
  • Выполнение подготовительных операций и настроек
  • Создание workflow-процесса

Одним из путей совершенствования и оптимизации направления DevOps есть применение технологии непрерывной интеграции и поставки кода (CI/CD) в процессах подготовки и внедрения программного обеспечения. Одной из реализаций данной технологии является механизм GitHub Actions, который обеспечивает необходимые рабочие условия для CI/CD и даже выходит за ее пределы, предоставляя расширенные возможности по управлению проектами. Рассмотрим более подробно характеристики и особенности применения GitHub Actions на практике.

Исходные положения

Обычный процесс разветвленной разработки ПО заключается в одновременном и/или последовательном внесении изменений в тело программы со стороны разработчиков на первых стадиях подготовки ПО. Сборка исходного кода, тестирование и устранение ошибок обычно переходят на последний этап этого процесса. Именно в этом и состоит главный недостаток «обычной» методологии – накопление большого количества ошибок на последней стадии разработки. Вместе с тем хорошо известно, что стоимость запоздалого исправления ошибки в коде будет значительно выше, по сравнению с ее исправлением на начальных этапах. В результате увеличивается общая стоимость проекта и время его разработки.

Выходом из ситуации может стать равномерное распределение и автоматизация работ по тестированию и исправлению ошибок в коде на протяжении всего цикла разработки. Преимущества подхода очевидны: 

• Удешевление процесса обнаружения и устранения ошибок;

• Применение стандартных модулей тестирования сразу же после внесения изменений;

• Возможность всегда иметь Stable-версию программы, в частности, для проведения дополнительных тестов;

• Работа с кодом в итеративном режиме с сокращенным временным циклом.

Указанные преимущества настолько существенны, что не вызывают сомнений в необходимости перехода на новую методологию разработки ПО, получившей название непрерывной интеграции CI (Continuous Integration). Задержка ее массового внедрения была связана со сложностью обеспечения условий ее функционирования и увеличением затрат на соответствующие машинные ресурсы.

Укажем основные условия для возможности применения CI на практике:

• Обеспечение хранения исходного кода проекта, средств его сбора и тестирования в репозитории одной из систем управления версиями;

• Автоматизация циклических операций по обслуживанию проекта;

• Упрощенный вызов сценариев операций по внешним программам;

• Наличие выделенного сервера, на котором запускается главный сервисный сервис проекта.  

Механизм GitHub Actions полностью обеспечивает выполнение указанных условий, что позволяет выполнять все работы по проекту, размещенному в GitHub репозитории в режиме CI. Ниже будут рассмотрены его строение и принципы использования.

Компоненты GitHub Actions и их взаимодействие

Выделим основные сущности, обеспечивающие существование среды CI:

• Рабочие процессы (workflows);

• События (events);

• Задание (jobs);

• Действия  (actions);

• Средства выполнения (runners).

Все эти сущности обычно присутствуют в workflows-файлах и формируют список задач с соответствующими сценариями для реализации определенной цели – тестирование, развертывание, извлечение результатов тестов и т.д. Рассмотрим каждую из них в отдельности.

Рабочие процессы

Рабочие процессы определяют тип и последовательность выполнения заданий, фиксируемых в формате файла YAML. Файлы хранятся в каталоге .github/workflows репозитория GitHub. Файл любого рабочего процесса должен включать в себя одно или несколько событий и задач.  

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

С целью облегчить работу с системой девелоперам, GitHub предоставляет множество вариантов шаблонов по нескольким основным направлениям:

• Непрерывная интеграция (CI);

• Развертывание (Dev);

• Автоматизация рабочих процессов (Automationworkflows);

• Сканирование кода (scan code);

• Рабочие процессы страниц (workflows pages).

Следует отметить, что сервис предоставляет только базовые, необходимые для старта проекта процессы. Их всегда можно отредактировать на сайте репозитория в зависимости от своих потребностей.

Полную базу шаблонов можно посмотреть насайте репозитория в разделе actions/starter-workflows.

События

Этот компонент выполняет роль триггера для запуска рабочего процесса, в котором он определен. Системой поддерживаются следующие их виды:

• События, происходящие в репозитории процесса;

• События, происходящие вне репозитория и активирующие событие repository_dispatch;

• События, происходящие в запланированное время, то есть по расписанию.

Задание

Компонент реализуется с помощью оператора работа и служит для определения этапов выполнения рабочего процесса в пределах одного и того же средства выполнения, например в виртуальной машине сервера Ubuntu. Каждый этап привязывается к сценарию или действию, которые будут поочередно выполняться. В рамках задачи идет его дополнительная детализация с помощью оператора. Steps, который будет рассмотрен нами позже.

Действия

Компонент представляет собой приложение пользователя, выполняющее любые циклические операции, например проверку кода, развертывание приложений, настройку среды для сборки проекта и т.п. Фактически он инструмент автоматизации многих процессов и позволяет уменьшить объем файлов рабочего процесса и увеличить скорость обработки данных. 

Код хранится в файле action.yml. В файле рабочего процесса он подключается с помощью оператора actions.

Компонент может быть предварительно создан пользователем, настраиваться в процессе работы или получен из Marketplace GitHub.

Средства выполнения

Это среда, в которой происходит выполнение всех рабочих действий после их активации. На каждый процесс выделяется одна виртуальная машина. Реализуется с помощью оператора бегать.GitHub предоставляет следующие виды серверов для образования виртуальных сред: Microsoft Windows, macOS да Linux Ubuntu.

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

Взаимодействие компонентов

Принцип взаимодействия компонентов GitHub Actionsприведен на Рисунку 1. В случае возникновения события Event на входе рабочего процесса, активируются процессы выполнения задач, определенных компонентами Jobs1 и Jobs2. Задачи в свою очередь разбиты на шаги: Step1-Step4 да Step1–Step 3 соответственно. Каждая из задач выполняется только в своей среде – Runner1 и Runner2 соответственно. 

Рисунок 1. Взаимодействие компонентов GitHub Actions.

Рассмотрим взаимодействие компонентов на практическом примере. Например, файл рабочего процесса docker-image.yml из базы GitHub репозиторию реализует развертывание системы Docker на VPS-сервере Ubuntu. В качестве события здесь указано значение толкать (отправка кода в ветвь разработки), а задача рабочие места определяет последовательность шагов для выполнения операций развертывания системы Docker на сервере. (см. сундук).

name: Docker Image CI
on:
push:
  branches: [ $default-branch ]
    pull_request:
  branches: [ $default-branch ]
jobs:
build:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
  - name: Build the Docker image
    run: docker build . --file Dockerfile --tag my-image-name:$(date +%s) 

Создание и развертывание PHP-проекта в Службе приложений Azure в режиме CD непрерывного развертывания   

Разобьем процесс решения задачи на два этапа:

• Выполнение подготовительных операций и настроек;

• Создание workflow-процесса.

Выполнение подготовительных операций и настроек

Перед формированием файла рабочего процесса GitHub Actions необходимо выполнить подготовительные действия в следующем порядке:

• Создать план указанной Службы приложений;

• Создать приложение;

• Создать секрет и настроить профиль публикации в Azure;

• Настройка среды развертывания.

Создание плана. Для этого можно воспользоваться сервисом Azure CLI:

Bash
 
az appservice plan create \
   --resource-group NEW_GROUP \
   --is-linux

Вместо этого NEW_GROUPнужно указать идентификатор имеющейся группы ресурсов. Вместо этого NEW_NAME_PLAN – новое имя плана. Подробности можно найти в соответствующем разделе документации по Azure CLI.

Создание приложения. Здесь также можно использовать возможности Azure CLI и среда PHP:

Bash
 
az webapp create \
--name NEW_NAME_WEB_APP \
--plan NEW_NAME_PLAN \
--resource-group NEW_GROUP \
--runtime "php|8.3"

Здесь NEW_NAME_WEB_APP – новое имя для веб-приложения. Значения всех других параметров должны соответствовать настройкам.

Создание секрета и настройка профиля публикации. Настройки профиля публикации описаны в этом разделе документации по Azure. После этого у GitHub-репозитории необходимо создать секрет AZURE_WEBAPP_PUBLISH_PROFILE с данными настроенного профиля публикации.

Настройка среды развертывания осуществляется при необходимости. В процессе развертывания среда визуализируется на главной странице репозитория для удобства управления процессом.

Создание workflow-процесса

Ниже представлено содержимое сформированного файла рабочего процесса по созданию и развертыванию PHP-проекта в службе приложений Azure.

YAML

 

name: Build and deploy of the project PHP in service Azure
 
env:
  AZURE_WEBAPP_NAME: NEW_NAME_WEB_APP # Задается имя нашего веб-приложения
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # Задается путь к веб-приложению
  PHP_VERSION: '8.x'                  # Устанавливается версия PHP
 
on:
  push:                           # Процесс активируется сразу после отправки изменений в главную ветвь тела программы
 
branches:
  - main
 
jobs:
  build:
runs-on: ubuntu-latest # Определяется средство выполнения
 
steps:
  - uses: actions/checkout@v4 # Проверяется пользовательский репозиторий в среде выполнения. Применяется каждый раз, когда рабочий процесс использует код из репозитория.
 
  - name: Setup PHP
    uses: shivammathur/setup-php@1f2e3d4c5b6a7f8e9d0c1b2a3e4f5d6c7b8a9e0f
    with:
      php-version: ${{ env.PHP_VERSION }}
 
  - name: Check if composer.json exists
    id: check_files
    uses: andstor/file-existence-action@2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b
    with:
      files: 'composer.json'
 
  - name: Get Composer Cache Directory
    id: composer-cache
    if: steps.check_files.outputs.files_exists == 'true'
    run: |
      echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT
 
  - name: Dependency caching
    uses: actions/cache@v3  # Запускается действие по кэшированию зависимостей
    if: steps.check_files.outputs.files_exists == 'true'
    with:
      path: ${{ steps.composer-cache.outputs.dir }}
      key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}
      restore-keys: |
        ${{ runner.os }}-composer-
 
  - name: Install composer if composer.json exists
    if: steps.check_files.outputs.files_exists == 'true'
    run: composer validate --no-check-publish && composer install --prefer-dist --no-progress
 
  - name: Setting up artifacts
    uses: actions/upload-artifact@v4 # Активируется действие по загрузке артифактов
    with:       
      name: php-app
      path: .
 
  deploy:              # Конфигурируется процесс развертывания в определенном средстве выполнения 
runs-on: ubuntu-latest
needs: build
environment:       # Настройка среды развертывания веб-додатку  
  name: 'production'
  url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
 
steps:
  - name: Loading an artifact based on the build results
        uses: actions/download-artifact@v4 # Завантаження артефактів за результатами збірки
    with:
      name: php-app
 
  - name: 'Deploy in service Azure'
    id: deploy-to-webapp
    uses: azure/webapps-deploy@85270a1854658d167ab239bce43949edb336fa7c
    with:       
      app-name: ${{ env.AZURE_WEBAPP_NAME }}
      publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
      package: .

Подписывайтесь на наш телеграм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

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

Дата: 20.11.2024 Автор: Александр Ровник #automation#devops#github#php

Голосование 1 2 3 4 5