Quiero compartir algunas impresiones sobre la necesidad o no de un panel de control para un proyecto web comercial de un solo servidor con un administrador muy a tiempo parcial. La historia comenzó hace un par de años, cuando conocidos de conocidos me pidieron que los ayudara con la compra de un negocio: un sitio web de noticias, desde el punto de vista técnico. Era necesario comprender un poco cómo funcionaba todo, asegurarse de que todos los requisitos necesarios se entregaran en la forma y volumen adecuados, y calcular estratégicamente qué se podía mejorar.
La transacción se completó, el violinista dejó de ser necesario. Fin. En realidad, no.
El sitio estaba funcionando en una máquina virtual de dos núcleos con 4 GB en Linode, en una especie de Debian5 anticuado con un tiempo de actividad de más de 400 días y una lista de paquetes no actualizados como esta. La parte web estaba en un CMS personalizado, nginx, php5.3 FPM, mysql optimizado con Percona. En principio, funcionaba.
Paralelamente a las conversaciones conmigo, el nuevo propietario buscaba un programador para adaptar el proyecto a las expectativas. Lo encontró. El programador evaluó el tráfico y los volúmenes y decidió que sabía cómo optimizar y gestionar costos. Migró todo el sitio a un hosting compartido de 700 rublos bajo la gestión de su proveedor IS****er habitual. Después de unos días, volvió a llamar el propietario: “todo se está ralentizando y parece que nos han hackeado”. Intenté resolver la situación a través del panel, pero después de algún tiempo de intentos infructuosos de cambiar la versión de PHP o el manejador de fcgi a fpm, me rendí y fui a la shell. Allí encontré el depurador activado, que exponía a toda la internet la contraseña de MySQL, permisos 777 en algunas carpetas, que en ese momento estaban a punto de explotar por malware colapsado y cosas similares. El propietario se dio cuenta y decidió que ahorrar en hosting, en programador y en un administrador que echara un ojo de vez en cuando, era incorrecto.
Nos dirigimos a RuVDS. Un poco más cerca que la británica Linode, y si en algún momento queremos almacenar datos personales y todo eso, no será necesario mudarse a otro lado. Como se planeaba expandir el proyecto, se optó por una VM "a futuro": 4 núcleos, 8 GB de RAM, 80 GB de disco. No es que no sepa manejar configuraciones de nginx manualmente, simplemente no tenía el entusiasmo para involucrarme tan íntimamente en este proyecto (ver arriba sobre trabajo a tiempo parcial). Por eso, instalé Plesk (aquí omitiré los detalles de la instalación, porque, en resumen, no hay mucho que contar: inicié el instalador, establecí una contraseña para el administrador, introduje la clave - todo), en ese momento era la versión 17.0. Las configuraciones básicas funcionan razonablemente bien de forma predeterminada, hay fail2ban y las versiones más recientes de PHP y nginx disponibles.
Probablemente, vale la pena detenerse a explicar por qué él. Dado que rara vez me dedico a estas cosas, y no tengo ninguna herramienta o plantilla especial para cada caso, era evidente que necesitaba algún tipo de automatización de las cosas básicas, para que, en primer lugar, fuera rápido, en segundo lugar, seguro, y en tercer lugar, que alguien ya hubiera implementado todas las mejores prácticas.
Así que lo instalé. Ahorré bastante tiempo, el reinicio del sitio en el nuevo servidor fue prácticamente instantáneo. Solo quedaba ajustar la configuración de MySQL, dándole la mitad de la memoria y aumentándole el número de buffer pools, y asignar la mitad de los núcleos a nginx (Plesk no toca las configuraciones globales), y durante un par de días entrar en el shell para revisar las estadísticas de mysqltuner. Ah, y compré ImunifyAV de pago del catálogo de extensiones, para deshacerme del malware que había sido subido. Encontré alrededor de 11,000 archivos infectados. La molestia es que en la estática se inyectaron fragmentos ofuscados de código, y limpiarlo a mano habría sido bastante aburrido. Primero probé ClamAV, pero, como resultó, no detecta ese tipo de cosas, mientras que ImunifyAV sí pudo. Además, los archivos curados permanecen en estado operativo, solamente se elimina la parte con malware.
La aritmética es sencilla: 50$ al mes por la VM, 10$ por Plesk (en realidad menos, porque lo compramos por un año con un descuento de dos meses) y 3$ por el antivirus. O, alternativamente, un montón de maletas de dinero por mi tiempo que pasaría en el servidor al principio lidiando con estos desastres manualmente. Al dueño le pareció bien este arreglo.
Mientras tanto, encontramos un nuevo programador. Negociamos con él la distribución de responsabilidades, creamos un subdominio para la versión de prueba y la trabajo comenzó. Él estaba desarrollando la nueva versión del sitio en Laravel, mientras yo revisaba fail2ban%).
Es interesante que el flujo de curiosos no cesa y en la lista de IP bloqueadas siempre hay alrededor de cien direcciones. El efecto es curioso: generalmente, si entro en la shell, en el saludo veo alrededor de 20000-30000 intentos fallidos de acceso por SSH. Con fail2ban activado, hay aproximadamente 70. Esfuerzo invertido: 0. Lamentablemente, no todo fue perfecto. Por defecto, el WAF (modsecurity) estaba "medio activado": en modo de detección. Es decir, registraba actividad sospechosa en el log, pero en realidad no tomaba ninguna acción. Y fail2ban revisaba todos los logs sin distinción, de acuerdo con los jails activados, y bloqueaba todo lo que se movía. Así que bloqueamos a la mitad del equipo :D. Tuvimos que desactivar ese jail y agregar las IP necesarias a la lista blanca por seguridad. Esfuerzos invertidos: dos clics y enseñar a los editores a decir su dirección IP.
Lo que le gustó al programador de inmediato fue la posibilidad de cargar bases de datos directamente en el panel y el acceso rápido a phpMyAdmin.
Lo que me gustó a mí fueron los logs y las copias de seguridad. Los logs se registran y rotan automáticamente; las copias de seguridad se configuran de manera muy sencilla. En el momento más inactivo se hace una copia de seguridad completa de unos 10 gigas, y luego cada día una incremental, de alrededor de 200 megabytes, durante una semana. La recuperación es granular, hasta un archivo específico o una base de datos. Si es necesario restaurar desde una incremental, no hay que lidiar antes con la completa y restaurar toda la cadena; Plesk se encarga de todo. Se pueden cargar las copias de seguridad en cualquier lugar: en ftp, en Dropbox, en un bucket de S3, en Google Drive, etc.
Día D: el programador finalmente terminó el nuevo motor, lo subimos a producción, importamos los datos antiguos y nos sentamos a elegir el color de nuestros futuros Maserati. Todavía estamos eligiendo.
Comenzaron los primeros problemas. El nuevo sitio era, como era de esperar, más pesado que el anterior, pero la verdadera trampa fue que para atraer tráfico utilizábamos entre otras cosas Yandex.Zen, que atraía visitantes a montones. El sitio fallaba con 150 conexiones simultáneas (no hablo de RPS porque no lo medimos). Comenzamos a presionar botones y girar perillas en la configuración de php_fpm:
¡Oh, ya soporta 500 conexiones! A medida que se aplicaba la tarjeta de crédito a los fondos de promoción, el tráfico empezó a aumentar. El siguiente hito son 1000 conexiones simultáneas. Aquí tuvimos que refinar el código y observar el rendimiento del servidor. Plesk no ayudó en esto, pero no se esperaba mucho de él. Activamos el registro de consultas lentas, agregamos índices a la base de datos, eliminamos consultas innecesarias del código y revisamos nuevamente la configuración de MySQL según las recomendaciones de mysqltuner.
El nuevo desafío son 2000 conexiones. Justo salió la versión 17.8 de Plesk, que además incluyó caché de Nginx. Actualizamos (sorprendentemente fácil). Probaremos. ¡Funciona! Y de inmediato ocurrió un problema: dejó de funcionar el feed de Yandex.Zen. El sitio funciona, pero el feed no. Sin el feed, no hay tráfico. La tensión aumenta. Bajo presión y por falta de creatividad, empecé a rastrear Nginx y encontré lo que estaba buscando. Resulta que en algún momento el tonto de Nginx almacenó en caché un error 500 como respuesta al request de Yandex para feed.xml. Lo corregimos agregando excepciones a la configuración de caché:
Es evidente que el propietario necesita más, el tráfico aumenta lentamente. Mientras tanto, estamos manejando, pero comenzamos a experimentar con memcached, afortunadamente Laravel lo soporta casi sin configuración adicional. No quería instalar memcached a mano para 'jugar', así que instalamos la imagen de Docker directamente desde el panel.
Bueno, está bien, lo admito, tuve que entrar en la shell y instalar el módulo a través de pecl. Directamente desde . Por ahora no puedo comentar sobre el aumento en la capacidad de procesamiento, no ha habido grandes picos aún. El motor del sitio se conectó en localhost:11211, las estadísticas se muestran, se está utilizando memoria. Si es satisfactorio, veremos qué hacer después. O lo dejaremos así, o instalaremos una versión 'real' directamente en el sistema. O probaremos con Redis de la misma manera.
Luego fue necesario implementar una campaña de correo electrónico. Nada de relay, solo autenticación smtp. Creé una dirección de correo y a través de sus credenciales, realizamos el envío usando PHP.
No hace mucho salió Plesk Obsidian (18.0), actualizamos sin temor, basándonos en experiencias pasadas. Todo fue muy fluido, no hay mucho que contar. Lo positivo es que la calidad de la interfaz ha mejorado notablemente, se modernizó y se volvió más fácil de usar en algunos aspectos. La función de Monitoreo Avanzado en Grafana es genial.
Aunque aún no he profundizado en ella, se pueden configurar alertas por cualquier parámetro a correo electrónico. Al propietario le encantará, jaja.
Dado que hablo sobre la interfaz, es adaptable y realmente funciona bastante bien en el teléfono. En las etapas iniciales, mientras intentábamos encontrar la configuración óptima de PHP y otros aspectos, esto nos ayudó mucho. Y especialmente cuando el programador, en un acceso de entusiasmo laboral, hace algo a las 11 PM, y yo, en un acceso de entusiasmo laboral, bebo vodka en la bañera, y URGENTEMENTE necesito cambiar algo.
Oh, por cierto. En la imagen se puede ver que ha aparecido PHP Composer. Aún no hemos jugado con él, pero, digamos, para Laravel puede ahorrar un par de inicios de sesión en el shell y algo de tiempo en la instalación de dependencias. Existe un sistema similar para Node.JS y Ruby.
Con SSL todo es simple. Si el dominio se resuelve donde se supone, Let’s Encrypt se hace con un clic y se actualiza solo, tanto para el dominio principal como para los subdominios, e incluso para los servicios de correo.
El propio Plesk, como software en este momento, es bastante agradable y estable. Se actualiza a sí mismo y el sistema operativo silenciosamente, consume pocos recursos y funciona sin problemas. Ni siquiera recuerdo haber encontrado algo que fuera un defecto evidente del producto. Hubo problemas, por supuesto, pero fueron o por la falta de perfeccionamiento de la configuración, o en la intersección, así que no hay mucho de qué quejarse. La impresión de trabajar con Plesk es en general agradable. Lo que no tiene, y hay que entenderlo, es cualquier tipo de (cualquier) clúster. Ni LB ni HA. Se puede intentar, pero la cantidad de esfuerzo involucrado será tal que es mejor hacer algo diferente desde el principio.
Creo que se puede resumir. En el caso de que no haya administrador, o que haya poco, cuando el precio del hosting y de los sitios que gira en él supera, digamos, 100 u.e., cuando no se trata de un hosting barato con 1500 sitios en el servidor, y cuando la persona que toma la decisión tiene que elegir entre contratar un administrador a tiempo parcial, comprar software y asignar un administrador a "medio tiempo", o no tener uno en absoluto, definitivamente hay un sentido. Desde el punto de vista de un administrador remoto, lo mismo. 10$ al mes, ahorra tiempo y proporciona flexibilidad en el trabajo por una cantidad mucho mayor. Si, por ejemplo, me pidieran encarecidamente que asuma un proyecto similar, insistiría en trasladarlo a Plesk.mayor audiencia.Quiero compartir algunas impresiones sobre la necesidad o no de algo como un panel de control para un proyecto web comercial de un solo servidor con un administrador muy a tiempo parcial.
Fuente: habr.com
