CI/CD для AWS Lambda: отслеживание функций через Git и развертывание через CodePipeline

ProjectDirectory
|--template.yml
|--Function
|  |--index.js
|--AnotherFunction
|  |--index.js

template.yml

AWSTemplateFormatVersion: '2010-09-09'

Type: AWS::Serverless::Function

Properties:

  Handler: HelloWorld/index.handler

  Runtime: nodejs8.10

AWSTemplateFormatVersion: '2010-09-09'

Type: AWS::Serverless::Function

Properties:

  Handler: HelloWorld/index.handler

  Runtime: nodejs8.10

  Events:

    HelloWorldApi:

      Type: Api

      Properties:

        Path: /helloworld

        Method: GET

Type: AWS::Lambda::Permission

Properties:

  Action: lambda:InvokeFunction

  FunctionName:

    Fn::GetAtt:

      - HelloWorld

      - Arn

  Principal: apigateway.amazonaws.com

  SourceArn:

    Fn::Sub: arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:*/*/*/***

pip install aws-sam-cli

sam package \
  --template-file template.yml \
  --output-template-file package.yml \
  --s3-bucket bucket-name

sam deploy \
  --template-file package.yml \
  --stack-name sam-hello-world \
  --capabilities CAPABILITY_IAM

{

"Statement": [

  {

    "Action": [

      "apigateway:*",

      "codedeploy:*",

      "lambda:*",

      "cloudformation:CreateChangeSet",

      "iam:GetRole",

      "iam:CreateRole",

      "iam:DeleteRole",

      "iam:PutRolePolicy",

      "iam:AttachRolePolicy",

      "iam:DeleteRolePolicy",

      "iam:DetachRolePolicy",

      "iam:PassRole",

      "s3:GetObject",

      "s3:GetObjectVersion",

      "s3:GetBucketVersioning"

    ],

    "Resource": "*",

    "Effect": "Allow"

  }

],

"Version": "2012-10-17"

}

version: 0.2

runtime-versions:

  nodejs: 10

commands:

  - npm install -g typescript

commands:

  - echo Build started on `date`

  - npm install time

  - npm run build

  - export BUCKET=typescript-lambda

  - aws cloudformation package --template-file template.yml --s3-bucket $BUCKET --output-template-file outputtemplate.yml

- template.yml

- outputtemplate.yml

Пояснения и рекомендации:

- Обновите runtime-versions.nodejs в соответствии с используемой версией Node.js (например, 14 или 16).
- Замените `npm install time` на реальные зависимости вашего проекта.
- Переключите `BUCKET` на S3-бакет, доступный для ролей пайплайна.
- Можно добавить тестовую фазу (test) и запуск unit/integration тестов.

### Стадия деплоя в CloudFormation

Вместо прямого использования CodeDeploy, в этом руководстве мы применяем CloudFormation change set:

1. В качестве deploy-провайдера в CodePipeline выберите CloudFormation.
2. Установите режим действия "Create or replace a change set" и укажите имя change set.
3. В шаблоне укажите артефакт сборки `BuildArtifact` и файл `outputtemplate.yml`.
4. Добавьте Capability IAM и выберите сервисную роль, созданную ранее.

![Настройка CloudFormation для Lambda](/files/e1f7d776-c8f6-4b93-a36b-d69c292a8002.png)

CodePipeline создаст change set, но не применит его автоматически. Чтобы выполнить change set, мы добавим ещё одну action-группу, которая выполнит созданный change set.

1. Нажмите Edit на пайплайне и в разделе Deploy выберите Edit.
2. Добавьте Action Group сразу после созданного действия создания change set (важно — новая группа должна идти после создания change set).

![Группа действий](/files/1d105ac6-94e4-45c0-8300-b96fa04f4dd2.png)

3. Выберите провайдер CloudFormation, укажите BuildArtifact как входной артефакт и укажите те же значения change set и режима.

![Конфигурация выполнения деплоя](/files/19c661d3-3561-4c3f-8876-6885a8791e4a.png)

4. Сохраните и вручную запустите Release Change, чтобы протестировать пайплайн.

После успешного выполнения вы увидите ресурсы в Lambda.

![Сборка успешна](/files/99ef08a1-902e-4583-9fea-ebe0234aa63d.png)

Если появляются ошибки, откройте "More Details" рядом с ошибкой в CodePipeline. Чаще всего это:

- неудачная сборка в CodeBuild;
- неполный/невалидный SAM-шаблон;
- недостаточные IAM-права для выполнения операций CloudFormation/CodeBuild.

Если вы продолжаете пушить в репозиторий, CodePipeline будет запускаться автоматически и проходить те же шаги.

## Практические рекомендации и лучшие практики

1. Минимизируйте права: давайте ролям только необходимые разрешения. Привилегированные политики удобно использовать только для initial bootstrap, но в production лучше иметь строго ограниченные роли.
2. Используйте алиасы и версии Lambda: публикуйте новую версию и меняйте алиас, это упрощает откат.
3. Настройте Canary/Linear deploys в CodeDeploy, если хотите постепенное переключение трафика.
4. Автоматизируйте тесты в сборочной фазе: unit, integration, contract tests для API-интерфейсов.
5. Включите логирование и мониторинг: CloudWatch Logs, метрики Lambda, X-Ray для трейсинга.
6. Храните секреты в AWS Secrets Manager или Parameter Store и не коммитите ключи в репозиторий.

## Чек-лист ролей и задач

Разделим задачи по ролям (кто отвечает за что):

Разработчик:

- писать и запускать unit-тесты;
- поддерживать структуру функций и template.yml;
- обновлять зависимости и фиксировать версии runtime.

DevOps-инженер:

- настраивать CodePipeline/CodeBuild/CloudFormation;
- создавать и поддерживать IAM роли и политики;
- управлять S3-артефактами,
- мониторить пайплайн.

QA-инженер:

- писать integration-тесты, проверять change sets перед применением;
- проводить нагрузочное тестирование и тесты на откат.

Продукт-менеджер:

- определяет правила релизов и политики отката;
- утверждает каналы трафика и окна развертывания.

## Playbook: шаги для нового проекта (SOP)

1. Создать репозиторий и инициализировать структуру проекта.
2. Написать минимальный SAM-шаблон и проверить локально через `sam deploy --guided`.
3. Настроить S3-бакет для хранения артефактов сборки.
4. Создать IAM роль с правами CloudFormation и загрузить inline-политику (адаптировать права).
5. Создать CodeBuild проект с корректным образoм и разрешениями.
6. Создать CodePipeline со стадиями: Source → Build → Deploy (CreateChangeSet) → Deploy (Execute).
7. Настроить мониторинг и оповещения на провале пайплайна.
8. Прописать тесты в buildspec и включить их в pipeline.

## Сценарий отката и runbook при инциденте

1. При критических ошибках переключите алиас на предыдущую стабильную версию.
2. Если используете CloudFormation и change set привёл к некорректному состоянию, откатите стек на предыдущую версию через консоль CloudFormation.
3. Проверяйте логи Lambda и CloudWatch для поиска причин ошибки.
4. В случае проблем с правами — проверьте IAM-логи и CloudTrail.
5. Документируйте причину и введите тест, чтобы предотвратить повтор.

Критерии приёмки (минимальные):

- пайплайн успешно собирает и упаковывает артефакты;
- change set создаётся и не содержит неожиданных удалений критичных ресурсов;
- все unit и integration тесты проходят;
- smoke-тесты на продакшн alias проходят.

## Тест-кейсы и примеры приёмки

- Unit tests: покрытие ключевой бизнес-логики (asserts on outputs).
- Integration: вызов API-эндпоинта и проверка ответа.
- Smoke: короткий сценарий, который выполняется после деплоя (health-check endpoint, проверка подключения к БД/посреднику).

## Безопасность и соответствие (GDPR/Конфиденциальность)

- Не храните персональные данные в логах.
- Секреты — в Secrets Manager/Parameter Store with encryption.
- Ограничьте доступ к IAM ролям и S3-бакетам.
- Для данных пользователей из ЕС убедитесь, что хранилища и обработки соответствуют политике компании и требованиям регуляторов.

## Альтернативные подходы

- Jenkins/GitLab CI вместо CodeBuild/CodePipeline: если ваша CI уже централизована в Jenkins, можно использовать его для сборки и вызывать SAM/CloudFormation шаги.
- Serverless Framework, Terraform: альтернативы SAM/CloudFormation. Serverless Framework даёт удобный UX и плагины; Terraform — декларативно управляет infra, но требует дополнительных интеграций для serverless-аспектов.
- Использование образов контейнеров для Lambda (Container image support) — полезно для монолитных зависимостей.

Когда CI/CD через CodePipeline может не подойти:

- У вас уже централизованная, отлаженная CI/CD-система, и миграция в AWS Pipeline экономически неоправдана.
- Нужна мультиоблачная стратегия, где инструменты облачного провайдера будут ограничивать переносимость.

## Ментальные модели и эвристики

- Разделяй и властвуй: каждая функция — отдельный модуль, отдельный пакет/zip.
- Декларативность выше импровизации: описали всё в шаблоне — можно повторить развертывание в другой среде.
- Маленькие релизы: меньше рисков и проще откат.

## Сравнение подходов (краткая матрица)

- CodePipeline + SAM: нативная интеграция, простая настройка, хорошая поддержка IAM. Подходит для AWS-centric команд.
- Jenkins + SAM: гибкость, но требует управляющей инфраструктуры для интеграции с AWS.
- Serverless Framework: удобные плагины, кросс-платформенность, дополнительная абстракция.

## Галерея пограничных случаев

- Большие zip-архивы: S3-бакеты и ограничения на размер артефактов.
- Длинные cold-starts: оптимизация пакета, разделение функциональности.
- Несовместимость runtime: проверьте версии Node/Python/Java.

## 1‑строчный глоссарий

- SAM — Serverless Application Model, расширение CloudFormation для serverless.
- Change Set — превью изменений CloudFormation перед применением.
- Alias — именованная ссылка на версию Lambda, удобна для маршрутизации трафика.

## Шаблоны и сниппеты

- Пример buildspec.yml и SAM-шаблон приведены выше.
- Инструменты для проверки: `aws cloudformation validate-template --template-body file://template.yml`.

## Отладка и советы по ошибкам

- "Insufficient permissions" — проверьте inline-политику роли и `iam:PassRole` для CloudFormation.
- "Template validation error" — используйте `aws cloudformation validate-template` и SAM linter.
- "Build failed" — смотрите логи CodeBuild, добавьте `echo` в buildspec для диагностики.

## Итог

CI/CD для AWS Lambda даёт контроль, повторяемость и безопасность релизов. Локальная разработка, Git, SAM и CodePipeline — комбинация, позволяющая выстроить предсказуемый процесс релизов. Не забудьте тестирование, мониторинг и минимизацию прав.

Примените чек-листы и playbook из этой статьи при создании первого пайплайна. Как только пайплайн настроен, добавляйте тесты и политики безопасности постепенно — так вы уменьшите риск человеческой ошибки и ускорите время вывода изменений в продакшн.

Примечание: при копировании примеров проверьте актуальность версий runtime и замените устаревшие значения.