Instalar

Por que o pacote é específico

O template do CloudFormation já vem com a conta, a região, a VPC, o ambiente e as contas de origem resolvidos. Não há nada para escolher na hora de instalar.

Isso é deliberado, não uma limitação. Essas decisões mudam quais recursos o template declara — um datalake em bucket existente declara recursos diferentes de um que cria o bucket; uma origem cross-account acrescenta políticas que uma instalação de conta única não tem. Oferecer essas opções no instalador criaria escolhas sem efeito, ou pior: recursos inconsistentes que só falhariam depois.

O próprio instalador recusa rodar fora do lugar: ele compara suas credenciais com a conta e a região do pacote e para se não baterem.

O handoff

Antes da entrega, definimos com você:

O que	Por que muda o pacote
Conta e região	Ficam gravadas no template e no manifesto
VPC e subnets	Usar uma VPC existente ou criar; define onde os jobs rodam
Bucket do datalake	Reaproveitar um bucket seu ou criar um novo
Ambiente	`prd`, `hom` — entra no nome de cada recurso
Banco do catálogo	Nome do banco no Glue (padrão: `datalake`)
Contas de origem	Cada conta cross-account acrescenta permissões ao template
Versão	Você escolhe; releases anteriores continuam disponíveis

Você recebe de volta um pacote com o template, o manifesto e os scripts — específico para esse cenário e para essa conta.

A CO2 Lab não recebe acesso à sua conta em momento nenhum. Quem roda os scripts é você, com as suas credenciais.

Quando pedir um pacote novo

Algumas mudanças não são configuráveis depois de instalado, porque alteram o próprio template:

Integrar uma conta de origem nova — as permissões dela precisam existir no template
Trocar a VPC ou o bucket do datalake
Atualizar de versão

Nesses casos, fale com a gente e instale o pacote novo por cima — o CloudFormation resolve a diferença.

Já existe uma instalação antiga?

Instalações feitas antes do modelo de pacote (via cdk deploy) não podem ser atualizadas por cima. Elas resolvem os mesmos recursos de formas incompatíveis: as funções Lambda vêm do bucket de assets do CDK na sua conta, não do pacote; as tabelas do DynamoDB ficam fora da stack; e a chave de uma delas mudou de formato.

O script migrate-legacy-install.sh diagnostica e conduz a troca:

sh migrate-legacy-install.sh check

Se for o caso, a instalação nova sobe ao lado da antiga, sem depender de nenhum recurso dela — a antiga continua rodando enquanto a nova é validada, e removê-la depois não afeta a nova.

Para isso, a nova precisa de um ambiente diferente: quase todo recurso tem nome fixo terminado no ambiente (datapump-task-role-hml), e dois recursos com o mesmo nome não coexistem na conta. Com a antiga em hml, a nova entra como stg. O ambiente é definido no handoff.

O bucket do datalake leva também o id da conta — datapump-datalake-329984708588-stg. Nome de bucket é global entre todas as contas da AWS, então sem isso o primeiro cliente a instalar em um ambiente tomaria o nome de todos os outros. Com a conta no nome, o mesmo cliente pode usar o mesmo ambiente em contas diferentes sem conflito.

sh migrate-legacy-install.sh export   # salva a configuração atual
sh install-datapump.sh                # a nova sobe ao lado
sh migrate-legacy-install.sh seed     # leva a configuração para a nova
# valide: uma execução completa, o console, o catálogo
sh migrate-legacy-install.sh decommission

1. Instalar a stack

Descompacte o pacote e rode, de dentro dele:

sh install-datapump.sh

O script confere que suas credenciais são da conta e da região do pacote — aplicar em outro lugar criaria recursos inconsistentes que só falhariam depois. Se estiver tudo certo, ele cria (ou atualiza) a stack.

Para atualizar para uma versão nova, rode o mesmo comando com o pacote novo. O CloudFormation resolve a diferença.

sh post-install.sh

O endereço do console só existe depois que o load balancer é criado, e o CloudFormation não permite a dependência circular entre ele e o Cognito. Este script fecha o ciclo.

Reexecutar é seguro — ele sobrescreve as URLs com os valores atuais.

3. Habilitar HTTPS

sh setup-https.sh

O Cognito recusa URLs de callback em http, exceto para localhost. Sem HTTPS, o login não funciona.

Sem um domínio próprio, o script gera um certificado autoassinado e o importa no ACM. O navegador vai avisar que o certificado não é confiável — é o custo de não ter domínio. Para eliminar o aviso, use um certificado seu:

CERTIFICATE_ARN=arn:aws:acm:... sh setup-https.sh

4. Criar o primeiro usuário

O console autentica pelo Cognito. Crie o primeiro usuário pelo console da AWS, no user pool datapump-*. Depois disso, a gestão de usuários é feita pelo próprio Data Pump, em Acessos.

5. Acessar

O console fica em um load balancer interno — não é exposto à internet. Você alcança de dentro da VPC, por VPN, ou por um túnel do Session Manager.

O endereço está nos outputs da stack:

aws cloudformation describe-stacks --stack-name DatapumpStack \
  --query "Stacks[0].Outputs[?OutputKey=='DatapumpConsoleUrl'].OutputValue" \
  --output text

E então

A instalação cria a infraestrutura, mas o datalake ainda está vazio: nenhum banco está marcado para ingestão. Siga para configurar a ingestão.