- Se voc\u00ea est\u00e1 com pressa… tudo bem!<\/a>
- O que voc\u00ea precisa<\/a>
- O que a GitHub Action vai fazer<\/a>
- Acesso SSH<\/a>
- 1. Criar um par de chaves SSH<\/a>
- 2. Autorizar a chave a conectar com o seu servidor<\/a>
- 3. Testar a chave SSH (Opcional)<\/a><\/li><\/ul><\/li>
- GitHub Actions<\/a>
- Nome do fluxo de trabalho<\/a>
- Segredos no GitHub Action<\/a>
- Como criar um segredo no GitHub Actions<\/a><\/li><\/ul>
- Gatilhos e eventos<\/a>
- Jobs<\/a>
- Etapas ou steps<\/a>
- Configura\u00e7\u00e3o do SSH<\/a>
- Enviar os arquivos com rsync<\/a>
- Sobre exclus\u00f5es no rsync<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/li>
- Fazendo mais com GitHub Actions<\/a>
- Por que abandonar o SFTP<\/a>
- Conclus\u00e3o<\/a><\/ul><\/ul><\/ul><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n
Se voc\u00ea est\u00e1 com pressa… tudo bem!<\/h2>\n\n\n\n
N\u00e3o tem problema se voc\u00ea est\u00e1 com pressa. De forma bem resumida isso \u00e9 o que vamos fazer:<\/p>\n\n\n\n
- \n
- Criar um par de chaves SSH que se conectem ao seu servidor<\/a>;<\/li>\n\n\n\n
- Criar os segredos
DEPLOY_SSH_HOST<\/code>,DEPLOY_SSH_USER<\/code> eDEPLOY_SSH_KEY<\/code> no GitHub<\/a>;<\/li>\n\n\n\n- Criar o arquivo
bin\/rsync-excludes.txt<\/code> no seu reposit\u00f3rio<\/a>;<\/li>\n\n\n\n- Criar o arquivo
.github\/workflows\/deploy.yml<\/code> no seu reposit\u00f3rio<\/a>;<\/li>\n\n\n\n- Fazer qualquer modifica\u00e7\u00e3o na branch
trunk<\/code>.<\/li>\n<\/ol>\n\n\n\n\n
Se este post ajudar, n\u00e3o se esque\u00e7a de compartilh\u00e1-lo nas suas redes sociais. Assine a newsletter para receber os novos posts!<\/p>\n<\/blockquote>\n\n\n\n
O que voc\u00ea precisa<\/h2>\n\n\n\n
A lista do que vamos precisar para esse post \u00e9 bem simples:<\/p>\n\n\n\n
- \n
- Acesso SSH ao seu servidor<\/strong>: Dispon\u00edvel em quase todas as hospedagens atualmente;<\/li>\n\n\n\n
- Um reposit\u00f3rio no GitHub<\/strong>: Gr\u00e1tis e ilimitados, inclusive os privados.<\/li>\n<\/ul>\n\n\n\n
N\u00e3o se esque\u00e7a de fazer um backup do conte\u00fado do seu servidor antes de continuar. Assim, se algo der errado, ser\u00e1 mais f\u00e1cil reverter.<\/p>\n\n\n\n
O que a GitHub Action vai fazer<\/h2>\n\n\n\n
Basicamente, o que vai acontecer \u00e9 que ao atualizar os arquivos em uma determinada branch do reposit\u00f3rio, uma GitHub Action se conectar\u00e1 via SSH com o servidor e enviar\u00e1 os arquivos<\/strong> usando o comando
rsync<\/code>.<\/p>\n\n\n\n![\"\"](\"https:\/\/felipeelia.com.br\/wp-content\/uploads\/2023\/01\/image-3.png\")
<\/a>O \u2713 verde significa que uma Action foi disparada e executada com sucesso.<\/figcaption><\/figure>\n\n\n\n Acesso SSH<\/h2>\n\n\n\n
A sua GitHub Action precisar\u00e1 se conectar atrav\u00e9s do SSH (Secure SHell) com o seu servidor para enviar os arquivos. Para que isso seja poss\u00edvel, vamos criar um par de chaves SSH e configurar o servidor para aceit\u00e1-lo<\/strong>.<\/p>\n\n\n\n
1. Criar um par de chaves SSH<\/h3>\n\n\n\n
A criptografia usada pelo protocolo SSH usa duas chaves: uma p\u00fablica e uma privada<\/strong>. Para que a sua GitHub Action consiga enviar os arquivos para o seu servidor, voc\u00ea precisar\u00e1 de um novo par de chaves. Embora poss\u00edvel, n\u00e3o recomendo usar a mesma chave que voc\u00ea usa normalmente.<\/p>\n\n\n\n
O comando para criar uma nova chave \u00e9 o seguinte:<\/p>\n\n\n\n
ssh-keygen -t ed25519 -C \"usuario@dominio\"<\/code><\/pre>\n\n\n\n- \n
ssh-keygen<\/code>: O comando que gera uma nova chave;<\/li>\n\n\n\n-t ed25519<\/code>: O algoritmo usado na cria\u00e7\u00e3o da chave;<\/li>\n\n\n\n-C \"usuario@dominio\"<\/code>: N\u00e3o precisa ser um e-mail de verdade. S\u00f3 \u00e9 usado para diferenciar as chaves, como um coment\u00e1rio. Algo comodeploy@meusite.com<\/code> j\u00e1 \u00e9 o suficiente.<\/li>\n<\/ul>\n\n\n\nO comando pedir\u00e1:<\/p>\n\n\n\n
- \n
- Uma senha<\/em>: deixe em branco para facilitar o processo;<\/li>\n\n\n\n
- Um nome de arquivo<\/em>: n\u00e3o use o padr\u00e3o, coloque um novo como
deploy<\/code> ou o nome do projeto. N\u00e3o use nenhuma extens\u00e3o.<\/li>\n<\/ul>\n\n\n\n![\"\"](\"https:\/\/felipeelia.com.br\/wp-content\/uploads\/2023\/01\/image-5-1024x494.png\")
<\/a>Chamada do comando ssh-keygen<\/code> e seu retorno<\/figcaption><\/figure>\n\n\n\n2. Autorizar a chave a conectar com o seu servidor<\/h3>\n\n\n\n
Cada servi\u00e7o de hospedagem cuida disso de uma forma diferente. Em hospedagens com algum tipo de painel de controle isso pode estar em Minha conta > SSH ou similar.<\/p>\n\n\n\n
Na Cloudways, por exemplo, as chaves SSH s\u00e3o gerenciadas por aplica\u00e7\u00e3o. Na se\u00e7\u00e3o Access Details<\/em>, \u00e9 poss\u00edvel gerenciar as chaves SSH em Application Credentials<\/em>.<\/p>\n\n\n\n
![\"\"](\"https:\/\/felipeelia.com.br\/wp-content\/uploads\/2023\/01\/cloudways-ssh-1024x477.png\")
<\/a>Painel de controle de uma aplica\u00e7\u00e3o na Cloudways<\/figcaption><\/figure>\n\n\n\n Na imagem vemos setas para tr\u00eas elementos:<\/p>\n\n\n\n
- \n
- Public IP<\/em>: Ser\u00e1 usado como Host na nossa configura\u00e7\u00e3o. Em muitos casos \u00e9 a URL do pr\u00f3prio site.<\/li>\n\n\n\n
- Username<\/em>: A Cloudways tem um username<\/em> diferente por aplica\u00e7\u00e3o. Algumas hospedagens usam o mesmo usu\u00e1rio para acessar tanto o painel quanto o servidor via SSH.<\/li>\n\n\n\n
- SSH Keys<\/em>: Este \u00e9 o lugar onde \u00e9 poss\u00edvel configurar novas chaves para essa aplica\u00e7\u00e3o. L\u00e1 voc\u00ea deve fornecer a chave p\u00fablica (
arquivo.pub<\/code>) do par gerado.<\/li>\n<\/ul>\n\n\n\n3. Testar a chave SSH (Opcional)<\/h3>\n\n\n\n
Do seu computador \u00e9 poss\u00edvel testar o acesso com a nova chave. Para isso basta executar o seguinte comando:<\/p>\n\n\n\n
ssh -i <caminho-chave-privada> <usuario>@<servidor><\/code><\/pre>\n\n\n\n- \n
<caminho-chave-privada><\/code>: O caminho do arquivo da chave privada (sem.pub<\/code>) no seu computador<\/li>\n\n\n\n<usuario>@<servidor><\/code>: Varia de servi\u00e7o para servi\u00e7o. No caso da Cloudways ter\u00edamosappname_ssh@12.34.567.890<\/code>.<\/li>\n<\/ul>\n\n\n\nSe us\u00e1ssemos a chave gerada no exemplo, a chamada ficaria assim:<\/p>\n\n\n\n
ssh -i \/home\/elia\/.ssh\/exemplopost appname_ssh@12.34.567.890<\/code><\/pre>\n\n\n\nSe tudo deu certo voc\u00ea vai conseguir acessar o terminal do seu servidor.<\/p>\n\n\n\n
GitHub Actions<\/h2>\n\n\n\n
GitHub Actions<\/a> \u00e9 a ferramenta de automa\u00e7\u00e3o do GitHub.<\/strong> Basicamente, o GitHub vai analisar qualquer arquivo
.yml<\/code> na pasta.github\/workflows<\/code> do seu reposit\u00f3rio e tentar execut\u00e1-lo cada vez que alguma coisa acontecer no seu reposit\u00f3rio.<\/p>\n\n\n\nNo nosso caso vamos criar um arquivo chamado
.github\/workflows\/deploy.yml<\/code>. Voc\u00ea pode dar o nome que quiser, desde que mantenha a extens\u00e3o.yml<\/code> e a localiza\u00e7\u00e3o do arquivo.<\/p>\n\n\n\n\n
ATEN\u00c7\u00c3O: Arquivos .yml n\u00e3o permitem tabs, s\u00f3 espa\u00e7os (2 ou 4).<\/p>\n<\/blockquote>\n\n\n\n
O conte\u00fado do nosso arquivo
.github\/workflows\/deploy.yml<\/code> ser\u00e1 o seguinte:<\/p>\n\n\n\nname: Deploy\n\nenv:\n SSH_USER: ${{ secrets.DEPLOY_SSH_USER }}\n SSH_HOST: ${{ secrets.DEPLOY_SSH_HOST }}\n\non:\n push:\n branches:\n - trunk\n\njobs:\n deploy_cloudways:\n name: Deploy to Cloudways\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions\/checkout@v2\n\n - name: Configure SSH\n run: |\n mkdir -p ~\/.ssh\/\n echo \"$SSH_KEY\" > ~\/.ssh\/deploy.key\n chmod 600 ~\/.ssh\/deploy.key\n cat >>~\/.ssh\/config <<END\n Host cloudways\n HostName $SSH_HOST\n User $SSH_USER\n IdentityFile ~\/.ssh\/deploy.key\n StrictHostKeyChecking no\n END\n env:\n SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}\n\n - name: Send files\n run: \"rsync --delete -avO ${{ env.RSYNC_FLAGS }} --exclude-from=${{ env.EXCLUDES }} .\/ ${{ env.SSH_USER }}@${{ env.SSH_HOST }}:${{ env.DESTINATION }}\"\n env:\n RSYNC_FLAGS: '' #--dry-run\n EXCLUDES: bin\/rsync-excludes.txt\n SSH_HOST: cloudways\n DESTINATION: \"~\/public_html\/wp-content\/\"\n<\/code><\/pre>\n\n\n\nNome do fluxo de trabalho<\/h3>\n\n\n\n
A primeira linha do nosso arquivo simplesmente d\u00e1 nome ao nosso workflow<\/a><\/em>. O nome \u00e9 usado simplesmente para visualiza\u00e7\u00f5es e n\u00e3o interfere no funcionamento da automa\u00e7\u00e3o.<\/p>\n\n\n\n
name: Deploy\n<\/code><\/pre>\n\n\n\nSegredos no GitHub Action<\/h3>\n\n\n\n
A segunda se\u00e7\u00e3o do nosso arquivo configura algumas vari\u00e1veis de ambiente compartilhadas por alguns “passos” mais adiante.<\/p>\n\n\n\n
env:\n SSH_USER: ${{ secrets.DEPLOY_SSH_USER }}\n SSH_HOST: ${{ secrets.DEPLOY_SSH_HOST }}<\/code><\/pre>\n\n\n\nComo a descri\u00e7\u00e3o do fluxo de trabalho \u00e9 feita em um arquivo vis\u00edvel para qualquer um que tenha acesso ao reposit\u00f3rio, o GitHub fornece um jeito de criar segredos, edit\u00e1veis apenas por administradores do reposit\u00f3rio ou organiza\u00e7\u00e3o.<\/p>\n\n\n\n
Como criar um segredo no GitHub Actions<\/h4>\n\n\n\n
Vamos relembrar o comando de acesso SSH que usamos para testar anteriormente:<\/p>\n\n\n\n
ssh -i <caminho-chave-privada> <usuario>@<servidor><\/code><\/pre>\n\n\n\nCom esse comando em mente, acesse o reposit\u00f3rio e v\u00e1 at\u00e9 Settings > Secrets and Variables > Actions. Vamos criar tr\u00eas segredos<\/strong>:<\/p>\n\n\n\n
- \n
DEPLOY_SSH_KEY<\/code>: O conte\u00fado <\/strong>da chave privada que voc\u00ea criou.<\/li>\n\n\n\nDEPLOY_SSH_USER<\/code>: O que voc\u00ea usou como<usuario><\/code>;<\/li>\n\n\n\nDEPLOY_SSH_HOST<\/code>: O que voc\u00ea usou como<servidor><\/code>;<\/li>\n<\/ul>\n\n\n\nRepare que
DEPLOY_SSH_KEY<\/code> \u00e9 diferente das outras: passamos o caminho do arquivo<\/em> no comando, mas o segredo tem o conte\u00fado <\/em>do arquivo. Isso acontece porque criaremos o arquivo durante a execu\u00e7\u00e3o da action<\/em>.<\/p>\n\n\n\n![\"\"](\"https:\/\/felipeelia.com.br\/wp-content\/uploads\/2023\/01\/image-4-1024x449.png\")
<\/a>Formul\u00e1rio para a cria\u00e7\u00e3o de um segredo no GitHub<\/figcaption><\/figure>\n\n\n\n O segredo
DEPLOY_SSH_KEY<\/code> n\u00e3o est\u00e1 nessa se\u00e7\u00e3oenv<\/code> de prop\u00f3sito. Ele ser\u00e1 usado mais adiante.<\/p>\n\n\n\nGatilhos e eventos<\/h3>\n\n\n\n
on:\n push:\n branches:\n - trunk<\/code><\/pre>\n\n\n\nO conte\u00fado dessa se\u00e7\u00e3o \u00e9 bem auto-explicativo: os passos neste arquivo s\u00f3 devem ser executados quando o conte\u00fado da branch
trunk<\/code> for modificado.<\/p>\n\n\n\nAo inv\u00e9s de
push<\/code>, poderia serpull_request<\/code> ouschedule<\/code>, por exemplo. <\/p>\n\n\n\nJobs<\/h3>\n\n\n\n
Um conjunto de passos que ser\u00e3o executados. Nosso arquivo de workflow <\/em>s\u00f3 tem um job<\/em>, mas \u00e9 poss\u00edvel ter mais de um. Diferentes jobs<\/em> s\u00e3o executados em paralelo.<\/p>\n\n\n\n
jobs:\n deploy_cloudways:\n name: Deploy to Cloudways\n runs-on: ubuntu-latest<\/code><\/pre>\n\n\n\n
- Username<\/em>: A Cloudways tem um username<\/em> diferente por aplica\u00e7\u00e3o. Algumas hospedagens usam o mesmo usu\u00e1rio para acessar tanto o painel quanto o servidor via SSH.<\/li>\n\n\n\n
- Um nome de arquivo<\/em>: n\u00e3o use o padr\u00e3o, coloque um novo como
- Um reposit\u00f3rio no GitHub<\/strong>: Gr\u00e1tis e ilimitados, inclusive os privados.<\/li>\n<\/ul>\n\n\n\n
- Criar os segredos
- Fazendo mais com GitHub Actions<\/a>
- Gatilhos e eventos<\/a>
- Segredos no GitHub Action<\/a>
- 2. Autorizar a chave a conectar com o seu servidor<\/a>
- O que voc\u00ea precisa<\/a>