Implantação de infraestrutura Blockchain baseada na AWS usando o Terraform

Organizações bancárias e financeiras já integram blockchains em suas operações para aumentar a eficiência e a segurança. Com a ajuda dessa tecnologia, eles aceleram transações, melhoram a rastreabilidade dos dados, automatizam processos manuais e reduzem custos. O blockchain também oferece maior confiança, transparência e segurança no gerenciamento de dados.

No entanto, projetar e implantar infraestrutura de blockchain para organizações financeiras é complexo e desafiador. Requer conhecimento profundo de criação e implantação de infraestrutura de nuvem, experiência relevante e extensa pesquisa.

Recentemente, publicamos um estudo de caso sobre a construção de infraestrutura blockchain para bancos internacionais. Neste artigo, compartilhamos mais detalhes técnicos desse processo e discutimos práticas e ferramentas de DevOps de alto nível. Este artigo será útil para engenheiros líderes que planejam construir uma infraestrutura de blockchain baseada na AWS com o Terraform e estão procurando um guia abrangente.

Definindo a arquitetura do projeto

Em um de nossos projetos, um cliente precisou de ajuda para construir e implantar infraestrutura de blockchain para bancos internacionais.

Eles já estavam usando o fluxo de trabalho do Git e o Terraform neste projeto, então foi lógico e benéfico continuar automatizando seus processos de DevOps usando a Amazon Web Services (AWS). A AWS fornece escalabilidade, confiabilidade e soluções de banco de dados seguras, tornando-a uma plataforma ideal para criar e manter uma infraestrutura de blockchain.

Usando as práticas de DevOps da Apriorit para implantar uma infraestrutura de blockchain na AWS, nossos engenheiros conseguiram:

• Use ferramentas de automação como Ansible, Chef e Puppet
• Acelere o processo de criação, configuração e implantação de recursos
• Reduzir os riscos de erros humanos
• Melhore a colaboração entre equipes

Tais práticas podem aumentar a velocidade e a confiabilidade das soluções de software, ao mesmo tempo em que reduzem o tempo necessário para criar e implantar recursos. Isso pode ser um divisor de águas para os desenvolvedores, ajudando-os a tirar o máximo proveito de sua infraestrutura de nuvem.

Além disso, escolher a abordagem de Infraestrutura como Código (IaC) em várias nuvens pode ajudá-lo a simplificar o processo de implantação de recursos de TI, evitando etapas manuais de configuração e implantação. Assim, os desenvolvedores podem criar, implantar e escalar sua infraestrutura de blockchain de forma rápida e fácil, ao mesmo tempo em que aproveitam as ferramentas de teste automatizadas da AWS.

Para atender a solicitação do cliente, dividimos o projeto em três etapas principais:

1. Estabeleça a estrutura de diretórios Terraform. Durante esta etapa, trabalhamos com arquivos de configuração, módulos, variáveis e saídas do Terraform.
2. Crie um fluxo de trabalho no Git para orquestrar o processo de implantação usando as Ações do GitHub. Esta etapa incluiu testes, planejamento e aplicação da configuração do Terraform. Além disso, gerenciamos o estado da infraestrutura para obter recursos de visibilidade, controle e reversão.
3. Gerencie a implantação da infraestrutura usando fluxos de trabalho do Git. Esse método de DevOps nos ajudou a garantir que a infraestrutura do cliente estivesse sendo executada com alta disponibilidade e escalabilidade.

Aqui está a arquitetura do projeto:

A infraestrutura não era assim no início. Começamos apenas com:

• Um Application Load Balancer (ALB)
• Um ECS (Elastic Container Service) com muitos serviços e tarefas
• Um serviço de banco de dados relacional (RDS) MySQL

Dividimos todo o processo de trabalho em oito etapas principais:

Vamos explorar cada uma dessas etapas em detalhes, discutindo brevemente as ferramentas que usamos e compartilhando exemplos de código. Começaremos explorando como criar infraestrutura na AWS com o Terraform.

1. Criando infraestrutura, ambientes, funções e espaços de trabalho

Para construir a infraestrutura, utilizamos o Terraform versão 1.3.0 e criamos três ambientes: desenvolvimento, teste e produção.

Para desenvolver a infraestrutura, criamos funções e usamos a infraestrutura em camadas para flexibilidade. Usamos uma função de gerenciamento de acesso e identidade (IAM) para criar a camada principal da infraestrutura do projeto e outras funções do IAM para criar diferentes serviços e ambientes.

Assim que as funções ficaram prontas, criamos um perfil para cada uma delas:

aws configure --profile blockchain-role1-us-east-1
aws configure --profile blockchain-roleN-us-east-1

Como você pode ver, esse processo exigiu que especificássemos credenciais e uma região padrão.

Para usar uma função específica, executamos o seguinte comando no diretório de trabalho:

export AWS_PROFILE=blockchain-role1-us-east-1

Agora, precisamos garantir o armazenamento do Estado. Para isso, usamos um bucket S3. O uso de buckets do S3 é uma ótima prática de DevOps porque oferece uma série de vantagens, incluindo:

• Controle de versão. Os buckets do S3 são versionados por padrão, o que significa que todas as alterações feitas nos arquivos de estado armazenados são rastreadas. Isso facilita o controle do histórico de alterações e a reversão rápida para uma versão anterior, se necessário.
• Durabilidade. Os buckets do S3 são altamente duráveis e armazenarão seus arquivos de estado com segurança. Isso significa que, se sua máquina local falhar, seus arquivos de estado ainda estarão seguros.
• Disponibilidade. Os buckets do S3 estão disponíveis em todas as regiões, o que significa que você pode acessar seus arquivos de estado de qualquer lugar. Isso é particularmente útil para equipes remotas.
• Escalabilidade. Os buckets do S3 podem ser dimensionados para atender às suas necessidades de armazenamento, permitindo que você armazene quantos estados Terraform forem necessários.

Armazenamos a descrição do estado necessário da infraestrutura – – em um bucket do Amazon S3, que oferece suporte ao bloqueio de estado e à verificação de consistência por meio do DynamoDB:terraform.state

resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-blockchain-structure-bucket-us-east-1"

  tags = {
Description
= "blockchain-structure terraform.tfstate."
ManagedByTerraform = "true"
Name
= "blockchain-structure"
  }

  lifecycle {
prevent_destroy = true
  }
}

resource "aws_dynamodb_table" "terraform_locks" {
  name
= "terraform-locks-my-blockchain-structure-us-east-1"
  billing_mode = "PAY_PER_REQUEST"
  hash_key
= "LockID"
  attribute {
name = "LockID"
type = "S"
  }
  tags = {
Environment = "dev"
Infra
= "Core"
Service
= "Terraform"
  }

}

Em seguida, usamos o seguinte controle de versão para o bucket do S3:

resource "aws_s3_bucket_versioning" "terraform_state" {
 # Enable versioning so we can see the full revision history of our state files
 bucket = aws_s3_bucket.terraform_state.id
 versioning_configuration {
   status = "Enabled"
 }
}

Depois de inicializar o projeto, precisávamos criar espaços de trabalho. Usamos espaços de trabalho Terraform, pois eles oferecem vários benefícios para criar e gerenciar diferentes ambientes de infraestrutura na Nuvem AWS:

• Organização de ambiente simples. Os espaços de trabalho permitem organizar facilmente ambientes de teste, preparação e produção. Isso torna conveniente gerenciar diferentes configurações e definições e simplifica a transição entre ambientes.
• Acesso direto aos ambientes. Os espaços de trabalho permitem que as equipes colaborem em ambientes diferentes, permitindo que vários usuários tenham acesso direto ao mesmo ambiente. Isso elimina a necessidade de ter vários usuários mantendo versões diferentes do mesmo ambiente e a necessidade de transferir manualmente um ambiente para um usuário diferente.
• Facilidade de implantação. Os espaços de trabalho Terraform ajudam você a implantar de forma rápida e fácil vários ambientes configurados de forma idêntica e a recriar rapidamente um ambiente de produção se algo der errado.
• Controle de alterações. Com os espaços de trabalho Terraform, você pode acompanhar as alterações feitas nos ambientes ao longo do tempo e reverter quaisquer alterações indesejáveis. Isso ajuda a garantir que todos os ambientes permaneçam consistentes e evita que alterações não planejadas ocorram.

Criamos o espaço de trabalho executando o seguinte comando:dev

terraform workspace create dev

Agora, vamos discutir como implantar a infraestrutura blockchain baseada na AWS usando o Terraform.

2. Implantação de um blockchain na plataforma da AWS usando o Terraform

Para implantar um blockchain na plataforma da AWS, tivemos que escolher entre duas soluções: Terraform e AWS CloudFormation. Ambos são ferramentas de infraestrutura como código (IaC) que fornecem automação e gerenciamento de infraestrutura na nuvem da AWS.

• O Terraform permite que você crie recursos da AWS usando uma única linguagem unificada. Ele oferece suporte a muitos serviços da AWS. Com o Terraform, você também pode fazer alterações nos recursos existentes da AWS, o que permite uma abordagem mais granular para modificar a infraestrutura.
• O AWS CloudFormation tem um escopo mais limitado quando se trata de configurar recursos da AWS, e sua sintaxe pode ser difícil de aprender. Além disso, o CloudFormation não oferece suporte a todos os serviços da AWS. Em termos de escalabilidade e desempenho, o CloudFormation tem a vantagem sobre o Terraform: ele pode implantar recursos em paralelo, enquanto o Terraform só pode implantá-los sequencialmente.

Depois de comparar estas duas soluções, decidimos escolher Terraform devido à sua flexibilidade. Vamos explorar o processo de implantação da infraestrutura blockchain com o Terraform.

Para usar o bucket onde o estado da infraestrutura está armazenado, aplicamos o seguinte código Terraform:

terraform {
  backend "s3" {
bucket = "my-blockchain-structure-bucket-us-east-1"
key = "path/to/my-env/my-blockchain-structure"
region = "us-east-1" 
dynamodb_table = "terraform-locks-my-blockchain-structure-us-east-1"
encrypt
= true
  }
}

Para acessar os recursos necessários de outra camada, usamos a fonte de dados:terraform_remote_state

data "terraform_remote_state" "network" {
  backend = "s3"
config = {
  bucket = "my-blockchain-structure-bucket-us-east-1"
  key = "path/to/my/blockchain-structure-network/terraform.tfstate"
  region = "us-east-1"
}
}

E aqui está o código que nos ajudou a armazenar várias imagens do Docker para serviços do Amazon Elastic Container Registry (ECR):

resource "aws_ecr_repository" "service1" {
  name
= join("/", [var.app, var.name_repository, var.env])
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
scan_on_push = true
  }

  encryption_configuration {
encryption_type = "AES256"
  }
}

 
resource "aws_ecr_lifecycle_policy" "repo_lifecycle_policy" {
  repository = aws_ecr_repository.service1.id
  policy
= file("${path.module}/policies/ecr_lifecycle_policy.json")
}


policies/ecr_lifecycle_policy.json" :
{
"rules": [

{
    
"rulePriority": 1,
    
"description": "Leave only 5 last images",

"selection": {

"tagStatus": "untagged",

"countType": "imageCountMoreThan",

"countNumber": 5

},

"action": {

"type": "expire"

}

}
]
}

Com isso em mente, vamos seguir em frente e discutir como usar os módulos do Terraform para implantar a infraestrutura da AWS.

Usando módulos Terraform

Decidimos usar os módulos Terraform para implantar a infraestrutura da AWS porque eles:

• Forneça uma maneira de implantar rapidamente a infraestrutura de nuvem na AWS com apenas algumas linhas de código
• Pode ser reutilizado para criar vários ambientes semelhantes, garantindo um fluxo de trabalho mais eficiente
• São versionados e podem ser facilmente revertidos para uma versão anterior em caso de erros
• Ajude-nos a gerenciar ambientes complexos, pois todas as configurações são facilmente rastreadas e monitoradas através do repositório de módulos

Para criar recursos para cada serviço, utilizamos um módulo separado com os submódulos necessários. E para acessar vários recursos através de uma ALB, usamos o recurso. Também usamos o módulo Route53 para descrever o nome de domínio do serviço.aws_lb_listener_rule

Veja como podemos criar qualquer serviço usando o módulo de serviço Terraform:

module "ecs_blockchain_service" { 
  source    
= "./modules/ecs_blockchain_service" 
  app       
= var.app 
  env       
= terraform.workspace 
  account_id
= var.account_id 
  keypair_name  
= module.private_key_blockchain_service.keypair_name 
  container_name
= "blockchain_service" 
  container_port
= 80 
  secrets_blockchain_service  = lookup(var.secret_arn_blockchain_service, terraform.workspace) 
  desired_count 
= var.service_desired 
  ecs_subnet_ids
= module.vpc.ecs_subnet_ids 
  public_subnet_ids = module.vpc.public_subnet_ids 
  sg_lb_id  
= module.sg.sg_alb_id_blockchain_service 
  sg_ecs_id 
= module.sg.sg_ecs_id_blockchain_service 
  sg_rds_id 
= module.sg.sg_rds_id_blockchain_service 
  vpc_id    
= module.vpc.vpc_id 
  aws_region
= var.aws_region 
 
  aws_lb_target_group = module.lb_blockchain_service.aws_lb_target_group 
  image_url   
= lookup(var.image_url_blockchain_service, terraform.workspace)  
  image_id    
= data.aws_ami.aws_optimized_ecs.id             
  instance_type   
= lookup(var.ami_blockchain_service_instance_type, terraform.workspace) 
  min_size    
= var.min_size 
  max_size    
= var.max_size 
  desired_capacity
= var.desired_capacity 
  min_elb_capacity
= var.min_elb_capacity 
  alb_arn_suffix  
= module.lb_blockchain_service.alb_arn_suffix 
 
  cpu_task_backend1 
= lookup(var.cpu_task_backend1, terraform.workspace) 
  memory_task_backend1  
= lookup(var.memory_task_backend1, terraform.workspace) 
  cpu_container_backend1
= lookup(var.cpu_container_backend1, terraform.workspace) 
  memory_container_backend1 = lookup(var.memory_container_backend1, terraform.workspace) 
 
  cpu_task_backend2 
= lookup(var.cpu_task_backend2, terraform.workspace) 
  memory_task_backend2  
= lookup(var.memory_task_backend2, terraform.workspace) 
  cpu_container_backend2
= lookup(var.cpu_container_backend2, terraform.workspace) 
  memory_container_backend2 = lookup(var.memory_container_backend2, terraform.workspace) 
 
  aws_lb_target_group_backend1   
= module.lb_blockchain_service.aws_lb_target_group_backend1 
  aws_lb_target_group_backend2  
= module.lb_blockchain_service.aws_lb_target_group_backend2 
  container_name_backend1    
= "backend1" 
  container_name_backend2   
= "backend2" 
  container_port_backend1    
= 3000 
  container_port_backend2   
= 3000 
  image_url_backend1         
= lookup(var.image_url_backend1, terraform.workspace)  
  image_url_backend2        
= lookup(var.image_url_backend2, terraform.workspace) #var.image_url_backend2 
  secrets_backend1           
= lookup(var.secret_arn_backend, terraform.workspace) 
  secrets_backend1_config_json_file  = lookup(var.secret_arn_backend1_config_json_file, terraform.workspace) 
  secrets_backend2          
= lookup(var.secret_arn_backend2, terraform.workspace) 
  secrets_backend_config_json_file2 = lookup(var.secret_arn_backend_config_json_file2, terraform.workspace) 
 
  db_host_backend1 
= module.rds_backend1.endpoint 
  db_username_backend1 = module.rds_backend.username 
  db_password_backend1 = module.rds_backend.password 
  db_port_backend1 
= module.rds_backend.port 
  db_name_backend1 
= module.rds_backend.db_name 
 
  autoscale_up_rpm_cooldown       
= var.autoscale_up_rpm_cooldown 
  autoscale_up_rpm_aggregation_type   
= var.autoscale_up_rpm_aggregation_type 
  autoscale_up_rpm_interval_lower_bound   = var.autoscale_up_rpm_interval_lower_bound 
  autoscale_up_rpm_adjustment     
= var.autoscale_up_rpm_adjustment 
  autoscale_down_rpm_cooldown     
= var.autoscale_down_rpm_cooldown 
  autoscale_down_rpm_aggregation_type 
= var.autoscale_down_rpm_aggregation_type 
  autoscale_down_rpm_interval_upper_bound = var.autoscale_down_rpm_interval_upper_bound 
  autoscale_down_rpm_adjustment   
= var.autoscale_down_rpm_adjustment 
 
  alarm_rpm_high_evaluation_periods = var.alarm_rpm_high_evaluation_periods 
  alarm_rpm_high_period     
= var.alarm_rpm_high_period 
  alarm_rpm_high_statistic  
= var.alarm_rpm_high_statistic 
  alarm_rpm_high_threshold  
= var.alarm_rpm_high_threshold 
  alarm_rpm_low_evaluation_periods  = var.alarm_rpm_low_evaluation_periods 
  alarm_rpm_low_period      
= var.alarm_rpm_low_period 
  alarm_rpm_low_statistic   
= var.alarm_rpm_low_statistic 
  alarm_rpm_low_threshold   
= var.alarm_rpm_low_threshold 
} 

3. Escolhendo uma ferramenta e construindo o pipeline de CI/CD

Para integração contínua (CI) e entrega contínua (CD), escolhemos entre GitHub Actions e AWS CodePipeline. Essas ferramentas fornecem funcionalidade semelhante e permitem automatizar fluxos de trabalho de desenvolvimento de software na AWS. Eles também ajudam você a gerenciar com eficiência suas implantações e testes.

Na Apriorit, costumamos usar o AWS CodePipeline para criar infraestrutura, pois é uma solução simples projetada especificamente para uso com a plataforma da AWS. O AWS CodePipeline é fácil de usar e não requer nenhum conhecimento de codificação. No entanto, não é tão rico em recursos quanto o GitHub Actions e é um produto comercial.

Também temos experiência em trabalhar com o GitHub Actions, que é considerado uma solução mais abrangente do que o AWS CodePipeline. É gratuito para usar e tem uma ampla gama de recursos, tais como:

• Integração com serviços externos
• Suporte para vários idiomas
• Suporte para vários sistemas operacionais

No lado negativo, o GitHub Actions é bastante complicado de usar e requer conhecimento de codificação para ser capaz de usá-lo de forma eficaz.

Depois de analisar as opções, decidimos nos ater ao GitHub Actions, pois parecia ser um ajuste melhor em nosso caso. Além disso, nosso cliente já estava usando o GitHub Actions para seu software.

Depois de mesclar o código na ramificação principal, lançamos um pipeline. Esse pipeline carrega a nova imagem no ECR, atualiza-a e inicia a nova tarefa do ECS. Criamos uma função do IAM que só tem direitos de acesso para atualizar tarefas do ECS.

Aqui está o código que usamos para criar o pipeline de CI/CD:

service1.yml : 
 
name: Service1 CI/CD 
 
on: 
  push: 
branches: ["aws_development"] 
paths: 
  	
- "service1/**" 
 
env: 
  STAGE: "development" 
jobs: 
  build_push_and_restart_tasks: 
runs-on: ubuntu-latest 
 
steps: 
  	
- uses: actions/checkout@v3 
 
  	
- name: Configure AWS Credentials 
		
uses: aws-actions/configure-aws-credentials@v1 
		
with: 
  		
aws-access-key-id: $ 
  		
aws-secret-access-key: $ 
  		
aws-region: $ 
 
  	
- name: Build, tag, and push the My-blockchain-Service1 Backend image to Amazon ECR 
		
run: | 
  		
cd service1 
  		
docker build -t my-/backend1/$ . 
  		
docker tag my-blockchain-service1/backend1/$:latest 012345678900.dkr.ecr.us-east-1.amazonaws.com/my-blockchain-service1/backend1/$:latest 
  		
docker push 012345678900.dkr.ecr.us-east-1.amazonaws.com/my-blockchain-service1/backend1/$:latest 
  	
- name: Restart service Backend Task 
		
run: | 
  		
aws ecs update-service --cluster my-blockchain-service1-service-$ --service my-blockchain-service1-backend1-$ --task-definition my-blockchain-service1-backend1-$ --force-new-deployment 
  		
aws ecs update-service --cluster my-blockchain-service1-service-$ --service my-blockchain-service1-backend2-$ --task-definition my-blockchain-service1-backend2-$ --force-new-deployment

4. Garantir a gestão de segredos

As duas soluções mais confiáveis para armazenar e gerenciar segredos, como chaves e senhas da API (Application Programming Interface), são o AWS Secrets Manager e o AWS Parameter Store:

• O AWS Secrets Manager é mais adequado para armazenamento de longo prazo e recuperação de segredos usados por aplicativos e serviços. Ele permite a rotação automática de segredos e se integra a outros serviços da AWS, como o AWS Lambda, que é usado para rotação automática de credenciais.
• O AWS Parameter Store é uma ótima ferramenta para gerenciar parâmetros de configuração que são usados com frequência por aplicativos e serviços. Ele não é tão seguro quanto o AWS Secrets Manager, mas é adequado para parâmetros que não precisam ser mantidos em segredo por longos períodos de tempo. Essa ferramenta também é útil para armazenar credenciais que não precisam ser giradas com frequência.

Para este projeto, decidimos armazenar dados confidenciais com acesso limitado no AWS Secrets Manager. Veja como configuramos as regras de rotação e o período de turno:

resource "aws_secretsmanager_secret" "secret_1" { 
  name ="/${var.app}/${terraform.workspace}/SECRET1" 
  description = “Blockchain secret 1” 
  secret_string = “SECRET1” 
  rotation_rules { 
automatically_after_days = 7 
  } 
} 

Para segredos que não exigem alterações frequentes, usamos o Parameter Store:

• Para criar um segredo:

resource "aws_ssm_parameter" "secret_2" { 
  name = "/${var.app}/${terraform.workspace}/SECRET2" 
  type  = "String" 
  value = "blockchain-secret1" 
 }

• Para obter o segredo:

data "aws_ssm_parameter" "secret_2" { 
  name = "/${var.app}/${terraform.workspace}/SECRET2" 
 }

Por exemplo, usamos o segredo no bloco de ambiente da descrição da tarefa ECS.

5. Como usar o AWS Cognito para garantir autenticação e autorização

Para autorização e autenticação do cliente, nossa equipe de DevOps escolheu o AWS Cognito, por ser uma plataforma nativa da Amazon baseada em nuvem segura, escalável e econômica. Essa ferramenta fornece uma série de recursos para autorização e autenticação, incluindo:

• Gerenciamento de usuários e grupos
• Perfis de usuário
• Autenticação multifator
• Autenticação baseada em token
• E mais

O AWS Cognito também oferece APIs poderosas que permitem que os desenvolvedores se integrem a outros serviços, incluindo AWS Lambda, Amazon S3, Amazon Kinesis e Amazon DynamoDB. Além disso, o AWS Cognito simplifica a implantação de aplicativos em vários dispositivos, mantendo a segurança dos dados do usuário.

Para este projeto, criamos um módulo Terraform Cognito para nos ajudar a configurar de forma rápida e fácil um serviço de autorização e autenticação para os clientes do cliente. Para fazer isso, usamos o Terraform para criar e configurar o serviço Amazon Cognito. Este módulo oferece uma solução poderosa, mas altamente segura e fácil de usar que pode ser integrada com uma ampla gama de aplicativos e serviços.

Por exemplo, com o módulo Terraform Cognito, você pode criar contas de usuário seguras e implementar rapidamente a autenticação para seus clientes. Aqui estão alguns benefícios que este módulo oferece:

• Autenticação de usuário com seu provedor de identidade existente
• Autorização e autenticação seguras
• Funções e permissões de usuário personalizáveis
• Suporte para autenticação multifator
• Configurações de segurança atualizadas automaticamente
• Integração e gerenciamento automatizados de usuários
• Fácil integração com outros serviços e aplicações
• Gerenciamento e manutenção simples de contas de usuário

E aqui está o código que usamos para garantir a autenticação e autorização dos usuários com o módulo Terraform Cognito:

module "cognito_service1" { 
  source = "./modules/cognito_service1" 
 
  name = join("-", [var.app, "service1", terraform.workspace]) 
  cognito_resource_server_identifier1 = lookup(var.cognito_resource_server_identifier1, terraform.workspace) 
  cognito_resource_server_identifier2 = lookup(var.cognito_resource_server_identifier2, terraform.workspace) 
  allowed_oauth_scopes_client1
= lookup(var.allowed_oauth_scopes_client1, terraform.workspace) 
  allowed_oauth_scopes_client2
= lookup(var.allowed_oauth_scopes_client2, terraform.workspace) 
  callback_urls_service1_client1  
= lookup(var.callback_urls_service1_client1, terraform.workspace) 
  callback_urls_service1_client2  
= lookup(var.callback_urls_service1_client2, terraform.workspace) 
  user_pool_domain
= join("-", [var.app, "user-pool-service1", terraform.workspace]) 
  create_cognito_pool = true 
}

Para limitar o acesso a determinados recursos, usamos funções do IAM com um determinado conjunto de políticas.

6. Configurando a rede e criando grupos de segurança

A próxima etapa é criar uma rede e grupos de segurança para todos os serviços para cada ambiente. Para isso, utilizamos os módulos Terraform vpc e sg:

module "vpc" { 
  source       
= "./modules/network" 
  env          
= terraform.workspace 
  app          
= var.app 
  vpc_cidr     
= lookup(var.vpc_cidr_env, terraform.workspace) 
  public_subnet_number = 2 
  ecs_subnet_number
= 3 
  db_subnet_number 
= 3 
 
  region = var.aws_region 
} 
 
module "sg" { 
  source 
= "./modules/sg" 
  app    
= var.app 
  env    
= terraform.workspace 
  vpc_cidr_block = module.vpc.vpc_cidr 
  vpc_id 
= module.vpc.vpc_id 
  db_port
= var.db_port 
  whitelist_ips = { 
"DevOPS IP main1" : var.devops1 
"DevOPS IP main2" : var.devops2 
"Dev IP main1" : var.dev_ip1 
 
  } 
  whitelist_ips_service = { 
"DevOPS IP main2" : var.devops2 
"Dev IP main2" : var.dev_ip2 
  } 
  depends_on = [ 
module.vpc 
  ] 
}

7. Estabelecendo monitoramento e registro em log usando o CloudWatch

Para o monitoramento de recursos, usamos o CloudWatch — um produto da AWS que fornece uma variedade de serviços para monitorar aplicativos e sistemas e pode ser integrado a outros serviços da AWS. Essa ferramenta é econômica, fornece insights sobre o desempenho do sistema e ajuda a otimizar os recursos da AWS. Além disso, o CloudWatch oferece um nível gratuito; O custo da camada paga depende do número de métricas enviadas.

Cada elemento de infraestrutura tem seu próprio conjunto padrão de parâmetros do CloudWatch para controlar. Na documentação oficial, você pode encontrar instruções detalhadas para ALB, RDS e ECS.

No entanto, certos elementos não tinham saída padrão no CloudWatch, como os logs de determinados serviços executados no EC2. Para esses elementos, lançamos o agente do CloudWatch no EC2. Veja como fazer isso:

1. Execute o agente do CloudWatch ao iniciar o EC2 usando a linha em sudo yum install -y awslogsuser_dataaws_launch_configuration
2. Adicione a configuração do agente usando a documentação oficial:

sudo cat << EOF >> "/etc/awslogs/awslogs.conf" 
 [/var/log/messages] 
file = /var/log/messages 
log_group_name = /var/log/messages 
log_stream_name = {instance_id} 
datetime_format = %b %d %H:%M:%S 
EOF

8. Testando a infraestrutura blockchain

Depois de concluir a implantação da infraestrutura de blockchain baseada na AWS usando o Terraform, é hora de verificar se tudo funciona como deveria.

O teste é uma parte crítica de qualquer processo de desenvolvimento de infraestrutura. Na AWS, é particularmente importante testar a infraestrutura porque todos os serviços são interconectados e complexos. Se um único componente não funcionar corretamente, ele pode causar grandes problemas em todo o sistema. Além disso, é importante testar a infraestrutura para garantir que ela seja segura e atenda aos requisitos de desempenho e disponibilidade desejados.

O teste da infraestrutura na AWS envolve a execução de testes automatizados, que podem ajudá-lo a:

• Verifique se há inconsistências ou vulnerabilidades
• Verifique se todos os componentes estão funcionando conforme o esperado e se o desempenho e a disponibilidade atendem aos SLAs desejados
• Garantir que a infraestrutura seja escalável para que possa acomodar as mudanças na demanda
• Verifique se a infraestrutura está em conformidade com os requisitos regulamentares e de segurança relevantes

O teste da infraestrutura de blockchain criada pela AWS de nosso cliente envolveu as seguintes etapas cruciais:

1. Configure a infraestrutura de blockchain na AWS. Isso envolveu a criação de uma conta da AWS, a configuração de uma instância e o lançamento do nó do blockchain. Com a ajuda do Ansible, integramos novos nós de blockchain na infraestrutura existente do cliente e fizemos as mudanças necessárias.
2. Teste o desempenho da rede. Para fazer isso, usamos ferramentas de monitoramento, incluindo CloudWatch e Grafana, Kibana, Logstash e Prometheus, bem como a interface de linha de comando (CLI) para fins de depuração.
3. Implante contratos inteligentes. Após testes e depuração bem-sucedidos, usamos a CLI do blockchain para implantar contratos e aplicativos inteligentes e usamos o kit de desenvolvimento do blockchain para escrever e depurar contratos.
4. Monitore as transações no blockchain. Para fazer isso, usamos o explorador de transações blockchain.

O processo de teste é complexo e requer uma compreensão profunda dos aspectos técnicos da AWS e dos blockchains. Por exemplo, você precisa estar ciente dos desafios comuns que podem surgir durante o teste de aplicativos blockchain. Uma delas é a necessidade de ferramentas de teste projetadas especificamente para cada estrutura de blockchain. Usar a ferramenta errada pode impedir que você construa uma solução eficiente.
Além disso, preste atenção aos processos de garantia de qualidade, especialmente testes de segurança. Certifique-se de que suas soluções de blockchain e contratos inteligentes não apenas funcionem como pretendido, mas também atendam aos requisitos relevantes de segurança cibernética.

Conclusão

Ao projetar e implantar a infraestrutura de blockchain para sua solução, é essencial planejar cuidadosamente cada etapa. A adoção de metodologias de DevOps para a criação de uma infraestrutura blockchain com o Terraform na AWS oferece inúmeras vantagens, como maior eficiência, confiabilidade e escalabilidade ao criar e implantar recursos, bem como soluções de banco de dados seguras.

Na Apriorit, temos fortes equipes de desenvolvimento e teste de blockchain com experiência no fornecimento de produtos de sucesso para vários setores, incluindo bancos e finanças. Nossos especialistas em tecnologia estão prontos para ajudá-lo a criar uma infraestrutura robusta para seu projeto e gerenciar seus ambientes de nuvem.

Entre em contato conosco para discutir seu projeto de blockchain e comece a trabalhar nele!

Artigo Original