Настройка CI/CD с AWS и Github Actions

Введение

В этой статье хотелось бы поведать о настройке CI/CD процессов на примере личного грантового проекта. Сам проект посвящен автоматической обработке T2 взвешенных снимков МРТ поясничного отдела позвоночника и представляет собой набор веб-приложений. На проекте используются разные веб-фреймворки, в частности, Flask, Django и Spring Boot. Приложения разворачиваются в инфраструктуре AWS, потому что это удобно, ибо Amazon остается гегемоном среди публичных облаков из-за огромного количества сервисов, а также, потому что это стильно, модно и молодежно. Чтобы избавиться от монотонной работы по разворачиванию веб-приложений, а также от постоянных проверок на их жизнеспособность, было решено настроить CI/CD процессы.

Про Github Actions

Для настройки CI/CD пайплайнов был выбран инструмент Github Actions, потому что все репозитории проекта размещены в Github, а еще, потому что не хочется держать свой Jenkins сервер. Учитывая то, что умельцы пишут свои собственные Actions, сейчас практически все потребности в разных операциях (например, подключение по SSH, работа с AWS CLI, сборка под разные ОС) удовлетворяются с лихвой. Определившись с инструментом разработки необходимо продумать требования к пайплайнам на примере Flask веб-приложения.

CI пайплайны, исходя из своего определения, должны выполнять сборку проекта, включая прогон тестов, а также размещать собранные артефакты в хранилище для последующего развертывания. Очевидно, что хранилищем артефактов в инфраструктуре AWS будет являться S3 bucket.

С CD пайплайном дела обстоят сложнее, ибо в данном случае необходимо продумать взаимодействие AWS сервисов между собой. Приложению нужно доменное имя (Route 53), которое будет смотреть на IP-адрес сервера (EC2) с самой программой. Также нужна база данных, в нашем случае реляционная (RDS). Для минимально жизнеспособного веб-приложения уже потребовалось 3 AWS сервиса. В существующем Flask проекте используется больше AWS сервисов. Ниже показана вольная схема AWS инфраструктуры для ранее описываемого проекта.

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

Конечно, можно настраивать эти сервисы каждый раз вручную, и при изменении программного кода мануально накатывать новую версию приложения на сервер, но лучше автоматизировать данный процесс, избавив себя от монотонной работы. У AWS и на этот случай есть сервис под названием CloudFormation, предоставляющий услуги вида «Infrastructure as a Code» (IaaC), позволяющий моделировать и управлять ресурсами AWS. Его и будем использовать.

Итак, можно приступать к непосредственной разработке пайплайнов.

Continuous Integration jobs

Все давно знают, что Github Actions пайплайны складируются в директории репозитория: .github/workflows/*.yml

Первым делом настроим прогон тестов на пулл реквестах, чтобы в main ветку не попал нерабочий код. Ниже представлен код пайплайна для вышеописанных действий.

name: Pipeline name  # Имя пайплайна
env:  # Переменные среды
  VARIABLE: "var"

on:  # Триггеры для запуска пайплайна
  workflow_dispatch:  # Ручной запуск через UI Гитхаба
  pull_request:  # Для пул реквестов

jobs: # Список джоб
  validation: # Имя джобы
    runs-on: ubuntu-latest
    steps:   # Действия для нашей job
      - name: Clone repo  # Клонируем наш репозиторий (можно клонировать и другие (даже приватные), только нужен другой action)
        uses: actions/checkout@v2

      - name: Set up Python 3.7  # Устанавливаем питончик нужной версии
        uses: actions/setup-python@v1
        with:
          python-version: 3.7

      - name: Configure AWS Credentials  # Конфигурируем креды для работы с AWS
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}  # Ниже будет картинка, где показана настройка secrets
          aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
          aws-region: ${{ env.AWS_REGION_NAME }}

      - name: Get response of RDS DB structure  # Получаем адрес БД через AWS CLI
        run: aws rds describe-db-instances --db-instance-identifier ${{ secrets.MYSQL_SCHEMA_NAME }} >> rds_response.json

      - name: Get database URL
        id: url
        uses: sergeysova/jq-action@v2
        with:
          cmd: "jq -r '.DBInstances[].Endpoint.Address' rds_response.json"  # Фильтруем JSON

      - name: Install dependencies  # Устанавлиаем Python зависимости
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
        
      - name: Lint with pycodestyle  # Проверяем соответствует ли наш код PEP8
        run: |
          source venv/bin/activate
          pycodestyle --exclude=venv --max-line-length=150 .

      - name: Run unit tests  # Запускаем тестики
        run: |
          sudo apt upgrade
          pytest
        env:  # Необходимые системные переменные, чтобы проект не крашнулся
          # Configure AWS settings environments for tests
          AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}
          AWS_SECRET_KEY: ${{ secrets.AWS_SECRET_KEY }}
          # Configure production MySQL settings
          MYSQL_USER: ${{ secrets.MYSQL_USER }}
          MYSQL_PASSWORD: ${{ secrets.MYSQL_PASSWORD }}
          MYSQL_URL: ${{ steps.url.outputs.value }}
          MYSQL_DB: ${{ secrets.MYSQL_DB }}
          # Configure SQLAlchemy
          SQL_ALCHEMY_SECRET_KEY: ${{ secrets.SQL_ALCHEMY_SECRET_KEY }}

Ниже показана настройка secrets для репозитория.

Ниже приведу пример конфигурации джобы (это уже другой .yml файлик) для сборки проекта с комментариями, которая скажет все за меня.

name: Pipeline name  # Все еще имя пайлайна
env:  # Все еще переменные среды, которые все также используются в виде: ${{ env.VAR_NAME }}
  ENV_VARIABLE: "value"

on:
  workflow_dispatch:
  push:
    branches: [ main ]  # При merge в main ветку

jobs:  
  ci:
    runs-on: ubuntu-latest  # Я офигел, когда узнал что можно и на MacOS бесплатно запускать

    steps:
      - name: Git clone our repo
        uses: actions/checkout@v1

      - name: Install zip  # Устаналиваем zip архиватор, т.к. проект на Python
        run: sudo apt-get install zip gzip tar

      - name: Archive project  # Архивируем наш проект из рабочей директории *
        run: sudo zip -r project.zip *

      - name: Configure my AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
          aws-region: ${{ env.AWS_REGION_NAME }}

      - name: Copy app to S3 bucket  # Копируем архив с проектом в AWS S3 bucket 
        run: aws s3 cp "project.zip" s3://${{ env.BUCKET_NAME }}/project.zip

      - name: Print Happy Message for CI finish
        run: echo "CI Pipeline part Finished successfully"	

Таким образом, имеем CI джобы, которые прогоняют тестики для пул реквестов, а при коммите в main ветку, архивируют проект и отправляют его в AWS S3 bucket. Из облачного хранилища уже можно брать актуальную версию проекта через AWS CLI и накатывать на EC2 инстансы.

Continious delivery job & CF template

Весь интерес и сложность CD джобы для проекта кроется не в пайплайне для Github Actions, а в CloudFormation шаблоне. Так исторически сложилось, что официальная документация для CloudFormation ужасна. Так считаю не только я, но и другие программисты. Даже имеющийся редактор шаблонов для CloudFormation не спасает положение. Поэтому приходится искать готовые сниппеты умельцев по всему Интернету и отсекать от сниппетов все ненужное. Например, для лендинг-страниц есть готовый CloudFormation шаблон с CDN (AWS CloudFront). Но для полноценных веб-приложений дела обстоят немного интереснее. Поскольку в существующем Flask проекте используется нестандартный Django-style менеджер запуска (Flask-Script), то использование AWS ELB для автоматического развертывания отпадает, потому что в конфигурации этого сервиса сам черт ногу сломит. Используется стандартный EC2.

Итак, начну с демонстрации CD джобы, которая заканчивается разворачиванием CloudFormation шаблона в AWS инфраструктуре. Эта джоба является продолжением предыдущего пайплайна.

...
cd_part:  # Имя джобы
  runs-on: ubuntu-latest
  needs: [ci_part]  # Запустится после успешного выполнения предыдущей джобы

  steps:
    - name: Git clone our repo  # Нам понадобится наш репозиторий, т.к. в нем хранится CloudFormation шаблон
      uses: actions/checkout@v1

    - name: Configure my AWS Credentials  # Все еще конфигурируем AWS креды, т.к. они сбрасываются после завершения предыдущей джобы
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
        aws-region: ${{ env.AWS_REGION_NAME }}

    - name: Deploy main stack  # AWS CLI команда для запуска CloudFormation шаблона, который хранится у нас в репозитории
      run: |
        aws cloudformation deploy \
        --stack-name main-stack \  # Имя стека (у AWS есть ограничения на спец. символы для имен CloudFormation стэков)
        --template-file cloudformation/main_stack.json \  # Путь до файла с CloudFormation шаблоном
        --capabilities CAPABILITY_NAMED_IAM \  # Магический параметр, про который мне лень писать
        --parameter-overrides YourParameterName=${{ secrets.PARAMETER }} \  # Наши параметры, которые можно прокидывать в CloudFormation шаблон
        --no-fail-on-empty-changeset  # Околомагический параметр, который нужен, чтобы при следующем старте джобы CloudFormation шаблон не падал с ошибкой, если не было изменений в шаблоне

    - name: Print Happy Message for CD finish
      run: echo "CD Pipeline part Finished successfully"

Это весьма простой пайплайн по сравнению с предыдущими. Просто нужно знать как использовать AWS CLI команду для работы с CloudFormation. Можно читать документацию по AWS CLI либо с официального сайта, либо непосредственно из консольки. Теперь самое интересное -  CloudFormation шаблон:

{
  "Description": "AWS CloudFormation stack",
  "Parameters": {
    "ParameterName": {
      "Type": "String"// в 99% случаев используем String
    }
  },
  "Resources": { // Создаем наши AWS ресурсы
    "S3Bucket": { // Файловое хранилище
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "S3BucketName",
        "PublicAccessBlockConfiguration": { // Эти настройки нужны для конфигурирования открытости/закрытости S3 bucket (можно ли обращаться к файлам из хранилища по URL)
          "BlockPublicAcls": false,
          "BlockPublicPolicy": false,
          "IgnorePublicAcls": false,
          "RestrictPublicBuckets": false
        }
      }
    },
    "LogGroup": { // Это облачное хранилище логов, запись в них настаивается в коде приложения
      "Type": "AWS::Logs::LogGroup",
      "Properties": {
        "LogGroupName": "LogGroupName"
      }
    },
    "SecurityIAMRole": {  // Это настройки безопасности для EC2
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Principal": {
                "Service": [
                  "ec2.amazonaws.com"
                ]
              },
              "Action": [
                "sts:AssumeRole"
              ]
            }
          ]
        },
        "Policies": [
          {
            "PolicyName": "S3Policy",
            "PolicyDocument": {
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": "s3:*",
                  "Resource": "arn:aws:s3:::YOUR_S3_BUCKET_FOLDER/*"
                }
              ]
            }
          }
        ],
        "RoleName": "IAMRoleName"
      }
    },
    "InstanceProfile": {  // Такая же околобезопасная штука для EC2
      "Type": "AWS::IAM::InstanceProfile",
      "Properties": {
        "Roles": [
          {
            "Ref": "SecurityIAMRole"
          }
        ]
      }
    },
    "SecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupName": "SecurityGroupName",
        "GroupDescription": "SecurityGroupDescription",
        "SecurityGroupIngress": [
          { // Порты, которые мы можем выставлять наружу для EC2 инстанса
            "IpProtocol": "tcp",
            "CidrIp": "0.0.0.0/0",
            "FromPort": 22,
            "ToPort": 22
          },
          {
            "IpProtocol": "tcp",
            "CidrIpv6": "::/0",
            "FromPort": 22,
            "ToPort": 22
          },
          {
            "IpProtocol": "tcp",
            "CidrIp": "0.0.0.0/0",
            "FromPort": 80,
            "ToPort": 80
          },
          {
            "IpProtocol": "tcp",
            "CidrIpv6": "::/0",
            "FromPort": 80,
            "ToPort": 80
          },
          {
            "IpProtocol": "tcp",
            "CidrIp": "0.0.0.0/0",
            "FromPort": 443,
            "ToPort": 443
          },
          {
            "IpProtocol": "tcp",
            "CidrIpv6": "::/0",
            "FromPort": 443,
            "ToPort": 443
          }
        ]
      }
    },
    "CertificateManagerCertificate": { // HTTPS сертификат
      "Type": "AWS::CertificateManager::Certificate",
      "Properties": {
        "DomainName": {
          "Ref": "ParameterUrlName" // Ваш url адрес
        },
        "ValidationMethod": "DNS",
        "SubjectAlternativeNames": [
          {
            "Ref": "ParameterUrlName"
          },
          {
            "Fn::Sub": [
              "www.${Domain}", // Чтобы работало обращение через www.
              {
                "Domain": {
                  "Ref": "ParameterUrlName"
                }
              }
            ]
          }
        ],
        "DomainValidationOptions": [
          {
            "DomainName": {
              "Ref": "ParameterUrlName"
            },
            "HostedZoneId": {
              "Ref": "HostZoneId" // Параметр на HostedZone id в Route53
            }
          },
          {
            "DomainName": {
              "Fn::Sub": [
                "www.${Domain}",
                {
                  "Domain": {
                    "Ref": "ParameterUrlName"
                  }
                }
              ]
            },
            "HostedZoneId": {
              "Ref": "HostZoneId"
            }
          }
        ]
      }
    },
    "Ec2Instance": { // Сам сервак с приложенькой
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "IamInstanceProfile": {
          "Ref": "InstanceProfile"
        },
        "AvailabilityZone": "us-east-1c", // Можете поставить свое
        "ImageId": "ami-047a51fa27710816e", // Amazon Linux ОС
        "InstanceType": "t2.micro", // 
        "KeyName": "key-pair", // ssh ключик
        "SecurityGroups": [ 
          {
            "Ref": "SecurityGroup"
          }
        ],
        "Tags": [
          {
            "Key": "Name",
            "Value": "Имя вашего EC2 инстанса"
          }
        ],
        "UserData": { // Команды запуска и настройки ec2 под наши нужды
          "Fn::Base64": {
            "Fn::Join": [
              "",
              [ 
                "Content-Type: multipart/mixed; boundary=\"//\"\n", // Фигня без которой ничего не работает
                "MIME-Version: 1.0\n\n",
                "--//\n",
                "Content-Type: text/cloud-config; charset=\"us-ascii\"\n",
                "MIME-Version: 1.0\n",
                "Content-Transfer-Encoding: 7bit\n",
                "Content-Disposition: attachment; filename=\"cloud-config.txt\"\n\n",
                "#cloud-config\n",
                "cloud_final_modules:\n",
                "- [scripts-user, always]\n\n",
                "--//\n",
                "Content-Type: text/x-shellscript; charset=\"us-ascii\"\nMIME-Version: 1.0\n",
                "Content-Transfer-Encoding: 7bit\n",
                "Content-Disposition: attachment; filename=\"userdata.txt\"\n\n", 
                "#!/bin/bash\n",
                "sudo yum -y install gcc openssl-devel bzip2-devel libffi-devel libssl-dev\n", // Устанавливаем python 3.7.2 и pip3
                "sudo yum -y install python37 python3-devel\n",
                "sudo yum -y install mysql-devel\n",
                "sudo yum -y install vim\n",
                "sudo yum -y install libXext libSM libXrender\n",
                "sudo curl -O https://bootstrap.pypa.io/get-pip.py\n",
                "sudo python3 get-pip.py\n",
                "pip3 install awsebcli --upgrade --user\n",
                "pip3 install jmespath==0.7.1 python-dateutil\n",
                "pip3 install awsebcli --upgrade --user\n",
                "sudo echo 'export ENV_VARIABLE=", // Сетаем переменную среды
                {
                  "Ref": "ParameterName"
                },
                "'>>/home/ec2-user/.bash_profile\n",
                // Удалил отсюда часть команд, т.к. они особой роли не играют
                "aws s3 cp s3://bucket/file.zip /home/ec2-user/file.zip\n", // Копируем исходный код проекта
                "nohup gunicorn -w 1 --reload -b 127.0.0.1:5000 --chdir /home/ec2-user 'app:create_app()' > log.txt 2>&1 &\n", // запускаем gunicorn
                "sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm\n", // Устанавливаем Let's encrypt
                "sudo yum install -y epel-release\n",
                "sudo yum install nginx -y\n",
                "sudo amazon-linux-extras install -y epel\n",
                "sudo yum-config-manager --enable epel*\n",
                "sudo yum install -y certbot\n",
                "sudo yum install -y python-certbot-nginx\n",
                "pip3 install certbot-nginx\n",
                "sudo sed -i '2 a server_name ", // Вставить url адрес для Let's Encrypt в nginx конфигурацию на 2 строчку
                {
                  "Ref": "ParameterUrlName"
                },
                " www.",
                {
                  "Ref": "ParameterUrlName"
                },
                ";' /home/ec2-user/deploy/app.conf\n",
                "sudo cp /home/ec2-user/deploy/app.conf /etc/nginx/conf.d/app.conf\n",
                "sudo certbot --nginx --non-interactive --agree-tos -d ",
                {
                  "Ref": "ParameterUrlName"
                },
                " -d www.",
                {
                  "Ref": "ParameterUrlName"
                },
                " -m ",
                {
                  "Ref": "YourEmailParameter"
                },
                "\n",
                "sudo certbot renew --dry-run\n", 
                "sudo systemctl stop nginx\n",
                "sudo pkill -f nginx & wait $!\n", // Костыль без которого у меня не работало
                "sudo systemctl start nginx\n",
                "sudo systemctl enable nginx\n"
              ]
            ]
          }
        }
      },
      "DependsOn": [ // EC2 не должен создаваться раньше чем логи и s3 хранилище
        "LogGroup",
        "S3Bucket"
      ]
    },
    "ElasticIP": { // постоянный ip адрес (можно и без него)
      "Type": "AWS::EC2::EIP",
      "Properties": {
        "Domain": "vpc",
        "InstanceId": {
          "Ref": "Ec2Instance"
        },
        "Tags": [
          {
            "Key": "Name",
            "Value": "YourElasticIPName"
          }
        ]
      }
    },
    "DNSRecord": { // Запись DNS 
      "Type": "AWS::Route53::RecordSetGroup",
      "Properties": {
        "HostedZoneId": {
          "Ref": "HostZoneId"
        },
        "RecordSets": [
          {
            "Name": {
              "Ref": "ParameterUrlName"
            },
            "Type": "A",
            "TTL": 900,
            "ResourceRecords": [
              {
                "Ref": "ElasticIP"
              }
            ]
          },
          {
            "Name": {
              "Fn::Sub": [
                "www.${Domain}",
                {
                  "Domain": {
                    "Ref": "ParameterUrlName"
                  }
                }
              ]
            },
            "Type": "A",
            "TTL": 900,
            "ResourceRecords": [
              {
                "Ref": "ElasticIP"
              }
            ]
          }
        ]
      }
    }
  }
}}

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

Заключение

В данной статье была рассмотрена настройка CI/CD пайплайнов на основе Github Actions в инфраструктуре AWS. Автоматизация развертывания AWS ресурсов проводилась с использованием сервиса CloudFormation.  У данного подхода есть минус в виде программирования на JSON (YAML) в CloudFormation шаблонах, но также имеется и плюс в виде гибкости конфигурации.

Кому будет интересно покопаться еще, то я создал Github Gist, где написал CloudFormation шаблон для реляционной базы данных (AWS RDS MySQL) и простейшую nginx конфигурацию, которую использует ранее представленный CloudFormation template.