Бөлісу құралы:


Развертывание веб-приложения Python Django с помощью PostgreSQL в Azure

В этом руководстве вы развернете веб-приложение Python на основе данных в службе приложений Azure , которая использует службу реляционной базы данных Azure для PostgreSQL . Служба приложений Azure поддерживает Python в среде сервера Linux. В этой статье используется Django. К альтернативным вариантам относятся Flask или учебник FastAPI.

Схема, демонстрирующая архитектуру службы приложений с базой данных PostgreSQL в Azure.

В этом руководстве вы узнаете, как:

  • Создайте архитектуру изначально безопасной службы приложений, PostgreSQL и кеша Redis.
  • Обеспечьте безопасность секретов подключения, используя управляемую идентификацию и ссылки на Key Vault.
  • Разверните образец Python-приложения в службе приложений из репозитория GitHub.
  • Доступ к Служба приложений строка подключения и параметрам приложения в коде приложения.
  • Внесите обновления и заново разверните код приложения.
  • Генерируйте схему базы данных, запуская миграции базы данных.
  • Транслируйте диагностические журналы из Azure.
  • Управляйте приложением в портале Azure.
  • Подготовьте ту же архитектуру и разверните её с помощью Azure Developer CLI.
  • Оптимизируйте ваш процесс разработки с помощью GitHub Codespaces и GitHub Copilot.

Предпосылки

Перейти к концу

Если вы просто хотите увидеть, как образец приложения из этого руководства работает в Azure, выполните следующие команды в Azure Cloud Shell и следуйте инструкциям на экране:

mkdir msdocs-django-postgresql-sample-app
cd msdocs-django-postgresql-sample-app
azd init --template msdocs-django-postgresql-sample-app
azd up

Запустите пример

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

Замечание

Если вы следуете вместе с этим руководством с собственным приложением, ознакомьтесь с описанием файла requirements.txt в README.md , чтобы узнать, какие пакеты вам нужны.

Шаг 1. В новом окне браузера:

  1. Войдите в свой аккаунт GitHub.
  2. Перейдите по адресу https://github.com/Azure-Samples/msdocs-django-postgresql-sample-app/fork.
  3. Снимите отметку Копировать только основную ветвь. Вы хотите все ветви.
  4. Выберите Создать форк.

Шаг 2. В форке GitHub:

  1. Выберите main> ветвь starter-no-infra для начальной ветви. Эта ветвь содержит только пример проекта и не содержит файлов или конфигурации, связанных с Azure.
  2. Выберите Код>Создать пространство кода на starter-no-infra. Настройка кодового пространства занимает несколько минут. Это выполняется pip install -r requirements.txt для вашего репозитория. Предоставленный ENV-файл уже содержит фиктивнуюSECRET_KEY переменную, которую Django необходимо выполнить локально.

Шаг 3. В терминале пространства кода:

  1. Выполните миграции базы данных с python manage.py migrate.
  2. Запустите приложение, выполнив команду python manage.py runserver.
  3. Когда появится уведомление Your application running on port 8000 is available., нажмите кнопку "Открыть в браузере". Вы должны увидеть пример приложения в новой вкладке браузера. Чтобы остановить приложение, введите Ctrl+C.

Подсказка

Вы можете попросить GitHub Copilot об этом репозитории. Рассмотрим пример.

  • @workspace Что делает этот проект?
  • @workspace Что делает папка devcontainer?

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Создание службы приложений, базы данных и кэша

На этом шаге создайте ресурсы Azure. В этом руководстве создается набор безопасных ресурсов по умолчанию, включая службу приложений, базу данных Azure для PostgreSQL и кэш Azure. Для процесса создания вы указываете:

  • Название для веб-приложения. Он используется в качестве части DNS-имени приложения.
  • Регион для физического запуска приложения в мире. Это также часть DNS-имени приложения.
  • Стек выполняющей среды для приложения. Вы выбираете версию Python, используемую для приложения.
  • План размещения для приложения. Ценовая категория включает набор функций и емкость масштабирования для приложения.
  • Группа ресурсов для приложения. Группа ресурсов позволяет группировать все ресурсы Azure, необходимые для приложения в логическом контейнере.

Войдите на портал Azure. Выполните следующие действия, чтобы создать ресурсы службы приложений Azure.

Шаг 1. На портале Azure:

  1. В верхней части портала Azure в поле поиска введите базу данных веб-приложения.
  2. В разделе заголовка Marketplace выберите элемент, помеченный веб-приложением и базой данных. Вы также можете перейти к созданию веб-приложения напрямую.

Шаг 2. На странице "Создание веб-приложения + база данных " заполните форму следующим образом.

  1. Группа ресурсов: выберите "Создать" и введите msdocs-django-postgres-tutorial.
  2. Регион: любой регион Azure рядом с вами.
  3. Имя: msdocs-python-postgres-XYZ.
  4. Стек среды выполнения: Python 3.14.
  5. База данных: PostgreSQL — гибкий сервер по умолчанию выбирается в качестве ядра СУБД. Имя сервера и имя базы данных также устанавливаются по умолчанию на соответствующие значения.
  6. Добавление кэша Azure для Redis: Да.
  7. План размещения: базовый. Когда вы будете готовы, вы можете перейти на производственный ценовой уровень.
  8. Выберите "Рецензирование и создание".
  9. После завершения проверки нажмите кнопку "Создать".

Шаг 3. Развертывание занимает несколько минут. После завершения развертывания выберите Перейти к ресурсу. Развертывание создает следующие ресурсы:

  • Группа ресурсов: контейнер для всех созданных ресурсов.
  • План службы приложений: определяет вычислительные ресурсы для службы приложений. Этот экземпляр является планом для Linux на уровне "Базовый".
  • App Service: представляет ваше приложение и работает в плане App Service.
  • Виртуальная сеть: интегрирована с приложением службы приложений и изолирует внутренний сетевой трафик.
  • Частная конечная точка: доступ к конечной точке кэша Redis в виртуальной сети.
  • Сетевые интерфейсы: частные IP-адреса, по одному для каждой из частных конечных точек.
  • Гибкий сервер Базы данных Azure для PostgreSQL: доступен только из виртуальной сети. Развертывание создает базу данных и пользователя на сервере.
  • Кэш Azure для Redis: доступен только из частной сети.
  • Частные зоны DNS: позволяет разрешение DNS для сервера базы данных Redis-кэша в виртуальной сети.

Защита секретов подключения и добавление SECRET_KEY

Процесс развертывания создает переменные подключения для вас в качестве параметров приложения. Рекомендуется ради безопасности полностью исключить хранение секретов в службе приложений. Переместите секреты в хранилище ключей и измените параметры приложения на ссылки на Key Vault с помощью коннекторов служб.

Шаг 1. Получение существующей строки подключения

  1. В меню слева на странице "Служба приложений" выберите Параметры>переменные среды.
  2. Выберите AZURE_POSTGRESQL_CONNECTIONSTRING.
  3. В разделе "Добавление и изменение параметра приложения" в поле "Значение " найдите часть password= в конце строки.
  4. Скопируйте строку пароля после пароля= для последующего использования. Этот параметр приложения позволяет подключаться к базе данных Postgres и кэшу Redis, защищенному за частными конечными точками. Секреты сохраняются непосредственно в приложении службы приложений, что не является лучшим подходом. Вы измените эту конфигурацию. Вы также добавляете SECRET_KEY параметр, который требуется вашему приложению Django.

Шаг 2. Создание хранилища ключей для безопасного управления секретами

  1. В верхней строке поиска введите хранилище ключей, а затем выберите Marketplace>Key Vault.
  2. В группе ресурсов выберите msdocs-python-postgres-tutorial.
  3. В имени хранилища ключей введите имя, состоящее только из букв и чисел.
  4. В регионе выберите то же расположение, что и группа ресурсов.

Шаг 3. Защита хранилища ключей с помощью частной конечной точки

  1. Выберите вкладку "Сеть".
  2. Отмена выбора включения общедоступного доступа.
  3. Выберите "Создать частную конечную точку".
  4. В группе ресурсов выберите msdocs-python-postgres-tutorial.
  5. В диалоговом окне в расположении выберите то же расположение, что и приложение службы приложений.
  6. В поле Name введите msdocs-python-postgres-XYZVaultEndpoint.
  7. В виртуальной сети выберите msdocs-python-postgres-XYZVnet.
  8. В подсетиmsdocs-python-postgres-XYZSubnet.
  9. Нажмите кнопку "ОК".
  10. Выберите "Просмотр и создание", а затем нажмите кнопку "Создать". Дождитесь завершения развертывания хранилища ключей. Вы увидите, что развертывание завершено.

Шаг 4. Настройка соединителя PostgreSQL

  1. В верхней строке поиска введите msdocs-python-postgres, а затем выберите ресурс службы приложений msdocs-python-postgres-XYZ.
  2. На странице "Служба приложений" в меню слева выберите "Параметры>соединителя службы". Уже существует два соединителя, которые процесс создания приложения сделал для вас.
  3. Установите флажок рядом с соединителем PostgreSQL, а затем нажмите кнопку "Изменить".
  4. В типе клиента выберите Django. Тип клиента Django в соединителе службы PostgreSQL предоставляет переменные базы данных в отдельных параметрах вместо одной строки подключения. Отдельные переменные проще использовать в параметрах базы данных Django.
  5. Выберите Проверка подлинности.
  6. Вставьте пароль, скопированный ранее.
  7. Выберите "Сохранить секрет" в Key Vault.
  8. В разделе "Подключение к Key Vault" выберите "Создать". Это действие открывает диалоговое окно "Создание подключения " в верхней части диалогового окна редактирования.

Шаг 5. Установка подключения к Key Vault

  1. В диалоговом окне "Создание подключения" для подключения Key Vault в Key Vault выберите созданное ранее хранилище ключей.
  2. Выберите "Рецензирование и создание".
  3. После завершения проверки нажмите кнопку "Создать".

Шаг 6. Завершение параметров соединителя PostgreSQL

  1. Вы вернулись в диалоговое окно редактирования элемента defaultConnector. Под аутентификацией дождитесь создания подключения к хранилищу ключей. Раскрывающийся список подключений Key Vault автоматически выбирает его.
  2. Нажмите кнопку "Далее" — сеть.
  3. Нажмите кнопку "Сохранить". Подождите, пока появится уведомление об успешном обновлении .

Шаг 7. Настройка соединителя Redis для использования секретов Key Vault

  1. На странице соединителей служб установите флажок рядом с соединителем Cache for Redis, а затем нажмите кнопку "Изменить".
  2. Выберите Проверка подлинности.
  3. Выберите "Сохранить секрет" в Key Vault.
  4. В разделе "Подключение к Key Vault" выберите созданное хранилище ключей.
  5. Нажмите кнопку "Далее" — сеть.
  6. Выберите "Настроить правила брандмауэра", чтобы включить доступ к целевой службе. Процесс создания приложения уже защищен базой данных SQL с помощью частной конечной точки.
  7. Нажмите кнопку "Сохранить". Подождите, пока появится уведомление об успешном обновлении .

Шаг 8. Проверка интеграции Key Vault

  1. В меню слева снова выберите Параметры Переменные среды>.
  2. Рядом с AZURE_POSTGRESQL_PASSWORD выберите "Показать значение". Значение должно быть @Microsoft.KeyVault(...). Это означает, что это ссылка на хранилище ключей , так как секрет теперь управляется в хранилище ключей.
  3. Чтобы проверить строку подключения Redis, выберите "Показать значение " рядом с AZURE_REDIS_CONNECTIONSTRING.

Шаг 9. Пример приложения считывает переменную среды SECRET_KEY, чтобы задать необходимый параметр SECRET_KEY. Вы создаете его в качестве параметра приложения на этом шаге.

  1. На вкладке "Параметры приложения " нажмите кнопку "Добавить".
  2. Установите Name в SECRET_KEY.
  3. Задайте значение длинной случайной строки.
  4. Нажмите кнопку "Применить", а затем еще раз применить , а затем подтвердите.

Вкратце, процесс защиты ваших секретов подключения включал:

  • Извлечение секретов подключения из переменных окружения приложения App Service.
  • Создание хранилища ключей.
  • Создание подключения к хранилищу ключей с использованием управляемой идентичности, назначенной системой.
  • Обновление служебных соединителей для хранения секретов в хранилище ключей.

Замечание

В идеале параметр приложения SECRET_KEY должен быть настроен как ссылка на хранилище ключей, что является многоэтапным процессом. Дополнительные сведения см. в статье о том, как изменить параметр приложения SECRET_KEY на ссылку Key Vault?

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".


Развертывание примера кода

В этом разделе описана настройка развертывания GitHub с помощью GitHub Actions. Это один из многих способов развертывания приложений в App Service. Это отличный способ непрерывной интеграции в процессе развертывания. По умолчанию каждый git push из репозитория GitHub запускает действие сборки и развертывания.

Шаг 1. В меню слева выберитеЦентр развертывания>.

Шаг 2. На странице Центра развертывания :

  1. В источнике выберите GitHub. По умолчанию GitHub Actions выбирается в качестве поставщика сборки.
  2. Войдите в свой аккаунт GitHub и следуйте указаниям, чтобы авторизовать Azure.
  3. В организации выберите свою учетную запись.
  4. В репозитории выберите msdocs-django-postgresql-sample-app.
  5. В Branch выберите starter-no-infra. Эта ветвь такая же, в которой вы работали с вашим примером приложения, но без файлов или конфигурации, связанных с Azure.
  6. Для типа проверки подлинности выберите пользовательское назначенное удостоверение.
  7. В верхнем меню нажмите кнопку "Сохранить". Служба приложений фиксирует файл рабочего процесса в репозитории GitHub в каталоге .github/workflows . По умолчанию центр развертывания создает назначаемое пользователем удостоверение для рабочего процесса для проверки подлинности с помощью Microsoft Entra (проверка подлинности OIDC). Другие параметры проверки подлинности см. в разделе "Развертывание в службе приложений" с помощью GitHub Actions.

Шаг 3. Вернитесь в GitHub Codespace вашего форка примера и выполните команду git pull origin starter-no-infra. Эта команда извлекает только что зафиксированный файл рабочего процесса в пространство кода.

Шаг 4 (вариант 1: с GitHub Copilot):

  1. Запустите новый сеанс чата, выбрав представление чата , а затем выберите +.
  2. Спросите: "@workspace Как приложение подключается к базе данных и redis?" Copilot может дать вам некоторое объяснение о настройке параметров в azureproject/development.py и azureproject/production.py.
  3. Спросите: "@workspace В рабочем режиме мое приложение работает в веб-приложении службы приложений, которое использует соединитель службы Azure для подключения к гибкому серверу PostgreSQL с помощью типа клиента Django. Что такое имена переменных среды, которые мне нужно использовать? Copilot может дать вам предложение кода, аналогичное варианту 2: без действий GitHub Copilot , и даже сообщить вам, чтобы внести изменения в файл azureproject/production.py .
  4. Откройте azureproject/production.py в обозревателе и добавьте предложение кода.
  5. Спросите: "@workspace мое приложение 'Моя служба приложений' также использует Azure Service Connector для подключения к Redis Cache через клиент Django. Имена переменных среды, которые мне нужно использовать? Copilot может предложить вам код, аналогичный тому, который описан в варианте 2: без GitHub Copilot, и даже указать, чтобы вы изменили файл azureproject/production.py.
  6. Добавьте рекомендацию кода. GitHub Copilot не дает вам одинаковый ответ каждый раз. Ответы не всегда верны. Вам, возможно, потребуется задать больше вопросов, чтобы уточнить его ответ. Советы см. в статье "Что можно сделать с помощью GitHub Copilot в моем пространстве кода?".

Шаг 4 (вариант 2: без GitHub Copilot):

  1. Откройте azureproject/production.py в обозревателе.
  2. Найдите закомментированный код (строки 29–48) и уберите комментарии. Этот код создает подключения PostgreSQL и Redis с помощью AZURE_POSTGRESQL_USER, , AZURE_POSTGRESQL_PASSWORD, AZURE_POSTGRESQL_HOSTAZURE_POSTGRESQL_NAMEи AZURE_REDIS_CONNECTIONSTRING.

Шаг 5.

  1. Выберите расширение Контроль версий.
  2. В текстовом поле введите сообщение о коммите, например Configure Azure database and cache connections. Или выберите и позвольте GitHub Copilot сгенерировать для вас сообщение коммита.
  3. Нажмите кнопку "Зафиксировать", а затем подтвердите значение "Да".
  4. Нажмите кнопку "Синхронизировать изменения 1", а затем нажмите кнопку "ОК".

Шаг 6. Вернитесь в Центр развертывания на портале Azure:

  1. Выберите журналы, а затем нажмите кнопку "Обновить ", чтобы увидеть новое выполнение развертывания.
  2. В элементе журнала для запуска развертывания выберите запись "Журналы сборки/развертывания" с последней меткой времени.

Шаг 7. Вы перейдете в репозиторий GitHub. Действие GitHub выполняется. Файл рабочего процесса определяет два отдельных этапа: сборку и развертывание. Дождитесь запуска GitHub, чтобы отобразить состояние успешности. Это занимает около 5 минут.

Есть проблемы? Ознакомьтесь с руководством по устранению неполадок.

Создание схемы базы данных

При использовании базы данных PostgreSQL, защищенной виртуальной сетью, проще всего запустить миграцию баз данных Django в сеансе SSH с контейнером Linux в службе приложений.

Шаг 1. Вернитесь на страницу службы приложений в меню слева:

  1. Выберите Средства разработки>SSH.
  2. Нажмите кнопку "Перейти".

Шаг 2. В сеансе SSH выполните команду python manage.py migrate. Если это удается, служба приложений успешно подключается к базе данных.

Подсказка

В SSH-сессии только изменения в файлах в /home могут сохраняться после перезапуска приложения. Изменения за пределами /home не сохраняются.

Сеанс SSH полезен для выполнения распространенных python manage.py команд, таких как создание пользователя с помощью .python manage.py createsuperuser Дополнительные сведения см. в разделе django django-admin и manage.py. Используйте учетную запись суперпользователя для доступа к /admin части веб-сайта.

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Переход в приложение

Шаг 1. На странице службы приложений :

  1. В меню слева выберите "Обзор".
  2. Выберите URL-адрес вашего приложения.

Шаг 2. Добавьте несколько ресторанов в список. Поздравляю! Вы запускаете веб-приложение в Службе приложений Azure с безопасным подключением к Базе данных Azure для PostgreSQL.

Трансляция журналов диагностики

Служба Azure App Service фиксирует все журналы консоли, чтобы помочь вам диагностировать проблемы с вашим приложением. Пример приложения содержит print() инструкции для демонстрации этой возможности.

def index(request):
    print('Request for index page received')
    restaurants = Restaurant.objects.annotate(avg_rating=Avg('review__rating')).annotate(review_count=Count('review'))
    lastViewedRestaurant = request.session.get("lastViewedRestaurant", False)

Шаг 1. На странице службы приложений :

  1. В меню слева выберите Мониторинг>журналы службы приложений.
  2. В разделе "Ведение журнала приложений" выберите файловую систему.
  3. В верхнем меню нажмите кнопку "Сохранить".

Шаг 2. В меню слева выберите поток журналов. Вы видите логи для своего приложения, включая логи платформы и логи внутри контейнера.

Дополнительные сведения о входе в приложения Python см. в статье о настройке Azure Monitor для приложения Python.

Очистите ресурсы

Когда вы закончите, вы можете удалить все ресурсы из вашей подписки Azure, удалив группу ресурсов.

Шаг 1. В строке поиска в верхней части портала Azure:

  1. Введите имя группы ресурсов.
  2. Выберите группу ресурсов.

Шаг 2. На странице группы ресурсов выберите "Удалить группу ресурсов".

Шаг 3.

  1. Чтобы подтвердить удаление, введите имя группы ресурсов.
  2. Нажмите кнопку "Удалить".

Создание ресурсов Azure и развертывание примера приложения

В этом разделе описано, как создать ресурсы Azure и развернуть пример приложения в Службе приложений в Linux. Действия, используемые в этом руководстве, создают набор защищенных по умолчанию ресурсов, включающих службу приложений, базу данных Azure для PostgreSQL и кэш Azure для Redis.

Контейнер разработки уже имеет интерфейс командной строки разработчика Azure (AZD).

  1. Выполните команду azd init из корневого каталога репозитория.

    azd init --template python-app-service-postgresql-infra
    
  2. При появлении запроса укажите следующие ответы:

    Вопрос Ответ
    Текущий каталог не пуст. Вы хотите инициализировать проект здесь, в '<вашем каталоге>'? Y
    Что вы хотите сделать с этими файлами? Сохранение существующих файлов без изменений
    Введите новое имя среды Введите уникальное имя. Шаблон AZD использует это имя как часть имени DNS вашего веб-приложения в Azure (<app-name>-<hash>.azurewebsites.net). Допустимы буквенно-цифровые символы и дефисы.
  3. Войдите в Azure, запустив команду azd auth login и следуя указаниям:

    azd auth login
    
  4. Создайте необходимые ресурсы Azure с помощью команды azd provision. Выполните указания, чтобы выбрать нужную подписку и местоположение для ресурсов Azure.

    azd provision
    

    Выполнение azd provision команды занимает около 15 минут. Кэш Redis занимает больше всего времени. Позже измените код для работы со Службой приложений и разверните изменения с помощью azd deploy. Во время выполнения команда в командной строке предоставляет сообщения о процессе подготовки и развертывания. Выходные данные включают ссылку на развертывание в Azure.

    Этот шаблон AZD содержит файлы (azure.yaml и infra каталог), создающие безопасную архитектуру по умолчанию со следующими ресурсами Azure:

    • Группа ресурсов: контейнер для всех созданных ресурсов.
    • План службы приложений: определяет вычислительные ресурсы для службы приложений. Он создает план Linux на уровне "Базовый ".
    • App Service: представляет ваше приложение и работает в плане App Service.
    • Виртуальная сеть: интегрирована с приложением службы приложений и изолирует внутренний сетевой трафик.
    • Частные конечные точки: доступ к конечным точкам для хранилища ключей и кэша Redis в виртуальной сети.
    • Сетевые интерфейсы: частные IP-адреса, по одному для каждой из частных конечных точек.
    • Гибкий сервер Базы данных Azure для PostgreSQL: доступен только из виртуальной сети. Он создает базу данных и пользователя на сервере.
    • Частная зона DNS: включает разрешение DNS сервера PostgreSQL в виртуальной сети.
    • Рабочая область Log Analytics: выступает в качестве целевого контейнера для вашего приложения для отправки журналов, где можно также запрашивать журналы.
    • Кэш Azure для Redis: доступен только через приватную конечную точку.
    • Хранилище ключей: доступно только из собственного частного конечного узла. Используется для управления секретами в приложении App Service.

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

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Использование строки подключения к базе данных

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

  1. В выходных данных AZD найдите параметры AZURE_POSTGRESQL_USER, AZURE_POSTGRESQL_PASSWORD, AZURE_POSTGRESQL_HOST, AZURE_POSTGRESQL_NAME и AZURE_REDIS_CONNECTIONSTRING. Чтобы сохранить секреты в безопасности, отображаются только названия настроек. Они выглядят следующим образом в выходных данных AZD:

     App Service app has the following connection settings:
             - AZURE_POSTGRESQL_NAME
             - AZURE_POSTGRESQL_HOST
             - AZURE_POSTGRESQL_USER
             - AZURE_POSTGRESQL_PASSWORD
             - AZURE_REDIS_CONNECTIONSTRING
             - AZURE_KEYVAULT_RESOURCEENDPOINT
             - AZURE_KEYVAULT_SCOPE
     
  2. Для вашего удобства шаблон AZD показывает вам прямую ссылку на страницу настроек приложения. Найдите ссылку и откройте ее в новой вкладке браузера.

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Изменение примера кода и повторное развертывание

  1. В пространстве кода GitHub запустите новый сеанс чата, выбрав представление чата , а затем выберите +.

  2. Спросите: "@workspace Как приложение подключается к базе данных?". Copilot может дать вам некоторое описание настройки параметров подключения в azureproject/development.py и azureproject/production.py.

  3. Спросите: "@workspace В рабочем режиме мое приложение работает в веб-приложении службы приложений, которое использует соединитель службы Azure для подключения к гибкому серверу PostgreSQL с помощью типа клиента Django. Что такое имена переменных среды, которые мне нужно использовать? Copilot может дать вам предложение кода, аналогичное варианту 2: без действий GitHub Copilot , и даже сообщить вам, чтобы внести изменения в файл azureproject/production.py .

  4. Откройте azureproject/production.py в обозревателе и добавьте предложение кода.

    GitHub Copilot не дает вам одинаковый ответ каждый раз. Ответы не всегда верны. Вам, возможно, потребуется задать больше вопросов, чтобы уточнить его ответ. Советы см. в статье "Что можно сделать с помощью GitHub Copilot в моем пространстве кода?".

  5. В терминале выполните azd deploy.

    azd deploy
    

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Создание схемы базы данных

При использовании базы данных PostgreSQL, защищенной виртуальной сетью, проще всего запустить миграцию баз данных Django в сеансе SSH с контейнером Linux в службе приложений.

  1. В выходных данных AZD найдите URL-адрес сеанса SSH и перейдите к нему в браузере. Это выглядит так на выходе:

    Open SSH session to App Service container at: <URL>
    
  2. В SSH-сессии выполните команду python manage.py migrate. Если команда выполнена успешно, служба приложений успешно подключается к базе данных.

    Снимок экрана, показывающий команды для выполнения в оболочке SSH и их вывод (Django).

    Замечание

    Только изменения файлов в /home могут сохраняться после перезапуска приложения. Изменения за пределами /home не сохраняются.

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Переход в приложение

  1. В выводе AZD найдите URL вашего приложения и откройте его в браузере. URL-адрес выглядит следующим образом в выходных данных AZD:

    Deploying services (azd deploy)
    
      (✓) Done: Deploying service web
      - Endpoint: <URL>
    
  2. Добавьте несколько ресторанов в список.

    Снимок экрана веб-приложения Django с PostgreSQL, работающим в Azure, где показаны рестораны и отзывы о ресторанах (Django).

    Поздравляю! Вы запускаете веб-приложение в Службе приложений Azure с безопасным подключением к Базе данных Azure для PostgreSQL.

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Трансляция журналов диагностики

Служба приложений Azure может записывать журналы консоли, чтобы помочь вам в диагностике проблем с вашим приложением. Для удобства шаблон AZD уже включает логирование в локальную файловую систему и отправляет лог-файлы в рабочую область Log Analytics.

Образец приложения включает операторы print(), чтобы продемонстрировать эту возможность, как показано в следующем фрагменте.

def index(request):
    print('Request for index page received')
    restaurants = Restaurant.objects.annotate(avg_rating=Avg('review__rating')).annotate(review_count=Count('review'))
    lastViewedRestaurant = request.session.get("lastViewedRestaurant", False)

В выводе AZD найдите ссылку для потоковой передачи журналов службы приложений и перейдите по ней в браузере.

Stream App Service logs at: <URL>

Узнайте больше о логгировании в Python-приложениях в серии статей о настройке Azure Monitor для вашего приложения на Python.

Есть проблемы? Ознакомьтесь с разделом "Устранение неполадок".

Очистите ресурсы

Чтобы удалить все ресурсы Azure в текущей среде развертывания, выполните azd down и следуйте инструкциям.

azd down

Устранение неполадок

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

Я не могу подключиться к SSH-сессии.

Если вы не можете подключиться к сеансу SSH, само приложение не запускается. Дополнительные сведения см. в журналах диагностики . Например, если отображается ошибка KeyError: 'AZURE_POSTGRESQL_HOST', это может означать, что переменная среды отсутствует. Возможно, вы удалили параметр приложения.

При выполнении миграции базы данных возникает ошибка

Если вы столкнётесь с ошибками, связанными с подключением к базе данных, проверьте, были ли изменены или удалены настройки приложения (AZURE_POSTGRESQL_USER, AZURE_POSTGRESQL_PASSWORD, AZURE_POSTGRESQL_HOST, и AZURE_POSTGRESQL_NAME). Без этой строки подключения команда migrate не может взаимодействовать с базой данных.

Часто задаваемые вопросы

Сколько стоит такая конфигурация?

Цены на созданные ресурсы следующие:

  • План службы приложений создается на уровне "Базовый" и может масштабироваться вверх или вниз. См. цены на службу приложений.
  • Гибкий сервер PostgreSQL создается на самом низком уровне, Standard_B1ms с минимальным размером хранилища, который можно масштабировать вверх или вниз. См. цены на Базу данных Azure для PostgreSQL.
  • Виртуальная сеть не требует оплаты, если вы не настроите дополнительные функции, такие как пиринг. См. цены на виртуальную сеть Azure.
  • За частную зону DNS взимается небольшая плата. См. цены на Azure DNS.

Как подключиться к серверу PostgreSQL, защищенному виртуальной сетью, с помощью других инструментов?

  • Для базового доступа из командной строки вы можете запустить psql из SSH-сеанса приложения.
  • Чтобы подключиться с помощью настольного инструмента, ваш компьютер должен находиться в виртуальной сети. Например, это может быть виртуальная машина Azure, подключенная к одной из подсетей, или компьютер в локальной сети с VPN-подключением типа "сеть — сеть " с виртуальной сетью Azure.
  • Вы также можете интегрировать Azure Cloud Shell с виртуальной сетью.

Как осуществляется разработка локальных приложений с использованием GitHub Actions?

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

git add .
git commit -m "<some-message>"
git push origin main

Как настроен пример Django для запуска в Службе приложений Azure?

Пример приложения Django настраивает параметры в файле azureproject/production.py, чтобы он мог выполняться в Службе приложений Azure. Эти изменения являются общими для развертывания Django в рабочей среде, а не для службы приложений.

  • Django проверяет заголовок HTTP_HOST в входящих запросах. Пример кода использует WEBSITE_HOSTNAME переменную среды в Службе приложений для добавления доменного имени приложения в параметр ALLOWED_HOSTS Django.

    # Configure the domain name using the environment variable
    # that Azure automatically creates for us.
    ALLOWED_HOSTS = [os.environ['WEBSITE_HOSTNAME']] if 'WEBSITE_HOSTNAME' in os.environ else []
    
  • Django не поддерживает обслуживание статических файлов в рабочей среде. В этом руководстве описано, как включить обслуживание файлов с помощью WhiteNoise . Пакет WhiteNoise уже был установлен вместе с requirements.txt, и его middleware добавлено в список.

    
    # WhiteNoise configuration
    MIDDLEWARE = [
        'django.middleware.security.SecurityMiddleware',
        # Add whitenoise middleware after the security middleware
        'whitenoise.middleware.WhiteNoiseMiddleware',
    

    Затем параметры статических файлов настраиваются в соответствии с документацией Django.

    SESSION_ENGINE = "django.contrib.sessions.backends.cache"
    STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
    

Дополнительные сведения см. в разделе "Рабочие параметры" для приложений Django.

Как изменить параметр приложения SECRET_KEY на ссылку Key Vault?

На портале Azure описано, как можно изменить SECRET_KEY ссылку на Key Vault, выполнив следующие команды Azure CLI в облачной оболочке:

# Change the following variables to match your environment
SUBSCRIPTION_ID=<subscription-id>
RESOURCE_GROUP=<resource-group-name>
KEY_VAULT_NAME=<key-vault-name>
APP_SERVICE_NAME=<app-name>
SECRET_NAME=djangoSecretKey

# Set the subscription ID
az account set --subscription $SUBSCRIPTION_ID

# Assign 'Key Vault Secrets Officer' role to your user at the scope of the key vault
az role assignment create \
  --assignee $(az ad signed-in-user show --query id -o tsv) \
  --role $(az role definition list --name "Key Vault Secrets Officer" --query "[].id" -o tsv) \
  --scope $(az keyvault show --name $KEY_VAULT_NAME --resource-group $RESOURCE_GROUP --query id --output tsv)

# Add the secret to the key vault
az keyvault secret set \
  --vault-name $KEY_VAULT_NAME \
  --name $SECRET_NAME \
  --value $(python -c 'import secrets; print(secrets.token_hex())')

# Add Key Vault reference to the App Service configuration
az webapp config appsettings set \
  --resource-group $RESOURCE_GROUP \
  --name $APP_SERVICE_NAME \
  --settings "SECRET_KEY=@Microsoft.KeyVault(SecretUri=https://$KEY_VAULT_NAME.vault.azure.net/secrets/$SECRET_NAME)"

Вы также можете сделать то же самое на портале. Дополнительные сведения можно найти здесь

Как отлаживать ошибки во время развертывания GitHub Actions?

Если шаг завершается ошибкой в автоматически создаваемом файле рабочего процесса GitHub, попробуйте изменить неудавшуюся команду, чтобы выводить более подробную информацию. Например, вы можете получить больше данных от команды python, добавив опцию -d. Закоммитьте и отправьте свои изменения, чтобы инициировать очередное развертывание на App Service.

У меня нет полномочий на создание идентификатора, назначаемого пользователем

См. статью "Настройка развертывания GitHub Actions" из Центра развертывания.

Что я могу сделать с GitHub Copilot в своем рабочем пространстве?

Представление чата GitHub Copilot уже присутствовало, когда вы создавали кодовую среду. Для удобства мы добавим расширение чата GitHub Copilot в определение контейнера (см. статью .devcontainer/devcontainer.json). Однако вам нужна учетная запись GitHub Copilot (доступна бесплатная пробная версия 30 дней).

Несколько советов для вас, когда вы разговариваете с GitHub Copilot:

  • В одном сеансе чата вопросы и ответы дополняют друг друга, и вы можете корректировать свои вопросы, чтобы получить более точный ответ.
  • По умолчанию GitHub Copilot не имеет доступа к каким-либо файлам в вашем репозитории. Чтобы задать вопросы о файле, сначала откройте файл в редакторе.
  • Чтобы GitHub Copilot имел доступ ко всем файлам в репозитории при подготовке своих ответов, начните свой вопрос с @workspace. Дополнительные сведения см. в разделе Use the @workspace agent.
  • В чате GitHub Copilot может предложить изменения и даже указать, где их следует внести (с помощью @workspace), но ему не разрешается делать изменения за вас. Вам нужно добавить предлагаемые изменения и проверить их.

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

Кроме того, узнайте, как служба приложений запускает приложение Python: