Поделиться через


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

В этом руководстве вы развернете веб-приложение Python на основе данных (Django) в Службе приложений Azure с помощью службы реляционной базы данных Azure для PostgreSQL . Служба приложений Azure поддерживает Python в среде сервера Linux. Если вы хотите, ознакомьтесь с учебником 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

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

Сначала вы создаете пример приложения, основанного на данных, как отправную точку. Для удобства пример репозитория включает конфигурацию контейнера разработки . Контейнер разработки имеет все необходимое для разработки приложения, включая базу данных, кэш и все переменные среды, необходимые образцу приложения. Контейнер разработки может выполняться в пространстве кода 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?

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

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

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

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

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

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

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

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

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

Шаг 3. Развертывание занимает несколько минут. После завершения развертывания нажмите кнопку "Перейти к ресурсу ". Вы сразу попадаете в приложение App Service, но при этом создаются следующие ресурсы:

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

3. Защита секретов подключения и добавление 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?

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


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

На этом шаге вы настроите развертывание GitHub с помощью GitHub Actions. Это всего лишь один из множества способов развертывания в Службе приложений, но это также отличный способ обеспечения непрерывной интеграции в процессе развертывания. По умолчанию каждый 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 минут.

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

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 части веб-сайта.

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

6. Перейдите к приложению

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

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

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

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

Служба 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.

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

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

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

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

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

Шаг 3.

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

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). Позже вы измените ваш код, чтобы он работал с App Service, и примените изменения с помощью 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.

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

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

Шаблон 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 показывает вам прямую ссылку на страницу настроек приложения. Найдите ссылку и откройте ее в новой вкладке браузера.

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

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

  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
    

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

5. Генерация схемы базы данных

При использовании базы данных 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 не сохраняются.

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

6. Перейдите к приложению

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

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

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

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

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

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

Служба приложений 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.

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

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

Чтобы удалить все ресурсы 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?

Следуя шагам, описанным выше на портале, вы можете преобразовать 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)"

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

  1. Назначение ролей области Key Vault
  2. Добавление секрета в Key Vault
  3. Получение секрета из Key Vault
  4. Настройка параметров приложения

Как отлаживать ошибки во время развертывания 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: