Как загрузить на Amazon S3 из действий GitHub
GitHub Actions — это мощный инструмент CI/CD для запуска автоматических сборок из вашего репозитория GitHub.
GitHub Actions — это мощный инструмент CI/CD для запуска автоматических сборок из вашего репозитория GitHub. Последним шагом этого процесса является развертывание, которое включает загрузку артефактов сборки туда, где к ним можно легко получить доступ. AWS S3 — это хранилище, которое выбирают многие люди, и его легко интегрировать со сценариями действий.
Зачем использовать сегменты AWS S3 для развертывания?
Стоит отметить, что GitHub Actions имеет базовую систему хранения артефактов, однако вы не захотите использовать ее в рабочей среде. Это предназначено для архивирования и тестирования, а срок действия артефактов из завершенных сборок истекает через 90 дней.
Также есть пакеты GitHub, которые предназначены для замены менеджеров пакетов для конкретных языков, таких как JavaScript.
npm
. Это может быть очень полезно, если вы публикуете пакет NPM, но не так полезно для других типов сборок.
Для любого другого типа артефактов корзины S3 Amazon остаются одним из распространенных способов загрузки файлов для распространения и развертывания. Они поддерживаются системой разрешений IAM AWS, которая обеспечивает превосходную безопасность и позволяет точно настроить контроль доступа к скомпилированному исходному коду.
Альтернативно, если вы используете контейнеры Docker для развертывания, вместо этого вам может понадобиться реестр контейнеров. К счастью, у GitHub есть частный реестр, с которым легко интегрироваться, и вы можете прочитать наше руководство по его использованию, чтобы узнать больше.
Использовать S3 довольно просто, и большинство показанных здесь шагов также применимо к S3-совместимым решениям для хранения данных, таким как Digital Ocean Spaces или MinIO с автономным размещением, поскольку они используют один и тот же API.
Загрузка в AWS S3 из действий GitHub
Для начала вам нужно убедиться, что остальная часть вашего сценария сборки GitHub Actions работает и создает действительную сборку, поскольку обычно вы не хотите отлаживать несколько проблем одновременно.
Если у вас его еще нет, настройка будет зависеть от вашей цепочки инструментов сборки, но вы можете прочитать наше руководство по настройке автоматических сборок, чтобы узнать больше. Вы также можете протестировать артефакт, который будет загружен, с помощью встроенного инструмента GitHub.
upload-artifact
действие, которое публикует содержимое каталога в виде пакета.
Затем вы можете подтвердить создание пакета в разделе «Сводка» > «Артефакты».
Если у вас есть сборка, которая не дает сбоев, вы можете добавить загрузку S3 в ее конец. Официального способа легко это сделать не существует, и на GitHub Action Marketplace существует множество различных решений.
Самым популярным из них является S3 Sync, который использует собственный API S3 для загрузки встроенных артефактов и прост в настройке. Существуют также простые оболочки, такие как s3cmd, которые позволяют передавать команды непосредственно в интерфейс командной строки S3.
Однако одно замечание: большинство из них полагаются на Linux-раннеры или контейнеры Docker, которые имеют необходимые зависимости для работы S3 CLI. Linux — это то, на чем работает большинство сборок, но если вам нужно использовать Windows для запуска сборок, вам придется использовать другое действие. Кроссплатформенный вариант, который, как мы обнаружили, работает, — это stcalica/s3-upload. При этом используется оболочка JavaScript, которая устанавливает пакет s3cmd и прекрасно работает в Windows.
Прежде всего вам нужно будет настроить секреты GitHub для ваших токенов аутентификации AWS. Разумеется, они не могут быть общедоступными, их нужно будет хранить в секретах репозитория и обращаться к ним по имени. Это предотвращает случайную утечку ваших токенов и позволяет легко управлять ключами.
Вы можете прочитать наше руководство по использованию секретов GitHub, чтобы узнать о них больше, но главное, что от вас требуется, — это зайти в настройки репозитория, затем нажать «Секреты» > «Действия» и создать
Затем в конце сценария действий GitHub добавьте именованный шаг «развертывание» и настройте его на использование действия s3-sync или любого другого, которое вы выбрали. Вам нужно будет передать секреты для ключа доступа и идентификатора, которые вы настроили в качестве переменных среды.
... - name: Deploy To S3 - uses: actions/checkout@master - uses: jakejarvis/s3-sync-action@master with: args: --acl public-read --follow-symlinks --delete env: AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_REGION: 'us-east-1' # optional: defaults to us-east-1 SOURCE_DIR: 'bin/Linux/net48' # optional: defaults to entire repository DEST_DIR: '/' # optional: defaults to root of the bucket
В частности, с помощью этого рабочего процесса вы также можете передавать аргументы непосредственно в s3cmd, который можно использовать, например, для включения общедоступных списков управления доступом для чтения. Здесь объект становится общедоступным, а старое содержимое в этом каталоге в корзине удаляется, гарантируя, что все соответствует выходным данным сборки и не содержит старых файлов.
После этого остается только зафиксировать изменения сценария сборки и, при необходимости, повторно запустить сборку вручную, если она не запускается автоматически при новой фиксации. Вы не увидите никаких результатов сборки в GitHub, поскольку они были отправлены на S3, но вы можете проверить журналы s3cmd на этапе «развертывание на S3» в журнале сборки:
Надеемся, вы увидите вывод журнала, аналогичный приведенному выше, подтверждающий успешное выполнение процесса.