Eae devs, tudo sussa? Senta que lá vem #textao, hoje vou falar um pouco sobre a evolução da nossa stack de tooling e infra nos servidores e com isso como vocês já sabem, sempre vem uma historinha do mundo real, eu costumo dizer que cada problema enfrentado é a oportunidade de ganhar ainda mais experiência, é claro que nós queremos que tudo sempre funcione perfeitamente bem, mas falando sério, teria alguma graça?
Quem me conhece pessoalmente, acompanha pelo twitter ou aqui pelo blog (mesmo com os posts espaçados), sabe que eu gerencio minha própria estrutura de servidores, antes de nuvem virar modinha tendência eu já gerenciava minhas VPS’s e dedicadas para hospedar meus próprios projetos e projetos de clientes (Isso é quase um “Quando eu cheguei aqui era tudo mato”).
Não é que os servidores compartilhados não me atendessem, mas o plano que me atendia era sempre muito caro, e eu sempre fui mão de vaca, não é que eu quisesse SOMENTE economizar (apesar de ser um objetivo), mas por que não entregar mais gastando menos?
Foi então que eu conheci o mundo dos servidores não gerenciados, que são servidores em que você é o responsável praticamente por tudo, já falei várias vezes sobre eles aqui, basicamente é um servidor (virtual ou físico) que só vem com rede, internet e sistema, se você quiser hospedar sites, manter o ambiente seguro, ter alta redundância, backups, é tudo com VOCÊ, o famoso SVN ou Se Vira Negão, pelo fato do provedor não ter que cuidar de toda a estrutura isso acaba por baratear os preços
Nada disso cara pálida… existe uma grande diferença entre você subir um apache em um playground para fazer testes e entre você ter o seu servidor ali de cara pra internet, com os jovens incautos desocupados tentando subir uma shell, obter uma credencial de e-mail válida ou explorar algum bug de sistema para tomar o controle do seu servidor.
O cenário que eu tinha era claro, sistemas web desenvolvidos com PHP e websites institucionais que rodariam tranquilamente no linux, nada que me prendesse ao windows (por enquanto) então aluguei uma VPS linux e migrei parte dos websites e abaixo eu compartilho os pontos da minha experiência e os problemas que tive em ordem CRONOLÓGICA, é fácil de lembrar, alguns desses problemas me deixaram alguns dias sem dormir, até estarem totalmente resolvidos, vale lembrar que isso aqui está um pouco romantizado, por motivos óbvios vou omitir os clientes me xingando quando as merdas aconteciam, as milhares de vezes que fiz coisas na tentativa e erro onde toda vez era obrigado a zerar um ou mais servidores por que tinha feito MERDA FEIA.
Configuração/Dimensionamento
Com uma máquina Linux de 1GB de RAM e 2 vCores você com certeza faz mais do que uma máquina windows com a mesma configuração, ainda mais se você usar uma distro mais enxuta como as MINIMAL da vida, só que de nada adianta você ter os recursos se você não CONFIGURAR o uso deles adequadamente, o meu problema foi que por padrão o apache subia com um limite de requisições e quando esse limite era atingido ele simplesmente não respondia, mesmo que a máquina tivesse recursos para responder, então depois de dar um “yum install httpd” ou “apt-get install apache2”, NÃO ESQUEÇA de dimensionar corretamente o uso de recursos de acordo com a configuração do seu servidor.
Conheça os tipos de virtualização
Um detalhe muito importante ao contratar servidores virtuais é saber o tipo de virtualização em que seu servidor está, os dois principais tipos são KVM e OPENVZ, e existem diferenças consideráveis entre eles, mas a principal é que OPENVZ é virtualização em containers enquanto KVM é realmente um ambiente isolado (apesar de ainda compartilhar recursos físicos), o OPENVZ dá a possíbilidade de um provedor fazer overselling o que eu só fui descobrir depois do server ficar absurdamente lento do nada, já imaginam o que pode ter acontecido né?
Aprenda a configurar um servidor de e-mail
Uma coisa é você contratar uma hospedagem, onde já está tudo configurado bonitinho, e-mails caem na inbox, na maioria das vezes tudo funciona bem, caso não funcione você abre um chamado e as coisas voltam a funcionar. Outra coisa é você instalar o postfix e o roundcube em um servidor próprio e não entender por que a porcaria do e-mail do cliente não chega na inbox dos contatos dele. DKIM, SPF, DMARCe RDNS eram apenas siglas desconhecidas pra mim, quando você se depara com problemas de e-mail, você vai perceber que conhecer estes caras faz toda a diferença.
Preocupe-se com segurança e monitoramento
Segurança em servidores é uma questão complicada, tive dor de cabeça com várias coisas, um único ponto de falha pode comprometer todo o servidor, vou pontuar alguns pontos que acho mais importantes.
Limitação de recursos: Procure limitar recursos dos seus clientes, seja na quantidade de e-mail permitidos por dia, política de segurança para senhas de e-mail, processos abertos ou recursos de hardware, imagine o seguinte cenário, um funcionário do seu cliente usa uma senha fraca, essa senha é descoberta por um spammer, ele envia 10 mil e-mail de spam com essa conta, o IP do seu servidor entra em uma blacklist… Uma vez que um IP entra em uma blacklist, para remover é um parto, fora isso o seu cliente também pode subir uma aplicação com vulnerabilidade (oi wordpress desatualizado) e se você não limitar o acesso dele no servidor, você pode comprometer todos os outros clientes dentro do mesmo servidor ou em todo o cluster.
Monitoramento: Configure alguma ferramenta para monitorar os recursos e logs do servidor, receber alertas e notificações quando algo estiver fora do comum, ferramentas como vi(“vi //var/log/apache2/error.log” quem nunca? ), fail2ban, denyhosts, clamav e logwatch foram meu melhores amigos por muito tempo, pelo menos até eu descobrir o CSF que reúne tudo isso e mais alguns caras, nessa época não existia kibana e logstach pra fazer dashboard não, era tudo na unha.
Evite portas padrão: Sempre que possível procure usar portas diferentes para os serviços, mude o SSH da 22 para outra porta, tire o FTP da 21, se usa mysql, tire da porta 3306 e assim por diante, depois que eu comecei a usar ferramentas de monitoramento que eu percebi quantos computadores zumbi ficam aleatóriamente na internet tentando conectar nos serviços padrão com senhas baseadas em wordlist, uma combinação de fail2ban com denyhosts resolve isso de forma tranquila.
HealthCheck: utilize alguma ferramenta de healthcheck do servidor, pode ser até um uptimerobot da vida, todos os provedores vem com a balela de 99,9% de uptime, alguns garantem 100% (oi turnkey) mas vira e mexe tem umas quedas ocasionais, o reboot é tão rápido que as vezes você não percebe, exceto quando uma aplicação perde uma sessão “do nada” ou algo do gênero
Faça BACKUP constantemente, de preferência em outro servidor em área geográfica diferente.
Essa história de backup constante já vem desde 1900 e bolinha né? não é nenhuma novidade, mas as vezes você confia demais nos serviços do provedor, não cria uma rotina de backup e DE REPENTE, DO NADA… PERDE TUDO, mas aí você imagina que os caras tem um snapshop nem que seja semanal, o prejuízo não vai ser tão grande e… não, os caras simplesmente não tem snapshop e te mandam uma mensagem simplesmente pedindo desculpas e esperando que você consiga fazer a restauração do ambiente o mais rápido possível.
Isso não foi brincadeira, aconteceu mesmo, em uma dessas blackfridays da vida eu peguei dois servidores de um provedor, subi todo o stack, comecei a migrar algumas coisas, e quando já estava migrando quase tudo, BAM, os servidores cairam e eu simplesmente perdi tudo, não de UM mas dos DOIS servidores alugados, não preciso nem falar que eu cancelei as VPS e enchi o saco dos caras até eles devolverem o valor que paguei pelas máquinas.
Por sorte eu tinha um script CRON de backup diário que fazia backup em um servidor remoto em outro provedor, mas obviamente eu não contei isso pros caras e botei um terror falando que tinha perdido os dados de uma semana dos meus clientes e que eles tinham falido minha empresa, o que dependendo do caso, poderia realmente ser verdade.
Mantenha servidor de aplicação e servidor de banco de dados separados.
Demorou um pouco até eu perceber que MYSQL, POSTGRES e MONGODB são gulosos de recursos, um blog wordpress com muitos visitas simplesmente estava fazendo o MYSQL parar em todo o servidor de aplicação, depois disso a minha solução foi separar ambos e depois clusterizar, falo sobre clusterização abaixo.
Clusterize o banco de dados
Até aqui já vimos que não dá pra deixar todos os ovos em uma cesta só, por mais confiável que possa parecer um provedor, uma coisa é certa, shit happens ou simplesmente, merdas acontecem, o que podemos fazer é tentar minimizar, no caso de banco de dados, o ideal é trabalhar com replicação ou clusterização, combinado com técnicas de alta disponibilidade você vai ter um ambiente com 100% de uptime.
Não reinvente a roda
Essa daqui é meio controversa né? justo eu que optei por fazer um monte de coisa na unha tendo várias soluções “já prontas” no mercado? Quantas vezes eu já não passei fazendo coisas em código, ou script bash pra coisas que com uma simples consulta na internet eu poderia achar algum biblioteca ou script que fizesse a mesma coisa? Quer um exemplo? no início eu digitava os comandos um a um para instalar o apache, nginx, mysql dentre outras bibliotecas sempre que subia um novo servidor, depois eu descobri o cheff e subia tudo de uma vez com apenas um recipe e por fim eu decidi usar um hosting panel que simplesmente instalava tudo isso em uma pancada só, demorou um tempinho eu descobrir que existiam ótimos hosting panels gratuitos e que o mundo não se resumia apenas ao cpanel para o linux, só para constar, passei de EHCP para Sentora/ZPanel depois para VestaCP e finalmente estou usando o CWP (CentOs Web Panel), lembrando que nenhum desses painéis possui cluster embarcado (apenas o CWP que tem cluster de DNS), ou seja, clusterização deve ser feito na unha.
Planeje para ter alta disponibilidade (HA)
Alta disponibilidade só passa a ser uma necessidade quando você enfrenta um problema. Entrou para o meu hall de clientes, uma empresa com uma loja virtual, ou seja, é um sistema que tem que estar online 24hs, não para, não fecha nunca, pois é… até esse ponto temos o banco de dados em cluster, mas, e se o servidor cair? Pois é, faltou ter alta disponibilidade e replicação de arquivos em vários servidores, além de um balanceador de carga na frente de tudo isso, proxy reverso, cache de arquivos estáticos e tal. Pra resolver estes problemas foi usado nginx, cloudflare como balanceador de carga, csync para sincronização de arquivos em múltiplos servidores e redis para manter as sessões, nesse momento aqui eu já estava com umas 6 VPS e um servidor dedicado.
Aí, quando você acha que está de boas, atingiu um bom patamar, o que acontece? o mundo da tecnologia vem e lhe trás mais surpresas, dessa vez em uma evento da QCONSP eu fui apresentado ao mundo dos containers e com isso tendo que aprender mais coisas, novas ferramentas.
Containers – o divisor de águas
Quando eu entendi o funcionamento e as aplicabilidades do uso de containers minha mente começou a confabular um monte de coisas que eu poderia mudar nos meus servidores e consequentemente otimizar nas aplicações dos clientes, comecei a imaginar usos mirabolantes e emabarquei no EXCELENTE curso do Docker do Jefferson da Linux Tips, sério, o cara manja MUITO.
Uma semana depois do curso eu já tinha migrado algumas instâncias de mongoDB e MYSQL de projetos de clientes para container.
Kubernetes <3
Sabe aqueles usos mirabolantes do tópico acima? pois é, o kubernetes me ajudou em vários deles, quando fui apresentado a esse orquestrador de containers para mim foi um murro na cara, healthcheck, criação de novos containers automaticamente, escala, replicação automática, kubernetes e containers vem pra ficar e forte, chuto aí que como parece que a tendência é a cultura de devops, esses caras vão ter papel essencial nessa história, quem quiser se manter antenado e por que não, relevante no mercado, recomendo fortemente embarcar nessa e por sinal o Jefferson lançou um curso de kubernetes que está SENSACIONAL, saliento que não estou ganhando um centavo com a indicação, o cara simplesmente manja MUITO.
Mas nem tudo são flores, tive que basicamente aprender na marra e com a documentação um monte de coisas, dentre os principais problemas eu destaco: master master com kubernetes, monitoramento de recursos dos clusters kubernetes, crashs aleatórios de containers DO NADA (vale salientar que isso hoje em dia não acontece mais, mas geralmente era relacionado a problemas na aplicação que estava rodando no container que dava pau e o container não sabia para poder criar outro container).
Mas aí o manjador vai vir aqui falar, “ah, mas você é um trouxa, tudo isso aí tem na AMAZON, GOOGLE, NA (insira o nome de um big player da nuvem aqui)”.
Claro que tem jovem padawan, mas aí, que graça teria né? observem que eu conto isso aqui não como shameless self promotion mas apenas por que hoje eu acordei com vontade de contar essa história, de deixar registrado, tanto que demorei 6 horas organizando os fatos e escrevendo este post.
Conclusão
Então é isso, me ferrei muito até chegar ao patamar que eu cheguei hoje (não que seja alguma coisa, mas a guidi host saiu de cocô da mosca que sobrevoa o cocô do cavalo do bandido morto para cocô do cavalo do bandido morto) mas se tem uma coisa que fica, é o conhecimento, as experiências e essas ninguém pode tirar de mim, no final, se tudo desse errado, pelo menos eu poderia falar que eu tentei, como último aviso eu diria, estudem docker, containers e kubernetes pois tenho a impressão que esses vão ser “os caras” dos próximos anos.
A evolução da nossa stack,
