Solucionar problemas de Workloads

Esta página lista os sintomas que um workload mostra no tráfego real ou em uma requisição recusada, cada um com a sua causa e a sua correção. Os sintomas do próprio workload abrem a página: respostas ausentes ou desatualizadas e domínios, configurações, deployments e certificados recusados. Seções para Certificate Manager, que emite e armazena os certificados do workload, e Custom Pages, que substitui as suas respostas de erro, a encerram. Uma recusa citada é a mensagem da API, a menos que a entrada nomeie outra fonte, e Azion CLI imprime a mesma mensagem dentro de Error: Failed to ... [...].

Um workload responde 404 com a página de erro da Azion

As requisições ao workload domain retornam HTTP/2 404 e a página de erro HTML da Azion em vez da resposta da sua aplicação.

O workload não tem uma aplicação para a qual enviar a requisição: nenhum deployment vincula uma ainda, ou o deployment ainda não se propagou, como O deployment explica. Um workload com Workload Domain Allow Access desativado também responde 404 no seu workload domain, enquanto os seus próprios domínios continuam servindo.

• Crie o deployment: ele nomeia a aplicação, como Primeiros passos com Workloads mostra para cada interface.
• Repita a requisição depois de vários minutos: um deployment só alcança o tráfego quando se propaga.
• Verifique o switch de acesso: o workload domain serve apenas enquanto workload_domain_allow_access for true.
• Leia os headers: curl -sI https://<your-workload-domain>/get imprime a linha de status e o header x-azion-request-id, que identifica a requisição.

Quando o deployment se propaga, a mesma requisição retorna 200 da sua aplicação.

Uma requisição recebe a configuração antiga depois de uma mudança

Depois que você salva uma mudança em um workload ou no seu deployment, algumas requisições ainda recebem o comportamento anterior, ou as respostas alternam entre o antigo e o novo.

A mudança se espalha pela infraestrutura distribuída da Azion um data center por vez, ao longo de vários minutos, e a propagação é best-effort. Cada data center serve a configuração antiga ou a nova até que todos concordem, como Propagação detalha.

• Espere vários minutos antes de testar: uma requisição antecipada mede a propagação, não a configuração.
• Envie várias requisições, não uma: repita a requisição até que as respostas concordem.
• Confirme que a API armazenou a mudança: azion describe workload --workload-id <workload-id> --format json imprime o workload como a API o guarda.

Quando todo data center serve a nova configuração, cada requisição recebe a resposta que essa configuração define.

Um domínio personalizado não alcança o workload

As requisições a um hostname seu não alcançam o workload, enquanto o seu workload domain responde.

Um workload responde apenas aos hostnames listados nos seus domínios, e um cliente só o alcança depois que o DNS envia o hostname para a Azion. As duas partes são necessárias, como Workload domain e domínios personalizados explica.

• Liste o hostname no workload: adicione-o a domains, ou como uma linha de Subdomain e Domain da seção Domains, como Adicione um domínio a um workload mostra.
• Aponte o hostname para o workload domain: adicione um registro CNAME no seu provedor de DNS, ou hospede a zona no Edge DNS, como Aponte um domínio para um workload mostra.
• Dê tempo aos resolvers: os visitantes alcançam o workload quando os seus resolvers obtêm o novo registro.
• Use um workload de produção: um workload de staging não aceita domínio personalizado.

O hostname então responde com o mesmo conteúdo do workload domain.

Um domínio é recusado com This account is not allowed to use the following CNAMEs

Salvar os domínios do workload falha com This account is not allowed to use the following CNAMEs: example.com., em que a mensagem nomeia cada domínio recusado.

A conta não tem permissão para um domínio em domains, e a API recusa a requisição inteira, como os erros de Configurações de workload mostram.

• Remova o domínio que a mensagem nomeia e salve o restante da lista.
• Liste apenas domínios para os quais a sua conta tem permissão.

Azion CLI então imprime Updated Workload with ID <workload-id>, e o workload responde nos domínios que manteve.

Um hostname personalizado é recusado em um workload de staging

Adicionar um domínio a um workload falha com Custom hostname is not available in the environment 'Staging Infrastructure'.

Um workload de staging, com infrastructure definido como 2, não aceita hostname personalizado, incluindo um hostname azion.app. Ele responde apenas no seu workload domain <id>.preview.azionedge.net.

• Teste no workload domain: envie "domains": [] e alcance o workload de staging pelo seu workload domain.
• Use um workload de produção para o seu hostname: um workload com infrastructure definido como 1 o aceita.
• Visualize o seu hostname antes que o DNS dele mude: mapeie-o para um workload de produção no arquivo hosts do seu dispositivo, como Teste uma aplicação pelo arquivo hosts mostra.

O workload de produção então aceita o hostname, e o workload de staging continua servindo no seu workload domain.

Um domínio azion.app é recusado

Adicionar um hostname azion.app, que o Azion Console chama de Azion Custom Domain, falha com uma de três mensagens.

Um workload contém no máximo um hostname azion.app, um nome pertence a um workload por vez e toda entrada precisa estar em conformidade com a RFC 1035, como os erros de Configurações de workload mostram.

• Mantenha um hostname azion.app por workload: Duplicated usage of suffix in alternate_domains: 'azion.app'. recusa um segundo, mesmo com outro nome.
• Escolha um nome que nenhum outro workload tenha: The custom hostname is not available. significa que outro workload o tem, então escolha outro nome ou remova-o de lá primeiro.
• Liste o hostname completo, nunca um wildcard: The domain does not conform to the format defined in RFC 1035. recusa *.azion.app.

A atualização então armazena o hostname com as maiúsculas e minúsculas que você enviou, e a Azion o serve por HTTPS com o seu certificado SAN, como Crie um Azion custom domain mostra.

O workload domain não pode ser fechado

Desativar Workload Domain Allow Access falha com When the workload hostname access is blocked, the workload requires alternate domains or domains.

Um workload precisa de um hostname no qual responder, então workload_domain_allow_access só pode ser false enquanto domains contiver pelo menos uma entrada.

• Adicione primeiro o seu próprio hostname ou um hostname azion.app.
• Feche o workload domain depois que os seus hostnames responderem em todos os lugares, como Boas práticas de Workloads explica.

O workload domain então responde 404, enquanto os seus hostnames continuam servindo.

A infraestrutura não pode ser alterada

Uma atualização que move um workload entre staging e produção falha com The infrastructure cannot be changed after Workload creation.

O valor de infrastructure é fixado quando o workload é criado, e o texto de ajuda do Console para Infrastructure diz “Once this option is saved, it cannot be modified.”

• Crie um segundo workload na outra infraestrutura, com infrastructure definido como 1 para produção, e dê a ele o seu próprio deployment.
• Deixe infrastructure fora das atualizações do workload existente.

O novo workload recebe o sufixo de workload domain da sua infraestrutura, .map.azionedge.net em produção, como Infraestrutura explica.

Um segundo deployment é recusado

Criar um deployment falha com The maximum number of deployments allowed per workload is 1.

Um workload contém um deployment, que nomeia a sua aplicação, o seu firewall e o seu conjunto de custom pages, então uma mudança vai para esse deployment, como O deployment explica.

• Encontre o deployment existente: azion list workload-deployment --workload-id <workload-id> imprime o seu ID, e GET /v4/workspace/workloads/<workload-id>/deployments o retorna.
• Edite-o no Azion Console: altere Application, Firewall ou Custom Page em Deployment Settings e selecione Save.
• Ou envie um PATCH para /v4/workspace/workloads/<workload-id>/deployments/<deployment-id> com as chaves alteradas de strategy.attributes.

O PATCH retorna 202, e a mudança alcança todo hostname do workload quando se propaga.

Uma mudança de porta ou de versão HTTP é recusada

Uma atualização dos protocolos do workload falha com Invalid choices for multiple choices field: [80, 8008, 8080, 8880]. ou Missing required choices for multiple choices field: ['http1', 'http2'].

A primeira mensagem lista as quatro portas HTTP que um workload aceita. A segunda significa que versions contém http3 sem http1 e http2.

• Use apenas 80, 8008, 8080 ou 8880 em http_ports, e as portas HTTPS que Protocolos e portas lista.
• Envie ["http1", "http2", "http3"] ou remova http3.
• Ative o suporte a HTTPS antes do suporte a HTTP/3 no Azion Console: HTTP/3 support exige HTTPS support.

Azion CLI então imprime Updated Workload with ID <workload-id>. Para as outras recusas de configuração, como um conjunto de cifras fora do intervalo de 1 a 8, consulte os erros de Configurações de workload.

Um cliente falha no handshake TLS em um workload com mTLS

Um cliente não recebe resposta: o curl termina com o código 56 depois da solicitação de certificado do servidor, e o LibreSSL reporta reason(1116), certificate required.

O workload tem mTLS no modo enforce, e o cliente não apresentou certificado ou apresentou um que a Trusted CA não assinou. Um cliente que não envia Server Name Indication (SNI) também é encerrado antes que uma rota da sua aplicação seja resolvida.

• Apresente um certificado que a Trusted CA assinou: a Trusted CA é o certificado em mtls.config.certificate, e o curl envia um certificado de cliente com --cert e --key.
• Envie SNI de todo cliente: em um workload enforce, uma conexão sem ele nunca alcança a sua aplicação, como mTLS lista.
• Admita clientes enquanto testa: permissive completa o handshake e deixa a decisão para uma regra de firewall, como Modos de verificação descreve.
• Espere uma mudança de modo se propagar: até lá, alguns data centers respondem com o modo anterior.

O handshake então se completa, e a requisição alcança a aplicação. Para a saída detalhada do curl de um handshake recusado, consulte os erros de mTLS.

Um certificado é recusado em uma configuração do workload

Vincular um certificado a um workload falha com Invalid certificate type, MUST be an Edge Certificate. ou Invalid certificate type, MUST be a Trusted CA.

Cada campo de certificado aceita um tipo. tls.certificate aceita um certificado de servidor, do tipo edge_certificate, e mtls.config.certificate um certificado de CA confiável, do tipo trusted_ca_certificate, como os erros de mTLS mostram.

• Verifique o tipo: a coluna TYPE de azion list digital-certificate --details o mostra.
• Coloque o certificado de servidor em tls.certificate, ou null para o certificado SAN da Azion.
• Coloque o certificado de CA confiável em mtls.config.certificate.

Azion CLI então imprime Updated Workload with ID <workload-id>, e o certificado vinculado aparece como active em Certificate Manager.

Certificate Manager

Certificate Manager solicita certificados Let’s Encrypt para os domínios de um workload, armazena os certificados que você envia e reporta o estado de cada um no seu campo status. Para saber onde ele age sobre uma requisição, consulte Como Workloads funciona.

Um certificado fica pendente

Um certificado Let’s Encrypt mantém o status pending ou challenge_verification, e o campo Digital Certificate do workload avisa “This certificate is pending validation and HTTPS may not work until it’s validated”.

O desafio não consegue validar um dos nomes. O HTTP-01 precisa que todo nome aponte para a Azion, e o DNS-01 precisa de um registro _acme-challenge, como Validação de domínio explica.

• Verifique os nomes: um certificado solicitado pelo formulário do workload cobre os Domains do workload, então confirme que cada um está correto.
• Para o HTTP-01, aponte todo nome para a Azion, incluindo os nomes alternativos.
• Para o DNS-01 em outro provedor de DNS, adicione o CNAME: _acme-challenge.<your-domain> com o valor <your-domain>.letsencrypt.azion.com. No Edge DNS, a Azion grava o registro ela mesma.
• Depois de 48 horas pendente, verifique os registros CNAME de novo: as novas tentativas passam então a ocorrer a cada 3 horas, e uma vez por dia depois de 7 dias, como Tempo de emissão e novas tentativas lista.

Depois que uma tentativa posterior valida, o certificado aparece como active enquanto um workload o nomeia, ou inactive até lá. Para os registros passo a passo, consulte Solicite um certificado Let’s Encrypt.

Uma solicitação de certificado é recusada com This account cannot use certain common or alternative names

Uma solicitação Let’s Encrypt ou uma solicitação de assinatura de certificado (CSR) falha com This account cannot use certain common or alternative names because it does not have permission for their domain names.

Um nome da solicitação pertence a um domínio para o qual a conta não tem permissão. Um hostname azion.app também é recusado, mesmo um que um workload da conta tenha, como os erros de Certificados mostram.

• Nomeie apenas hostnames em domínios para os quais a sua conta tem permissão, em common_name e alternative_names.
• Não solicite certificado para um hostname azion.app: com tls.certificate definido como null, o workload apresenta o certificado SAN da Azion, que cobre o Azion Custom Domain e o workload domain.

Uma solicitação aceita retorna o id do certificado com o status pending.

A emissão de um certificado falha

Um certificado Let’s Encrypt aparece como failed, e o campo Digital Certificate do workload avisa “This digital certificate failed and HTTPS cannot be used until the issue is resolved”.

A validação falhou, e a Azion registra o motivo no campo status_detail do certificado. Um valor típico nomeia o hostname cujo registro deve ser verificado:

Leia status_detail em qualquer interface e corrija o registro ou o nome para o qual ele aponta:

• Azion Console: em Certificate Manager, o ícone de erro do certificado o mostra. Para entrar, consulte Como acessar o Azion Console.
• Azion CLI: azion describe digital-certificate --digital-certificate-id <certificate-id> --format json o imprime ao lado de status.
• API: GET /v4/workspace/tls/certificates/<certificate-id> o retorna com o certificado.

Uma tentativa posterior no cronograma de novas tentativas pode então emitir o certificado, e um certificado emitido em uso aparece como active, com status_detail em "".

Uma chave privada enviada é recusada

O envio de um certificado de servidor falha com The provided private key is invalid. Please check the key and try again.

A API não consegue ler a private_key enviada com o certificado, como os erros de Certificados mostram.

• Envie a chave que corresponde ao certificado.
• Envie-a em PEM, com as suas linhas -----BEGIN e -----END e sem passphrase, como Algoritmos e formatos de chave lista.
• Mantenha a chave como uma única string JSON em um corpo de API, com cada quebra de linha escrita como \n.

Azion CLI então imprime Created Digital Certificate with ID <certificate-id>, e o certificado aparece como inactive até que um workload o nomeie.

Custom Pages

Custom Pages substitui as respostas de erro de um workload por páginas que você escolhe, por meio de um conjunto de custom pages que o deployment do workload nomeia. Para saber onde ele age sobre uma requisição, consulte Como Workloads funciona.

Um conjunto de custom pages é recusado com Ensure this field has at least 1 elements

Criar um conjunto de custom pages falha com Ensure this field has at least 1 elements., ou o Azion Console se recusa a salvá-lo com You must have at least one custom page code.

Um conjunto contém pelo menos uma página, e a requisição enviou "pages": [], como os erros de Configurações de custom page mostram.

• Adicione uma página a pages: uma página vincula um código de status a um conteúdo em um connector, como {"code": "404", "page": {"type": "page_connector", "attributes": {"connector": <connector-id>, "ttl": 0, "uri": "/html", "custom_status_code": 404}}}.
• Adicione um código de página no Azion Console: a tabela Page Codes precisa de uma linha antes que você salve o conjunto.

Azion CLI então imprime Created Custom Page with ID <custom-page-id>.

Uma página de erro não aparece

A resposta de erro do connector chega ao cliente sem alteração, mesmo que um conjunto de custom pages contenha uma página para o seu código de status.

Um workload usa um conjunto apenas quando o seu deployment o nomeia em strategy.attributes.custom_page. Um deployment sem um conjunto mostra "custom_page": null em GET /v4/workspace/workloads/<workload-id>/deployments.

• Nomeie o conjunto no deployment: selecione-o no campo Custom Page de Deployment Settings, envie o seu ID em um PATCH de strategy.attributes.custom_page, ou passe --custom-page quando criar o deployment com Azion CLI.
• Verifique o código de status que o connector retorna: uma página age apenas sobre o código que lista, como "404".
• Espere a mudança se propagar, e o ttl de uma página editada expirar.

O cliente então recebe o conteúdo da página no próprio lugar, com o custom_status_code da página e sem header Location.

Recursos relacionados