Configurações de workload

Um workload é o objeto que recebe o tráfego de um conjunto de domínios. Ele carrega os domínios, a infraestrutura em que roda, as versões de HTTP e as portas, as configurações de TLS e o mTLS. Um subobjeto do workload, o deployment, nomeia a aplicação, o firewall e o conjunto de custom pages que atendem esse tráfego. Esta página lista cada campo dos dois objetos pelo nome na API, com o controle do Console ao lado. Para os limites numéricos em um só lugar, consulte Limites de Workloads. Para o caminho que uma requisição percorre por esses objetos, consulte Como Workloads funciona.

Interfaces

Quatro interfaces escrevem os mesmos dois objetos. As tabelas desta página nomeiam o controle do Console, o campo da API e a flag da CLI de cada campo.

azion create workload define name e active por flags; todos os outros campos do workload vão no arquivo JSON de --file. azion update workload --file lê o ID do workload de uma chave "id" dentro desse arquivo. A CLI não tem comando que atualize ou exclua um deployment. Altere a aplicação, o firewall ou o conjunto de custom pages de um deployment no Console ou com o PATCH da API.

Na API v3, as configurações de protocolo e de TLS desta página ficavam nas Main Settings de uma aplicação. Na API v4, elas pertencem ao workload. Para o mapeamento completo entre os dois modelos, consulte Migração para API v4.

Geral

Os campos gerais identificam o workload e registram quem o alterou. A API exige name e nada mais. Todos os outros campos desta tabela são somente leitura, exceto active.

O name identifica o workload na sua conta e não é um endereço de domínio, então você pode alterá-lo a qualquer momento. Um nome com 101 caracteres ou mais é recusado com Ensure this field has no more than 100 characters.

Infraestrutura

O campo infrastructure escolhe a rede que atende o workload e o sufixo do seu workload domain. No Console, a seção Infrastructure diz: “Select the infrastructure type for your Workload. Once this option is saved, it cannot be modified.”

Os dois valores diferem em onde o workload roda e nos domínios que ele aceita:

Um workload de staging é acessado apenas pelo seu workload domain, e as alterações feitas nele não afetam o workload de produção. O valor é fixado na criação: uma atualização que o altere é recusada com The infrastructure cannot be changed after Workload creation. Por exemplo, para levar uma configuração testada em staging para produção, você cria um segundo workload com infrastructure definido como 1 em vez de editar o primeiro.

Domínios

Os campos de domínio decidem a quais hostnames o workload responde. Todo workload recebe um workload domain somente leitura, e domains adiciona seus próprios hostnames e o hostname azion.app gratuito e opcional que o Console chama de Azion Custom Domain. A seção Domains do Console escreve os três campos.

O campo Domain aceita um domínio que você digita ou um que você seleciona no Edge DNS. O campo Azion Custom Domain aceita um nome como my-custom-name e acrescenta .azion.app, e o hostname completo é armazenado em domains ao lado dos seus. O hostname azion.app está disponível sem custo adicional.

workload_domain_allow_access definido como true permite que os clientes acessem o workload pelo seu workload domain, independentemente do que mais domains contenha. Defina-o como false quando o workload deve responder apenas nos seus próprios hostnames. Para apontar seu próprio domínio para o workload domain, consulte Aponte um domínio para um workload.

A API aplica estas regras a domains:

A API armazena cada hostname com a caixa que você envia: Docs-Rework-Upper.azion.app é lido de volta sem alteração.

Protocolos e portas

O objeto protocols.http define as versões de HTTP que o workload aceita e as portas em que ele escuta. No Console, a seção Protocol Settings o escreve, por meio de dois switches e três listas de portas.

O HTTP/3 roda sobre QUIC. O texto de ajuda do Console para HTTP/3 support diz “Enable HTTP/3 over QUIC. Requires HTTPS support to be enabled.”, e a API acrescenta uma segunda dependência em versions: uma lista com http3 também precisa conter http1 e http2. Caso contrário, a API a recusa com Missing required choices for multiple choices field: ['http1', 'http2'].

Uma porta HTTP fora dos quatro valores é recusada com Invalid choices for multiple choices field: [80, 8008, 8080, 8880]. Por exemplo, um workload que atende HTTP em 8080 junto com 80 envia "http_ports": [80, 8080]. Para as combinações de portas de entrega e de origem que uma aplicação pode usar, consulte Configure portas HTTP e HTTPS.

TLS

O Transport Layer Security (TLS) criptografa a conexão entre um cliente e o workload. O objeto tls nomeia o certificado que o workload apresenta, a versão mais baixa de TLS que ele aceita e o conjunto de cifras que ele oferece. No Console, esses controles ficam na seção Protocol Settings, e Digital Certificate aparece quando o switch HTTPS support está ativado.

O HTTPS precisa de um certificado X.509. Você pode fazer upload do seu próprio certificado no Certificate Manager ou solicitar um certificado Let’s Encrypt gerenciado pela Azion, ambos sem custo adicional. Com tls.certificate definido como null, o workload apresenta o certificado SAN da Azion, que cobre o Azion Custom Domain e o workload domain. Um certificado de outro tipo é recusado: um certificado de CA confiável em tls.certificate retorna Invalid certificate type, MUST be an Edge Certificate.

tls.minimum_version define um piso, não a versão exata que uma sessão usa. Um workload com tls_1_2 ainda pode atender uma sessão em TLS 1.3, dependendo da cifra que o cliente e o workload negociam a partir do conjunto. A Azion bloqueia a renegociação de TLS e a retomada de TLS por padrão. Para alterar isso, entre em contato com o time de Vendas.

O conjunto de cifras decide quais algoritmos criptográficos uma conexão TLS pode usar. O cliente e o workload negociam uma cifra do conjunto para cada sessão. A API recusa um valor fora de 1 a 8. Para 9, a mensagem é "9" is not a valid choice. Para alterar o conjunto passo a passo, consulte Defina o conjunto de cifras TLS.

Conjuntos de cifras

Cada valor de tls.ciphers seleciona um conjunto nomeado. As tabelas abaixo listam as cifras que cada conjunto contém, com a versão de TLS a que cada cifra pertence.

Conjunto 1, TLSv1.2_2018

ciphers: 1 seleciona TLSv1.2_2018, que contém três cifras de TLS 1.3 e 13 cifras de TLS 1.2:

Conjunto 2, TLSv1.2_2019

ciphers: 2 seleciona TLSv1.2_2019, que contém três cifras de TLS 1.3 e 10 cifras de TLS 1.2:

Conjunto 3, TLSv1.3_2022

ciphers: 3 seleciona TLSv1.3_2022, que contém seis cifras de TLS 1.2:

Conjunto 4, TLSv1.2_2021

ciphers: 4 seleciona TLSv1.2_2021, que contém três cifras de TLS 1.3 e seis cifras de TLS 1.2:

Conjunto 5, Legacy_v2025Q1

ciphers: 5 seleciona Legacy_v2025Q1, que contém três cifras de TLS 1.3 e 15 cifras de TLS 1.2:

Conjunto 6, Compatible_v2025Q1

ciphers: 6 seleciona Compatible_v2025Q1, que contém três cifras de TLS 1.3 e 12 cifras de TLS 1.2:

Conjunto 7, Modern_v2025Q1

ciphers: 7 seleciona Modern_v2025Q1, que contém três cifras de TLS 1.3 e seis cifras de TLS 1.2:

Conjunto 8, Legacy_v2017Q1

ciphers: 8 seleciona Legacy_v2017Q1, que contém três cifras de TLS 1.3 e 26 cifras de TLS 1.2:

mTLS

O TLS mútuo (mTLS) faz o cliente também apresentar um certificado, e o workload o verifica contra uma autoridade certificadora em que você confia. O objeto mtls ativa a verificação e nomeia o certificado de CA confiável e as listas de revogação de certificados (CRLs) que ela usa. Defina-o pela API ou pelo arquivo JSON de azion update workload --file.

Um certificado de servidor em mtls.config.certificate é recusado com Invalid certificate type, MUST be a Trusted CA. Por exemplo, um workload que verifica certificados de cliente contra sua CA e uma CRL, no modo enforce, envia "mtls": {"enabled": true, "config": {"certificate": <trusted-ca-id>, "crl": [<crl-id>], "verification": "enforce"}}. Para saber como enforce e permissive tratam um certificado de cliente, consulte mTLS.

Deployment

Um deployment vincula a aplicação, o firewall e o conjunto de custom pages que atendem o tráfego de um workload. Ele é um sub-recurso do workload, em /v4/workspace/workloads/{workload_id}/deployments, e um workload carrega um deployment. Um segundo é recusado com The maximum number of deployments allowed per workload is 1. No Console, a seção Deployment Settings do workload o escreve.

strategy.attributes contém exatamente essas três chaves. Um deployment criado sem conjunto de custom pages contém "custom_page": null. Um deployment sem firewall mostra Select a Firewall no campo Firewall do Console e 0 em azion list workload-deployment --details. Um conjunto de custom pages só tem efeito quando o deployment o nomeia em custom_page. Um workload que ainda usa um firewall impede que esse firewall seja excluído, e excluir o deployment não o libera: exclua o workload primeiro.

Corpo da requisição

O corpo JSON abaixo cria um workload de staging com TLS 1.2 como piso, o conjunto de cifras 4 e duas portas HTTP e duas HTTPS. O mesmo corpo funciona para POST /v4/workspace/workloads e para o arquivo de azion create workload --file:

Envie-o com a CLI, com o corpo salvo como wl-staging.json:

O comando imprime o ID do novo workload:

azion describe workload --workload-id <workload-id> --format json então retorna o workload como a API o armazena, com seu workload domain de staging:

Pela API, POST /v4/workspace/workloads responde com HTTP 202 e state definido como pending. Um workload de produção criado apenas com name, active, infrastructure e workload_domain_allow_access retorna todos os padrões:

O corpo de deployment abaixo vincula uma aplicação e um firewall por meio de POST /v4/workspace/workloads/{workload_id}/deployments:

A API responde com HTTP 202, state definido como pending e o deployment com custom_page definido como null:

A CLI cria o mesmo vínculo por flags, aqui com uma aplicação e um conjunto de custom pages:

O comando imprime o ID do novo deployment:

azion list workload-deployment --workload-id <workload-id> --details mostra o deployment, sua aplicação e seu firewall, com 0 quando não há firewall:

Erros

A API recusa cada requisição abaixo com a mensagem da primeira coluna. Para uma recusa de workload ou de deployment, a CLI imprime a mensagem dentro de Error: Failed to create the Workload: [...], Error: Failed to update the Workload: [...] ou Error: Failed to create the Workload Deployment: [...], seguida de Check your settings and try again. If the error persists, contact Azion support. A linha 24003 é a resposta da API a um DELETE de firewall.

Recursos relacionados