Quero compartilhar algumas impressões sobre a necessidade ou a desnecessidade de algo como um painel de controle para um projeto comercial da Web de servidor único com um administrador de meio período. A história começou há alguns anos, quando conhecidos de amigos me pediram para acompanhar a compra de uma empresa - um site de notícias - do ponto de vista técnico. Era necessário entender um pouco o que estava trabalhando, garantir que todos os detalhes necessários fossem transferidos na forma e no volume adequados e descobrir estrategicamente o que poderia ser melhorado.
O acordo ocorreu, o violinista não era mais necessário. O fim Na verdade não.
O site estava rodando em um VMk dual-core de 4 GB no Linode, em algum Debian5 musgoso com tempo de atividade de 400 dias e uma lista de pacotes não atualizados. Web part em Samopisny TsMSke, nginx, php5.3 FPM, mysql ajustado em Percona. Em princípio, funcionou.
Paralelamente às conversas comigo, o novo proprietário procurava um programador para levar o projeto às expectativas. Encontrei. O programador avaliou o tráfego e os volumes e decidiu que era capaz de otimizar e gerenciar custos. Ele migrou o site inteiro para uma hospedagem compartilhada de 700 rublos, sob o controle de seu IS IS normal. Alguns dias depois, novamente uma ligação do proprietário: "tudo está diminuindo a velocidade e parece que estávamos quebrados". Tentei consertar a situação através do painel, mas após algumas tentativas infrutíferas de alterar a versão do PCP ou do manipulador de fcgi para fpm, desisti e entrei no shell. Lá encontrei a depuração incluída, que brilhava em toda a Internet com uma senha de um músculo, 777 em algumas pastas que, naquela época, estavam estalando devido a uma avalanche de malvari e jogos similares. O proprietário percebeu e decidiu que economizar na hospedagem, no programador e no administrador, que olharia de olho em como as coisas estão indo, está errado.
Nós estamos indo para o RuVDS. Um pouco mais perto do que o britânico Linode, e se você deseja armazenar dados pessoais e tudo isso de repente, não precisa se mudar para outro lugar. Como o projeto estava planejado para ser expandido, eles usaram o VMKU "para crescimento": 4 núcleos, 8 GB de memória, 80 GB de disco. Não é que eu não saiba usar as configurações do nginx com as mãos, apenas não tive o entusiasmo de fazer esse projeto tão intimamente (veja acima, em tempo parcial). Porque - coloque o Plesk (aqui vou omitir os detalhes da instalação, porque em geral eles não estão lá: lancei o instalador, configurei a senha do administrador, digitei a chave - tudo), na época era 17.0. As configurações básicas funcionam razoavelmente prontas para uso, existem fail2ban e as últimas versões disponíveis do PHP, nginx.
Provavelmente vale a pena parar e explicar o porquê. Como raramente faço essas coisas e não tenho ferramentas especiais e um conjunto de espaços em branco para cada caso, ficou claro que era necessário algum tipo de automação de coisas básicas, primeiro, rápido, segundo, com segurança e terceiro todas as práticas recomendadas alguém já implementou.
Então, pronto. Ele economizou tempo decentemente, reiniciar o site no novo servidor acabou sendo quase instantâneo. Restava mexer na configuração do músculo, fornecendo metade da memória e aumentando o número de buffer pools e dando metade dos núcleos ao nginx (o Splash não toca nas configurações globais) e entrando no shell por alguns dias para examinar as estatísticas do mysqltuner. Sim, e comprei um ImunifyAV pago do catálogo de extensões para me livrar dos malvari inundados. Havia algo em torno de 11.000 arquivos infectados. A abominação é que pedaços de código ofuscados despejavam a estática, e escová-lo com as mãos seria completamente monótono. No começo, tentei o ClamAV, mas ele não aceitou essas coisas, mas o ImunifyAV conseguiu. Além disso, os arquivos curados permanecem em condições de funcionamento, apenas uma parte do malware é removida.
A aritmética é simples: US $ 50 por mês para o VMku, US $ 10 para o Splash (na verdade, menos, porque você o comprou imediatamente por um ano com um desconto de dois meses) e US $ 3 para um antivírus. Ou muitas malas de dinheiro para o meu tempo, que eu gastaria no servidor a princípio, ajuntando esses estábulos manualmente. O proprietário está muito feliz com esse alinhamento.
Enquanto isso, eles encontraram um novo programador. Concordamos com ele na distribuição de responsabilidades, criamos um subdomínio para a versão de teste e o trabalho começou. Ele viu uma nova versão do site no Laravel, e eu olhei para fail2ban%).
Curiosamente, o fluxo de curiosos não para, e sempre há cerca de cem endereços na lista de endereços proibidos. O efeito é interessante: em particular, geralmente, quando vou ao shell, vejo cerca de 20000-30000 tentativas malsucedidas de entrar via SSH na saudação. Com o fail2ban ativado, cerca de 70. Esforço investido: 0. Infelizmente, houve uma queda de alcatrão. Por padrão, o WAF (modsecurity) era "semi-ativado": no modo de descoberta. Ou seja, ele escreveu atividades suspeitas no log, mas na verdade não tomou nenhuma ação. E o fail2ban leu indiscriminadamente todos os registros, de acordo com as prisões incluídas, e encharcou tudo que se mexia. Assim, banimos metade da equipe editorial: D. Eu tive que desativar essa prisão e colocar os endereços IP necessários na lista branca para garantir a confiabilidade. O esforço é investido: cutuque duas vezes com o mouse e ensine os editores a dizer seu endereço IP.
O que o programador gostou imediatamente foi a capacidade de fazer upload de bancos de dados diretamente no painel e o acesso rápido ao phpMyAdmin
O que eu gostei - logs e backups. Os logs são gravados e rotacionados para fora da caixa; os backups são configurados de maneira muito simples. Nos momentos mais lentos, é feito um backup completo, em algum lugar em 10 shows e, em seguida, todos os dias em incrementos de 200 megabytes, por uma semana. Recuperação granular para um arquivo ou banco de dados específico. Se você precisar restaurar a partir de incremental, não precisará se contorcer primeiro com a restauração completa e toda a cadeia, o Splash fará tudo sozinho. Você pode fazer o upload de backups em qualquer lugar: em ftp, dropbox, s3 bucket, google drive e muito mais.
Dia F: o programador finalmente terminou o novo mecanismo, o despejamos no produto, importamos os dados antigos e sentamos para escolher a cor do futuro Maserati. Ainda estamos escolhendo.
Os primeiros problemas começaram. O novo site era provavelmente mais pesado que o antigo, mas o verdadeiro rake foi que o Yandex.Zen foi usado entre outras coisas para atrair tráfego, que alcançou os visitantes em lotes. O site foi dobrado em 150 conexões simultâneas (não estou falando de RPS, porque não o medi). Começamos a apertar botões e girar botões na área de configurações do php_fpm:
Op, já possui 500 conexões. À medida que o cartão de crédito é aplicado aos meios de promoção, as ondas de tráfego aumentam. O próximo marco é de 1000 conexões simultâneas. Aqui eu tive que refrear o código e olhar para os músculos da minha alma. O respingo não ajudou, mas eles realmente não esperavam. Eles ativaram o log de consultas lentas, travaram índices no banco de dados, removeram consultas desnecessárias do código, vasculharam a configuração do mysql mais uma vez, seguindo o conselho do mysqltuner.
Novo desafio - 2000 conexões. Consegui apenas lançar a versão Plesk 17.8, na qual, entre outras coisas, danificava o cache do nginx. Atualizado (surpreendentemente fácil). Nós tentamos. Isso funciona! E então eles entraram suavemente, o feed Yandex.Zen parou de funcionar. O site está funcionando, o feed não está funcionando. O feed não funciona, sem tráfego. A atmosfera está esquentando. Sob a pressão das circunstâncias e a falta de imaginação, imediatamente subi ao nginx e encontrei o que estava procurando. Acontece que, em algum momento, o estúpido nginx armazenou em cache o 500º erro em tempo real, como uma resposta ao Yandex get feed.xml. Corrigido adicionando exceções às configurações de cache:
É claro que o proprietário precisa AINDA, as ondas estão aumentando lentamente. Enquanto estamos lidando com isso, mas começamos a experimentar antecipadamente o memcached, pois o Laravel o suporta quase que imediatamente. De alguma forma, eu não queria colocar o memcached em minhas mãos para brincar, então instalei a imagem do docker. Diretamente do painel.
Bem, estou mentindo, tive que entrar no shell e colocar o módulo no pecl. Diretamente de acordo com as
instruções . Não há nada a dizer sobre o aumento na taxa de transferência, não houve influxos grandes o suficiente. O mecanismo do site pegou no localhost: 11211, as estatísticas são mostradas, a memória está consumindo. Se você gosta, vamos ver o que fazer a seguir. Deixe assim ou coloque o "real" no Eixo. Ou tente redis da mesma maneira
Então eu precisava anexar uma lista de discussão. Sem relés, apenas autenticação SMTP. Eu tenho um endereço para correspondência, através dos detalhes através do PHP, fazemos o boletim.
Há não muito tempo, o Plesk Obsidian (18.0) foi lançado, atualizado de acordo com a experiência passada sem medo. Tudo correu muito bem, não há nada para falar. Do agradável - a interface melhorou muito a qualidade, modernizou-se e tornou-se mais conveniente em alguns lugares. Cool piece Monitoramento avançado no Grafana.
Ainda não descobri, mas você pode, por exemplo, configurar alertas para qualquer parâmetro no e-mail. Para o proprietário, lol.
Como estou falando da interface, ela é adaptável e funciona muito bem no telefone. Nos estágios iniciais, enquanto tentávamos encontrar as configurações ideais do PHP e outras coisas, isso ajudou muito. E, especialmente, quando um programador com um entusiasmo profissional faz algo às 23 horas, e eu bebo vodka no banho com um entusiasmo profissional, e urgentemente preciso mudar alguma coisa.
Ah, a propósito. Na foto, o PHP Composer apareceu. Ainda não brincamos com ele, mas, digamos, para o mesmo Laravel, ele pode salvar alguns logins no shell e algum tempo para instalar dependências. O mesmo sistema existe para Node.JS e Ruby.
Com o SSL, tudo é simples. Se o domínio resolver onde deveria estar, o Let's Encrypt será feito com um clique e será atualizado ainda mais, tanto no próprio domínio quanto nos subdomínios e até nos serviços de correio.
O próprio Plesk, como software, é atualmente bastante agradável e estável. Atualiza-se e o Eixo é silencioso, consome poucos recursos, funciona sem problemas. Eu nem me lembro que em algum lugar pisei em algo, o que seria um defeito claro no produto. Obviamente, houve problemas, mas eles foram causados por imperfeições da configuração ou em algum lugar do cruzamento, portanto não havia o que reclamar. As impressões de trabalhar com o Splash geralmente são agradáveis. O que está faltando nele, e é preciso entender isso, é qualquer (qualquer) cluster. Nem LB nem HA. Você pode tentar, mas haverá tanto esforço investido que é melhor fazer algo diferente inicialmente.
Eu acho que você pode resumir. Para o caso em que não há administrador, ou não é suficiente, quando o preço da hospedagem e o (s) site (s) rodando nele excederem, digamos 100u.e. vale a pena optar por contratar um administrador em período parcial ou comprar um software e obter um administrador por "meio período", ou simplesmente não iniciar - definitivamente faz sentido. Do ponto de vista do administrador remoto - a mesma coisa. 10 $ por mês, economiza tempo e oferece flexibilidade no trabalho por uma quantia muito grande. Se, por exemplo, me pedem fortemente que assuma um projeto semelhante, insistirei no transporte para Plesk.
