Ir al contenido
InicioPT · EN · ES · JA · ZH

Instalar

La plantilla de CloudFormation ya viene con la cuenta, la región, la VPC, el ambiente y las cuentas de origen resueltos. No hay nada que elegir a la hora de instalar.

Esto es deliberado, no una limitación. Esas decisiones cambian qué recursos declara la plantilla — un datalake sobre un bucket existente declara recursos distintos de uno que crea el bucket; un origen cross-account agrega políticas que una instalación de cuenta única no tiene. Ofrecer esas opciones en el instalador crearía elecciones sin efecto, o peor: recursos inconsistentes que solo fallarían después.

El propio instalador se niega a ejecutarse fuera de lugar: compara tus credenciales con la cuenta y la región del paquete y se detiene si no coinciden.

Antes de la entrega, definimos contigo:

Qué Por qué cambia el paquete
Cuenta y región Quedan grabadas en la plantilla y en el manifiesto
VPC y subredes Usar una VPC existente o crearla; define dónde se ejecutan los jobs
Bucket del datalake Reutilizar un bucket tuyo o crear uno nuevo
Ambiente prd, hom — entra en el nombre de cada recurso
Base del catálogo Nombre de la base en Glue (predeterminado: datalake)
Cuentas de origen Cada cuenta cross-account agrega permisos a la plantilla
Versión La eliges tú; las releases anteriores siguen disponibles

Recibes de vuelta un paquete con la plantilla, el manifiesto y los scripts — específico para ese escenario y para esa cuenta.

CO2 Lab no recibe acceso a tu cuenta en ningún momento. Quien ejecuta los scripts eres tú, con tus propias credenciales.

Algunos cambios no son configurables después de instalado, porque alteran la propia plantilla:

  • Integrar una cuenta de origen nueva — sus permisos necesitan existir en la plantilla
  • Cambiar la VPC o el bucket del datalake
  • Actualizar de versión

En esos casos, habla con nosotros e instala el paquete nuevo por encima — CloudFormation resuelve la diferencia.

Descomprime el paquete y ejecuta, desde dentro de él:

Ventana de terminal
sh install-datapump.sh

El script verifica que tus credenciales sean de la cuenta y la región del paquete — aplicarlo en otro lugar crearía recursos inconsistentes que solo fallarían después. Si todo está bien, crea (o actualiza) el stack.

Para actualizar a una versión nueva, ejecuta el mismo comando con el paquete nuevo. CloudFormation resuelve la diferencia.

Ventana de terminal
sh post-install.sh

La dirección de la consola solo existe después de que se crea el load balancer, y CloudFormation no permite la dependencia circular entre este y Cognito. Este script cierra el ciclo.

Volver a ejecutarlo es seguro — sobrescribe las URLs con los valores actuales.

Ventana de terminal
sh setup-https.sh

Cognito rechaza URLs de callback en http, excepto para localhost. Sin HTTPS, el login no funciona.

Sin un dominio propio, el script genera un certificado autofirmado y lo importa en ACM. El navegador va a avisar que el certificado no es confiable — es el costo de no tener dominio. Para eliminar el aviso, usa un certificado tuyo:

Ventana de terminal
CERTIFICATE_ARN=arn:aws:acm:... sh setup-https.sh

La consola autentica por Cognito. Crea el primer usuario desde la consola de AWS, en el user pool datapump-*. Después de eso, la gestión de usuarios se hace en el propio Data Pump, en Acessos (Accesos).

La consola queda en un load balancer interno — no está expuesta a internet. La alcanzas desde dentro de la VPC, por VPN, o por un túnel de Session Manager.

La dirección está en los outputs del stack:

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

La instalación crea la infraestructura, pero el datalake todavía está vacío: ninguna base está marcada para ingesta. Sigue a configurar la ingesta.