Como automatizar a instalação de agentes em instâncias EC2 Windows na AWS

Bruno Lopes, Sr. Solutions Architect Specialist, Microsoft Workloads on AWS

Automatizar processos repetitivos e rotineiros não é mais um luxo, mas sim uma necessidade básica de qualquer time de sysadmin. Não só pela praticidade conferida pelas ações automatizadas, mas também por evitar falhas humanas, falta de padronização e até mesmo melhorar a postura de governança dentro das organizações de TI.

Na Nuvem não é diferente. Inclusive, ela oferece diversas opções para que você otimize a forma como você automatiza seus processos. Porém, com tantas opções disponíveis, pode ficar complicado decidir qual se encaixa melhor com a sua necessidade e ambiente.

Abaixo podemos observar algumas das principais opções que a AWS oferece aos seus clientes e um breve comparativo:

* Para pacotes com attachments acima de 1GB e tamanho total maior que 20GB, recomendo a utilização do Run Command no próprio Systems Manager.

O cenário descrito aqui se propõe a automatizar o processo de instalação de quaisquer tipos de agentes para ambientes com servidores Windows, levando em consideração que o parque computacional pode estar em processo de provisionamento e/ou migração, ou já estar ativo na AWS. Levando em consideração que agentes são recursos necessários para uma comunicação cliente -> servidor em diversos tipos de cenários, como monitoração, backup, segurança, migração e vários outros.

Visão geral da solução

Como resultado proposto para este roteiro, vamos focar em duas soluções: uma delas usando o EC2 User Data e a outra usando o Systems Manager (SSM) Distributor, uma vez que são as opções descritas na tabela acima como as que requerem menor esforço para o uso. Essas duas opções também cobrem diferentes necessidades dos ambientes, tanto na automação como parte do provisionamento e/ou migração de novos servidores, quanto também para a gestão de ambientes já existentes.

O Distributor, um recurso do AWS Systems Manager, ajuda você a empacotar e publicar software para nós gerenciados do AWS Systems Manager. Você pode empacotar e publicar seu próprio software ou usar o Distributor para encontrar e publicar pacotes de software de agentes fornecidos pela AWS, como o AmazonCloudWatchAgent, ou pacotes de terceiros, como Trend Micro.

Para o fim deste post, usaremos o agente do Amazon CloudWatch, que inclusive pode ser utilizado para monitoração de servidores fora da AWS, como por exemplo servidores on-premises ou em outros Cloud Service Providers, como no Azure ou Google Cloud. A instalação do agente do CloudWatch estende a capacidade de monitoração padrão, adicionando outras métricas e até mesmo suportando customizações e logs de aplicações.

Passos para a configuração

Para esses passos, serão necessárias algumas configurações prévias, como por exemplo no AWS IAM, afim de criar as Roles e Políticas específicas que serão usadas para correto provisionamento das permissões necessárias.

Reforçando que o foco é sempre atuar no conceito do “mínimo privilégio necessário”, afim de melhorar sua postura de segurança dentro de qualquer arquitetura computacional. Para estes exemplos, usamos AWS Managed Policies, políticas já criadas e configuradas pela AWS. Mas você pode também trabalhar com as Customer Managed Policies, onde a customização pode lhe fornecer um cenário mais eficaz ainda, com Conditions e granularidades que se encaixem com suas regras de Governança.

EC2 User Data

Ao executar uma instância do Windows no Amazon EC2, é possível passar o User Data para a instância, que usará essas informações para realizar tarefas de configuração automatizadas ou executar scripts após a inicialização da mesma. As informações do User Data da instância são tratados como dados encapsulados, ou seja; cabe à instância interpretá-los. As informações do User Data são processadas pelo EC2Launch v2 (AMIs compatíveis ou por download), pelo EC2Launch no Windows Server 2016 e versões posteriores e pelo EC2Config no Windows Server 2012 R2 e versões anteriores.

Para que o EC2Config ou o EC2Launch execute scripts, será necessário adicionar ao script uma tag especial ao adicioná-lo User Data. A tag usada depende dos comandos a serem executados em uma janela de Prompt de Comando (batch script) ou usando o Windows PowerShell.

Por padrão, os scripts do User Data são executados uma vez ao inicializar a instância. Para executar os scripts do User Data sempre que você reiniciar ou iniciar a instância, adicione <persist>true</persist> aos dados do usuário.

Abaixo, um exemplo de um script utilizando a tag <powershell>, com a automação da instalação do agente do Amazon CloudWatch.

<powershell>
$dir = $env:TEMP + "\cwagent"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi", $dir + "\amazon-cloudwatch-agent.msi ")
Start-Process .\amazon-cloudwatch-agent.msi -Wait
</powershell>

SSM Distributor

Antes de começar a usar o Distributor, um dos componentes do AWS Systems Manager, é importante que você siga os passos abaixo, afim de que os requisitos necessários sejam satisfeitos para um correto funcionamento.

Passo 1: Requisitos básicos para uso do Systems Manager: IAM Roles e SSM Agent

Como falamos anteriormente, o agente do Systems Manager já vem previamente instalado nas AMIs oferecidas pela AWS, o que torna o uso do SSM Distributor muito mais facilitado. Com isso, um dos requisitos que seria a instalação do SSM Agent já não nos preocupa mais.

Podemos partir então para a segunda parte deste passo; a configuração da IAM Role, que será utilizada no EC2 Instance Profile. Pra quem não conhece, o Instance Profile é o recurso que permite “passar” uma IAM Role para uma instância EC2, e com isso evitar que sejam necessários Access Keys/Secrets Keys ou até mesmo usuários e senhas para interação com os recursos da AWS.

Depois de criar a IAM Role e associar à instância desejada, será necessário também incluir permissões que permitam que o Systems Manager possa ser executado na sua instância. Outras permissões podem ser necessárias, dependendo do nível de utilização que você planejar para o seu cenário. Para fim deste blog, usaremos AWS Managed Policies sugeridas para o Systems Manager. Como citamos anteriormente, dê preferência para Customer Managed Policies.

Escolhemos uma política específica para o SSM, e as outras duas para o CloudWatch, uma vez que é parte do recurso que desejamos configurar para este cenário.

Como podemos ver na imagem acima, as três políticas estão anexadas na IAM Role que foi criada e vinculada à instância EC2.

Passo 2: Criar ou selecionar o bucket do Amazon S3

O Distributor solicitará um bucket do Amazon S3 no momento de criação do pacote de instalação. O bucket usado para configuração do SSM Distributor é meramente temporário, e só é necessário até que o pacote seja finalizado. Após isso, o Distributor faz upload dos dados para o armazenamento interno do SSM, e o bucket pode ser reutilizado para outra finalidade ou até mesmo removido.

Passo 3: Criar o pacote no Distributor

Na console AWS é possível encontrar o Distributor dentro dos componentes do Systems Manager, na seção Node Management do menu esquerdo. Após isto, você verá diversos pacotes já existentes, fornecidos pela AWS ou até mesmo por terceiros.

Nós desejamos criar o nosso próprio pacote. Para isso, selecionamos a opção “Create Package”. Após isso, nos deparamos com duas opções: Simple e Advanced. Na Simple, o próprio Distributor ficará encarregado de criar os scripts de instalação e desinstalação padronizados, e também escreverá os manifestos do pacote de deployment. Já na opção Advanced teremos que fazer tudo isso manualmente, e ao final disponibilizar em forma de um arquivo .zip para o Distributor, contendo todos os arquivos de instalação, desinstalação e manifesto (vide imagem abaixo). Se quiser saber mais detalhes sobre o modo Advanced, veja nesta documentação de referência.

Vamos seguir com a opção Simple.

Logo após, iremos escolher o bucket do S3 que será usado no processo. Lembrando que este bucket é temporário, e depois que o pacote estiver criado, pode ser esvaziado ou até mesmo deletado.

Agora, faremos o upload do software, para que ele possa prosseguir com a criação do pacote de instalação. Lembrando que para este processo, apenas arquivos do tipo msi, deb ou rpm são suportados. Para o cenário de servidores Windows, trabalharemos com msi. Se você tem um .exe como parte do seu agente a ser instalado, pesquise sobre alternativas para converter seu .exe em um .msi. Há diferentes formas de fazer, e inclusive ferramentas que podem te ajudar nisto.

Nesta seção há um ponto muito interessante, que é a possibilidade de customizar scripts para execução em conjunto com a sua instalação. Por padrão, ele traz a instrução msiexec /i amazon-cloudwatch-agent.msi /quiet como script de instalação padrão, e a instrução msiexec /x amazon-cloudwatch-agent.msi /quiet como script de desinstalação. Você pode customizar isso, de acordo com a suportabilidade do software que você está utilizando, e até mesmo com instruções via batch script ou PowerShell. Consulta a documentação de cada produto para saber mais.

Por fim, a criação do manifesto é feito de forma automática pelo Distributor. O manifesto pode ajudar na organização de pacotes que são configurados para múltiplos sistemas operacionais e arquiteturas, tornando melhor ainda a gestão da sua infraestrutura e Governança.

Agora, basta clicar na aba “Owned by me” e selecionar o pacote que deseja instalar. Depois de criar um pacote no Distributor, você poderá instalar o pacote de uma das seguintes formas:

• Uma vez, usando AWS Systems Manager Run Command
• De forma periódica, usando AWS Systems Manager State Manager

Após finalizado, podemos conferir a instalação do agente no Painel de Controle do Windows.

Conclusão

Vimos neste blogpost algumas das opções existentes na AWS para automação de atividades comuns na rotina de um sysadmin, como por exemplo a instalação de agentes e softwares em servidores. Vimos que existem diferentes formas de alcançar este objetivo, e que também algumas delas envolvem um cenário de maior complexidade e esforço para alcançar o objetivo. Neste post também vimos o passo-a-passo para executar duas dessas formas em nossos ambientes: EC2 User Data e SSM Distributor.

Sobre o autor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Revisores

Diego Voltz atua como Arquiteto de Soluções Senior no seguimento de Enterprise na AWS. Ele atuou por 17 anos como CTO de Startups no seguimento de Web Hosting e Health, tendo como foco virtualização, Storage e Containers. Hoje ajuda os clientes da AWS na jornada de adoção da nuvem e na otimização dos custos.

Carlos Felicio é Senior Partner Technical Account Manager da AWS LATAM. Atua no mercado de tecnologia nos últimos 22 anos. No seu portfólio trabalhou em diversas consolidações e migrações em ambientes híbridos com workloads Microsoft. No momento trabalha como TAM auxiliando os parceiros em dúvidas e utilização da AWS para prover melhor benefício nos workload dos seus clientes