Oi @kapa.ai, tenho algumas perguntas , você poderia me ajudar a entender o seguinte? 1. Principais diferenças entre v0.50.29, v1.4 e v2.0 — o que mudou em termos de arquitetura e funcionalidade entre essas versões? 2. Autenticação — como funciona a autenticação em cada versão? As versões v1.4 e v2.0 oferecem suporte nativo à autenticação? Quais opções estão disponíveis (SSO, autenticação básica, OAuth)? 3. Espaços de trabalho e suporte a múltiplas equipes — é possível segregar conexões por espaço de trabalho? Equipes diferentes podem trabalhar independentemente na mesma instância do Airbyte na versão gratuita/de código aberto? Quais são as limitações? 4. Provedor Terraform — existe um provedor Terraform oficial disponível? Quais versões ele suporta? É possível gerenciar origens, destinos e conexões como código? Existem limitações conhecidas? 5. Implantação — quais são as opções de implantação recomendadas para instâncias autohospedadas (Kubernetes/Helm)? Houve alguma mudança significativa na estrutura do gráfico entre as versões 0.50.x e 1.x/2.x?

Vou responder ponto a ponto, mas com uma limitação importante: as fontes não trazem detalhes específicos sobre a versão v0.50.29 nem uma matriz completa de diferenças entre v0.50.x, v1.4 e v2.0. Onde faltar informação, vou sinalizar. 1. Diferenças entre v0.50.29, v1.4 e v2.0 (arquitetura e funcionalidades) As notas de versão disponíveis são agregadas por “grandes versões” (1.0, 1.5, 2.0 etc.) e não detalham especificamente v0.50.29 nem v1.4. O que conseguimos ver é a evolução geral: • Linha 0.5x (ex.: 0.50.29) As notas de novembro/2023 (0.50.34–0.50.35) mostram um Airbyte ainda pré‑1.0, com: ◦ Introdução de SSO e RBAC (apenas admin) no Cloud. [Nov 2023] ◦ Melhorias em conectores e monitoramento (heartbeats). [Nov 2023] Não há, nas fontes, um resumo arquitetural completo dessa linha. • Versão 1.x (ex.: 1.0, 1.5, 1.6, 1.8) A partir do 1.0 há um salto claro em confiabilidade e operação:As fontes não descrevem especificamente o que muda em 1.4 em relação a 1.3/1.5, apenas que 1.4 é uma release intermediária listada nas notas gerais. [Release notes] ◦ Introdução de

abctl

como forma recomendada de deploy self‑managed. [Airbyte 1.0] ◦ Autenticação nativa (email/senha) para que qualquer instância OSS seja segura por padrão. [Airbyte 1.0] ◦ Workloads: nova arquitetura de jobs separando agendamento/orquestração do movimento de dados, para melhor escalabilidade. [Airbyte 1.0] ◦ Recursos de resiliência (refreshes, resumable full refresh, melhorias em CDC, etc.). [Airbyte 1.0] ◦ Ao longo de 1.x, foram adicionados: tags de conexão, melhorias de OAuth declarativo no Connector Builder, etc. [Airbyte 1.5; Look back v1] • Versão 2.0 É apresentada como um marco arquitetural: ◦ Faster sync speed (4–6x mais rápido em média, com uso mais eficiente de recursos). [Airbyte 2.0] ◦ Data activation GA (movimentar dados do warehouse para ferramentas operacionais). [Airbyte 2.0] ◦ Airbyte Enterprise Flex (control plane gerenciado na nuvem + data planes na sua infra). [Airbyte 2.0] ◦ Ingress passa a ser entregue diretamente no Helm chart, facilitando configuração via

values.yaml

. [2.0 – Other improvements] ◦ Continuidade de melhorias de 1.x: self‑managed data planes, audit logging, novo Helm chart V2, OAuth simplificado, tags, etc. [Look back v1] Resumo: • 0.50.x: pré‑1.0, sem as garantias de “plataforma 1.x/2.x”, com SSO/RBAC apenas em Cloud e menos recursos de resiliência. [Nov 2023] • 1.x: introduz

abctl

, autenticação nativa, Workloads, melhorias fortes de confiabilidade e gestão. [Airbyte 1.0] • 2.0: otimizações de performance (faster sync), data activation, Enterprise Flex e melhorias adicionais de deploy (ingress no chart). [Airbyte 2.0; 2.0 – Other improvements] 2. Autenticação em cada versão (nativa, SSO, OAuth) As fontes não descrevem explicitamente o comportamento de v0.50.29 nem de v1.4 em particular, mas temos o seguinte panorama: Autenticação nativa (email/senha) • Introduzida em OSS como parte da linha 0.63.x e consolidada em 1.0: ◦ Notas de julho/2024: “Native authentication by email and password is available in Airbyte OSS so that any instance of Airbyte is secure by default.” [July 2024] ◦ Reforçada nas notas de 1.0 como recurso de “ease of deployment”. [Airbyte 1.0] Portanto, v1.4 e v2.0 (que são posteriores) suportam autenticação nativa. As fontes não dizem se 0.50.29 já tinha esse mecanismo; tudo indica que é anterior a essa mudança, mas isso não está explicitamente documentado. SSO (OIDC / Okta / Entra ID) • SSO aparece primeiro em Cloud nas notas de novembro/2023 (linha 0.50.34–0.50.35), com Okta e RBAC admin. [Nov 2023] • Para Airbyte 2.0 (e 1.x Enterprise), há documentação de SSO via OIDC (Okta, Entra ID) para: ◦ Airbyte Cloud (planos Pro/Enterprise Flex). [SSO 2.0] ◦ Self‑Managed Enterprise (SSO com Okta/Entra ID). [Self‑Managed Enterprise; SSO 2.0] As fontes não detalham SSO específico para OSS “gratuito” fora do contexto Enterprise/Cloud. OAuth (para conectores) • OAuth 2.0 é usado para autenticar conectores (não usuários) em todas as edições, com: ◦ Fluxo simplificado na UI (Airbyte gerencia client credentials em Cloud para alguns conectores). [OAuth overview] ◦ Em Self‑Managed, você registra o app no provedor, configura Client ID/Secret e usa o botão de autenticação. [OAuth overview] • Em 1.5, foi introduzido OAuth declarativo no Connector Builder e no low‑code CDK. [Airbyte 1.5] Isso vale para 1.4+ e 2.0, mas a forma declarativa é explicitamente documentada a partir de 1.5. 3. Espaços de trabalho e múltiplas equipes na mesma instância As fontes falam de forma mais detalhada sobre Self‑Managed Enterprise: • Self‑Managed Enterprise oferece: ◦ Multiple Workspaces: “Manage multiple isolated projects or teams on a single Airbyte deployment.” [Self‑Managed Enterprise] ◦ Role-Based Access e Single Sign-On para gerenciar permissões entre workspaces. [Self‑Managed Enterprise] Isso implica que, nessa edição, é possível segregar conexões por workspace e ter equipes diferentes trabalhando de forma isolada na mesma instância. Sobre a versão gratuita/OSS: • As fontes não trazem uma comparação clara de recursos de workspaces entre OSS e Enterprise, nem listam explicitamente limitações de multi‑workspace na edição gratuita. • Sabemos apenas que: ◦ Workspaces existem (pois são usados em APIs, notificações, etc.). [Airbyte 1.5] ◦ A funcionalidade de múltiplos workspaces como recurso de governança é destacada especificamente como benefício de Self‑Managed Enterprise. [Self‑Managed Enterprise] Portanto, com base apenas nas fontes: • Sim, há conceito de workspaces e conexões associadas a workspaces. • Sim, em Self‑Managed Enterprise é claramente suportado ter múltiplos workspaces para múltiplas equipes na mesma instância. [Self‑Managed Enterprise] • Limitações na OSS gratuita: as fontes não detalham quais recursos de multi‑workspace/RBAC estão disponíveis ou restritos; não há informação suficiente para afirmar com segurança o nível de isolamento e controle de acesso na edição OSS. 4. Provedor Terraform • Existe um provedor Terraform oficial da Airbyte: ◦ Documentação oficial no Terraform Registry. [Terraform provider 2.0] • O provedor é construído sobre a API do Airbyte. [Terraform provider 2.0] • É possível gerenciar: ◦ Sources, destinations e connections como código, usando recursos genéricos

airbyte_source

/

airbyte_destination

(há um guia de migração para 1.0 que fala justamente dessa mudança). [Terraform provider 2.0] • A documentação detalhada (incluindo versões suportadas, exemplos e limitações) está no Registry: ◦ Getting Started, provider reference, recursos e data sources, guia de migração. [Terraform provider 2.0] As fontes não especificam explicitamente quais versões mínimas de Airbyte o provedor suporta, apenas apontam para o Registry como “source of truth”. [Terraform provider 2.0] 5. Implantação self‑hosted (Kubernetes/Helm) e mudanças de chart Opções recomendadas • Para Self‑Managed em geral: ◦

abctl

é apresentado como a forma mais fácil e rápida de começar com Airbyte Self‑Managed. [Airbyte 1.0] • Para Kubernetes/Helm: ◦ Há um Helm chart V2 recomendado para novas instalações e para upgrades: ▪︎ Para Core/Community: guia “chart‑v2‑community”. [Release notes v2.0 – look back] ▪︎ Para Self‑Managed Enterprise: guia específico de upgrade para Helm chart V2. [Helm V2 Enterprise 2.0] Mudanças significativas entre chart V1 e V2 • Motivações para o Helm chart V2 (Enterprise, mas o racional é similar para Community): ◦ Não requer mais Keycloak; permite usar OIDC genérico. [Helm V2 Enterprise 2.0] ◦ Mais alinhado com boas práticas de design de charts Helm. [Helm V2 Enterprise 2.0] ◦ Interface de configuração mais rica, reduzindo necessidade de muitas env vars em

values.yaml

. [Helm V2 Enterprise 2.0] • Requisitos de versão para usar o chart V2 (Enterprise): ◦ Airbyte 1.6.0+ instalado e gerenciado com Helm. [Helm V2 Enterprise 2.0] ◦ Versões anteriores a 1.6.0 não podem usar o chart V2. [Helm V2 Enterprise 2.0] • Processo de upgrade recomendado (Enterprise): ◦ Usar novo namespace, nova

values.yaml

, e instalar uma nova instância apontando para DB e storage externos já existentes. [Helm V2 Enterprise 2.0] ◦ Novo repositório Helm (

https://airbytehq.github.io/charts

, prefixo

airbyte-v2

). [Helm V2 Enterprise 2.0] Para 0.50.x: • As fontes não descrevem diretamente a estrutura do chart nessa linha, apenas que o “new helm chart” (V2) é uma melhoria importante introduzida na era 1.x. [Look back v1] Se você quiser, posso ajudar a traduzir isso em recomendações práticas, por exemplo: “estou hoje em 0.50.29, quero ir para 2.0 em Kubernetes, qual caminho de migração faz mais sentido?” com base nesses docs. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.