Deploy aplicação Laravel para hospedagem KingHost

Olá galera, hoje vou compartilhar a experiência de fazer deploy da minha aplicação para a KingHost, minha aplicação utiliza as seguintes tecnologias:

• Apache;
• Laravel (PHP 8.2);
• Vue.Js (fazendo o build com Vite e Node);
• E outras que não vão ser relevantes para esse post.

Temos algumas formas de se fazer esse deploy. Mas antes, como de costume, vamos ao problema:

O Problema

Como a KingHost em seu plano mais barato é um servidor compartilhado, temos algumas limitações, como por exemplo, as configurações de Nginx é por crud própria deles e entre outras.

Meu problema inicial era fazer o build da aplicação no servidor, sim, eu não tinha o conhecimento que dava para fazer isso automaticamente por "fora", na minha cabeça, deveria ser dentro do servidor.

Então, com esse pensamento, eu precisava do Node no servidor para rodar o bendito comando de build lá dentro. Ai foi onde os problemas começaram a surgir.

Primeiro problema, o servidor da KingHost com Apache e PHP 8.2 não suporta Node acima da versão 10 e o Vite exige Node acima da versão 16.

Segundo problema, o servidor que suporta o Node que eu precisava, só tinha Nginx, que como é configurado via crud deles, é super limitado.

Trocando ideias com um amigo, ele me explicou que o build deve ser feito fora do servidor, logo, eu não preciso de Node no servidor. Basta configurar o pipeline para enviar os dados para lá via RSync, mas adivinhem, depois de perder um tempo indo atrás de como configurar o RSync, descobri que ele é bloqueado na KingHost.

Isso nos leva ao segundo tópico desse post, que é como eu fazia até então.

Como eu fazia o Deploy antes

Na KingHost temos como fazer a publicação via Git, basta configurar a conta do GitHub lá dentro do painel deles e configurar a aplicação, isso é bem simples também. A cada merge o GitHub dispara um WebHook para a KingHost, que por sua vez, faz um git pull na pasta do projeto.

Como eu precisava do build dos arquivos do Vue.Js, rodava o build local e subia via FTP a todo santo merge com a branch main.

A Solução

Por incrível que parece e tenha me dado vontade, a solução não foi migrar de servidor para outra plataforma… Foi algo, em teoria, mais fácil de se fazer.

A solução foi configurar o pipeline para fazer o build e mandar para a KingHost via FTP pelo próprio pipeline. Simples assim.

Encerramos por aqui, a solução foi essa. Brincadeira, segue o rolo…

Vamos ao passo a passo desde o zero de como fazer esse deploy.

Configurando o WebHook

Vamos começar pelo pré suposto que você já tem o vinculo entre a KingHost e a sua conta do GitHub, então aqui neste passo é apenas configurar o WebHook mesmo. Basta ir na área de publicações via Git no painel principal da KingHost e escolher a opção GitHub nas conexões com repositório.

Aqui, teremos quatro configurações bem simples:

• Repositório: fica em uma listagem, basta selecionar o radio button referente ao seu repositório.
• Branch: aqui deve ser digitado o nome da sua branch principal, um cuidado aqui, no GitHub, o nome padrão da branch é main já na KingHost é master. Se você colocar o nome errado, só não vai funcionar, mas sem nenhum aviso em nenhum lugar que isso está errado.
• Diretório: nesta configuração, deve ser digitado o caminho no qual o ser repositório irá ficar no servidor.
• Configurações: basta selecionar se deseja que a KingHost apenas cadastre o WebHook ou se deve fazer o clone do projeto para a pasta especificada. Se quiser apenas cadastrar o WebHook, tenha em mente que o git (pasta .git) tem que estar na pasta do seu projeto.

Com essas opções configuradas o Deploy ao fazer merge com a main já deve estar funcionando. Caso utilize o composer para algo, terá que conectar via SSH com o seu servidor para rodar o composer update manualmente.

Pipeline de Deploy

Vou pular a parte do job de testes, e vamos direto para o job de deploy…

deploy:
    runs-on: ubuntu-latest
    needs: [ back-end-tests ]

    steps:
      - name: 🔥 Configuring checkout V3
        uses: actions/checkout@v3

      - name: 🔥 Configuring Node
        uses: actions/setup-node@v3
        with:
          node-version: 'latest'

      - name: 🔨 Installing Node dependencies
        run: npm install

      - name: 📄 Making .env
        run: |
          echo "${{ secrets.ENV_DEPLOY }}" > .env

      - name: 🔨 Building application
        run: npm run build

      - name: 📂 Upload files
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.FTP_ADDRESS }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          local-dir: ./public/build/
          server-dir: ./projects/project-abc/public/build/
          dangerous-clean-slate: true

Praticamente esse é o pipeline que faz a magica acontecer. Vamos a explicação dele.

deploy:
    runs-on: ubuntu-latest
    needs: [ back-end-tests ]

    steps:
      - name: 🔥 Configuring checkout V3
        uses: actions/checkout@v3

      - name: 🔥 Configuring Node
        uses: actions/setup-node@v3
        with:
          node-version: 'latest'

      - name: 🔨 Installing Node dependencies
        run: npm install

Essa parte acima, diz que para esse job vai rodar em uma imagem do Ubuntu e tem que esperar o job back-end-tests acabar com sucesso, caso de algum erro no job, o deploy não ocorre.

Esses três passos (steps) iniciais está apenas configurando o Checkout e o Node, instalando todas as dependências necessárias para o build acontecer.

- name: 📄 Making .env
  run: |
    echo "${{ secrets.ENV_DEPLOY }}" > .env

- name: 🔨 Building application
  run: npm run build

Aqui, estamos gerando o .env, um ponto de atenção aqui, o .env está vindo do secrets do GitHub, caso seu .env tenha variáveis tipo parecida com essa:

VITE_PUSHER_HOST=”${PUSHER_HOST}”

Ao fazer o a cópia do secret, ele não irá interpretar o ${PUSHER_HOST} e deixará o VITE_PUSHER_HOST vazio. Sendo assim, no build os locais que usam essa variável, ficará sem valor, podendo dar dor de cabeça para descobrir isso.

Demorei umas 4 horas para descobrir isso, pois meu token api estava dessa forma no .env, para resolver, no .env do secret deixei o valor duplicado mesmo.

Em seguida, rodamos o build para gerar os arquivos.

- name: 📂 Upload files
  uses: SamKirkland/FTP-Deploy-Action@v4.3.4
  with:
    server: ${{ secrets.FTP_ADDRESS }}
    username: ${{ secrets.FTP_USERNAME }}
    password: ${{ secrets.FTP_PASSWORD }}
    local-dir: ./public/build/
    server-dir: ./projects/project-abc/public/build/
    dangerous-clean-slate: true

Nesse passo é onde a mágica acontece, basicamente temos via secret o endereço, login e senha do FTP. Outro ponto de atenção aqui. na KingHost por padrão o acesso ao FTP é bloqueado para ip's de fora do Brasil, o pipeline roda no servidor do GitHub, logo, é de fora do brasil.

Basta apenas entrar na guia de gerenciar FTP no painel da KingHost e liberar o acessos Global.

Na opção local-dir, é onde está a origem que deseja copiar, no nosso caso está em ./public/build, ou seja, é onde o nosso build foi gerado.

Na opção server-dir, é onde os arquivos deverão ir, ou seja, ao se conectar via FTP a pasta padrão no qual caímos é a www, então basta apontar onde deve ficar o build do projeto.

Na opção dangerous-clean-slate é onde vem o pulo do gato, como a cada build os arquivos terão nomes diferentes, se não definirmos ela como true, vai só jogar os arquivos lá, gerando um monte de arquivos desnecessários. Com essa opção ele vai limpar (apagar) tudo no diretório do servidor para então jogar os arquivos novos.

Com isso temos o nosso build sengo feito para o servidor, sem a necessidade de pagar a mais pelo Node e migrar o Apache para Nginx.

Ainda temos pendências aqui. O Migration e o update do composer ainda é manual, mas como isso é mais raro de precisar fazer, não vou esquentar a cabeça com isso agora.

Até poderíamos rodar o composer no pipeline e enviar para o servidor por FTP igual fizemos com o build, mas como é uma pasta com muitos arquivos, a KingHost corta a conexão com o pipeline após certo tempo, sim antes do upload ser completado.

Penso em futuramente fazer algo que se conecte via SSH e dá os comandos. Mas isso talvez é assunto para um outro post.

Resumo

• Configurar o WebHook para dar o git pull;
• Configurar o projeto;
• Liberar acesso para fora do país no FTP;
• Criar pipeline para fazer o build;
• Mandar o build do pipeline para o servidor via FTP;
• Se necessário, conectar via SSH para atualizar o composer e o banco.

Com isso, vou ficando por aqui, até a próximo pessoal ;)