# Migração para API v4 import DocButton from '~/components/webkit/DocButton.vue'; import Code from '~/components/Code/Code.astro' ## Visão geral da migração Azion está lançando a API v4 nos próximos meses para aprimorar o desempenho, a flexibilidade e a gestão de recursos da plataforma. Esta atualização vai além de uma simples mudança de API: ela introduz um novo conceito central, **Workloads**, além de novos produtos como **Connectors** e **Custom Pages**, e traz melhorias significativas tanto para a API quanto para o Console da Azion. A API v4 apresenta uma nova arquitetura assíncrona e orientada a eventos, projetada para maior desempenho e resiliência. O novo modelo de recurso Workload centraliza a configuração, facilitando o gerenciamento, reutilização e escalabilidade das suas aplicações. O Connectors permite integrações de backend mais flexíveis e seguras. A API v4 da Azion já está disponível em `Preview` para novas contas do suporte Developer e será liberada em ondas para `Disponibilidade Geral (GA)` de acordo com o seu serviço de suporte. **Pontos-chave sobre a migração**: - A migração afeta tanto a plataforma (com a introdução de **Workloads**, **Connectors** e **Custom Pages**) quanto os endpoints da API. - Algumas configurações foram movidas para novos locais para melhorar a reutilização e a clareza. - Novas contas developer usarão a API v4 por padrão. Contas existentes serão migradas em ondas. - Durante a transição, você pode ver documentações com banners permitindo alternar entre as versões v3 e v4 de um recurso. - Após a migração da sua conta, não será mais possível utilizar os endpoints da API v3 ou criar novos `Domains`, `Origins` ou `Error Responses`. Você deverá utilizar os novos recursos equivalentes. A API v4 representa um avanço tecnológico, fornecendo a base para futuras funcionalidades e maior eficiência operacional em toda a Azion Web Platform. :::note As alterações descritas neste documento serão aplicadas à sua conta somente após a migração da sua conta. ::: --- ## Migração da API Todos os endpoints da API serão migrados para a v4 em ondas. Para visualizar os endpoints e parâmetros disponíveis, consulte a [referência da API v4](https://api.azion.com/v4). A API v3 está agora **obsoleta** e não receberá mais atualizações. Ela será descontinuada em uma data futura. Após essa data, todas as operações deverão ser realizadas exclusivamente utilizando a API v4. ### Ações necessárias Automatizações, scripts e pipelines de CI/CD conectados à Azion devem ser atualizados para utilizar a API v4 até o prazo especificado. ### Novas funcionalidades - Autenticação JWT. - Histórico de atividades via GraphQL para auditoria completa. - Nova arquitetura orientada a eventos. ### Benefícios da migração - Desempenho aprimorado - Maior flexibilidade - Acesso a updates futuros. - Parâmetros de consulta: Agora você pode usar parâmetros de consulta para personalizar solicitações de API. As opções suportadas incluem ordenar resultados por um campo específico e filtrar resultados por um termo de pesquisa ou por valor de campo. Isso permite que você recupere e organize dados de acordo com seus requisitos. --- ## Mudanças nas Applications A funcionalidade das Applications permanece inalterada. No entanto, algumas opções de configuração que antes eram gerenciadas dentro das **Applications** foram movidas para outros componentes como parte da migração. | Configuração | Novo local | |----------------------------|-------------------| | Applications > Main Settings > Delivery Settings | Workloads | | Applications > Origin Settings | Connectors | | Applications > Error Responses | Custom Pages | | Applications > Load Balancer | Connectors | --- ## Mudanças de cobrança e métricas Ao migrar para a API v4, há mudanças importantes na forma como o uso é medido e cobrado. Essas mudanças podem afetar seu faturamento dependendo dos seus padrões de uso. ### Workloads Com a introdução dos Workloads, as métricas de **Requests** e **Data Transfer** passam a ser medidas no nível do Workload em vez do nível da Application. | Métrica | API v3 (Applications) | API v4 (Workloads) | |--------|----------------------|-------------------| | Requests | Medidas por Application | Medidas por Workload | | Data Transfer | Medidas por Application | Medidas por Workload | :::tip Após a migração, você verá as métricas de Requests e Data Transfer no dashboard e nos relatórios de faturamento do seu Workload. Os valores medidos permanecem os mesmos de antes da migração. ::: ### Connectors e Load Balancer A métrica de Data Transfer do Load Balancer foi alterada significativamente: | Métrica | API v3 | API v4 | |--------|--------|--------| | Load Balancer Data Transfer | Todo o tráfego da Application | Apenas tráfego entre Connector e Origin | - **API v3**: Data Transfer era calculado com base em todo o tráfego que passava pela sua Application. - **API v4**: Data Transfer é calculado apenas sobre o tráfego entre seu Connector e seus servidores de origem (tráfego edge-to-origin). Essa mudança pode resultar em otimização de custos, pois apenas o tráfego de backend passa a ser medido para fins de Load Balancer. ### Firewall O modelo de mensuração de requests do Firewall foi atualizado: | Métrica | API v3 | API v4 | |---------|--------|--------| | Firewall Requests | Apenas firewalls com Network Shield habilitado | Todos os firewalls (todas as requests que passam) | - **API v3**: Requests do Firewall eram mensuradas apenas para firewalls com o módulo Network Shield habilitado. - **API v4**: O Firewall mede todas as requests que passam por ele, incluindo: - Requests processadas pelo WAF - Requests processadas pelo Network Shield - Todas as requests que transitam pelo Firewall :::note Essa abordagem consolidada significa que você pode ver um aumento na contagem de requests do Firewall após a migração, pois todas as requests que passam por qualquer Firewall agora são medidas, não apenas aquelas com Network Shield habilitado. ::: ### Origin Shield Com a introdução dos Connectors na API v4, uma nova métrica de cobrança está disponível: | Métrica | API v3 | API v4 | |---------|--------|--------| | Shielded Connectors | Não disponível | Número de Connectors com Origin Shield habilitado | - **API v3**: Origin Shield estava disponível como um Add-On separado com uma Subscription. Nenhum Shielded Connector era medido. - **API v4**: Connectors com o módulo Origin Shield habilitado são contabilizados como Shielded Connectors e aparecem nos seus relatórios de faturamento. :::tip Esta é uma nova métrica. Se você habilitar Origin Shield nos seus Connectors, verá Shielded Connectors nos seus relatórios de faturamento após a migração. ::: --- ## Comparação de Endpoints da API Esta seção fornece uma comparação analítica detalhada entre os endpoints da API v3 e da API v4, incluindo URLs base, estruturas de requisição/resposta e diferenças comportamentais. ### Visão Geral da Arquitetura | Aspecto | API v3 | API v4 | |---------|--------|--------| | URL Base | `https://api.azionapi.net/` | `https://api.azion.com/v4/` | | Arquitetura | Síncrona | Assíncrona (orientada a eventos) | | Autenticação | Token no header | Token ou JWT no header | | Formato de Resposta | Resultados diretos no objeto `results` | Baseado em estado com objetos `state` e `data` | | Modelo de Recursos | Recursos aninhados sob Applications | Recursos independentes vinculados via Deployments | | Header de Versão da API | `Accept: application/json; version=3` | Não é necessário | ### Mapeamento de Recursos | Recurso API v3 | Endpoint API v3 | Recurso API v4 | Endpoint API v4 | |----------------|-----------------|----------------|-----------------| | Domains | `/domains` | Workloads | `/workspace/workloads` | | Origins | `/edge_applications/{id}/origins` | Connectors | `/edge_connector/connectors` | | Error Responses | `/edge_applications/{id}/error_responses` | Custom Pages | `/workspace/custom_pages` | | Applications | `/edge_applications` | Applications | `/edge_application/applications` | | Rules Engine | `/edge_applications/{id}/rules_engine` | Rules Engine | `/edge_application/applications/{id}/rules_engine` | | Cache Settings | `/edge_applications/{id}/cache_settings` | Cache Settings | `/edge_application/applications/{id}/cache_settings` | | Device Groups | `/edge_applications/{id}/device_groups` | Device Groups | `/edge_application/applications/{id}/device_groups` | | Functions | `/edge_functions/functions` | Functions | `/edge_functions/functions` | | Digital Certificates | `/digital_certificates` | Digital Certificates | `/digital_certificates/certificates` | | Edge Firewall | `/edge_firewall` | Edge Firewall | `/edge_firewall/firewalls` | | Network Lists | `/network_lists` | Network Lists | `/workspace/network_lists` | --- ### Domains (v3) → Workloads + Deployments (v4) Na API v3, **Domains** eram um recurso único que conectava uma Application ao tráfego de usuários. Na API v4, esse conceito é dividido em **Workloads** (configuração de infraestrutura e protocolos) e **Deployments** (vinculação com Applications e outros componentes). #### Comparação de Endpoints | Operação | API v3 | API v4 | |----------|--------|--------| | Listar todos | `GET /domains` | `GET /workspace/workloads` | | Obter um | `GET /domains/{domain_id}` | `GET /workspace/workloads/{workload_id}` | | Criar | `POST /domains` | `POST /workspace/workloads` | | Atualizar | `PATCH /domains/{domain_id}` | `PATCH /workspace/workloads/{workload_id}` | | Deletar | `DELETE /domains/{domain_id}` | `DELETE /workspace/workloads/{workload_id}` | | Vincular à Application | Incorporado na criação do Domain | `POST /workspace/workloads/{workload_id}/deployments` | #### Payload de Requisição: Criar Domain/Workload **API v3 (Domains):** ```json { "name": "string", "cname_access_only": false, "cnames": ["custom.example.com"], "digital_certificate_id": null, "edge_application_id": 1234, "edge_firewall_id": null, "is_active": true, "environment": "production" } ``` **API v4 (Workloads):** ```json { "name": "string", "active": true, "infrastructure": 1, "protocols": { "http": { "versions": ["http1", "http2"] } }, "tls": { "certificate": null, "ciphers": 7, "minimum_version": "tls_1_3" }, "domains": ["custom.example.com"], "workload_domain_allow_access": true } ``` #### Payload de Requisição: Vincular à Application (Deployment) **API v3:** A vinculação ocorre automaticamente durante a criação do Domain através do campo `edge_application_id`. **API v4 (Deployments):** Uma requisição separada é necessária: ```json { "name": "string", "active": true, "current": true, "strategy": { "type": "default", "attributes": { "edge_application": 1234, "edge_firewall": null, "custom_page": null } } } ``` #### Estrutura de Resposta **Resposta API v3 (Síncrona):** ```json { "results": { "id": 5678, "name": "string", "cnames": ["custom.example.com"], "cname_access_only": false, "digital_certificate_id": null, "edge_application_id": 1234, "is_active": true, "domain_name": "xxxxxxxxxx.map.azionedge.net", "environment": "production" } } ``` **Resposta API v4 (Assíncrona):** ```json { "state": "pending", "data": { "id": 5678, "name": "string", "active": true, "infrastructure": 1, "last_editor": "user@example.com", "last_modified": "2025-01-15T10:30:00Z", "domains": ["custom.example.com"], "workload_domain": "xxxxxxxxxx.map.azionedge.net", "workload_domain_allow_access": true, "tls": { "certificate": null, "ciphers": 7, "minimum_version": "tls_1_3" }, "protocols": { "http": { "versions": ["http1", "http2"] } } } } ``` #### Principais Diferenças Comportamentais | Aspecto | API v3 | API v4 | |---------|--------|--------| | Fluxo de criação | Única requisição cria Domain e vincula à Application | Dois passos: criar Workload, depois criar Deployment | | Identificador | `id` numérico | `id` numérico (Workload) + ID de Deployment separado | | CNAME Access | `cname_access_only` booleano | `workload_domain_allow_access` booleano | | Ambiente | `environment: "production"` ou `"staging"` | `infrastructure: 1` (Produção) ou `2` (Staging) | | Resposta | Imediata, síncrona | Assíncrona com `state: "pending"` | | mTLS | Campos no Domain | Objeto `mtls` separado com verification, certificate, crl | --- ### Origins (v3) → Connectors (v4) Na API v3, **Origins** eram recursos aninhados sob Applications. Na API v4, **Connectors** são recursos independentes de nível superior que podem ser reutilizados em múltiplas Applications. #### Comparação de Endpoints | Operação | API v3 | API v4 | |----------|--------|--------| | Listar todos | `GET /edge_applications/{app_id}/origins` | `GET /edge_connector/connectors` | | Obter um | `GET /edge_applications/{app_id}/origins/{origin_key}` | `GET /edge_connector/connectors/{connector_id}` | | Criar | `POST /edge_applications/{app_id}/origins` | `POST /edge_connector/connectors` | | Atualizar | `PATCH /edge_applications/{app_id}/origins/{origin_key}` | `PATCH /edge_connector/connectors/{connector_id}` | | Deletar | `DELETE /edge_applications/{app_id}/origins/{origin_key}` | `DELETE /edge_connector/connectors/{connector_id}` | #### Payload de Requisição: Criar Origin/Connector **API v3 (Origins - Single Origin):** ```json { "name": "My Origin", "origin_type": "single_origin", "addresses": [ { "address": "origin.example.com" } ], "origin_protocol_policy": "https", "host_header": "www.example.com", "origin_path": "/api", "connection_timeout": 60, "timeout_between_bytes": 120, "hmac_authentication": false, "hmac_region_name": "", "hmac_access_key": "", "hmac_secret_key": "" } ``` **API v3 (Origins - Load Balancer):** ```json { "name": "My Load Balanced Origin", "origin_type": "load_balancer", "addresses": [ { "address": "origin1.example.com", "weight": 1, "server_role": "primary" }, { "address": "origin2.example.com", "weight": 1, "server_role": "primary" } ], "origin_protocol_policy": "https", "host_header": "www.example.com" } ``` **API v4 (Connectors - Tipo HTTP):** ```json { "name": "My Connector", "active": true, "type": "http", "attributes": { "addresses": [ { "active": true, "address": "origin.example.com", "http_port": 80, "https_port": 443 } ], "connection_options": { "dns_resolution": "preserve", "transport_policy": "force_https", "http_version_policy": "http1_1", "host": "www.example.com", "path_prefix": "/api", "following_redirect": false, "real_ip_header": "X-Real-IP", "real_port_header": "X-Real-PORT" }, "modules": { "load_balancer": { "enabled": false, "config": { "method": "round_robin", "max_retries": 0, "connection_timeout": 60, "read_write_timeout": 120 } }, "origin_shield": { "enabled": false, "config": null } } } } ``` **API v4 (Connectors - Tipo Object Storage):** ```json { "name": "My Storage Connector", "active": true, "type": "edge_storage", "attributes": { "bucket": "my-bucket", "prefix": "/" } } ``` #### Estrutura de Resposta **Resposta API v3:** ```json { "results": { "origin_id": 123, "origin_key": "abc123def456", "name": "My Origin", "origin_type": "single_origin", "addresses": [ { "address": "origin.example.com", "weight": null, "server_role": "primary", "is_active": true } ], "origin_protocol_policy": "https", "host_header": "www.example.com", "origin_path": "/api", "connection_timeout": 60, "timeout_between_bytes": 120 } } ``` **Resposta API v4:** ```json { "state": "pending", "data": { "id": 789, "name": "My Connector", "active": true, "type": "http", "last_editor": "user@example.com", "last_modified": "2025-01-15T10:30:00Z", "attributes": { "addresses": [ { "active": true, "address": "origin.example.com", "http_port": 80, "https_port": 443 } ], "connection_options": { "dns_resolution": "preserve", "transport_policy": "force_https", "host": "www.example.com", "path_prefix": "/api" }, "modules": { "load_balancer": { "enabled": false }, "origin_shield": { "enabled": false } } } } } ``` #### Principais Diferenças Comportamentais | Aspecto | API v3 | API v4 | |---------|--------|--------| | Escopo do recurso | Aninhado sob Application | Recurso independente de nível superior | | Reutilização | Uma Origin por Application | Um Connector pode servir múltiplas Applications | | Distinção de tipo | `origin_type: "single_origin"` ou `"load_balancer"` | `type: "http"` com módulo `load_balancer` habilitado para múltiplos endereços | | Política de protocolo | `origin_protocol_policy` | `connection_options.transport_policy` | | Host header | `host_header` | `connection_options.host` | | Path | `origin_path` | `connection_options.path_prefix` | | Timeouts | `connection_timeout`, `timeout_between_bytes` | `modules.load_balancer.config.connection_timeout`, `read_write_timeout` | | HMAC Auth | Campos diretos na Origin | Requer módulo `origin_shield` | | Portas | Não configuráveis | `http_port`, `https_port` por endereço | | Identificador | `origin_key` usado para updates | `id` usado para todas as operações | #### Ativando um Connector/Origin em uma Application **API v3 - Rules Engine:** ```json { "name": "Set Origin Rule", "behaviors": [ { "name": "set_origin", "target": "" } ], "criteria": [ [{ "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/api" }] ] } ``` **API v4 - Rules Engine:** ```json { "name": "Set Connector Rule", "active": true, "criteria": [ { "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/api" } ], "behaviors": [ { "type": "set_edge_connector", "attributes": { "value": "" } } ] } ``` --- ### Error Responses (v3) → Custom Pages (v4) Na API v3, **Error Responses** eram aninhados sob Applications. Na API v4, **Custom Pages** são recursos independentes vinculados a Workloads via Deployments. #### Comparação de Endpoints | Operação | API v3 | API v4 | |----------|--------|--------| | Listar todos | `GET /edge_applications/{app_id}/error_responses` | `GET /workspace/custom_pages` | | Obter um | `GET /edge_applications/{app_id}/error_responses/{error_id}` | `GET /workspace/custom_pages/{page_id}` | | Criar | `POST /edge_applications/{app_id}/error_responses` | `POST /workspace/custom_pages` | | Atualizar | `PATCH /edge_applications/{app_id}/error_responses/{error_id}` | `PATCH /workspace/custom_pages/{page_id}` | | Deletar | `DELETE /edge_applications/{app_id}/error_responses/{error_id}` | `DELETE /workspace/custom_pages/{page_id}` | | Vincular à Application | Aninhado sob Application | Via Workload Deployment | #### Payload de Requisição **API v3 (Error Responses):** ```json { "name": "My Error Pages", "errors": [ { "code": 404, "uri": "/errors/404.html", "ttl": 300, "custom_status_code": 404, "origin_id": 123 }, { "code": 500, "uri": "/errors/500.html", "ttl": 60, "custom_status_code": 500, "origin_id": 123 } ] } ``` **API v4 (Custom Pages):** ```json { "name": "My Error Pages", "active": true, "pages": [ { "code": "404", "page": { "type": "page_connector", "attributes": { "connector": 456, "ttl": 300, "uri": "/errors/404.html", "custom_status_code": 404 } } }, { "code": "500", "page": { "type": "page_connector", "attributes": { "connector": 789, "ttl": 60, "uri": "/errors/500.html", "custom_status_code": 500 } } } ] } ``` #### Estrutura de Resposta **Resposta API v3:** ```json { "results": { "id": 100, "name": "My Error Pages", "errors": [ { "code": 404, "uri": "/errors/404.html", "ttl": 300, "origin_id": 123 } ] } } ``` **Resposta API v4:** ```json { "state": "pending", "data": { "id": 200, "name": "My Error Pages", "active": true, "last_editor": "user@example.com", "last_modified": "2025-01-15T10:30:00Z", "pages": [ { "code": "404", "page": { "type": "page_connector", "attributes": { "connector": 456, "ttl": 300, "uri": "/errors/404.html" } } } ] } } ``` #### Principais Diferenças Comportamentais | Aspecto | API v3 | API v4 | |---------|--------|--------| | Escopo do recurso | Aninhado sob Application | Recurso independente de nível superior | | Origin por código de erro | Único `origin_id` para todos os erros | ID de `connector` diferente por código de página | | Vinculação | Automática (aninhado) | Via Workload Deployment com atributo `custom_page` | | Campo code | `code` (inteiro) | `code` (string) | | Definição de página | Estrutura plana no array `errors` | Objeto `page` aninhado com `type` e `attributes` | --- ### Comparação do Rules Engine A estrutura do Rules Engine teve mudanças significativas no formato do payload e na nomenclatura de behaviors. #### Comparação de Endpoints | Operação | API v3 | API v4 | |----------|--------|--------| | Listar regras de request | `GET /edge_applications/{id}/rules_engine/request/rules` | `GET /edge_application/applications/{id}/request_rules` | | Listar regras de response | `GET /edge_applications/{id}/rules_engine/response/rules` | `GET /edge_application/applications/{id}/response_rules` | | Obter uma | `GET .../rules_engine/{phase}/rules/{rule_id}` | `GET .../{phase}_rules/{rule_id}` | | Criar | `POST .../rules_engine/{phase}/rules` | `POST .../{phase}_rules` | | Atualizar | `PATCH .../rules_engine/{phase}/rules/{rule_id}` | `PATCH .../{phase}_rules/{rule_id}` | | Deletar | `DELETE .../rules_engine/{phase}/rules/{rule_id}` | `DELETE .../{phase}_rules/{rule_id}` | #### Comparação de Payload de Requisição **Rules Engine API v3:** ```json { "name": "My Rule", "phase": "request", "behaviors": [ { "name": "set_origin", "target": "123" }, { "name": "redirect_to_https", "target": true } ], "criteria": [ [ { "variable": "${uri}", "operator": "is_equal", "conditional": "if", "input_value": "/path" } ] ], "order": 1, "description": "Rule description" } ``` **Rules Engine API v4:** ```json { "name": "My Rule", "active": true, "behaviors": [ { "type": "set_edge_connector", "attributes": { "value": "456" } }, { "type": "redirect_https", "attributes": { "enabled": true } } ], "criteria": [ { "conditional": "if", "variable": "${uri}", "operator": "is_equal", "argument": "/path" } ], "description": "Rule description" } ``` #### Principais Diferenças Comportamentais | Aspecto | API v3 | API v4 | |---------|--------|--------| | Path do endpoint | `/rules_engine/{phase}/rules` | `/{phase}_rules` | | Formato de behavior | `{ "name": "...", "target": "..." }` | `{ "type": "...", "attributes": { ... } }` | | Formato de criteria | Arrays aninhados `[[{...}]]` | Array plano `[{...}]` | | Argumento do criteria | `input_value` | `argument` | | Behavior Set Origin | `set_origin` | `set_edge_connector` | | Campo order | Campo `order` explícito | Ordenação implícita por criação | --- ### Comparação de Fluxo de Criação Esta seção ilustra o fluxo passo a passo para configurar uma aplicação completa. #### Fluxo de Criação API v3 (4 requisições) 1. **Criar Application:** ```bash POST /edge_applications { "name": "My App", "delivery_protocol": "http,https" } ``` 2. **Criar Domain:** ```bash POST /domains { "name": "My Domain", "edge_application_id": } ``` 3. **Criar Origin:** ```bash POST /edge_applications//origins { "name": "My Origin", "origin_type": "single_origin", "addresses": [...] } ``` 4. **Criar Regra para ativar Origin:** ```bash POST /edge_applications//rules_engine/request/rules { "behaviors": [{ "name": "set_origin", "target": }] } ``` #### Fluxo de Criação API v4 (5 requisições) 1. **Criar Application:** ```bash POST /edge_application/applications { "name": "My App" } ``` 2. **Criar Workload:** ```bash POST /workspace/workloads { "name": "My Workload", "infrastructure": 1 } ``` 3. **Criar Workload Deployment:** ```bash POST /workspace/workloads//deployments { "strategy": { "type": "default", "attributes": { "edge_application": } } } ``` 4. **Criar Connector:** ```bash POST /edge_connector/connectors { "name": "My Connector", "type": "http", "attributes": {...} } ``` 5. **Criar Regra para ativar Connector:** ```bash POST /edge_application/applications//request_rules { "behaviors": [{ "type": "set_edge_connector", "attributes": { "value": } }] } ``` --- ### Implicações de Billing por Endpoint | Mudança de Endpoint | Impacto no Billing | |---------------------|-------------------| | Domains → Workloads | Requests e Data Transfer medidos por Workload em vez de por Application | | Origins → Connectors | Load Balancer Data Transfer agora mede apenas tráfego edge-to-origin, não todo o tráfego da Application | | Error Responses → Custom Pages | Sem impacto direto no billing; depende do uso do Connector | | Rules Engine | Sem impacto direto no billing | --- ## Workloads A Azion adotou o conceito de Workload para centralizar a lógica da aplicação, separando regras de negócio da infraestrutura. Isso permite reutilização e aplicação consistente de políticas entre ambientes, seguindo um modelo inspirado no Kubernetes. **Workloads** substituem os **Azion Domains**. Todas as configurações anteriormente gerenciadas em **Azion Domains** agora estão organizadas sob **Workloads**. ### Mudanças operacionais e impacto para o usuário As seguintes configurações foram movidas de **Azion Domains** para **Workloads**. | Configuração | Local anterior | Novo local na v4 | |---------------------------------|-----------------------|-----------------------------------------| | Environment Type | Domains | Workload > Infrastructure | | Domain Settings | Domains | Workload > Domains | | Applications | Domains > Settings | Workload > Deployment Settings | | Firewall | Domains > Settings | Workload > Deployment Settings | | CNAME (text input box) | Domains > Settings | Workload > Domains | | Digital Certificate | Domains > Settings | Workload > Protocol Settings | | CNAME Access Only | Domains > Settings | Workload > Domains | | mTLS (Mutual TLS) Settings | Domains | Workload > Mutual Authentication Settings| **Delivery Settings** que antes eram configuradas dentro de uma Applications agora podem ser encontradas em **Workloads** em **Protocol Settings**: - Protocol Settings - Delivery Ports - Minimum TLS version - TLS Ciphers #### Mudanças comportamentais notáveis - **CNAME Access Only** - *Comportamento anterior*: Quando ativado, a aplicação só podia ser acessada via CNAME (por exemplo, `app.example.com`). - *Novo comportamento*: Substituído por “Workload Domain Allow Access”, permitindo acesso pela URL gerada automaticamente do workload (por exemplo, `xxxxxxxx.map.azionedge.net`). #### Uso da API Cada Workload está implicitamente associado a um Deployment. O Deployment define a relação entre o Workload e a Applications (obrigatório), além de componentes opcionais como Firewall e Custom Pages. Ao criar um **Workload** via API, você também deve criar um Workload Deployment para vincular o Workload a uma Applications. Essa associação garante que o **Workload** esteja corretamente vinculado à Applications desejada. Ao utilizar o Console, essa associação é criada automaticamente ao selecionar `Deployment Settings`. ##### Exemplos de requisições **Criando um Workload**: **Criando um Workload Deployment**: /deployments \ --header 'Accept: application/json' \ --header 'Authorization: Token [TOKEN VALUE]' \ --header 'Content-Type: application/json' \ -- '{ "name": "Workload Deployment Example", "current": true, "active": true, "strategy": { "type": "default", "attributes": { "edge_application": } } }' `} /> :::tip Para mais informações sobre os parâmetros da API, visite a [referência da API de Workloads](https://api.azion.com/v4#/operations/GetWorkspaceWorkloads). ::: ### O que acontece com meus Domains existentes? Os Domains serão automaticamente convertidos em Workloads em fases, garantindo compatibilidade com as configurações originais. A migração ocorrerá em ondas. Após a migração da sua conta, não será mais possível criar novos Domains. ### Ação necessária Se você possui automações que atualmente utilizam os endpoints da API de **Domains**, é necessário atualizá-las para utilizar os endpoints de **Workloads** da v4. ### Novas funcionalidades - **Custom Pages**: Substitui e expande o antigo recurso de Error Responses. [Mais detalhes são fornecidos abaixo](#custom-pages). - **Azion Custom Domain**: Permite configurar um domínio personalizado da Azion para sua aplicação no formato `example.azion.app`. ### Benefícios da migração - **Organização aprimorada**: Agrupe logicamente todos os recursos relacionados a uma aplicação ou serviço em uma única unidade (Workload), tornando o gerenciamento, visualização e navegação mais eficientes. Essa estrutura cria relações claras entre os componentes. - **Escalabilidade e flexibilidade**: Simplifica o deploy, atualizações e escalabilidade de aplicações complexas ao permitir que todos os componentes necessários sejam gerenciados como parte de um Workload. - **Gestão simplificada**: Centraliza a configuração e o controle de diferentes elementos da aplicação, reduzindo a complexidade operacional. - **Base para novas capacidades**: Essencial para recursos futuros, como versionamento de configuração e conexões de serviço mais intuitivas, por exemplo, vincular um domínio diretamente ao Object Storage sem depender de uma Applications. --- ## Connectors O **Connectors** centraliza as configurações de conexão com backends, permitindo reutilizá-las em múltiplas aplicações e fornecendo controle granular sobre desempenho, segurança e roteamento por meio de uma interface unificada para conectar **Applications** a uma origem (seu backend), incorporando nativamente recursos como balanceamento de carga, autenticação HMAC e Origin Shield. O **Connectors** substitui as configurações de **Origin** das Applications. Todas as configurações anteriormente gerenciadas na aba **Origins** das Applications agora estão organizadas sob o **Connectors**. ### Mudanças operacionais e impacto para o usuário Todas as configurações anteriormente gerenciadas na aba **Origins** das Applications agora estão organizadas sob o **Connectors**. | Configuração | Local anterior | Novo local na v4 | |-----------------------------|-----------------------------------------------------|----------------------------------------------------| | Type | Applications > Origins > Host Settings | Connector Type | | Protocol Policy | Applications > Origins > Host Settings | Connector Options > Transport Protocol Policy | | Host Header | Applications > Origins > Host Settings | Connector Options > Host | | Address | Applications > Origins > Host Settings | Connector Options > Address Management > Address | | Path | Applications > Origins > Host Settings | Connector Options > Path | | HMAC Authentication | Applications > Origins > Host Settings | HMAC | | Connection Timeout | Applications > Origins > Host Settings > Timeouts| Load Balancer Configuration > Connection Timeout | | Between Bytes Timeout | Applications > Origins > Host Settings > Timeouts| Load Balancer Configuration > Read/Write Timeout | #### Mudanças comportamentais notáveis - **Connector Type** - *Comportamento anterior*: As opções incluíam `Single Origin` e `Load Balancer`. Isso definia se era possível configurar uma ou múltiplas origens. - *Novo comportamento*: Os tipos `Single Origin` e `Load Balancer` foram unificados no tipo `HTTP`. Ao usar múltiplas origens, é necessário habilitar o **Load Balancer Module** para adicionar mais origens. - **HMAC Authentication** - *Comportamento anterior*: Disponível ao configurar uma Origin. - *Novo comportamento*: Agora é necessário habilitar o **Origin Shield Module** ao configurar um connector do tipo `HTTP`. - **Timeouts** - *Comportamento anterior*: `Connection Timeout` e `Between Bytes Timeout` tinham valores fixos. - *Novo comportamento*: Agora é possível configurar os valores de `Connection Timeout` e `Read/Write Timeout` na seção de Load Balancer Configuration do connectors. #### Uso da API Você pode gerenciar **Connectors** e suas configurações pela API utilizando os endpoints v4 disponíveis. Consulte a [referência da API](https://api.azion.com/v4#/operations/GetEdgeConnectorConnectors) para detalhes sobre operações e parâmetros suportados. ##### Exemplos de requisições **Criando um connector com o tipo Object Storage**: **Criando um connector com o tipo HTTP**: :::tip Para mais informações sobre os parâmetros da API, visite a [referência da API de Connectors](https://api.azion.com/v4#/operations/GetEdgeConnectorConnectors). ::: ### O que acontece com meus Origins existentes? As Origins existentes serão migradas de acordo com um cronograma, que será comunicado para cada caso. A migração ocorrerá em fases. ### Ação necessária Se você possui automações que atualmente utilizam os endpoints da API de **Applications - Origins**, é necessário atualizá-las para utilizar os endpoints da v4. ### Novas funcionalidades - **Reutilização de configuração**: O mesmo Connectors pode ser conectado a múltiplas Applications. - **Timeouts configuráveis**: Os valores de `Connection Timeout` e `Read/Write Timeout` podem ser configurados na seção de Load Balancer Configuration do **Connectors**. ### Benefícios da migração - **Gestão simplificada de backend**: O **Connectors** centraliza todas as definições de conexão de backend, reduzindo a complexidade de configuração. Múltiplas **Applications** podem usar um único **Connectors**, facilitando a manutenção e garantindo consistência de configuração. - **Arquitetura pronta para o futuro**: O **Connectors** fornece a base para novos recursos e otimizações da Azion Web Platform, garantindo que suas Applications estejam prontas para aproveitar novas capacidades assim que estiverem disponíveis. --- ## Custom Pages O **Custom Pages** é um recurso da Azion que permite personalizar páginas de erro para os usuários com base no código de status recebido de um [Connectors](/pt-br/documentacao/produtos/secure/connectors/) ao buscar o conteúdo da sua origem. O **Custom Pages** substitui as configurações de **Error Responses** das Applications. Todas as configurações anteriormente gerenciadas na aba **Error Responses** das Applications agora estão organizadas sob **Custom Pages**. ### Mudanças operacionais e impacto para o usuário Todas as configurações anteriormente gerenciadas na aba **Error Responses** das Applications agora estão organizadas sob **Custom Pages**. | Configuração | Local anterior | Novo local na v4 | |-----------------------------|-------------------------------------------------------|-------------------------------------------------------| | Default Error Response | Applications > Error Responses | Custom Pages > Page Codes | | Custom Error Response | Applications > Error Responses | Custom Pages | | Status Code | Applications > Error Responses > Custom Error | Custom Pages > Status Configuration > Page Code | | Page Path | Applications > Error Responses > Custom Error | Custom Pages > Response Details > Page Path (URI) | | Default Response TTL | Applications > Error Responses > Custom Error | Custom Pages > Response Details > Response TTL | | Set Origin | Applications > Error Responses > Set Origin | Custom Pages > Response Details > Page Path (URI) | #### Mudanças comportamentais notáveis - **Relacionamento** - *Comportamento anterior*: As páginas de erro faziam parte de uma **Applications**. - *Novo comportamento*: Custom Pages são recursos separados e são vinculados a um **Workload**. - **Connectors por código de página** - *Comportamento anterior*: Todas as respostas de erro precisavam ter a mesma **Origin**. - *Novo comportamento*: Agora é possível atribuir um **Connectors** específico para cada código de página de erro em Custom Pages. Isso permite personalizar a resposta para cada código de erro individualmente. #### Uso da API Você pode gerenciar **Custom Pages** e suas configurações pela API utilizando os endpoints v4 disponíveis. Consulte a [referência da API](https://api.azion.com/v4#/operations/GetWorkspaceCustomPages) para detalhes sobre operações e parâmetros suportados. Para utilizar uma **Custom Page**, é necessário vinculá-la a um **Workload** usando o endpoint de **Workload Deployment**. Ao utilizar o Console, essa associação é criada na configuração de deployment do Workload. ##### Exemplos de requisições **Criando uma Custom Page**: , "ttl": 300, "uri": "/path/error_page.html", "custom_status_code": 100 } } } ] }' `} /> **Vinculando uma Custom Page a um Workload Deployment**: /deployments \ --header 'Accept: application/json' \ --header 'Authorization: Token [TOKEN VALUE]' \ --header 'Content-Type: application/json' \ -- '{ "name": "Workload Deployment Example", "current": true, "active": true, "strategy": { "type": "default", "attributes": { "edge_application": , "custom_page": } } }' `} /> :::tip Para mais informações sobre os parâmetros da API, visite a [referência da API de Custom Pages](https://api.azion.com/v4#/operations/GetWorkspaceCustomPages). ::: ### O que acontece com meus Error Responses existentes? Os Error Responses existentes serão automaticamente convertidos em **Custom Pages** em fases, mantendo a compatibilidade com as configurações originais. A migração ocorrerá em ondas. ### Novas funcionalidades - **Detalhes da resposta**: Personalize a resposta para cada código de status. Especifique o URI, código de status, TTL a ser retornado ao cliente. - **Atribuição de Connectors por código de status**: Atribua um connector específico para cada código de página de erro em **Custom Pages**. Isso permite personalizar a resposta para cada código de erro individualmente. ### Benefícios da migração - **Opções de configuração abrangentes**: - Defina um código de status personalizado para cada página. - Configure o tempo de vida (TTL) da resposta. - Especifique o caminho para a página personalizada. - Vincule cada página personalizada a um ou mais connectors. - **Ativação e gerenciamento**: - Ative ou desative qualquer **Custom Page** usando um controle de status. - Visualize e gerencie uma lista paginada de todos os códigos de status configurados pela interface do usuário. --- ## Cronograma planejado de migração O processo de migração ocorrerá nos próximos seis meses. --- ## Recomendações Aqui estão ações recomendadas para garantir uma migração tranquila: - **Acompanhe as comunicações da Azion**: Mantenha-se informado sobre datas de migração, guias e quaisquer ferramentas fornecidas para a transição. - **Planeje sua migração**: Avalie como suas configurações atuais se encaixarão na nova estrutura e planeje estrategicamente a migração dos seus recursos. - **Prepare sua equipe**: Garanta que sua equipe compreenda o conceito de Workloads e seu impacto no desenvolvimento e deploy de aplicações na Azion Web Platform. - **Teste as novas funcionalidades**: À medida que os novos recursos forem implementados, teste as novas capacidades para otimizar suas aplicações e serviços. --- ## Perguntas e Respostas ### Como posso testar as novas funcionalidades? Novas contas Developer terão acesso aos recursos atualizados. Para avaliar essas funcionalidades, você pode criar uma conta pessoal que não esteja associada à conta da sua organização. Isso permite testar as novas funcionalidades de forma independente. ### Preciso fazer alguma coisa? A maioria dos usuários não precisará tomar nenhuma ação, pois o processo de migração é automático e preserva as configurações existentes. No entanto, se você utiliza automações personalizadas, scripts ou pipelines de CI/CD que interagem com os endpoints antigos da API, será necessário atualizá-los para utilizar os novos endpoints da v4. Revise suas integrações para garantir a compatibilidade após a migração. ## O que devo fazer se precisar de assistência? Você pode entrar em contato com nossa [equipe de suporte](/pt-br/documentacao/servicos/suporte/#canais-de-atendimento) ou perguntar diretamente ao [Azion Copilot](https://console.azion.com/copilot).