Quero compartilhar algumas impressões sobre a utilidade ou inutilidade de uma ferramenta como o painel de controle para um projeto web comercial de um único servidor, considerando que há um administrador muito part-time. A história começou há alguns anos, quando conhecidos de conhecidos me pediram para auxiliar na compra de um negócio — um site de notícias — do ponto de vista técnico. Foi necessário compreender um pouco sobre o que estava funcionando, garantir que todos os requisitos necessários fossem entregues de forma adequada e em volume, e estrategicamente avaliar o que poderia ser melhorado.
O negócio foi fechado, o programador tornou-se desnecessário. Fim. Na verdade, não.
O site rodava em uma VM de dois núcleos com 4 GB na Linode, em um Debian 5 ultrapassado com um uptime de 400 dias e com uma lista de pacotes não atualizados assim. A parte web estava em um CMS desenvolvido sob medida, usando nginx, php5.3 FPM, mysql otimizado com Percona. Em princípio, funcionava.
Paralelamente às conversas comigo, o novo proprietário procurava um programador para alinhar o projeto às expectativas. Ele encontrou. O programador avaliou o tráfego e os volumes e decidiu que sabia como otimizar e gerenciar custos. Ele migrou todo o site para um hosting compartilhado de 700 rublos, sob a administração de um IS****er que ele conhecia. Alguns dias depois, nova ligação do proprietário: "tudo está lento e parece que fomos invadidos". Tentei corrigir a situação através do painel, mas após um tempo de tentativas infrutíferas de mudar a versão do PHP ou o handler de fcgi para fpm, desisti e fui para o shell. Lá eu encontrei o debug ativado, que expunha na internet a senha do mysql, permissões 777 em algumas pastas, que já estavam comprometidas com malware, entre outras coisas. O proprietário percebeu e decidiu que economizar em hosting, programador e em um administrador que desse uma olhadinha de vez em quando, era errado.
Estamos indo para o RuVDS. Um pouco mais perto do que a britânica Linode, e se for preciso armazenar dados pessoais e tudo isso, não será necessário mudar novamente. Como o projeto estava sendo planejado para expansão, pegamos uma VM "para crescer": 4 núcleos, 8 GB de memória, 80 GB de disco. Não que eu não saiba lidar com configurações do nginx manualmente, apenas não tinha entusiasmo para lidar com este projeto de forma tão próxima (ver acima sobre trabalho em meio período). Então, instalei o Plesk (aqui vou pular os detalhes da instalação, pois na verdade não existem muitos: executei o instalador, defini uma senha para o administrador, inseri a chave – tudo isso), na época era a versão 17.0. As configurações básicas funcionam razoavelmente bem de imediato, há o fail2ban e as últimas versões disponíveis do PHP e nginx.
Acho que vale a pena parar e explicar por que escolhi isso. Como faço esse tipo de coisa raramente, e não tenho ferramentas ou templates especiais para cada caso, ficou claro que precisava de alguma automatização para as tarefas básicas, para que, em primeiro lugar, fosse rápido, em segundo, seguro e, em terceiro, que as melhores práticas já estivessem implementadas por alguém.
Então, instalei. Economizei bastante tempo, o reinício do site no novo servidor foi quase instantâneo. Resta apenas cortar a configuração do MySQL, alocando metade da memória e aumentando o número de buffer pools, e destinar metade dos núcleos ao nginx (o Plesk não altera as configurações globais), e ao longo de alguns dias, acessar o shell para verificar as estatísticas do mysqltuner. Ah, e comprei o ImunifyAV pago do catálogo de extensões, para me livrar da malware. Encontraram cerca de 11.000 arquivos infectados. A parte desagradável é que trechos de código ofuscado estavam infiltrados na parte estática, e limpar isso manualmente seria bastante tedioso. Primeiro tentei o ClamAV, mas descobri que ele não lida com esse tipo de coisa, enquanto o ImunifyAV conseguiu. Além disso, os arquivos recuperados permanecem funcionais, apenas a parte com a malware é removida.
A aritmética é simples: 50$ por mês pela VM, 10$ pelo Plesk (na verdade menos, porque compramos para um ano com um desconto de dois meses) e 3$ pelo antivírus. Ou muitos pacotes de dinheiro pelo meu tempo, que eu passaria no servidor nos primeiros momentos limpando esses estábulos manualmente. O proprietário ficou bastante satisfeito com esse arranjo.
Enquanto isso, encontramos um novo programador. Fazemos um acordo sobre a distribuição de responsabilidades, criamos um subdomínio para a versão de teste e o trabalho começou. Ele estava desenvolvendo a nova versão do site em Laravel, enquanto eu monitorava o fail2ban%.
Curiosamente, o fluxo de curiosos não para e a lista de endereços banidos sempre contém cerca de cem endereços. O efeito é interessante: geralmente, quando entro no shell, vejo cerca de 20.000 a 30.000 tentativas de acesso SSH sem sucesso. Com o fail2ban ativado, isso cai para cerca de 70. O esforço investido: 0. Infelizmente, não passou sem um pouco de amargura. Por padrão, o WAF (modsecurity) estava 'semi-ativado': em modo de detecção. Isso significa que ele registrava atividades suspeitas no log, mas, na verdade, não tomava nenhuma ação. E o fail2ban analisava todos os logs, de acordo com os jails ativados, e bloqueava tudo que se movia. Assim, acabamos banindo metade da redação :D. Tivemos que desativar esse jail e adicionar os IPs necessários à lista de permissões por segurança. O esforço investido: clicar duas vezes com o mouse e ensinar os editores a dizerem seu IP.
O que agradou imediatamente ao programador foi a possibilidade de carregar bancos de dados diretamente no painel e o rápido acesso ao phpMyAdmin.
O que me agradou foram os logs e backups. Os logs são gravados e rotacionados automaticamente; os backups são configurados de forma muito simples. No período mais lento, é feito um backup completo de cerca de 10 gigas, seguido de backups incrementais diariamente, com cerca de 200 megabytes, ao longo da semana. A restauração é granular, até arquivos ou bancos de dados específicos. Se for necessário restaurar a partir de um incremental, não há necessidade de lidar primeiro com o completo e a restauração de toda a cadeia, o Plesk faz tudo isso automaticamente. Os backups podem ser enviados para qualquer lugar: FTP, Dropbox, S3 bucket, Google Drive, etc.
Dia D: o programador finalmente terminou o novo motor, nós o colocamos em produção, importamos os dados antigos e nos sentamos para escolher a cor de nossos futuros Maseratis. Até agora, ainda estamos escolhendo.
Os primeiros problemas começaram. O novo site estava, como esperado, mais pesado que o antigo, mas o verdadeiro desafio foi que, para atrair tráfego, estávamos usando, entre outras coisas, o Yandex.Zen, que trazia visitantes em massa. O site estava enfrentando dificuldades com 150 conexões simultâneas (não estou falando sobre RPS porque não medimos). Começamos a ajustar as configurações do php_fpm.
Ops, já estamos mantendo 500 conexões. À medida que a cartão de crédito é aplicado aos fundos de promoção, as ondas de tráfego aumentaram. O próximo marco são 1000 conexões simultâneas. Aqui foi necessário refinar o código e examinar a alma do musculo. O Plesk não ajudou nisso, mas não esperávamos muito. Ativamos o log de consultas lentas, adicionamos índices ao banco de dados, removemos consultas desnecessárias do código e revisamos novamente a configuração do MySQL com as dicas do mysqltuner.
Novo desafio — 2000 conexões. Justamente saiu a versão Plesk 17.8, que além de tudo, trouxe o cache do nginx. Atualizamos (surpreendentemente fácil). Testamos. Funciona! E logo de cara, surgiu um problema, o feed do Yandex Zen deixou de funcionar. O site opera, mas o feed não. Sem o feed, sem tráfego. A tensão aumenta. Sob pressão das circunstâncias e pela falta de ideias, fui logo estracear o nginx e descobri o que estava errado. Acontece que em algum momento o nginx imprudentemente cacheou uma resposta de erro 500 como resposta ao get feed.xml do Yandex. Corrigimos, adicionando exceções nas configurações de cache:
É claro que o proprietário precisa de MAIS, as ondas estão aumentando lentamente. Por enquanto estamos lidando, mas começamos a experimentar com o memcached desde cedo, ainda bem que o Laravel o suporta quase que diretamente. Não queria instalar o memcached manualmente para 'brincar', então usamos uma imagem do Docker. Direto do painel.
Bom, na verdade, tive que entrar no shell e instalar o módulo pelo pecl. Diretamente por . Não há nada a dizer sobre o aumento da taxa de transferência até agora, não houve fluxos grandes o suficiente. O motor do site se conectou no localhost:11211, as estatísticas aparecem, a memória está sendo usada. Se funcionar bem, vamos ver o que fazer depois. Ou deixamos assim, ou instalamos um 'real' diretamente no sistema. Ou tentamos o redis da mesma forma.
Depois foi necessário adicionar um serviço de envio de e-mails. Sem relay, apenas autenticação smtp. Criei um endereço de e-mail, e por suas credenciais fazemos o envio pelo PHP.
Recentemente saiu o Plesk Obsidian (18.0), atualizamos com base na experiência anterior sem medo. Tudo ocorreu de forma muito suave, não há nada a relatar. De bom, a qualidade da interface melhorou muito, se modernizou e ficou mais conveniente em alguns pontos. Uma coisa legal é o Advanced Monitoring no Grafana.
Ainda não examinei em detalhes, mas é possível, por exemplo, configurar alertas para qualquer parâmetro por e-mail. Para o proprietário, lol.
Já que estou falando sobre a interface, ela é responsiva e realmente funciona bem no telefone. Nos primeiros estágios, enquanto tentávamos encontrar as configurações ideais do PHP e outras coisas, isso ajudou muito. E especialmente quando o programador, em um surto de entusiasmo pelo trabalho, faz algo às 23 horas, e eu, em um surto de entusiasmo pelo trabalho, estou bebendo vodka no banheiro, e PRECISO urgentemente mudar algo.
Ah, a propósito. Na imagem, pode-se ver que o PHP Composer apareceu. Ainda não brincamos com ele, mas, digamos, para o Laravel, ele pode economizar alguns logins no shell e um tempo na instalação de dependências. Há um sistema semelhante para Node.JS e Ruby.
Com o SSL, tudo é simples. Se o domínio resolve para onde deve, o Let’s Encrypt é feito com um clique e se atualiza sozinho, tanto para o domínio quanto para subdomínios e até serviços de e-mail.
O Plesk, como software, é bastante agradável e estável atualmente. Ele se atualiza sozinho e o sistema de forma silenciosa, consome poucos recursos e funciona de maneira precisa. Não me lembro de ter enfrentado um problema que fosse um defeito claro do produto. Houveram problemas, claro, mas ou eram por causa da configuração imperfeita ou em alguma interseção, então não há muito o que recriminar. A experiência de usar o Plesk é, no geral, agradável. O que ele não possui, e isso deve ser entendido, é qualquer tipo de (qualquer) clusterização. Nem LB, nem HA. É possível tentar, mas o esforço investido seria tanto que é melhor fazer algo de outra forma desde o início.
Acho que podemos resumir. Para o caso em que não há administrador, ou é escasso, quando o preço do hosting e do(s) site(s) nele excede, digamos, 100 u.e., quando não se fala de um compartilhamento barato com 1500 sites no servidor, quando a decisão está em escolher entre contratar um administrador em meio período, ou comprar um software e trazer um administrador por 'metade do preço', ou até mesmo não ter um — definitivamente faz sentido. Do ponto de vista de um administrador remoto — o mesmo. 10$ por mês, economiza tempo e proporciona flexibilidade no trabalho com um valor muito maior. Se, por exemplo, me pedirem fortemente para assumir um projeto semelhante, vou insistir na migração para o Plesk.maiorQuero compartilhar algumas impressões sobre a necessidade ou desnecessidade de algo como um painel de controle para um projeto web comercial em um único servidor com um administrador muito part-time.
Fonte: habr.com
