Mão na massa – Integração contínua com FTP em hospedagem compartilhada

Dando continuidade ao post sobre integração contínua com FTP (Se não viu segue o link).

Vamos a como resolvi esse meu problema.

Não vou explicar sobre o Git, esse já tem sua documentação fácil.

Começando com o Bitbucket, ative o pipeline, em seu projeto Configurações > Pipelines > Settings (O Bitbucket ainda não fez toda a tradução)

Criei o arquivo bitbucket-pipelines.yml na raiz do projeto, ele é o responsável pela build. Um exemplo simples, apenas rodando o PHPUnit é esse:

Pronto, com isso a cada commit que for feito, o Bitbucket vai disparar a pipeline e com isso gerar o build, com isso vamos ter o seguinte resultado:

Com o processo de build e testes automatizado, podemos pensar no deploy. Para isso usei o DeployBot. Quando criamos o primeiro repositório, o DeployBot faz uma interface passo a passo, mas, como meu plano é o gratuito, só tenho um repositório e ele esta em uso. Vou mostrar as configurações, ai você pode ajustar 🙂

No primeiro passo, criamos o ambiente, no meu caso, apenas produção (no test no fear).

E suas configurações.

Com a configuração de deploy manual, eu preciso mandar fazer o deploy todas as vezes, se esse servidor fosse de QA, facilmente estaria no automático.

Depois de criar o ambiente, é necessário criar os servidores, essa parte é o simples apontamento para onde os arquivos de deploy devem ir.

Configuração de FTP.

No seu cPanel.

Agora que já sabe para onde vai, hora de ajustar as dependências

Outra coisa que podemos fazer aqui, é colocar arquivos com base no ambiente, isso ajuda nas configurações de banco de dados por exemplo.

Essa parte eu não consegui entender bem, mas, em meus testes, sem usar isso a próxima parte da problema…

Aqui ele simplesmente instancia o docker e executa “php -v”, só para saber a versão mesmo, sem segredo.
Essa é a parte da mágica, o DeployBot, só vai executar essa parte caso o composer.json seja alterado, isso é muito bom, pois não vai enviar a pasta vendor sem a necessidade

Agora é só partir para o deploy.

Quando você executa o deploy a primeira vez, ele vai enviar tudo (TUDO) e ficar mais ou menos assim.

Carregando as dependências.Enviando os arquivos.Quando precisar fazer outro deploy, vai enviar apenas a diferença.Aqui, você também pode ver o arquivo de configuração por ambiente foi enviado.

Agora é só curtir 🙂

Integração contínua com FTP em hospedagem compartilhada

Deploy via FTP hoje em dia é tipo o Batman, o herói que nós precisamos e não o que queremos.

Nos últimos dias, estou trabalhando em um projeto que não há orçamento disponível, basicamente, minha esposa mandou parar de gastar.

Junto com um amigo, tenho um plano de revenda de hospedagem compartilhada, esse aqui, vendemos esse serviço para outros amigos e por ai vai. Como não há orçamento para esse projeto, estou usando uma cota minha da revenda.

Sendo uma hospedagem compartilhada eu perco diversas coisas, uma delas é o acesso SSH, algumas até disponibilizam, mas a minha experiência com isso não foi das melhores.

Vamos ao ambiente. Como repositório de código eu deixo no Bitbucket, isso porque eu posso criar repositórios privados de graça. Com ele eu uso o serviço de pipeline, também de graça. No pipeline, posso montar da mesma forma como no Trevis CI, um arquivo de configurações e ele se vira para rodar os testes unitários, de aceitação e por ai vai.

O deploy, faço via FTP, sim é muito chato fazer isso, mas tem um cara que resolve esse problema para mim, novamente, DE GRAÇA, ele é o DeployBot, com ele, consigo rodar “composer install” em uma imagem docker e ele gerencia isso para mim, pega os arquivos criados na pasta vendor e encaminha para o servidor, conforme for alterado o composer.json ele vai enviar novamente essa pasta, caso contrário só vai enviar as alteraçõs que estão no commit, esse gerenciamento é o que possibilita o deploy via FTP ser aceitável.

Juntando tudo isso, eu consigo fazer meus deploys de forma fácil, não preciso deixar as dependências no projeto e o melhor, usar efetivamente um FTP, o DeployBot que se vire nisso.

Volto a falar, existem formas melhores de fazer isso, mas o deploy via FTP é uma realidade, vamos deixar isso pelo menos mais fácil.

Assim que terminar eu posto o mão na massa, explicando como eu fiz tudo.

 

[ATUALIZAÇÃO]

Link explicando como foi feito.

Vagrant para ambiente de dev

Há alguns dias, perdi um bom tempo tendo que acertar algumas configurações para um servidor WAMP. Sim, isso me irritou, pois como rodar um Apache no Ubuntu é mais fácil eu demorei para achar como configurar. Ai eu tinha que configurar um LAMP e depois um WAMP, isso me deixou um pouco irritado, pois eu fiquei pensando, deveria ter algo melhor para fazer isso.

Mas tudo isso é apenas algo trabalhoso que pode ser feito, não chega a ser um grande problema, agora, imagine que a sua aplicação usa PHP, MySQL, Memcached, Redis, MongoDB e para terminar a festa, uma API RestFul feita em Java rodando no Apache Tomcat. Isso para um projeto, agora pense nos inúmeros ambientes que podemos precisar em uma mesma máquina, instalando tudo isso estaríamos sobrecarregando essa máquina, deixando até as tarefas mais simples como responder um e-mail complicadas de serem executadas pela demora na resposta da máquina.
Agora, você poderia ir desativando e ativando os serviços conforme necessário, porem isso também seria trabalhoso. É nesse ponto que entra o Vagrant. Nele podemos subir uma interface mais próxima ao nosso servidor e habilitar e desabilitar ele com apenas um comando. Como nem tudo na vida é fácil, ainda vamos precisar configurar o ambiente, porem isso sera feito apenas uma vez.

Site Vagrant

Vamos agora ao que interessa 🙂

Para o Vagrant funcionar, precisamos ter um gerenciador de máquinas virtuais, o Vagrant suporta VirtualBox, VMware e Hiper-V. Para nosso teste vamos utilizar a VirtualBox, ela pode ser baixada aqui.

Vamos precisar também baixar o Vagrant Aqui.

Depois dele instalado precisamos iniciar o Vagrant em alguma pasta, da mesma forma que fazemos para o git.

vagrant init

Esse comando vai criar o Vagrantfile, esse arquivo sera usado mais a frente para fazer algumas configurações.

O Vagrant, funciona com “boxes”, que são as VMs. No site vagrantbox.es você pode baixar a box que quiser. Eu escolhi a precise32 para demonstrar.

vagrant box add precise32 http://files.vagrantup.com/precise32.box

Ai só esperar baixar e partir para a configuração.

vagrant up

Esse comando ira iniciar a VM.

Quando ela estiver iniciado, basta acessar ela via ssh e configurar da forma que achar melhor.

vagrant ssh

Se por acaso você fizer merda, basta destruir a VM, depois disso basta iniciar e acessar via ssh.

vagrant destroy

Agora vamos configurar o Vagrantfile.


Vagrant.configure(2) do |config|
    config.vm.box = "ubuntu32"

    config.vm.network :forwarded_port, host: 8080, guest: 80
    config.vm.network :forwarded_port, host: 3306, guest: 3306
end

Com essa configuração, estamos fazendo um redirecionamento de portas, apontando as portas do host (minha máquina) para o guest (VM).
Bom, eu não sei muito sobre o Vagrantfile, mas aqui esta a sua documentação.

Até aqui falamos como configurar, subir e bla bla bla. Agora vamos falar sobre o motivo de usarmos o Vagrant e não a VM direto.

A parte interessante do uso do Vagrant é o fato que ele já monta uma unidade de disco “/vagrant” dentro da VM, essa pasta é a mesma que você fez o “vagrant init”.

Se ainda não consegui te convencer, seguem alguns dos meus motivos para usar o Vagrant.

  • Todo o trabalho para instalar uma VM
  • “vagrant destroy” desfaz toda a merda que você fez
  • Redirecionamento de portas de forma simples
  • “vagrant up” tudo funcionando “vagrant halt” seu computador fica limpo
  • Monta uma unidade de disco por padrão

Acho que é isso, escrevi bastante aqui, espero que tenham gostado.

Utilizando o Load Balancer Amazon AWS

Boa tarde.

Fiz um screencast para mostrar como criar um Load Balancer junto com dois servidores a baixo dele rodando apache na estrutura da Amazon AWS. Eu pensei em fazer com screenshots, mas depois de ver que eu já tinha tirando uns 15 e não estava na metada eu desisti.

Espero que esse post ajude vocês. Caso tenham alguma dúvida ou sugestão para outro screencast só deixar nos comentários 🙂

O video não ficou muito bom quando baixei a qualidade para 480p, mas era isso ou nada no vimeo.

Um abraço

Amazon AWS – Experiência de uso

Olá.

Nos últimos dias venho utilizando o serviço Amazon AWS e preciso dizer uma coisa, é animal.
Ele foi muito bem pensado (até onde percebi), criei um servidor LAMP em poucos minutos, não satisfeito fui usar o banco de dados relacional deles o RDS, sensacional.
A partir dai comecei a brincar a parte de segurança de acesso deles, muito simples, consegui dizer exatamente que porta estava aberta para quais IPs, públicos ou privados com pouco esforço.
Para finalizar minha experiência, fiz alguns testes com o load balancer. Minha primeira experiencia com essa tecnologia fico até sem saber como fazer esse review.

Tudo o que fiz ficou dentro do uso gratuito de 12 meses deles, para saber mais clique aqui.
Nos próximos posts irei demonstrar algumas aplicações que podem ser feitas

Abraço