Nova Arquitetura F5 Sites: Nginx-proxy Reverso de Múltiplos Dockers WordPress

Finalizando a tarefa mais difícil demorada, complexa e importante da história da F5 sites, mesmo tendo achado, ou até mesmo escrito posts anteriormente aqui no blog com o mesmo argumento, apenas agora, tive a plena consciência do que significa a nova arquitetura do F5 sites, como eu fiz uma virada há 2 anos e tudo isso aos poucos foi fazendo sentindo e criando pequenas soluções que juntas formam uma complexa nova arquitetura. O resultado prático é simples, mas o caminho para chegar nesse esquema é único e representa o passado, presente e futuro da F5 Sites.

Nem sempre uma tarefa nasce com o título que deveria, no começo do ano tive um excedente de caixa e pude contratar mais um pequeno servidor, uma micro cloud, com configuração mais básica e econômica (nanode de 5 dólares, uma micro VM). Para manter os custos sempre enxutos, não contratava qualquer serviço que não fosse estritamente necessário, regra que começou a valer em 2017, se não é necessário, se existe solução grátis ou se eu posso fazer, não contrato. Aqui no blog tem-se muitos posts sobre como migrei de um plano de revenda de hospedagem super custoso que hospedava mais de 10 sites, para uma micro VM de 5 dólares, hospedando os mesmos sites. Aqui já temos os ingredientes da sopa dessa publicação:

  • Mudanças na forma de administrar recursos
  • Possibilidade de contratação de um servidor adicional
  • A forma improvisada (algumas vezes atrapalhada e apressada) de criar soluções

(O apressado acaba sendo uma característica inerente de quem não tem muito tempo para se dedicar integralmente para os próprios projetos, já que trabalho contratado 8 horas por dia para terceiros, além de ter uma vida pessoal que reduz minha atuação na F5 Sites as vezes a poucas horas por mês.)

Assim essa nova tarefa surgiu com o tema de “eliminar uma VM” (voltar a operar somente com uma VM). Portanto precisei migrar toda a arquitetura da VM antiga para a nova arquitetura da VM nova, com docker com nginx-proxy e acme certbots automatizado, proxyando diversos outros dockers, seja WordPress, Node ou Python.

Entrei no maior desafio da minha vida, que para muitos é algo bem simples e trivial, para mim foi uma jornada ao desconhecido. Significa ter um objetivo e buscar o conhecimento, estudar muito, fazer milhões de testes para chegar em uma fórmula muito simples. Como pegar uma AK 47, uma arma tão simples e fácil de fazer que surpreende, mas levou muitos anos para chegar nesse produto.

Então descobri com muita pesquisa, mais do que muitas semanas de teste a fio, como sustentar em pé um serviço docker que fizesse o proxy reverso para cada domínio. Porque o docker / apache trabalha com a porta 80/443, assim não tem como levantar outro docker no mesmo ambiente, se for trabalhar com um projeto WordPress precisa desligar o outro. O grande desafio foi encontrar uma forma de levantar dois dockers / apache usando a mesma porta 80 e magicamente entregar para o usuário na ponta, o site que está acessando.

Acredito que o conhecimento que construi nestes meses são muito relevantes e por isso vou criar uma série de vídeos, talvez até mesmo um curso ensinando passo a passo como fazer uso desta tecnologia e solução, como já falei, simples para quem conhece, mas um longo caminho de conhecimento para quem quer dominar todas as etapas.

FSlint: Deletando Arquivos Duplicados no Linux

A manutenção de sistemas exige limpezas constantes, ter arquivos duplicados em servidores tem um custo muito alto, as vezes temos várias cópias do mesmo arquivo, ocupando espaço, dificultando backups, custando espaço, tempo e dinheiro.

Instale o script com o comando

sudo apt-get install fslint

Basta encontrar o programa para iniciar a busca de arquivos duplicados, pode ser feito a remoção em massa ou arquivo por arquivo.

Referências

https://www.edivaldobrito.com.br/remover-arquivos-duplicados-no-linux/

Estrutura de Múltiplos WordPress Multi-Site

Uma instalação de WordPress é basicamente os arquivos do WordPress (wp-config, core, plugins, temas, uploads, etc.) e um banco de dados (tabelas prefixadas). Qualquer instalação precisa de um endereço de URL para ser acessada, que é uma instalação simples de WordPress.

Porém seria possível habilitar o multi-site nesta instalação (veja como habilitar o multi-site na documentação oficial ¹), basta ativar no wp-config, assim uma única instalação de WordPress pode ativar em uma URL vários subsites.


Em algumas situações podemos ter duas instalações de WordPress Multi-Site em duas URL diferentes, funcionando de forma independente. Cada instalação com seus arquivos e seu banco de dados.

Uma alternativa seria usar a mesma instalação de WordPress, mas com banco de dados diferentes, pois o serviço que mais consome recursos do servidor é o banco de dados, em bancos diferentes (até mesmo em servidores diferentes) temos mais segurança no caso de uma queda do serviço não derrubar a rede toda.

Em uma configuração mais avançada podemos fazer estas duas instalações diferentes usarem os mesmo arquivos e o mesmo banco de dados (com prefixos diferentes para as tabelas), cada uma com sua URL diferente.

Mas também é possível ter várias instalações de WordPress Multi-site na mesma URL, funcionando basicamente como o exemplo acima, mas só que múltiplos subdomínios ou subpastas também podem ser diferentes WordPress multi-site, mas compartilhando a mesma instalação e o mesmo banco de dados.

Assim temos vantagens e desvantagens em cada um dos modelos.

Múltiplas contas BitBucket na mesma máquina

A situação que passei foi a seguinte, trabalhar com dois clientes diferentes no mesmo computador, porém os dois usavam BitBucket para a gestão de repositórios git, assim, a chave SSH que foi configurada para um, não iria funcionara para o outro.

Criar chaves SSH

Primeiro é preciso criar uma chave para cada usuário

 ssh-keygen -t rsa -C "franciscof5" -f "franciscof5"

Adicioná-las em sua conta

Depois copiar cada chave para cada usuário do BitBucket, para mais informações visite a documentação oficial.

Configurar seu SSH

Na pasta ~/.ssh/ crie um arquivo chamado config com o seguinte conteúdo:

#default account
Host bitbucket.org
	HostName bitbucket.org
	User git
	IdentityFile ~/.ssh/id_rsa
	IdentitiesOnly yes

#franciscof5 account
Host bitbucket.org-franciscof5
	HostName bitbucket.org
	User git
	IdentityFile ~/.ssh/franciscof5
	IdentitiesOnly yes

Configurando repos

Se não tem um repositório clonado, use o seguinte comando (repare no nome do usuário)

git clone git@bitbucket.org-franciscof5:franciscof5/your-repo-name.git

Se já tem um clone, atualize a origin

git remote set-url origin git@bitbucket.org-franciscof5:franciscof5/your-repo-name.git

Agora entre no repo local e atualize o usuário e email

git config user.name "franciscof5"
git config user.email "user1@example.com

Agora você pode trabalhar com uma ou mais conta de BitBucket na mesma máquina, espero que tenha gostado, deixe comentários.

Referências

Tip of the Week: Using different SSH keys for multiple Bitbucket accounts

https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html

 

Deploy avançado com WordPress

O que é deploy?

Primeiro, o que é deploy? Deploy é o processo de “empacotar” o trabalho de desenvolvimento e transportá-lo de um ambiente para outro, por exemplo, quando um programador termina uma atualização de um sistema e vai disponibilizá-la para os usuários.

Essa entrega precisa acontecer sem comprometer o serviço atual, o site não pode cair, também é importante não consumir muitos recursos do servidor e nem levar muito tempo, em muitos casos é preciso reverter (rollback) o processo caso surja algum erro, para evitar correria para apagar incêndios. Pensa no site da sua empresa, se ele cair quando a TI fizer uma atualização é provável erro de deploy.

Minha experiência pessoal

Fazer deploy com WordPress tem sido umas das minhas maiores dificuldades como desenvolvedor, pois as linguagens e pastas do sistema são uma “bagunça”, temos PHP, misturado com JavaScript, HTML, CSS inline e arquivos separados, muitas configurações em locais diferentes, podem estar no código e no banco de dados. Pastas que são substituídas totalmente com atualizações do WordPress e pastas que não são tocadas.

Nos meus projetos pessoais, antes de ter uma “estrutura de deploy”, entre 1998 e 2010, fazia os updates da forma mais tradicional (e ainda usada por muitas empresas em 2020), terminava algum update e utilizava um sistema de FTP, que listava os arquivos alterados mais recentemente. Assim bastava subir e trocar, por FTP, os arquivos. Eficiente, econômico, mas sem controle de versão, além de não permitir múltiplas pessoas trabalharem no mesmo projeto ao mesmo tempo (de forma eficiente).

Uma solução inicial, ainda em 2011, foi utilizar o Dropbox na minha máquina local de desenvolvimento e instalar o Dropbox no servidor, todas as mudanças eram transferidas automaticamente, existia controle de versão de arquivos, porém sofria por muitos aspectos, deletar um arquivo acidentalmente podia derrubar o sistema inteiro, não conseguia trabalhar em arquivos e fazer as entregas por partes, antes da funcionalidade inteira estar pronta, poderia derrubar o sistema, o que acontecia era os temidos “testes em produção”.

Assim, ao final de 2012 me foi finalmente apresentado o git, sistema de versionamento de projetos, ali a minha mente “explodiu”, finalmente entendi como grandes empresas trabalham com grandes projetos. Aprendi o básico, commits, push, pull e o básico do básico de branchs.

Neste projeto de cliente aprendi a commitar na branch master e o gestor de TI dava o pull em produção quando tudo estava pronto. Ainda havia um grande problema, sendo WordPress e o banco de dados? Muitos vão rir, mas colocava o dump na raíz do git, funciona e não é tão estúpido, se tiver numa pasta acima do conteúdo público, trabalhoso sim, mas versiona.

Então basicamente não tinha uma estrutura de deploy muito boa, copiei esse sistema para os meus projetos pessoais, optava por velocidade e facilidade de deploy, abrindo mão de alguns quesitos de segurança. Migrei todos os meus projetos para o git ao longo de 2013, este conhecimento de git me alavancou e me fez conseguir uma boa colocação no mercado, trabalhei em uma empresa com muitos profissionais no mesmo projeto. Ali tinha review de pull request.

Houve um hiato de programação na minha carreira durante meu mestrado entre 2014-2016, voltei a estudar programação pois em 3 anos fiquei muito desatualizado. Retomei meus projetos pessoais e decidi criar um sistema próprio para deploy (em shell) de banco de dados chamado F5 Sites WordPress MySQL Manager (que uso até hoje). Percebi que 90% das configurações ficam na tabela wp_options, então com esse sistema subia para produção uma cópia desta tabela de forma inovadora, fazia um dump específico desta tabela (prefixo do projeto)_options, comprimia, enviava via SSH para o servidor, conectava no servidor e fazia um cópia de segurança da tabela e import do dump. Em paralelo com um script simples de push e pull em máquina de dev e produção, a velocidade de entrega disparou.

Esteira de Deploy: Jenkis, SonarQube e GitFlow e live

Tudo ia mais ou menos bem, alguns problemas contornáveis, como git no servidor de produção (!), porém para o nível de requerimento exigidos para um projeto pessoal de uma pessoa só, tudo ok. Um novo projeto aparece no radar, um grande portal WordPress de um cliente como forte estrutura de TI.

Com uma equipe de especialistas, recursos e investimentos pesados por anos, uma estrutura conhecida como “esteira” foi implementada pela equipe. Conheci novas tecnologias, promissoras, parrudas, inteligentes e funcionais. Com o Jenkis é possível fazer uma estrutura de deploy realmente automatizada, fazendo diversos processos testes antes da entrega antes do servidor de produção.

SonarQube permite uma análise automática de qualidade de código e brechas de seguranças antes do pull request, pelo próprio pipeline do BitBucket. GitFlow é uma técnica interessante de organizar commits e merges de branches de dev, homolog, produção e hotfixes. E git live é um forma de manter cópias de gits sem a pasta .git no servidor remoto.

Assim em 2020 conheci um processo muito forte, mas não a prova de bugs e erros. Ainda fica a minha premissa pessoal que sistema ou processo nenhuma vale mais que um profissional experiente e/ou atencioso.

Referências:

https://roselleebarle.com/wordpress-auto-deploy-using-git-jenkins/

A Jenkins Pipeline for WordPress Projects

https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-16-04

https://www.digitalocean.com/community/tutorials/how-to-configure-jenkins-with-ssl-using-an-nginx-reverse-proxy

https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-in-jenkins-on-ubuntu-16-04

https://www.google.com/search?q=deploy+wordpress+with+git

https://tableless.com.br/deploy-usando-git-pull-e-hooks/

https://git-scm.com/book/en/v2/Git-Tools-Submodules

https://git-scm.com/docs/git-submodule

https://www.ostraining.com/blog/wordpress/deploy-git-wordpress/

WordPress Deployment Part 3: Deploying WordPress Using Git

http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/

https://github.com/vicenteguerra/git-deploy

https://wppusher.com/wordpress-git-course

https://medium.com/@jmarhee/running-multiple-web-applications-on-a-docker-host-with-apache-85f673f02803

https://www.atlassian.com/git/tutorials/comparing-workflows

https://www.atlassian.com/git/tutorials/comparing-workflows

Ativando WordPress Multisite (MU)

Também conhecido com WordPress network essa funcionalidade permite criar vários blogs na mesma instalação do WordPress, que compartilham plugins e temas, é uma das ferramentas mais avançadas do sistema, é como multiplicar o poder do WordPress por mil. Lembre-se de fazer backup da sua instalação. Para quem gosta de tutoriais rápidos, vamos direto ao passos.

Passo 1 – Habilite multisite no wp-config.php
Existem dois tipos de redes, que operam em subdomínios e subpastas, vamos tratar somente da segunda opção que é mais simples de ativar, acesse o link na referência para o tutorial completo. Cole o código abaixo na última linha do wp-config.php, salve e não feche o arquivo ainda.

/* Multisite */
define('WP_ALLOW_MULTISITE', true);

Passo 2 – Ative a rede pelo painel

Ferramentas -> Instalação da Rede
Ferramentas -> Instalação da Rede

Um novo item irá aparecer no seu painel, em Ferramentas -> Instalação da Rede. Vai pedir para você desativar os plugins antes de prosseguir.

Depois de ativada a rede você vai ter que colar dois trechos de códigos, um no wp-config.php e outro no .htaccess, que serão exibidos se tudo correr bem.

Passo 3 – Painel do administrador

Para instalar plugins, temas e atualizações surgiu um novo painel, chamado painel do administrador. Se você criar um blog para um usuário ele não vai poder instalar um plugin, sempre que você precisar instalar um plugin vai ter que acessar o painel da rede e depois voltar para o cada blog e ativar. Dica, se você usa o plugin BuddyPress vai ter que colar esse código no wp-config:


/* Enable BuddyPress Multisite*/
define ( 'BP_ENABLE_MULTIBLOG', true );

Referências

http://codex.wordpress.org/Create_A_Network – Página oficial que ensina a ativar a rede de blogs com muito mais informação, em inglês