Implantar um aplicativo Django com SQL Server para Serviço de Aplicativo do Azure

Este artigo explica como implantar um aplicativo Django que usa o back-end mssql-django no Serviço de Aplicativo do Azure, incluindo a configuração do driver ODBC, segredos baseados em variáveis de ambiente e autenticação com identidade gerenciada.

Pré-requisitos

Uma assinatura de Azure
Uma instância do Banco de Dados SQL do Azure ou do SQL Server acessível do Azure
Um projeto do Django configurado com mssql-django
CLI do Azure instalado

Driver ODBC no Serviço de Aplicativo do Azure

As instâncias do Serviço de Aplicativo do Azure no Linux incluem o Driver ODBC da Microsoft para SQL Server. Você pode verificar a versão do driver instalada executando:

az webapp ssh --resource-group <your-rg> --name <your-app>
odbcinst -j

Note

Serviço de Aplicativo do Azure normalmente inclui o Driver ODBC 17 e/ou 18 pré-instalado nos planos do Linux. Os planos do Serviço de Aplicativo do Windows também incluem o driver ODBC.

Usar variáveis de ambiente para segredos

Não codifique as credenciais do banco de dados em settings.py. Use variáveis de ambiente e defina-as como configurações de aplicativo do Serviço de Aplicativo:

import os

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": os.environ.get("DB_NAME", "<your-database>"),
        "USER": os.environ.get("DB_USER", ""),
        "PASSWORD": os.environ.get("DB_PASSWORD", ""),
        "HOST": os.environ.get("DB_HOST", "<your-server>.database.windows.net"),
        "PORT": os.environ.get("DB_PORT", "1433"),
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
        },
    },
}

Tip

Para valores necessários, como DB_NAME e DB_HOST, considere usar os.environ["DB_NAME"] (sem um padrão) para que o aplicativo falhe imediatamente com uma clara KeyError se a variável de ambiente estiver ausente.

Defina as variáveis de ambiente em Serviço de Aplicativo do Azure:

az webapp config appsettings set \
    --resource-group <your-rg> \
    --name <your-app> \
    --settings DB_NAME=<your-database> DB_HOST=<your-server>.database.windows.net DB_USER=<your-username> DB_PASSWORD=<your-password>

Use a autenticação de identidade gerenciada

Para implantações de produção, use a identidade gerenciada para evitar o armazenamento de credenciais. Habilite a identidade gerenciada atribuída pelo sistema em seu Serviço de Aplicativo:

az webapp identity assign --resource-group <your-rg> --name <your-app>

Conceda acesso à identidade gerenciada ao banco de dados SQL do Azure:

CREATE USER [<your-app-name>] FOR EXTERNAL PROVIDER;

ALTER ROLE db_datareader ADD MEMBER [<your-app-name>];
ALTER ROLE db_datawriter ADD MEMBER [<your-app-name>];
ALTER ROLE db_ddladmin ADD MEMBER [<your-app-name>];

Note

Conceda apenas as funções de que seu aplicativo precisa. A db_ddladmin função de banco de dados fixa será necessária somente se o aplicativo executar migrações. Para cargas de trabalho somente de leitura, db_datareader é suficiente.

Se o servidor estiver configurado para autenticação somente pelo Microsoft Entra, FROM EXTERNAL PROVIDER falhará com Msg 33130 porque o servidor não consegue acessar o Microsoft Graph para resolver o nome da identidade. Crie o usuário manualmente com CREATE USER [<your-app-name>] WITH SID = 0x<sid-hex>, TYPE = E, onde <sid-hex> é derivado da ID do aplicativo (cliente) da identidade gerenciada, não de sua ID de objeto. Para obter as etapas de conversão, consulte Conceder acesso à identidade em SQL do Azure.

Configurar settings.py para usar a identidade gerenciada:

import os

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": os.environ.get("DB_NAME", "<your-database>"),
        "HOST": os.environ.get("DB_HOST", "<your-server>.database.windows.net"),
        "PORT": "1433",
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
            "extra_params": "Authentication=ActiveDirectoryMsi",
        },
    },
}

Usar tokens de acesso com ManagedIdentityCredential

Como alternativa, use a configuração TOKEN com azure.identity:

Cuidado

O TOKEN valor é buscado uma vez na inicialização do processo e expira após 60 a 90 minutos. Para implantações de serviço de aplicativo de longa execução, use essa abordagem somente se você também implementar a lógica de atualização de token ou a reciclagem de trabalho de curta duração. Se o padrão direto ActiveDirectoryMsi funcionar no seu ambiente, isso evita o problema de token na inicialização.

import os
from azure.identity import ManagedIdentityCredential

credential = ManagedIdentityCredential()
token = credential.get_token("https://database.windows.net/.default").token

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": os.environ.get("DB_NAME", "<your-database>"),
        "HOST": os.environ.get("DB_HOST", "<your-server>.database.windows.net"),
        "PORT": "1433",
        "TOKEN": token,
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
        },
    },
}

Tip

DefaultAzureCredentialé conveniente para desenvolvimento e bases de código compartilhadas porque tenta vários tipos de credencial automaticamente, portanto, o mesmo código funciona em um laptop, em CI e em Azure. No entanto, cada tipo de credencial que não se aplica adiciona vários segundos de tempo limite, o que retarda a inicialização. Como o App Service sempre tem uma identidade gerenciada disponível, ManagedIdentityCredential autentica imediatamente sem a cadeia de sondagem. Instale azure-identity no arquivo de requisitos: pip install azure-identity.

Executar migrações durante a implantação

Adicione um script pós-implantação ou um comando de inicialização para executar migrações automaticamente:

az webapp config set \
    --resource-group <your-rg> \
    --name <your-app> \
    --startup-file "python manage.py migrate && gunicorn myproject.wsgi"

Coletar arquivos estáticos

Configurar o tratamento de arquivos estáticos para produção:

STATIC_URL = "/static/"
STATIC_ROOT = os.path.join(BASE_DIR, "staticfiles")

Execute collectstatic como parte de sua implantação:

python manage.py collectstatic --noinput

Implantar no Serviço de Aplicativo

O Serviço de Aplicativo pode hospedar um aplicativo Django de duas maneiras:

Imagem interna do Python no Linux: o App Service compila seu código a partir do código-fonte e fornece o runtime do Python.
Imagem personalizada do Docker: você mesmo cria a imagem e faz referência a ela a partir de um registro de contêiner.

Ambos os caminhos podem usar uma identidade gerenciada atribuída pelo sistema para autenticar em SQL do Azure, mas a receita é diferente. Escolha a guia que corresponde ao seu tipo de implantação.

Imagem Python integrada
Imagem personalizada do Docker

Com a imagem interna do Python no Linux, o builder Oryx do App Service instala requirements.txt e inicia automaticamente seu aplicativo Django com gunicorn. O proxy HTTP local de identidade gerenciada permite que Authentication=ActiveDirectoryMsi funcione diretamente a partir da cadeia de conexão ODBC. Use o settings.py conforme mostrado em Usar autenticação de identidade gerenciada.

Implante seu código com az webapp up, habilite a identidade gerenciada atribuída pelo sistema e defina as variáveis de ambiente de banco de dados:

az webapp up \
    --resource-group <your-rg> \
    --name <your-app> \
    --runtime "PYTHON:3.12" \
    --sku B1

az webapp identity assign --resource-group <your-rg> --name <your-app>

az webapp config appsettings set \
    --resource-group <your-rg> \
    --name <your-app> \
    --settings DB_NAME=<your-database> DB_HOST=<your-server>.database.windows.net

Em seguida, conceda o acesso à identidade gerenciada no SQL, conforme descrito em Usar autenticação de identidade gerenciada.

Use uma imagem personalizada quando precisar de uma versão específica do driver ODBC, pacotes adicionais do sistema ou controle total sobre o runtime.

O App Service expõe a identidade gerenciada aos aplicativos por meio das variáveis de ambiente IDENTITY_ENDPOINT e IDENTITY_HEADER, e não pelo ponto de extremidade padrão do Serviço de Metadados de Instância do Azure (IMDS) em 169.254.169.254, que o driver ODBC espera quando Authentication=ActiveDirectoryMsi está definido. Em um contêiner personalizado, o modo MSI do driver ODBC não pode acessar o IMDS, portanto, a conexão será interrompida até que o temporizador de logon expire. Obtenha o token de acesso em Python e passe-o para mssql-django por meio da configuração TOKEN. Use o padrão settings.py mostrado em Usar tokens de acesso com ManagedIdentityCredential.

Crie um Dockerfile na raiz do projeto. O Dockerfile instala o driver ODBC, mantém o ambiente de execução do Kerberos de que o driver precisa para autenticação do Microsoft Entra e inicia o aplicativo sob gunicorn:

FROM python:3.12-slim

# Install ODBC driver and runtime dependencies. libgssapi-krb5-2 is listed
# explicitly so apt-get --auto-remove keeps it after curl and gnupg2 are
# purged; msodbcsql18 needs it at runtime for Microsoft Entra authentication.
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    gnupg2 \
    unixodbc-dev \
    libgssapi-krb5-2 \
    && curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg \
    && curl -fsSL https://packages.microsoft.com/config/debian/12/prod.list > /etc/apt/sources.list.d/mssql-release.list \
    && apt-get update \
    && ACCEPT_EULA=Y apt-get install -y --no-install-recommends msodbcsql18 \
    && apt-get purge -y --auto-remove curl gnupg2 \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN python manage.py collectstatic --noinput

EXPOSE 8000
CMD ["gunicorn", "myproject.wsgi", "--bind", "0.0.0.0:8000", "--timeout", "180"]

Os contêineres personalizados não obtêm a instalação automática do Oryx, portanto, liste gunicorn e azure-identity em seu requirements.txt:

Django
mssql-django
gunicorn
azure-identity

Para RUN python manage.py collectstatic --noinput ter êxito durante docker build, settings.py deve ser importável antes que as variáveis de ambiente de runtime sejam definidas. Leia DB_NAME e DB_HOST com os.environ.get(..., "") , em vez de os.environ[...], e verifique se STATIC_ROOT está configurado conforme mostrado em Coletar arquivos estáticos.

Importante

Duas omissões comuns aparecem como erros enganosos:

Sem libgssapi-krb5-2, a primeira chamada de banco de dados falha com Can't open lib '/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.x.so.x.x' : file not found, mesmo que o .so arquivo esteja presente. O carregador de driver está relatando uma dependência transitiva ausente.
Sem gunicorn em requirements.txt, o contêiner falha ao iniciar com exec: "gunicorn": executable file not found in $PATH.

Consulte Solução de problemas para ver mais erros de contêiner.

Crie, faça push e implante a imagem:

# Create a container registry (one time)
az acr create --resource-group <your-rg> --name <your-acr> --sku Basic --admin-enabled true

# Build and push the image
az acr build --registry <your-acr> --image mydjango:latest .

# Create an App Service plan for containers
az appservice plan create --name <your-plan> --resource-group <your-rg> --is-linux --sku B1

# Create a web app using the container image
az webapp create \
    --resource-group <your-rg> \
    --plan <your-plan> \
    --name <your-app> \
    --container-image-name <your-acr>.azurecr.io/mydjango:latest

# Enable system-assigned managed identity
az webapp identity assign --resource-group <your-rg> --name <your-app>

# Configure database environment variables
az webapp config appsettings set \
    --resource-group <your-rg> \
    --name <your-app> \
    --settings DB_NAME=<your-database> DB_HOST=<your-server>.database.windows.net

Em seguida, conceda o acesso à identidade gerenciada no SQL, conforme descrito em Usar autenticação de identidade gerenciada.

Desenvolvimento local com o Docker Compose

Para desenvolvimento e teste locais, use o Docker Compose para executar seu aplicativo Django ao lado de um contêiner de SQL Server:

# docker-compose.yml
services:
  db:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: "<password>"  # Must meet SQL Server complexity requirements
    ports:
      - "1433:1433"

  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DB_HOST: db
      DB_NAME: mydb
      DB_USER: sa
      DB_PASSWORD: "<password>"
    depends_on:
      - db

Tip

O contêiner SQL Server não cria bancos de dados de aplicativo automaticamente. Depois de iniciar os contêineres, crie o banco de dados e execute as migrações:

docker compose exec db /opt/mssql-tools18/bin/sqlcmd -S localhost -U sa -P "<password>" -No -Q "CREATE DATABASE mydb"
docker compose exec web python manage.py migrate

A imagem de contêiner SQL Server requer ACCEPT_EULA=Y e uma senha SA forte. Para ambientes de produção, use o Banco de Dados SQL do Azure com identidade gerenciada em vez de credenciais do SQL Server. Consulte Usar autenticação de identidade gerenciada.

Comentários

Esta página foi útil?

Last updated on 2026-07-01