Я настроил веб-приложение и базу данных в Azure, и сейчас пытаюсь развернуть свой код через действия GitHub в центре развертывания. Я добавил строку подключения к моей базе данных в секреты GitHub, но получаю ошибку:
[22:54:57] ERROR (payload): Ошибка: невозможно подключиться к Postgres. Подробности: getaddrinfo
ENOTFOUND myapp-database-server.postgres.database.azure.com
Ошибка: команда завершилась с кодом выхода 1.
На самом деле это имеет смысл, потому что как могут действия GitHub проверить, существует ли моя база данных, если она находится за VNet? Поэтому мне интересно, как я могу решить эту проблему, не удаляя свой VNet и не делая базу данных публичной?
Один из вариантов, указанных в комментариях, это раннеры. Я нашел этот код для добавления в мой yml файл:
- name: Добавить IP GitHub Runner в белый список
uses: azure/CLI@v1
with:
inlineScript: |
set -eu
agentIP=$(curl -s https://api.ipify.org/)
az storage account network-rule add \
--resource-group "${{ secrets.RESOURCE_GROUP }}" \
--account-name "${{ secrets.STORAGE_ACCOUNT_NAME }}" \
--ip-address $agentIP
sleep 300
Мой вопрос: как я могу добавить исключение IP в VNet? Нужно ли мне как-то настроить брандмауэр и разрешить доступ по IP?
Ответ
Чтобы разрешить доступ GitHub Actions к вашей базе данных в Azure, находящейся за виртуальной сетью (VNet), существует несколько шагов, которые нужно выполнить. Ниже приведены детальные шаги для настройки нужного доступа, не открывая вашу базу данных для публичного доступа.
Шаг 1: Настройка Azure для разрешения доступа по IP
-
Получите IP-адрес GitHub Actions: Каждый раз, когда ваш действие GitHub выполняется, вам необходимо получить IP-адрес текущего исполнителя (runner). GitHub Actions использует динамические IP-адреса, поэтому необходимо использовать API, чтобы узнавать актуальный адрес.
- Изменение правил сети: Вы можете добавить этот IP-адрес в правила сетевого доступа вашей базы данных в Azure, чтобы разрешить входящий трафик от него. Для этого вам нужно будет использовать Azure CLI.
Шаг 2: Добавление правила исключения IP в виртуальную сеть
В вашем .yml файле действий GitHub вам нужно будет добавить код, чтобы получить IP-адрес ощущателя и добавить его в правила доступа, используя Azure CLI. Вот пример того, как это сделать:
name: Deploy to Azure
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Azure CLI
uses: azure/setup-cli@v1
- name: Whitelist GitHub Runner IP
uses: azure/CLI@v1
with:
inlineScript: |
set -eu
agentIP=$(curl -s https://api.ipify.org/)
az postgres server firewall-rule create \
--resource-group "${{ secrets.RESOURCE_GROUP }}" \
--server "${{ secrets.DB_SERVER_NAME }}" \
--name "GitHubActionsRule" \
--start-ip-address $agentIP \
--end-ip-address $agentIP
- name: Deploy to Azure Web Apps
run: |
# Ваша команда развертыванияШаг 3: Убедитесь, что у вас есть необходимые разрешения
Для выполнения вышеприведенных команд у вашего действия GitHub должны быть надлежащие права доступа к ресурсам Azure. Убедитесь, что ваш сервисный принципал (или пользователя, под которым выполняется GitHub Actions) имеет права на Microsoft.DBforPostgreSQL/servers/firewallRules/*.
Шаг 4: Поддержка обновления правил
Так как IP-адреса GitHub Actions могут меняться, потребуется обновлять правила, используя вышеприведенный скрипт каждый раз, когда выполняется GitHub Action. Это может быть обработано в том же процессе развертывания.
Шаг 5: Удаление старых правил (по желанию)
Если ваш GitHub Actions будет выполняться часто и вы не хотите перегружать свои правила сети, вы можете добавить шаг для удаления старого правила, прежде чем добавлять новое:
- name: Remove old GitHub Runner IP rule
uses: azure/CLI@v1
with:
inlineScript: |
az postgres server firewall-rule delete \
--resource-group "${{ secrets.RESOURCE_GROUP }}" \
--server "${{ secrets.DB_SERVER_NAME }}" \
--name "GitHubActionsRule" || echo "No existing rule to delete"Заключение
Эти шаги помогут вам разрешить доступ GitHub Actions к вашей базе данных в Azure через виртуальную сеть, не открывая ее для публичного доступа. Убедитесь, что вы тестируете и следите за изменениями в IP-адресах, чтобы поддерживать доступ.