Implantação na AWS — ecosif-automations

Versão: 0.7.05.202605280
Runtime: cinco funções AWS Lambda (Python 3.11), orquestradas por S3, SQS e DynamoDB.
IaC: CloudFormation (entrega a bancos) ou Terraform (infrastructure/terraform/) para ambientes internos.
Não utiliza Docker/ECS para este módulo.

1. Visão do serviço

Pipeline event-driven de importação contábil (ficheiros .IPL + mestre CT32.LD):

flowchart LR
  S3[S3 .IPL] --> LI[Lambda Import]
  LI --> IW[(import-window)]
  LI --> IDQ[import-defer SQS]
  IDQ --> LD[Lambda Import-Dispatcher]
  LD --> EQ[entries FIFO]
  EQ --> LE[Lambda Entries]
  LE --> PG[(PostgreSQL RDS)]
  LE --> CDQ[consolidation-defer]
  LE --> CFQ[consolidation FIFO]
  CDQ --> LS[Lambda Consolidation-Scheduler]
  LS --> CFQ
  CFQ --> LC[Lambda Consolidation]
  LC --> S3out[S3 reports / imported]

Sem cron — debounce usa DelaySeconds em SQS + tabelas DynamoDB.

2. Recursos AWS criados

Pré-requisitos externos: VPC com subnets privadas + NAT, RDS PostgreSQL, ALB interno com ecosif-auth (8081), masterdata (8082), moviments (8083).

3. CloudFormation (caminho recomendado — cliente / stack pai)

3.1 Artefactos

3.2 Parâmetros obrigatórios

• ProjectName, Environment
• VpcId, PrivateSubnet1Id, PrivateSubnet2Id, RdsSecurityGroupId
• AlbDnsName — base HTTP do ALB (ECOSIF_API_BASE_URL)
• PostgresHost, RdsSecretArn
• LambdaCodeS3Bucket, LambdaCodeS3Key — localização do lambda.zip

3.3 Parâmetros de comportamento (defaults de produção)

3.4 Passos de implantação

1. Build (fornecedor): ./build_lambda.sh → publicar zip no S3 de artefactos.
2. Validar hash: sha256sum -c delivery/publish-ready/*.sha256
3. Stack: criar/atualizar nested stack com ecosif_automations.yaml (via stack pai ecosif-backend ou standalone).
4. Pós-deploy: - Rotacionar secret automations-service (nunca usar password do template). - Colocar CT32.LD no bucket na chave Ct32MasterKey (default CT32.LD). - Teste E2E: upload .IPL → logs das 5 funções.

Detalhe auditável: ../dev/integradores/manual_entrega_cliente_banco.md.

4. Terraform (ambiente interno / standalone)

Caminho: infrastructure/terraform/

Alinhado com CloudFormation: mesmas 5 Lambdas, filas FIFO, import defer, tabelas DynamoDB.

4.1 Pré-requisitos

• Terraform >= 1.5
• lambda.zip na raiz do módulo (./build_lambda.sh)
• vpc_subnet_ids e vpc_security_group_ids com acesso a RDS e ALB

4.2 Exemplo terraform.tfvars

aws_region   = "us-west-1"
environment  = "dev"
project_name = "ecosif"
bucket_name  = "ecosif-dev-import-UNIQUE_SUFFIX"

ecosif_api_base_url = "http://internal-alb.example.com"
ecosif_auth_port    = "8081"
ecosif_masterdata_port = "8082"
ecosif_moviments_port  = "8083"

postgres_host     = "rds.internal"
postgres_user     = "ecosif"
postgres_password = "CHANGE_ME"

vpc_subnet_ids         = ["subnet-a", "subnet-b"]
vpc_security_group_ids = ["sg-lambda"]

import_defer_enabled = true

4.3 Comandos

cd infrastructure/terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan

Ou: scripts/deploy.sh dev (build + plan interativo).

4.4 Outputs principais

import_lambda_name, import_dispatcher_lambda_name, entries_queue_url, import_defer_queue_url, consolidation_queue_url, tabelas DynamoDB — ver outputs.tf.

5. Variáveis de ambiente (resumo)

Referência completa: delivery/env.import.lambda.example, env.import-dispatcher.lambda.example, env.entries.lambda.example, env.consolidation.lambda.example.

6. Validação pós-implantação

1. CT32.LD presente no bucket (CT32_MASTER_KEY).
2. Upload NNNNNN_YYYYMMDD.IPL válido.
3. CloudWatch: logs /aws/lambda/{project}-{env}-automations-*.
4. S3: imported/files/ ou importError/ + CSV de erro.
5. DLQs vazias após teste bem-sucedido.

7. Escolha CloudFormation vs Terraform

Ambos os modelos devem permanecer sincronizados em cada release; a versão em VERSION é a fonte da verdade.