Conversation
Trabalho inicial do RFC-001: Migração do bot da agenda para a Azure
Proposta da nova configuração dos módulos Terraform e descrição dos pipelines de CI/CD.
rfcs/RFC-001.md
Outdated
| ### iac-mentoria-bots | ||
|
|
||
| `iac-mentoria-bots` será o repositório raiz que irá definir a infraestrutura | ||
| base e consumir os outros módulos. Nesse repositório será criado o resource | ||
| group ([`azurerm_resource_group`][azurerm_resource_group]) onde os outro | ||
| recursos dos bots serão definidos, os App Service Plans | ||
| ([`azurerm_app_service_plan`][azurerm_app_service_plan]) necessários para | ||
| rodar os bots e um servidor PostgreSQL | ||
| ([`azurerm_postgresql_server`][azurerm_postgresql_server]) que poderá ser | ||
| compartilhado entre os bots. |
There was a problem hiding this comment.
IMHO seria legal colocar tudo de iac do bots dentro do repo de bot e evitar criar um repo só pra isso.
There was a problem hiding this comment.
Então teria um repo de bot com tudo dentro? Tipo código fonte, Dockerfile, configurações do Terraform etc?
There was a problem hiding this comment.
@lgfa29 já tem o repo: https://github.com/mentoriaiac/bot-discord-mentoria-agenda
A ideia era usa isso como repo de produto.
There was a problem hiding this comment.
Mas esse repo é só para o bot de agenda né? O iac-mentoria-bots teria a infraestrutura compartilhada entre vários bots. Acho que faltou explicar o que cada coisa da Azure faz, mas a infra final ficaria tipo assim:
Esse Resource Group e App Service Plan pode ser compartilhados entre vários apps (bots).
O que a gente pode fazer para deixar o código de produto e infra junto é usar data source. Então o iac-mentoria-bots cria a parte compartilhada e o bot-discord-mentoria-agenda teria algo assim:
bot-discord-mentoria-agenda
├── infra
│ └── main.tf
├── README.MD
└─── src
└── bot.py
...
Aí o main.tf nesse repo seria algo assim:
data "azurerm_resource_group" "mentoria_bots" {
name = "mentoria-bots"
}
data "azurerm_app_service_plan" "mentoria_bots" {
name = "mentoria-bots"
resource_group_name = data.azurerm_resource_group.mentoria_bots.name
}
module "bot_agenda" {
source = "github.com/mentoriaiac/iac-modulo-app-service-docker.git?ref=v0.1.0"
name = "bot-agenda"
image = "metoria-iac/bot-agenda:1.0.0"
resource_group_name = azure_resource_group.bots.name
app_service_plan_id = azurerm_app_service_plan.bots.id
app_settings = {
"KEY" = "value"
}
}Então o bot de agenda teria uma pipeline separada de outros bots, o que parece ser uma boa 🙂
There was a problem hiding this comment.
Isso funciona perfeito pra mim ;) Como nova sugestão com base nisso, eu chamaria esse repo compartilhado de "iac-plataforma-bots" ao invés de "iac-mentoria-bots" não precisa ter mentoria no nome, já que a org seria de mentoria ;) O que acha?
There was a problem hiding this comment.
Boa! Vou atualizar o texto com essas sugestões. Valeu!
O código-fonte do bot de agenda foi autualizado de forma que não será mais necessário um banco de dados, então o RFC-001 não precisa mais descrever como o serviço de PostgreSQL será utilizado.
Inicialmente o repositório do módulo de App Service descrito no RFC-001 era chamado `iac-modulo-bot-docker`, mas não é preciso deixar específico para bots, já que é possível usar o mesmo módulo para outros tipos de aplicativos. O módulo agora irá ser chamado `iac-modulo-app-service-docker`.
Usando sub-pastas para as RFCs permite que cada documento possua suas próprias imagens. A primeira imagem criada é para a arquitetura da Azure na RFC-001.
Usar o mesmo repo para infra e código-fonte permite a melhor integração de deploy e controle sobre a zona de impacto de mudanças.
Adicionando mais detalhes de como irão ficar os pipelines de deploy dos bots.
| Quando o PR for aprovado e a branch for integrada à `main`, o pipeline de CD | ||
| para staging será iniciado. Esse pipeline irá construir a imagem Docker e | ||
| publicá-la no Docker Hub usando a versão curta (7 caracteres) do SHA do commit. | ||
| Depois de publicada, o arquivo de variáveis será editado para atualizar a | ||
| variável `image_staging_tag` para o valor da nova tag. Essa modificação irá ser | ||
| integrada de volta ao repositório através de um commit e push para manter o | ||
| registro de alteração da infraestrutura. A configuração do Terraform será então | ||
| aplicada para atualizar o slot de staging na Azure. | ||
|
|
||
| O pipeline de produção será parecido, mas irá ser iniciado a partir da criação | ||
| de uma tag de release. A imagem Docker será criada e publicada no Docker Hub | ||
| usando a tag git como tag da imagem. A variável `image_prod_tag` será | ||
| atualizada para esse novo valor e a aplicando a configuração do Terraform irá | ||
| atualizar o slot de produção na Azure. |

O Discord da Mentoria IaC possui um bot que auxilia no agendamento de reuniões. Atualmente esse bot roda no Heroku mas vamos trabalhar para migrá-lo para a Azure usando o App Service e o serviço de PostgreSQL.
Texto renderizado.