Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O Azure Container Apps gere os detalhes do Kubernetes e da orquestração de contentores por si. Os contentores no Azure Container Apps podem utilizar qualquer runtime, linguagem de programação ou pilha de desenvolvimento à sua escolha.
As Aplicações de Contentor do Azure suportam:
- Qualquer imagem de contêiner x86-64 (
linux/amd64) baseada em Linux - Contentores de qualquer registo de contentores público ou privado
- Sidecar opcional e contentores de entrada
As características também incluem:
- Os aplicativos usam a
templateseção de configuração para definir a imagem do contêiner e outras configurações. As alterações na seção de configuração acionam uma novatemplatedo aplicativo de contêiner. - Se um contêiner falhar, ele será reiniciado automaticamente.
Os recursos de trabalho incluem:
- As execuções de trabalho usam a
templateseção de configuração para definir a imagem do contêiner e outras configurações quando cada execução é iniciada. - Se um contêiner sair com um código de saída diferente de zero, a execução do trabalho será marcada como falha. Você pode configurar um trabalho para repetir execuções falhadas.
Configuração
A maioria dos aplicativos de contêiner tem um único contêiner. Em cenários avançados, um aplicativo também pode ter sidecar e contêineres de inicialização. Em uma definição de aplicativo de contêiner, o aplicativo principal e seus contêineres de sidecar são listados na containers matriz na properties.template seção e os contêineres init são listados na initContainers matriz. O trecho a seguir mostra as opções de configuração disponíveis ao configurar os contêineres de um aplicativo.
{
"properties": {
"template": {
"containers": [
{
"name": "main",
"image": "[parameters('container_image')]",
"env": [
{
"name": "HTTP_PORT",
"value": "80"
},
{
"name": "SECRET_VAL",
"secretRef": "mysecret"
}
],
"resources": {
"cpu": 0.5,
"memory": "1Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
],
"probes": [
{
"type": "liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}
]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}
]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}
]
}
]
},
"initContainers": [
{
"name": "init",
"image": "[parameters('init_container_image')]",
"resources": {
"cpu": 0.25,
"memory": "0.5Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
]
}
]
...
}
...
}
| Definição | Descrição | Observações |
|---|---|---|
image |
O nome da imagem do contêiner para seu aplicativo de contêiner. | Este valor assume a forma de repository/<IMAGE_NAME>:<TAG>. Evite usar tags estáticas, como latest para imagens de contêiner. O uso de tags estáticas pode levar a problemas de cache e dificultar a solução de problemas do seu aplicativo. Em vez disso, use tags exclusivas para cada implantação, como um hash Git ou data e hora para garantir que as atualizações sejam rastreadas e implantadas corretamente. |
name |
Nome amigável do contentor. | Usado para relatórios e identificação. |
command |
O comando de inicialização do contêiner. | Equivalente ao campo de entrada do Docker. |
args |
Iniciar argumentos de comando. | As entradas na matriz são unidas para criar uma lista de parâmetros para passar para o comando de inicialização. |
env |
Uma matriz de pares nome/valor que definem variáveis de ambiente. | Use secretRef em vez do campo value ao fazer referência a um segredo. |
resources.cpu |
O número de CPUs alocadas ao contêiner. | Consulte vCPU e requisitos de alocação de memória |
resources.memory |
A quantidade de RAM alocada para o contêiner. | Consulte vCPU e requisitos de alocação de memória |
volumeMounts |
Uma matriz de definições de montagem de volume. | Você pode definir volumes de armazenamento temporários ou permanentes para seu contêiner. Para obter mais informações sobre volumes de armazenamento, consulte Usar montagens de volumes de armazenamento em Aplicações de Contêiner do Azure. |
probes |
Uma matriz de sondas de saúde habilitadas no contentor. | Para obter mais informações sobre configurações de sondas, consulte Sondas de integridade em aplicativos de contêiner do Azure. |
Requisitos de alocação de vCPU e memória
Quando se utiliza o plano de consumo, a CPU total e a memória alocadas para todos os contêineres numa aplicação de contêiner devem corresponder a uma das seguintes combinações.
| vCPUs (núcleos) | Memória |
|---|---|
0.25 |
0.5Gi |
0.5 |
1.0Gi |
0.75 |
1.5Gi |
1.0 |
2.0Gi |
1.25 |
2.5Gi |
1.5 |
3.0Gi |
1.75 |
3.5Gi |
2.0 |
4.0Gi |
2.25 |
4.5Gi |
2.5 |
5.0Gi |
2.75 |
5.5Gi |
3.0 |
6.0Gi |
3.25 |
6.5Gi |
3.5 |
7.0Gi |
3.75 |
7.5Gi |
4.0 |
8.0Gi |
Nota
As aplicações que utilizam o plano de Consumo num ambiente apenas de Consumo estão limitadas a um máximo de 2 núcleos e 4 Gi de memória.
Vários contentores
Em cenários avançados, você pode executar vários contêineres em um único aplicativo de contêiner. Use esse padrão somente em casos específicos em que seus contêineres estejam firmemente acoplados.
Para a maioria dos cenários de microsserviço, a prática recomendada é implantar cada serviço como um aplicativo de contêiner separado.
Vários contêineres no mesmo aplicativo de contêiner compartilham recursos de disco rígido e rede e experimentam o mesmo ciclo de vida do aplicativo.
Há duas maneiras de executar contentores adicionais numa aplicação de contentor: contentores de sidecar e contentores de inicialização.
Contentores para sidecar
Você pode definir vários contêineres em um único aplicativo de contêiner para implementar o padrão sidecar.
Exemplos de contentores para sidecar incluem:
Um agente que lê logs do container de aplicação principal em um volume partilhado e os encaminha para um serviço de registo.
Um processo em segundo plano que atualiza um cache usado pelo contêiner de aplicativo primário em um volume compartilhado.
Esses cenários são exemplos e não representam as únicas maneiras de implementar um sidecar.
Para executar vários contêineres em um aplicativo de contêiner, adicione mais de um contêiner na containers matriz do modelo de aplicativo de contêiner.
Contentores de inicialização
Você pode definir um ou mais contêineres de inicialização em um aplicativo de contêiner. Os contêineres de inicialização são executados antes do contêiner de aplicativo principal e são usados para executar tarefas de inicialização, como baixar dados ou preparar o ambiente.
Os contêineres de inicialização são definidos na initContainers matriz do modelo de aplicativo de contêiner. Os contêineres são executados na ordem em que são definidos na matriz e devem ser concluídos com êxito antes que o contêiner do aplicativo principal seja iniciado.
Nota
Os contêineres de inicialização em aplicativos que usam o plano dedicado ou que estão a ser executados em um ambiente de apenas consumo não podem aceder à identidade gerida em tempo de execução.
Registros de contêineres
Você pode implantar imagens hospedadas em registros privados fornecendo credenciais na configuração de Aplicativos de Contêiner.
Para usar um registro de contêiner, defina o registries registro na matriz na properties.configuration seção do modelo de recurso de aplicativo de contêiner. O passwordSecretRef campo identifica o nome do segredo no nome da secrets matriz onde você definiu a senha.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
As credenciais salvas são usadas para extrair uma imagem de contêiner do registro privado à medida que seu aplicativo é implantado.
O exemplo a seguir mostra como configurar as credenciais do Registro de Contêiner do Azure em um aplicativo de contêiner.
{
...
"configuration": {
"secrets": [
{
"name": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
Nota
O Docker Hub limita o número de downloads de imagens do Docker. Quando o limite é atingido, os contêineres em seu aplicativo não são iniciados. Use um registro com limites suficientes, como o Registro de Contêiner do Azure para evitar esse problema.
Identidade gerenciada com o Registro de Contêiner do Azure
Você pode usar uma identidade gerenciada do Azure para autenticar com o Registro de Contêiner do Azure em vez de usar um nome de usuário e senha. Para obter mais informações, consulte Identidades gerenciadas em aplicativos de contêiner do Azure.
Para usar a identidade gerida com um registo, a identidade deve ser habilitada na aplicação e deve ser-lhe atribuída a acrPull função no registo. Para configurar o registo, utilize o ID do recurso de identidade gerida para uma identidade atribuída pelo utilizador, ou system para a identidade atribuída pelo sistema na propriedade identity do registo. Não configure um nome de usuário e senha ao usar a identidade gerenciada.
{
"identity": {
"type": "SystemAssigned,UserAssigned",
"userAssignedIdentities": {
"<IDENTITY1_RESOURCE_ID>": {}
}
}
"properties": {
"configuration": {
"registries": [
{
"server": "myacr1.azurecr.io",
"identity": "<IDENTITY1_RESOURCE_ID>"
},
{
"server": "myacr2.azurecr.io",
"identity": "system"
}]
}
...
}
}
Para obter mais informações sobre como configurar identidades atribuídas pelo usuário, consulte Adicionar uma identidade atribuída pelo usuário.
Limitações
Os Aplicativos de Contêiner do Azure têm as seguintes limitações:
Contêineres privilegiados: os Aplicativos de Contêiner do Azure não permitem o modo de contêineres privilegiados com acesso no nível do host.
Sistema operacional: imagens de contêiner baseadas em Linux (
linux/amd64) são necessárias.Tamanho máximo da imagem:
- O perfil de tarefas de consumo suporta imagens de contentor que totalizam até 8 GB para cada aplicação ou réplica de trabalho.
- Perfis de carga de trabalho dedicados suportam imagens de contêiner maiores. Como um perfil de carga de trabalho dedicado pode executar vários aplicativos ou trabalhos, várias imagens de contêiner compartilham o espaço em disco disponível. O tamanho real da imagem suportada varia com base nos recursos consumidos por outros aplicativos e trabalhos.