O blog da AWS
Criação de portais para desenvolvedores usando Backstage e Amazon EKS Blueprints
Por Riccardo Freschi, arquiteto sênior de soluções na AWS.
A complexidade dos ambientes contemporâneos de desenvolvimento de software levaram, nos últimos anos, à criação e adoção de plataformas internas de desenvolvedores (IDPs). O objetivo dos IDPs é diminuir a carga cognitiva dos desenvolvedores de software, que precisam usar um grande número de ferramentas e produtos para realizar seus trabalhos. Essa fragmentação causa mudanças de contexto demoradas e aumenta a curva de aprendizado para novos funcionários. Os IDPs resolvem essas desvantagens fornecendo um front-end unificado, onde as diferentes ferramentas e produtos são reunidos e disponibilizados ao desenvolvedor em um único catálogo.
O Backstage é um Portal do Desenvolvedor (DP – Developer Portal), criado no Spotify e teve seu código aberto em março de 2020. Os DPs servem como interface de usuário para explorar e acessar os recursos dos IdPs. Como DP, o Backstage centraliza os diferentes tipos de entidades em sua empresa, por exemplo: APIs, recursos, usuários, equipes, documentação etc. Ele também apresenta uma arquitetura extensível em que componentes adicionais de terceiros podem ser conectados e consumidos no mesmo contexto, como, por exemplo, o plugin do AWS Proton. O Amazon EKS Blueprints for CDK (chamado de Amazon EKS Blueprints, no restante da postagem) é um conjunto de módulos de infraestrutura como código (IaC) que ajuda você a inicializar clusters completos do Amazon Elastic Kubernetes Service (Amazon EKS), entre contas e regiões, de forma rápida e com o mínimo de código. Desenvolvido inicialmente na AWS, teve seu código aberto em abril de 2022. Os Add-ons são construções do Amazon EKS Blueprint, para ajudar você a gerenciar add-ons do Kubernetes, que são executados dentro do contexto de um cluster.
Esta postagem mostra como instalar e configurar o Add-on do Backstage para o Amazon EKS Blueprints, com a ajuda dos padrões do Amazon EKS Blueprints. O Add-on permitirá efetivamente que você instale a aplicação Backstage em seu cluster Amazon EKS recém-implantado. Você poderá acessar o Backstage por meio de um Amazon Elastic Load Balancer (Amazon ELB). Esta postagem não aborda uma integração mais estreita entre o Amazon EKS Blueprints e o Backstage, por exemplo, para exibir e controlar ambientes, status do pipeline, integração de equipes, etc., que é um assunto para desenvolvimento futuro.
Visão geral da solução
O diagrama a seguir mostra a solução completa que apresentaremos neste post:
Você precisará de uma imagem Docker pré-construída do Backstage, configurada como achar melhor, por exemplo, com os plugins de sua escolha. Você pode ver detalhes técnicos sobre como realizar essa etapa e as próximas na seção “Implantar Backstage” desta postagem.
O padrão Backstage irá cobrir:
- Implantar essa imagem em um novo cluster do Amazon EKS
- Criar uma nova instância do Amazon Relational Database Service (Amazon RDS) para PostgreSQL na VPC do cluster Amazon EKS
- Configurar as credenciais do banco de dados acima como um segredo no AWS Secrets Manager
- Criar um External Secret refletindo as credenciais do banco de dados
- Criar um segredo do Kubernetes a partir do External Secret, para ser carregado pelo Backstage como variáveis de ambiente $POSTGRES_USER e $POSTGRES_PASSWORD
- Instalar o add-on do AWS Load Balancer Controller, que implantará um Application Load Balancer (ALB), implementando as regras listadas no Backstage Helm Chart Ingress
- Criar um certificado para o ALB
Pré-requisitos
Você precisará do seguinte para concluir as etapas desta postagem:
- Uma conta da AWS
- aws-cli, configurado
- Make
- Node.js
- npm
- Docker
- AWS Cloud Development Kit (CDK), inicializado na conta e região selecionadas
Você também precisará de um nome de domínio, mantido em uma das zonas públicas hospedadas do Amazon Route 53, semelhante à imagem da AWS Management Console mostrada abaixo:
Clonar o Amazon EKS Blueprints Patterns
Abra sua interface de linha de comando (CLI) favorita e clone o repositório EKS Blueprints Patterns no GitHub:
$ git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git
Implementar o Backstage
Siga as instruções do arquivo Backstage na pasta docs no repositório EKS Blueprints Patterns. Aqui está um resumo das etapas que você precisa seguir:
- Crie o aplicativo Backstage e construa a imagem do Docker
- Crie um Amazon Elastic Container Registry (Amazon ECR) e um repositório
- Faça o upload da imagem do Docker para o repositório recém-criado
- Defina a conta e a região como parte do seu perfil da AWS CLI e insira os parâmetros necessários no contexto do CDK:
Parâmetro | Descrição |
---|---|
backstage.namespace.name |
Namespace Kubernetes para implantar o Backstage, por exemplo, “backstage“ |
backstage.image.registry.name |
Seu registro de imagens, por exemplo, Amazon Elastic Container Registry (ECR): “{account} .dkr.ecr. {region} .amazonaws.com”, |
backstage.image.repository.name |
O repositório no registro acima, por exemplo: “backstage“ |
backstage.image.tag.name |
A tag da sua imagem do Backstage, por exemplo: “latest“ |
backstage.parent.domain.name |
Seu nome de domínio, sob o qual um subdomínio e um certificado relacionado serão criados, por exemplo: “exemplo.com“ |
backstage.subdomain.label |
O label que será usado para criar o subdomínio a ser atribuído ao Backstage, por exemplo: “backstage“; o subdomínio final será então, por exemplo: “backstage.example.com“ |
backstage.hosted.zone.id |
A sequência de 20 caracteres, representando a Zona Hospedada no Route 53, contendo seu nome de domínio |
backstage.certificate.resource.name |
O nome a ser atribuído ao seu recurso de certificado, por exemplo: “backstage-certificate“ |
backstage.database.resource.name |
O nome a ser atribuído ao seu recurso de banco de dados, por exemplo: “backstage-database“ |
backstage.database.instance.port |
A porta a ser atribuída ao novo banco de dados Backstage, por exemplo: 5432 |
backstage.database.secret.resource.name |
O nome a ser atribuído ao recurso secreto (usado como referência no CDK), por exemplo: “backstage-database-credentials“ |
backstage.database.username |
O nome de usuário do banco de dados, por exemplo: “postgres“ |
backstage.database.secret.target.name |
O nome a ser atribuído ao segredo no manifesto do Kubernetes, por exemplo: “backstage-database-secret“ |
- Implante conforme explicado na documentação de padrões do Amazon EKS Blueprints.
Finalmente, em um navegador da Web, navegue até {"parent.domain.name"}. {"subdomain.label"}
. Você verá uma tela semelhante à seguinte, dependendo da configuração do aplicativo Backstage:
Análise de código
É importante observar que o add-on do Backstage está hospedado no repositório Amazon EKS Blueprints, enquanto o Backstage Pattern, que demonstra como configurar o add-on e implantar os recursos necessários, está hospedado no repositório Amazon EKS Blueprints Patterns.
O add-on se baseia no Helm Chart do Backstage, hospedado publicamente no GitHub, onde você pode encontrar uma explicação detalhada dos chart values.
Por meio dos valores, precisamos configurar o Helm Charts da seguinte forma:
- Defina os parâmetros do Ingress
- Forneça as coordenadas da imagem Docker do aplicativo Backstage
- Passe para o aplicativo Backstage:
- o subdomínio que pretendemos atribuir
- o endpoint do banco de dados e as variáveis de ambiente, que posteriormente serão definidas para os valores das credenciais do banco de dados
- o nome do segredo, contendo os valores reais das credenciais do banco de dados
A configuração mais notável do Ingress é o Amazon Resource Name (ARN) do certificado.
Estamos usando o PostgreSQL, em oposição ao banco de dados SQLite padrão na memória, para obter melhor escalabilidade, simultaneidade, centralização e controle (acesse o guia Backstage para obter mais detalhes). Suas credenciais são injetadas nos pods do aplicativo Backstage por meio de variáveis de ambiente, extraídas do segredo. O chart obtém as informações sobre o nome do segredo a partir do valor Backstage.extraEnvVarsSecrets
e as define na seção envFrom
do manifesto de implantação do Kubernetes:
Portanto, os parâmetros esperados pelo Add-on são:
O padrão fornece as dependências do add-on.
Um provedor de recursos (DatabaseInstanceCredentialsProvider)
cria e armazena as credenciais do banco de dados no AWS Secrets Manager (ASM).
Um segundo provedor de recursos (DatabaseInstanceProvider)
cria uma instância de banco de dados Amazon RDS para PostgreSQL dentro do cluster VPC, pega o nome secreto do ASM do contexto e passa para o banco de dados, na criação.
Um add-on (BackstageSecretAddon)
, aproveitando o External Secrets Add-On, cria um objeto ClusterSecretStore
, apontando para o ASM, e um ExternalSecret
, que extrai as credenciais do ASM e as injeta em um novo Kubernetes Secret, com as chaves POSTGRES_USER
e POSTGRES_PASSWORD
:
Como explicamos anteriormente, as credenciais mantidas no segredo são então passadas para os pods como variáveis de ambiente $POSTGRES_USER
e $POSTGRES_PASSWORD
.
Um terceiro provedor de recursos (CreateCertificateProvider)
cria o subdomínio na zona hospedada do Amazon Route 53 e o certificado relacionado no AWS Certificate Manager (ACM):
O certificado é então obtido pelo add-on do Backstage a partir do contexto, e seu ARN extraído…
… e atribuído ao Ingress:
setPath(values, "ingress.annotations", annotations);
Na seção Route 53 da AWS Management Console, os novos registros do subdomínio serão mostrados, semelhantes a esta captura de tela:
O certificado aparecerá na seção AWS Certificate Manager:
O que eu posso fazer agora?
O Backstage fornece um único painel para visualizar os recursos da sua organização, independentemente de sua localização, bem como uma maneira simples de integrar e começar a usar ferramentas de desenvolvimento. Ele também permite que você crie novos recursos, como aplicativos de back-end e front-end, com mais facilidade, a partir de seu portal.
Agora que você tem sua plataforma de desenvolvedor configurada, você pode aproveitar esses benefícios e começar criando um catálogo de software. Um Software Catalog permite que você acompanhe a propriedade e os metadados de todo o software em seu ambiente (serviços, sites, bibliotecas, pipelines etc.) em um local centralizado. O catálogo é criado a partir de arquivos YAML de metadados armazenados no source control, que são registrados no Backstage de várias maneiras e apresentados ao desenvolvedor em uma visão abrangente.
Outro recurso que você talvez queira explorar são os Software Templates, que permitem que as equipes de engenharia construam componentes e criem rapidamente novos projetos alinhados às melhores práticas da equipe. Isso os ajuda a evitar a necessidade de reinventar a roda, ter menos decisões a tomar e permite que eles se concentrem mais nas atividades principais. Os modelos de software são fundamentais para o conceito de Golden Paths, que são formas opinativas e apoiadas de criar algo (por exemplo, um serviço de back-end, uma aplicação web ou um pipeline de CI/CD). Em vez de legislar convenções e padrões, com o Golden Paths, você pode facilitar que as equipes iniciem novos projetos com da melhor forma possível.
Outro exemplo do que você pode fazer é criar documentação com o TechDocs. Isso permite que você escreva arquivos Markdown armazenados no mesmo local do código ao qual estão relacionados. Esses arquivos são então exibidos de forma limpa e clara no Backstage.
Consulte o site do Backstage para obter documentação detalhada e exemplos de recursos e casos de uso.
Cleaning Up
Para evitar cobranças futuras, execute o comando:
make pattern backstage destroy
Conclusão
Neste post, mostramos como você pode usar o add-on do Backstage do Amazon EKS Blueprints e o Backstage Patterns do Amazon EKS Blueprints Patterns para implantar um aplicativo Backstage pré-construído e pré-configurado. Explicamos os parâmetros de configuração padrão e como esse padrão conecta provedores de recursos e outros add-ons para obter uma solução completa executando o Backstage com suas dependências.
Esse artigo foi originalmente publicado em inglês no AWS Blog (link aqui).
Autores
![]() |
Ricardo Freschi é arquiteto sênior de soluções na AWS, com foco na modernização de aplicações. Ele trabalha em estreita colaboração com parceiros e clientes para ajudá-los a transformar seus cenários de TI em sua jornada para a nuvem da AWS, refatorando aplicativos existentes e criando novos, de forma nativa na nuvem. |
Tradutores/Revisores
![]() |
Bruno Lopes é Sr. Specialist Solutions Architect na AWS LATAM. Com mais de 17 anos de experiência em TI, é especialista na modernização de aplicações legadas. Sua experiência abrange ambientes híbridos e capacitação técnica como Technical Trainer e Evangelista. Como Arquiteto de Soluções, simplifica a adoção de tecnologias avançadas, auxiliando clientes a superar desafios diários com soluções inovadoras. |
![]() |
Karine Ferrari é arquiteta de soluções na AWS com experiência em clientes SMB e Financial Services. Com 15 anos de experiência na área de tecnologia da informação atuando em instituições de grande porte e nos últimos 4 anos atua com arquitetura para projetos em cloud e modernização de aplicações. Possui experiência em implementar e fornecer documentações, guias e experimentações com intuito de evangelizar e apoiar as equipes de negócios para utilização de microserviços, APIs, mensageria, eventos e banco de dados em projetos em nuvem. |