# Do zero à automação com GitHub Actions em 7 minutos Como começar do 0 e automatizar toda a sua pipeline de containers em menos de 7 minutos! Tudo com GitHub Actions - URL: https://blog.lsantos.dev/do-zero-a-automacao-de-containers-em-5-minutos/ - Published: 2020-05-08 - Updated: 2026-07-16 - Category: technology - Tags: containers, infrastructure, ci, azure, github - Language: pt - Author: Lucas Santos --- Em um [artigo anterior](https://dev.to/azure/construindo-e-publicando-um-backend-graphql-completo-sem-escrever-uma-linha-de-codigo-g40), comentei como poderíamos criar um backend GraphQL completo apenas usando uma imagem Docker e um arquivo de configuração. Tudo isso hospedado no [Azure](https://docs.microsoft.com/azure/container-instances/?WT.mc_id=blog-devto-ludossan). Agora vamos aprender a automatizar os deploys que são feitos para a nossa hospedagem e a atualização automática do nosso backend! Este projeto todo visa criar um backend para meu futuro arquivo de conteúdo que estará presente no [meu site](https://lsantos.dev/). Mas sempre que eu atualizar o backend ou mudar o schema do GraphQL vou ter que fazer todo o deploy do serviço novamente. Então, ao invés disso, eu gostaria que, a cada push no meu branch master, eu gerasse uma nova versão do arquivo e enviasse a atualização para o [Azure](https://portal.azure.com/?WT.mc_id=blog-devto-ludossan). Porém eu não quero ter que usar outras ferramentas para isso, quero manter toda a stack o mais simples possível, como estamos utilizando somente o GitHub e o [Azure](https://portal.azure.com/?WT.mc_id=blog-devto-ludossan), nada mais justo do que continuar no GitHub para fazer a automação, não é mesmo? Por isso que vamos usar os [**GitHub Actions**](https://azure.microsoft.com/blog/github-actions-for-azure-is-now-generally-available/?WT.mc_id=blog-devto-ludossan) Similar a outros provedores de CI como o Travis ou o Circle, o GitHub também possui um sistema de integração e automação do repositório. A facilidade deste sistema em relação aos outros é que você já está dentro do mesmo repositório e ja está dentro da mesma ferramenta. O projeto que vamos utilizar para automatizar será o [meu repositório publico de backend](https://github.com/khaosdoctor/site-backend): ![](./0-h2hisw4sxqkq0-ck-23eed9.png) Veja que o repositório é super simples, não contém muitos arquivos, apenas um `docker-compose.yml` para testes locais e o nosso arquivo `yml` do `mongoke` que será o schema GraphQL. No topo da página, ao lado de settings, temos o botão `Actions`, será lá que vamos configurar a nossa automação! ![](./0-tmzfh1snxaxb4aji-b6ce13.png) O GitHub já possui uma série de workflows prontos, porém, infelizmente, ainda não temos nenhum para o que queremos fazer. Mas o que queremos fazer? Para deixar tudo mais claro, vamos listar todas as etapas do processo: 1. Recebemos um push na branch `master` 2. Conectamos com a [Azure](https://portal.azure.com/?WT.mc_id=blog-devto-ludossan) através de um [service principal](https://docs.microsoft.com/azure/app-service/deploy-github-actions?WT.mc_id=blog-devto-ludossan#create-a-service-principal) e de uma action chamada [Azure/login](https://github.com/Azure/login) 3. Depois vamos utilizar a action [Azure/cli](https://github.com/Azure/CLI) para poder executar o comando de deploy do nosso container Alguns detalhes que temos que perceber: - O cache do GitHub Pages é um pouco longo, então vamos ter que gerar um número aleatório ou uma fingerprint para colocar na URL do nosso arquivo YAML do Mongoke - Temos uma URI do MongoDB que deve ser um segredo ## Criando um secret Primeiramente vamos tratar das nossas dependências, a dependência mais fácil de ser resolvida é criar a URL do MongoDB como um secret. Para isso vamos até a nossa aba `Settings` e clicamos em `Secrets`. Basta adicionar um novo secret clicando no link `Add new Secret` e preencher um nome e o conteúdo do mesmo. No caso estamos adicionando a URI do MongoDB, então vamos chamar este secret de `MONGODB_URI` ![](./0-tdihpbbgiwg-3u2-5c517d.png) ## Permitindo ações na Azure Para que possamos permitir que o GitHub execute ações em nosso nome na [Azure](https://portal.azure.com/?WT.mc_id=blog-devto-ludossan), vamos precisar criar um [Service Principal](https://docs.microsoft.com/azure/app-service/deploy-github-actions?WT.mc_id=blog-devto-ludossan#create-a-service-principal). Este recurso nos dá uma conta de aplicação para que possamos permitir que outras pessoas ou serviços conectem-se em nosso portal e realize ações em nosso nome. Para criarmos este recurso, vamos usar o [Azure CLI](https://docs.microsoft.com/cli/azure/install-azure-cli?view=azure-cli-latest&WT.mc_id=blog-devto-ludossan). Depois de realizar o login com o comando `az login`, basta executar o seguinte comando: [Embedded content] Para obter o ID da sua subscription basta executar o comando `az account list` e buscar a chave `id` da subscription que estiver com a chave `isDefault` marcada como `true`. Você também pode dar qualquer nome ao seu Service Principal, faça com que ele seja descritivo para saber a quem você está garantindo permissões. Por último, outro detalhes importante é somente dar as permissões aos recursos necessários, ou seja, não vamos criar um SP para a conta **TODA**, mas sim somente para o _Resource Group_ que precisamos, no meu caso, este RG se chama `personal-website` e é onde eu estou agrupando todos os recursos relativos ao meu site. Este comando deve dar uma resposta em JSON do tipo: [Embedded content] Copie toda essa resposta e crie um novo secret no GitHub chamado `AZURE_CREDENTIALS`: ![](./0-oq5qyamor7ac7i1q-057f23.png) Agora devemos ter dois secrets criados: ![](./0-q-riyelrwfa3zxtu-cde0bd.png) ## Criando um workflow Para criarmos o nosso primeiro workflow, basta voltarmos para o painel `Actions` ao lado de `Settings` e clicar no botão `Set up this workflow`: ![](./0-diywmxg2tpj82sm1-a23185.png) Esta ação deve levar para uma nova tela com um modelo inicial do código: ![](./0-v0jnclx9rai2sarx-7a0528.png) Perceba que as GitHub Actions nada mais são do que um arquivo YAML que ficam em uma pasta `/.github/workflows` e este será o nome do workflow, portanto é importante que ele seja bastante descritivo. Vamos dar o nome do nosso de `publish-prod.yml`: ![](./0-i8b-fwsttrzuktlv-7920bd.png) O conteúdo que temos é o seguinte: ![](./1-zexvrp9-lvoptwg5oyzmcq-0d266a.png) Primeiro, vamos setar um nome para nosso workflow, este será o nome que aparecerá na UI do GitHub, então podemos deixar um pouco mais bonito: ![](./1-jc3jshv1vu5yravs8zhofq-c72694.png) Agora vamos definir em qual tipo de ação queremos que ele rode. Como queremos que ele rode em qualquer push ou PR no branch `master`, não vamos fazer nenhuma alteração, mas se precisássemos alterar esta ação, teríamos que mudar a chave `on`. Para verificar quais são as ações disponíveis, basta clicar no editor e apertar `ENTER` que um _intellisense_ será mostrado:[^n1] ![](./0-bxe5hg2b5h7kil7s-024031.png) Então vamos criar uma seção para compartilhar variáveis de ambiente e conteúdos que vamos usar na parte mais a frente do nosso script, por exemplo, o nome do container e também o nome do resource group. Para isso criamos um bloco `env`: ![](./1-c-ttd9itkom4cref-j8i6g-f4c3aa.png) Agora vamos, de fato, criar a máquina e o que chamamos de `runner`, que é quem vai rodar o nosso código de testes e de publicação. Todo o workflow é composto de um ou mais jobs que podem ser executados sequencialmente ou em paralelo. No nosso caso não temos que fazer muita coisa, apenas conectar e fazer o deploy. Portando vamos modificar a seção `jobs`: ![](./1-d2e42tjpqiis6nkobjbm8w-2c2146.png) Iremos rodar nosso job em uma imagem do Ubuntu, veja as demais opções [na documentação](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on). Depois disso vamos configurar os nossos `steps`, um step é uma sequencia de tarefas que serão executadas como partes de um `job`, ou seja, aqui será o lugar onde vamos executar o nosso login e o nosso deploy! Para isso vamos modificar a chave `steps` e vamos remover todo o conteúdo, então vamos utilizar os steps pré prontos da Azure para poder fazer o login! Podemos pesquisar na caixa de texto lateral por `Azure/login`: ![](./0-4bbsyavjq9jdtefl-b2ce5c.png) Ao clicar no nome do step, vamos ter um tutorial de como usá-lo, neste caso é bastante simples, basta copiarmos o seguinte código para dentro do nosso step: ![](./1-fxk7z3x6sywzaanhprjx2a-48c5c5.png) E será aqui que vamos setar o nosso primeiro secret, precisamos do `AZURE_CREDENTIALS` que criamos anteriormente para poder prover as credenciais de acesso para o login. Para usar um secret basta colocá-lo entre chaves duplas como em: `${{ secrets.AZURE_CREDENTIALS }}`. Nosso arquivo está assim: ![](./1-dgzjwlvnondqne0lielzuq-4b3b72.png) Vamos criar um segundo step que vamos chamar de `Deploy ACI`, que será aonde vamos executar o nosso comando do Azure CLI. Para isso vamos utilizar outro step com o comando `run` que vai conter a linha que vamos executar em nosso CLI. Em nosso a caso, já com as variáveis substituídas, será esta: ![](./1-yiclmwwzalr7io2ws26cla-cd19ca.png) Vamos observar bem a última parte onde criamos a variável `MONGOKE_CONFIG_URL`, esta variável sozinha não vai ser suficiente, temos que concatená-la com o valor do SHA do commit para não sofrermos com o cache. Para concatenarmos variáveis, temos que trabalhar somente no nível de steps, pois expressões não são permitidas a níveis de jobs ou do workflow como um todo. Vamos então criar um outro step e chamá-lo de `Create URL`. Neste step, vamos executar uma [**Workflow Command**](https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#using-workflow-commands-to-access-toolkit-functions), que são comandos nativos do GitHub Actions, que podem ser acessados com a sintaxe `::comando`. No nosso caso vamos usar o comando `set-env`, que serve para criar uma nova variável de ambiente, a sintaxe é a seguinte: `::set-env name=::` e ai poderemos utilizar as expressões de concatenação: ![](./1-wwgcattcatvy1njwaug-ca-7677fb.png) Veja que estamos concatenando `${{ env.MONGOKE_CONFIG_URL }}` com `?v=` e pegando os seis primeiros digitos de uma [variável nativa de ambiente](https://help.github.com/pt/actions/configuring-and-managing-workflows/using-environment-variables) chamada `GITHUB_SHA`. Vamos adicionar este step após o login: ![](./1-6nt5gncws6fem5teankfqw-a7f49f.png) Agora vamos para o último passo, onde vamos executar o nosso comando, com uma pequena alteração, ao invés de utilizar a variável `MONGOKE_CONFIG_URL`, vamos trocar para a nossa nova variável `MONGOKE_URL`: ![](./1-qqsaniai1089jdwgbh3o8q-f28781.png) Nosso arquivo final será assim: ![](./1-urbn1mgpw9gyrp-xnjvbwg-896711.png) Agora podemos clicar no botão `Start Commit` e esperar o nosso action ser executado: ![](./0-hcts-h0cjzc1ejo2-910dc3.png) ## Acompanhando o workflow Podemos acompanhar o nosso workflow na aba `Actions`: ![](./0-wb7qzmr5ajrjx-0-a35a35.png) Lembrando que **workflows não executados nenhuma vez não vão aparecer na lista**. Basta clicarmos no nome do workflow para podermos ver o que aconteceu: ![](./0-mb8osipeyxiwf3bg-34033b.png) Agora podemos observar no portal da Azure que nosso container foi atualizado: ![](./0-5ucncdfkuzajqmzl-0199fd.png) E que também nossas URLs estão corretas: ![](./0-sh4pnq2japgdumwd-af035e.png) ## Conclusão Em 7 minutos automatizamos todo o processo de deploy da nossa aplicação para a Azure e, sem perceber, ganhamos muito tempo com uma ação simples e rápida que pode ser feita em poucos minutos! Em outros artigos vamos explorar ainda mais os GitHub Actions para outras ferramentas e modelos de aplicação distribuída! Não deixe de acompanhar mais do meu conteúdo no meu blog e se inscreva na newsletter para receber notícias semanais! [^n1]: Veja que temos várias ações possíveis, para detalhar melhor, veja [a documentação oficial](https://help.github.com/en/actions/reference/events-that-trigger-workflows#webhook-events).