O processo de deploy de uma aplicação pode ser feito de várias formas dependendo do ambiente escolhido tanto para o desenvolvimento quanto para a hospedagem final dele. Esse processo pode ser descomplicado com o simples fato de subir o código que está no seu Github direto na imagem docker e continuar com o processo de build e outras tarefas todas por lá, dessa forma tudo já fica bem mais encaminhado para usarmos CD/CI no futuro.
O problema…
Quando estamos lidando com repositórios públicos é bem simples de se fazer. Basta fazer o clone lá no Dockerfile da mesma forma que nós faríamos na nossa estação de desenvolvimento.
Algo como:
... RUN git clone https://github.com/seu_usuario/seu_repositorio.git ...
Esse processo é simples porque o repositório é público e não precisa de nenhuma autenticação para clona-lo. O que obviamente não acontece no repositório privado.
Para fazer o clone do repositório privado nós precisamos estar autenticados e não seria interessante passarmos as informações de autenticação pela url, isso seria uma falha de segurança seríssima.
Então, para resolver esse problema vamos usar SSH para se autenticar de forma segura e mais elegante 🙂
Autenticando no Github por SSH
Para que o Github possa nos autorizar a fazer a clonagem do repositório na imagem Docker, nós vamos precisar gerar um par de chaves criptografadas na nossa estação de desenvolvimento. Você pode gerar as chaves em todas as máquinas que forem necessárias.
Se você não sabe o que é SSH, aqui vai um link bem completo que vai te ajudar, mas basicamente, usaremos um par de chaves assimétricos de criptografia, nas quais existem uma chave privada, que é sua (da sua máquina em questão) que vamos usar mais pra frente e uma chave pública que você vai configurar lá na sua conta no site do Github em seguida.
Uma coisa importante a saber é que cada par de chaves é único e a autorização é concedida quando a chave pública conseguir “entender” a chave privada que será passada à ela.
Feitas as apresentações, vamos ver como gerar nosso par de chaves SSH.
Verificando as chaves SSH
Antes de sair gerando as chaves, pode ser que você já as tenha gerado antes.
Vale lembrar que todos os procedimentos citados aqui podem ser utilizados em plataformas Microsoft Windows, GNU/Linux e MacOS. Nesse caso estou utilizando um GNU/Linux Ubuntu 20.04.1 LTS
Para verificar se você já possui um par de chaves SSH gerados, digite o seguinte comando no terminal do do seu sistema operacional ls -al ~/.ssh para ver se existe alguma chave criada.
$ ls -al ~/.ssh # Lista os arquivos do seu diretório .ssh, se eles existem
Por padrão os arquivos que nos interessam podem ter o nome de id_rsa e extensões .pub
Se você encontrou algum desses arquivos no seu diretório, é provável que possamos usá-los nos passos seguintes ao invés de criar um novo par de chaves.
Se você viu um par de chave pública e privada listado (por exemplo id_rsa.pub and id_rsa) e gostaria de usá-las para conectar com o Github, você pode adicionar sua chave SSH ao SSH-agent e pular o próximo passo da geração de chave do tutorial.
Se mesmo assim você quiser gerar um novo par de chaves não fará mal algum.
Como gerar o par de chaves SSH
Você vai precisar utilizar um pacote específico para gerar o par de chaves SSH. O mais conhecido é o openssh e ele tem versões para os sistemas operaacionais mais utilizados no mercado.
Para gerar o seu par de chaves, vá ao terminal do seu sistema operacional e digite ssh-keygen -t rsa -b 4096 -C “your_email@example.com” substituindo o email pelo email da sua conta do Github.
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Vai aparecer Enter a file in which to save the key no seu terminal. Você pode aceitar o caminho padrão (/home/seu_usuario/.ssh/id_rsa) pressionando enter ou digitar outro caminho para gerar suas chaves.
Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]
Caso haja algum arquivo com o mesmo nome no diretório escolhido, será perguntado se você quer substituí-lo.
No próximo passo não informe nenhuma senha no arquivo, caso contrário teremos um erro de chave inválida (invalid key) quando gerarmos nossa imagem Docker.
Enter passphrase (empty for no passphrase): [Type a passphrase] Enter same passphrase again: [Type passphrase again]
Depois disso seu par de chaves assimétricas será gerado. Vamos ver agora como adicioná-las ao seu agente.
Adicionado as chaves ao agente
Nessa etapa você pode adicionar as chaves já existentes ou adicionar as novas chaves geradas na etapa anterior.
Para adicionar as chaves no agente, vamos iniciá-lo em bacakground
$ eval "$(ssh-agent -s)" Agent pid 43558
e agora adicione sua chave privada no agente. Se você alterou o nome e/ou o diretório da chave, substitua no comando.
$ ssh-add ~/.ssh/id_rsa
Esse procedimento deixa essa chave configurada e pronta para trabalhar em futuros commits e outros comandos, mas não necessariamente é obrigatório para gerarmos a imagem Docker, como vamos ver mais pra frente.
Adicionando a chave pública no Github
Lembra que para que a autenticação ocorra é preciso que as chaves pública e privada “conversem”? Nesse passo damos início á essa “conversa” configurando a chave pública na conta do Github. Para fazer isso, precisamos copiar o conteúdo da chave gerada no seu computador.
Você pode usar o xclip para fazer isso ou simplesmente copiar o arquivo gerado.
$ sudo apt-get install xclip
# Faz o download e instala o xclip. Se você não tem instalado o 'apt-get', você pode usar outro instalador (como o 'yum')$ xclip -sel clip < ~/.ssh/id_rsa.pub
# Copia o conteúdo da sua chave id_rsa.pub
Para usar o arquivo sem xclip
$ cat ~/.ssh/id_rsa.pub
Agora siga os passos para adicionar a chave na sua conta do Github.
- Acesse sua conta do Github
- Clique na sua foto de perfil no canto superior direito
- Clique em “Settings“
- No menu à esquerda, clique em “SSH and GPG keys“
- Clique em New SSH Key ou Add SSH key
- Adicione uma descrição para a nova chave (Ex.: note-dev)
- Cole a chave no campo Key
- Clique em Add SSH key
- Se for solicitado, confirme sua senha do Github.
Feito isso, vamos configurar nosso Dockerfile
Configurando o Dockerfile
Para configurar o dockerfile, vamos criar uma imagem intermediária para fazer o clone e depois elminá-lá, dando lugar apenas para a imagem definitiva.
# Choose and name our temporary image
FROM alpine as intermediate
# Add metadata identifying these images as our build containers (this will be useful later!)
LABEL stage=intermediate
# Take an SSH key as a build argument.
ARG SSH_PRIVATE_KEY
# Install dependencies required to git clone.
RUN apk update && \
apk add --update git && \
apk add --update openssh
# 1. Create the SSH directory.
# 2. Populate the private key file.
# 3. Set the required permissions.
# 4. Add github to our list of known hosts for ssh.
RUN mkdir -p /root/.ssh/ && \
echo "$SSH_PRIVATE_KEY" > /root/.ssh/id_rsa && \
chmod -R 600 /root/.ssh/ && \
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
# Clone a repository (my website in this case)
RUN git clone git@github.com:seu_usuario/seu_repositorio.git
# Choose the base image for our final imageFROM alpine
RUN apk update && \
apk upgrade && \
apk add --update nodejs npm && \
npm install -g @angular/cli
# Copy across the files from our `intermediate` container
RUN mkdir app
COPY --from=intermediate /qualico/. /app/.
WORKDIR /app
…
Basicamente estamos dizendo apara o dockerfile que vamos informar uma variável $SSH_PRIVATE_KEY na hora de gerar a imagem. Queremos que ele crie uma instância intermediária só para fazer a clonagem do nosso repositório e depois elimine ela e aí sim nós configuramos a imagem definitiva.
Nesse ponto, já configuramos a chave pública na nossa conta do Github, agora chegou a hora de informar a chave privada para autenticação.
Para fazer isso, é preciso carregá-la em uma variável temporária no seu sistema operacional. Faça isso com o seguinte comando.
MY_KEY=$(cat ~/.ssh/id_rsa)
E agora já podemos fazer o build da imagem Docker
docker build --build-arg SSH_PRIVATE_KEY="$MY_KEY" --no-cache --tag clone-example . … Successfully tagged clone-example:latest
Nesse ponto já temos a imagem construída com sucesso e podemos fazer o nosso deploy para onde quisermos, mas se você ainda se preocupa com segurança e quer se livrar dos resquícios desse processo, siga em frente com mais alguns passos.
Limpando os vestígios
Mesmo utilizando uma imagem intermediária para dar mais segurança ao processo, se visualizamos os logs das operações, ainda podemos ver nossa chave privada por lá e não queremos isso, não é?
docker history clone-example > IMAGE CREATED CREATED BY SIZE >b3dbbf389a73 2 minutes ago /bin/sh -c #(nop) COPY file:90e3ecf812fe16bf… 254B >39d11e01b3ad 2 minutes ago /bin/sh -c mkdir files 0B >196d12cf6ab1 2 weeks ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B ><missing> 2 weeks ago /bin/sh -c #(nop) ADD file:25c10b1d1b41d46a1… 4.41MB
Durante a configuração do Dockerfile utilizamos o comando LABEL onde especificamos o valor de intermediate. Fizemos isso justamente para identificar e facilitar a remoção dos dados sensíveis nessa etapa.
Onde apenas com um comando, vamos remover todos os vestígios da operação, não deixando a sua chave privada exposta.
Para isso, execute o comando:
docker rmi -f $(docker images -q --filter label=stage=intermediate)
Feito pessoas!
Agora seu processo de deploy está mais automatizado e seguro 🙂
Espero ter ajudado!
Grande abraço 🙂
