Gustaríame compartir algunhas impresións sobre a necesidade ou non dun panel de control para un proxecto web comercial dun só servidor cun administrador a tempo parcial. A historia comezou hai un par de anos, cando uns amigos de amigos me pediron que supervisase a compra dun negocio (un sitio web de noticias) desde un punto de vista técnico. Necesitaba obter unha comprensión básica do que se executaba en que, asegurarme de que todos os detalles necesarios se transferisen no formato e alcance axeitados e avaliar estratexicamente o que se podía mellorar.
O trato estaba feito, o violinista xa non era necesario. Fin. En realidade non.
O sitio executábase nunha máquina virtual de dobre núcleo e 4 GB en Linode, unha especie de Debian 5 pouco funcional con arredor de 400 días de funcionamento e unha lista enorme de paquetes desactualizados. O elemento web executaba un CMS personalizado, nginx, PHP 5.3 FPM e un Percona MySQL optimizado. Basicamente, funcionaba.
Mentres falaba comigo, o novo propietario estaba a buscar un programador para levar o proxecto á altura das expectativas. Atopou un. O programador avaliou o tráfico e o volume e decidiu que tiña un don para a optimización e a xestión de custos. Migrou todo o sitio a un servizo de aloxamento compartido de 700 rublos xestionado polo seu IS****er habitual. Uns días despois, o propietario volveu chamar: "Todo vai lento e parece que estamos rotos". Intentei arranxar a situación a través do panel de control, pero despois dalgúns intentos infrutuosos de cambiar a versión de PHP ou o controlador de fcgi a fpm, rendínme e entrei no shell. Alí, atopei a depuración activada, o que revelou un contrasinal para toda a internet, 777 para algúns cartafoles, que nese momento estaban cheos de malware e parvadas similares. O propietario decatouse e decidiu que escatimar en aloxamento, un programador e un administrador que vixiase de preto como ían as cousas estaba mal.
Estamos a mudarnos a RuVDS. Está un pouco máis preto que o Linode do Reino Unido, e se de súpeto queremos almacenar datos persoais e todo iso, non teremos que mudarnos a ningún outro lugar. Como o proxecto estaba planeado para a expansión, obtivemos unha máquina virtual "para o crecemento": 4 núcleos, 8 GB de memoria, 80 GB de espazo en disco. Non é que non saiba como axustar as configuracións de nginx manualmente, simplemente non tiña o entusiasmo para traballar neste proxecto de forma tan intima (vexa máis arriba sobre o traballo a tempo parcial). Entón, instalei Plesk (omitirei os detalles da instalación aquí, xa que realmente non hai ningún: execute o instalador, estableza un contrasinal para o administrador, introduza a clave e listo). Naquel momento, era a versión 17.0. A configuración básica funciona bastante ben desde o primeiro momento; ten fail2ban e as últimas versións dispoñibles de PHP e nginx.
Quizais debería facer unha pausa e explicar por que. Dado que raramente fago este tipo de traballo e non teño ferramentas especiais ou predefinicións para cada situación, estaba claro que se necesitaba certa automatización dos conceptos básicos, en primeiro lugar, para facelo rápido, en segundo lugar, seguro e, en terceiro lugar, para garantir que xa se implementaran todas as mellores prácticas.
Entón, instaleino. Aforrei bastante tempo e o sitio reiniciouse no novo servidor case ao instante. O único que quedaba era axustar a configuración do muscle, asignando a metade da memoria e aumentando o número de grupos de búfer, e asignando a metade dos núcleos a nginx (Splash non toca as configuracións globais) e logo iniciar sesión no shell durante un par de días para ver as estatísticas de mysqltuner. Ah, e merquei o ImunifyAV de pago do catálogo de extensións para desfacerme do malware que fora inxectado. Atoparon uns 11000 ficheiros infectados. O desagradable é que se estaban inxectando fragmentos de código ofuscados nos ficheiros estáticos e limpalos manualmente tería sido unha auténtica molestia. Probei primeiro ClamAV, pero resultou que non podía manexar esas cousas, mentres que ImunifyAV si. Ademais, os ficheiros limpos seguen funcionais; o fragmento infestado de malware simplemente elimínase.
As contas son sinxelas: 50 $ ao mes por VMware, 10 $ por Plesk (en realidade menos, porque compramos un ano completo cun desconto de dous meses) e 3 $ polo antivirus. Ou moito diñeiro polo tempo que tería pasado no servidor inicialmente, limpando manualmente estas desfeitas. O propietario quedou bastante satisfeito con este acordo.
Mentres tanto, atopamos un novo programador. Acordamos unha división de responsabilidades, creamos un subdominio para a versión de proba e puxémonos mans á obra. El estaba a construír unha nova versión do sitio en Laravel e eu estaba a vixiar fail2ban.
Curiosamente, o fluxo de xente curiosa nunca cesa, e a lista de prohibidos sempre contén arredor de cen enderezos. O efecto é interesante: en particular, cando normalmente inicio sesión no shell, a pantalla de benvida adoita mostrar uns 20000-30000 intentos de inicio de sesión SSH sen éxito. Con fail2ban activado, son uns 70. O esforzo investido: 0. Desafortunadamente, houbo un pequeno inconveniente. Por defecto, o WAF (modsecurity) estaba "semiactivado": en modo de detección. É dicir, rexistraba actividade sospeitosa no rexistro pero non realizaba ningunha acción real. E fail2ban lía indiscriminadamente todos os rexistros, segundo os jail activados, e eliminaba todo o que se movía. Así, prohibimos a metade do persoal editorial :D. Tivemos que desactivar este jail e engadir á lista branca os enderezos IP requiridos para maior fiabilidade. O esforzo investido foi un par de clics do rato e adestrar aos editores para que proporcionasen os seus enderezos IP.
O que lle gustou inmediatamente ao programador foi a capacidade de subir bases de datos directamente ao panel e o acceso rápido a phpMyAdmin
O que me gustou foron os rexistros e as copias de seguridade. Os rexistros escríbense e rótanse automaticamente de inmediato; as copias de seguridade son moi fáciles de configurar. Durante os momentos máis lentos, créase unha copia de seguridade completa duns 10 GB e, a continuación, créase unha copia de seguridade incremental de 200 MB diariamente durante unha semana. A restauración é granular, ata un ficheiro ou base de datos específicos. Se necesitas restaurar desde unha copia de seguridade incremental, non tes que preocuparte por facer unha copia de seguridade completa e despois restaurar toda a cadea: Plesk faino todo automaticamente. Podes cargar copias de seguridade en calquera lugar: a FTP, Dropbox, S3 Bucket, Google Drive, etc.
Día G: O programador finalmente rematou o novo motor, cargámolo en produción, importamos os datos antigos e sentámonos a escoller a cor dos nosos futuros Maseratis. Aínda estamos escollendo.
Comezaron os primeiros problemas. O novo sitio web era, como era de esperar, máis pesado que o antigo, pero o verdadeiro problema era que estaban a usar Yandex.Zen, entre outras cousas, para atraer tráfico, o que atraía a unha gran cantidade de visitantes. O sitio web colapsou con menos de 150 conexións simultáneas (non estou a falar do RPS, porque non o medimos). Comezaron a premer botóns e axustar periféricos na área de configuración de php_fpm:
Vaites, xa ten 500 conexións. A medida que aplicaba a miña tarxeta de crédito a ferramentas promocionais, as ondas de tráfico aumentaron. O seguinte fito foron as 1000 conexións simultáneas. Aquí, tiven que refinar o código e examinar o músculo. Splash non axudou, pero iso non era o que esperaba. Activei o rexistro de consultas lento, engadín índices á base de datos, eliminei as consultas innecesarias do código e volvín axustar a configuración de MySQL seguindo os consellos de mysqltuner.
Novo reto: 2000 conexións. Acababa de saír Plesk 17.8, que, entre outras cousas, engadía a caché de nginx. Actualizamos (sorprendentemente doado). Probámolo. Funciona! E entón atopamos un inconveniente: a fonte de Yandex.Zen deixou de funcionar. O sitio funciona, pero a fonte non funciona. A fonte non funciona, non hai tráfico. O ambiente está a quentarse. Baixo a presión das circunstancias e a falta de imaxinación, inmediatamente intentei rastrexar nginx e atopei o que estaba buscando. Resulta que nalgún momento, o estúpido nginx almacenou na caché un erro 500 perdido como resposta ao get feed.xml de Yandex. Arranxámolo engadindo excepcións á configuración da caché:
Está claro que o propietario necesita MÁIS, e as ondas están a aumentar lentamente. De momento imos xestionando a situación, pero comezamos a experimentar con memcached desde o principio, xa que Laravel o admite case de fábrica. Non queriamos instalar memcached manualmente só para xogar, así que instalamos unha imaxe de Docker. Directamente desde o panel.
Vale, estou mentindo, tiven que ir ao shell e instalar o módulo mediante pecl. De súpeto. Aínda non hai nada que informar sobre as melloras no rendemento; non houbo picos significativos. O motor do sitio está conectado a localhost:11211, as estatísticas móstranse, pero a memoria está a ser consumida. Se nos gusta, veremos que facer a continuación. Ou o deixaremos como está ou instalaremos o "real" directamente no sistema operativo. Ou probaremos Redis do mesmo xeito.
Entón necesitaba configurar un boletín informativo por correo electrónico. Sen retransmisións, só autenticación SMTP. Creei un enderezo de correo electrónico e usamos os seus datos para enviar o boletín informativo a través de PHP.
Plesk Obsidian (18.0) foi lanzado recentemente e actualizámolo sen medo, baseándonos na experiencia pasada. Todo foi moi ben, non hai nada que destacar. O lado positivo é que a interface mellorou significativamente, modernizouse e agora é máis fácil de usar nalgunhas áreas. A monitorización avanzada en Grafana é unha función xenial.
Aínda non o explorei en detalle, pero podes, por exemplo, configurar alertas por correo electrónico para calquera parámetro. Para o propietario, jajaja.
Falando da interface, é adaptable e funciona moi ben nun teléfono. Nas primeiras etapas, mentres tentabamos atopar a configuración óptima de PHP e outras cousas, isto foi de gran axuda. Especialmente cando o programador, nun arrebato de entusiasmo laboral, está traballando en algo ás 23:00, e eu estou nun arrebato de entusiasmo laboral, bebendo vodka na sauna, e necesito cambiar algo URXENTEMENTE.
Ah, por certo. Podes ver na imaxe que apareceu PHP Composer. Aínda non xogamos con el, pero por exemplo, para Laravel, pode aforrar un par de inicios de sesión na shell e algo de tempo instalando dependencias. Existe un sistema semellante para Node.JS e Ruby.
O SSL é sinxelo. Se o dominio se resolve como se espera, Let's Encrypt instálase cun só clic e actualízase automaticamente para o propio dominio, os subdominios e mesmo os servizos de correo electrónico.
O propio Plesk é actualmente bastante doado de usar e estable. Actualízase a si mesmo e o sistema operativo de forma silenciosa, usa poucos recursos e funciona sen problemas. Nin sequera recordo ningún problema que se considerase un defecto claro no produto. Houbo algúns problemas, por suposto, pero debíanse a unha configuración imperfecta ou a problemas nalgún momento do proceso, polo que non hai nada no que atoparlle fallos. En xeral, a miña experiencia con Plesk foi agradable. O que non ten, e é importante entendelo, é ningún tipo de agrupamento en clústeres. Sen LB, sen HA. Podes intentalo, pero o esforzo que supoña será tan grande que é mellor facer algo diferente desde o principio.
Creo que podemos resumir. Para unha situación na que non hai ningún administrador, ou só uns poucos, cando o custo do aloxamento e dos sitios web que se executan nel supera, por exemplo, os 100 dólares, cando non estamos a falar dun servidor compartido masivo con 1500 sitios, cando quen toma as decisións se enfronta á elección de contratar un administrador a tempo parcial, mercar software e contratar un administrador "a media xornada", ou non contratar ningún, definitivamente ten sentido. Desde a perspectiva dun administrador remoto, é o mesmo. 10 dólares ao mes aforran tempo e engaden flexibilidade para traballar a moi grande escala.оUnha cantidade maior. Se, por exemplo, me piden encarecidamente que me encargue dun proxecto semellante, insistirei en trasladalo a Plesk.
Fonte: www.habr.com
