Servidores y caso real: Vabiso.com

 Hola, bienvenido o bienvenida aquí otra semana más al podcast de Drupalizate. Estamos en una serie de episodios donde quiero hablar de casos reales. La semana pasada hablé de Babiso, que es uno de mis proyectos personales que hace un tiempo que ya creé. ¿Por qué de proyectos personales o side projects? Porque por temas legales y bueno, temas de privacidad, mejor no comentar temas de clientes que he tenido yo, o sea que la web era del cliente, básicamente porque seguramente no puedo recontar todo lo del proyecto, en cambio si el proyecto es mío propio pues puede ser lo que yo quiera, puedo contarlo todo. Así que como tengo varios y no son los típicos proyectos pequeños, los voy a usar a modo de ejemplo. Dicho esto, este episodio debería haber sido de otra web que tengo pero como semanas pasadas os pregunté por feedback de que me diéseis feedback y os dije que desde menetri.com que es mi web me contactáis por allí o el link que le di me dejáis un mensaje o un comentario en la newsletter y me dais feedback de qué tipo de episodios queréis para este podcast. Y una persona, Tomás, me dio feedback, me entró en la web, en mi web, menetri.com y me envió un mail. No voy a leerlo todo, básicamente porque hay datos personales del chico, pero bueno básicamente me dijo de que sí, que le interesa el tema de casos reales y que sobre todo el tema de desplegar en Kubernetes, arquitecturas escalables, alta disponibilidad, problemas habituales en este tipo de proyectos y que cuestiones técnicas pues también le interesan. Y que me felicita por el podcast y la temática que bueno, que bien. Así que muchísimas gracias, Tomás. Y a raíz de esto, este episodio, voy a hablar más de temas servidores y poner el caso de el ejemplo real de Eva Pizo, que creo que no comenté nada del tema de servidores de esa web. Vale, dicho todo esto, cosas que me comenta Tomás, Kubernetes por ejemplo. Yo de Kubernetes tengo conocimientos dos justos. No he tocado ningún proyecto real de cliente final con Kubernetes, básicamente por tema de precio, porque supongo que es muy caro y clientes deciden de que mejor tenerse un caso de servidores virtuales independientes, uno para base de datos por ejemplo y otro para Apache, pero no tener todo montado con Kubernetes. Antes esto, que ya estoy yendo demasiado técnico, vamos a explicar los, muy por encima, pero los tipos de servidores que pueden haber para tener una web Drupal. Normalmente se dice que hay tres tipos distintos, yo en verdad yo considero que son cuatro. El primero es el hosting compartido, esto yo por mí es no, o sea, un Drupal, he tenido clientes que tenían webs en Drupal, tanto 8 como 7, sobre todo en Drupal 7, que eran un hosting compartido, pero yo sobre todo por tema de memoria de límite de RAM y de tiempo de ejecución, yo te diría que no, dan más problemas que otra cosa y no, si son los más baratos, pero si es un proyecto mediano o grande no tiene ningún sentido y si es un proyecto pequeño, ahora veremos que hay otras otras opciones que son también muy económicas. ¿Servidores compartidos? No. Después tenemos servidores virtuales y servidores dedicados, que viene a ser casi lo mismo, la diferencia es que uno es virtual y el otro es una máquina física, pero básicamente significa que tienes una máquina con recursos reservados para ti, tienes una CPU que te aseguras que es toda para ti, una RAM que es toda para ti y una transferencia y un expresión disco que es todo para ti. Como digo, es casi lo mismo, luego que uno es físico y el otro no. La diferencia también es el precio, cuando eres una máquina dedicada o física acostúmbrase más cara que uno virtual. A día de hoy, cuando hablamos de Amazon Web Service, Google Cloud, Linode, Digital Ocean, Herzner y ese tipo de servicios, todo esto son servidores virtuales. O sea que casi muchas de las webs que están en internet corren sobre servidores virtuales básicamente. Yo es lo que uso en mis proyectos personales y lo que recomiendo a clientes que se tienen que montar su servidor. Móntatelo al menos en un único servidor virtual y si tienes más dinero y el proyecto lo requiere, lo puedes montar en varios servidores. Y aquí entra el cuarto tipo de servidor, que son no un servidor sino varios al mismo tiempo, con lo cual tenemos, como hemos dicho, el primero sería hosting compartido, el segundo hosting virtual, el tercero, perdón, hosting virtual, servidor virtual, el tercero servidor dedicado y el cuarto tipo sería servidores múltiples para una única web. Y lo normal es tener pues varios servidores virtuales porque son más baratos que el dedicado. Aquí se puede incluir el tema de Kubernetes, que sería tener Kubernetes para quien no sepa, trabaja con Docker y te monta digamos mini servidores virtualizados que se auto escalan, se van creando y destruyendo en base a la carga que tiene la web. Pero bueno, eso tiene un costo final. Y digamos que para simplificar las cosas, a menos con los que he trabajado yo en proyectos, teníamos por ejemplo la base de datos en un servidor virtual independiente, lo que es a PHP y Apache o NGINX en otro servidor virtual y si el proyecto por ejemplo requiere Solar o Elasticsearch para el tema de búsquedas, en otro servidor virtual separado, con lo cual teníamos pues unos 2 o 3 servidores o cuarto. Depende del tipo de proyecto y de las necesidades. En algunos casos sí que estaba localizado, aunque eran servidores independientes, en otros directamente era configurado como antaño, sin Docker, sin nada. Bueno, al final tiene sus desventajas, pero como no me ocupaba yo de gestionarlos, pues es cosa de cliente. En mi caso personal yo recomiendo que sea con Docker, es más fácil la gestión, la actualización y moverte de proveedor si en un futuro lo requiere. Pero bueno, esto es mi opinión personal, así que si puedes trabajar con Docker, mejor. Si puedes permitirte trabajar con Kubernetes, que por lo que he entendido yo son muchísimo más caros, pues adelante. He escuchado maravillas de Kubernetes, pero yo no tenía la oportunidad de trabajar en ningún proyecto real que use Kubernetes. ¿Qué más comentaba Tomás por aquí? Kubernetes, arquitecto escalable. Bueno, básicamente es esto, Kubernetes te permite escalar horizontalmente, esto significa crear mini servidores, por ejemplo el Frontend, o sea lo que sería Apache o Nginx, en vez de tener un único servidor con un Apache y que si tienes muchas visitas a la web, la web se cae, o tienes que aumentar la potencia de ese servidor de Apache para que tenga más CPU o más RAM, normalmente sería problema de CPU en este caso, pues en vez de aumentar un único servidor, lo que hay de Kubernetes sería crear varios servidores y balancear la carga entre ellos automáticamente. Esto en vez de Kubernetes se puede hacer manualmente teniendo en vez de un servidor dos o tres y también que balancear la carga entre varios servidores, pero estos son para webs con muchísimo tráfico y digamos que se complica bastante en la gestión de servidores. Desde el punto de vista de Drupal no se complica tanto, al final es tener un PHP y un Apache y se ejecutan varios servidores al mismo tiempo y apuntan todos a la misma base de datos, con lo cual es un no excesivo problema en ese sentido, pero la gestión de servidores sí que se complica mucho y también se complica el tema de los deploys, o sea al final desplegar en este tipo de entornos, o sea desplegar el código, subir el código a producción, digamos que tiene que estar automatizado para tener el mismo código en todos los servidores, no tener un código de hace un mes en un servidor y un código de hace dos días en otro, porque van a haber conflictos. Bueno, pues esto, escalabilidad, o sea que sea escalable vertical o horizontal. Vertical es subir la potencia del servidor en plan de tengo un único servidor con toda la web, de MySQL, Apache, PHP, todo en el mismo sitio, subo potencia de CPU y ramasago, esto es escalar verticalmente. Y horizontal es lo que digo, es tener servidores en paralelo y tener un balanceador de carga para dividir la carga. Esto por ejemplo también se puede aplicar si tienes un uso intensivo en tallas Chrome, porque estás leyendo datos de fuentes externas, podrías tener varios servidores Chrome corriendo al mismo tiempo que hacen cosas, le importan datos y escriben en la única base de datos que tienes. Al final tendrías varios servidores y repartes la carga de las tallas Chrome en varios servidores al mismo tiempo. Pocas cosas más a comentar, sí que he trabajado con temas de escalamiento horizontal, pero yo no he montado el servidor. Yo los pocos servidores que he montado eran de escalamiento vertical, o sea, un único servidor o uno y el de la base de datos que estaba suelto, pero poca cosa más. Problemas habituales que me preguntaba Thomas por esto, lo que comentaba antes, el tema de los deploys tiene que estar muy bien implementado para no tener conflictos. Después el tema de, por ejemplo, que tenía yo, es ese tipo de proyectos tan grandes que tienen problemas de escalabilidad, por así decirlo, acostuman a tener una CDN delante de todo esto. En algunos casos me he contado que la CDN cachaba más de la cuenta, con lo cual había unos usuarios que estaban viendo cosas que no deberían verse. Un caso en concreto, esto es de un cliente, pero como no voy a decir nombres, pasaba de que el usuario administrador cuando navegaba por la web, pues se cachaba lo que estaba viendo el usuario administrador, y cuando venía un usuario anónimo estaba viendo cosas que veía al administrador, como por ejemplo la barra negra de administración de Drupal, pues había usuarios anónimos que de vez en cuando les salía la barra y negra, y es un ¿qué está pasando? porque están logados como admin. No, no están logados como admin, están cacheados y están viendo el frontend de la web como si fueran admin, cosa que tampoco es muy recomendable, pero esto era un problema completamente de la CDN, esto no es cosa de Drupal. En otros proyectos me he contado de que tenían un servidor dedicado sólo para Memcache, pero no están bien configurado lo que estaba el Drupal contra Memcache, y tenían varios Drupals atacando a ese servidor de Memcache, sin especificar ningún ID identificador, con lo cual la caché de Memcache, digamos que no sea la palabra corrompido, no estoy corrompido, pero digamos que no se estaba diferenciando qué caché era de qué web Drupal, lo cual era un puñetero caos y también salían cosas que no deberían, así que es mala configuración de cómo estás usando Memcache en ese caso en concreto. Y pocos más, lo otro es muy similar a trabajar con Drupal, tener claro que al final puedes tener un ping un poco mayor, sobre todo si tienes servidores que están alejados entre ellos, que tampoco es recomendable, lo lógico sería tener servidores que están lo más próximos entre ellos posibles para el tema del ping, o sea me refiero que si tienes un servidor de PHP con Apache y ha de contactar con la base de datos, si la base de datos la tienes en América y el servidor de Apache lo tienes en Europa, pues tendrás un ping de la conexión hiper lento, no tiene ningún sentido, deberían estar en la misma red a poder ser local. Pero como digo, todos estos problemas de la configuración, o sea de la persona del sysadmin, del de sistemas, esto si tú solo trabajas con temas de Drupal, esto no es cosa tuya, a menos que también te hayan encasquetado esta tarea. Y pocos más, vale ahora les toca comentar cómo tengo yo montados mis proyectos personales y explicar un poco los motivos. Primero de todo, yo recomiendo docker, y yo mismo mis proyectos personales, todos ellos los tengo dockerizados. Dockerizados no con un docker con toda la web Drupal y la base de datos y todo, sino tengo un docker para cada servicio, esto significa que tengo un docker que es traffic, que es digamos un balonzón de carga, pero bueno básicamente es para el tema de renovación de lscl, después tengo un docker que es el de PHP, un docker que es el de NGINX, yo recomiendo NGINX en vez de Apache, por temas de rendimiento, y que en Drupal funciona perfectamente con NGINX, y por temas de seguridad también, prefiero NGINX que no Apache, para que no ejecute por ejemplo fichados PHP que no debería, por ejemplo cuando alguien intenta jacar una web y sube fichados PHP a la carpeta de size default files, pues con NGINX, si lo tienes bien configurado, lo normal es que no se ejecuten esos ficheros. Con Apache lo normal es que si quiera se ejecute, así que bueno, por temas de seguridad y rendimiento recomiendo NGINX. Después temas de MayaDB en vez de MySQL, tengo un docker solo de MayaDB, también por temas de rendimiento básicamente, después recomiendo mucho usar o Memcache o Redis, en mi caso personal me gusta más Redis, así que tengo un docker solo de Redis, como digo todo esto está en todos los proyectos que tengo yo personales, y después en algunos de los proyectos lo que tengo es un docker de Elasticsearch, iba a decir o Solas, pero en mi caso en casi todos que me hace falta un motor de búsqueda, lo uso con Elasticsearch, con lo cual tengo un docker solo de Elasticsearch. Y qué más me dejo uno que no me sé cuál es... En algunos casos ya que trabajo con Elasticsearch tengo un docker solo de Kibana, que es el dashboard de gestión, el panel de control, digamos así, de Elasticsearch, un panel de control visual. Puedo tener otro docker que es solo de PHP My Admin o Adminer, depende del caso, que es para control de base de datos, que en muchos casos lo es activo y en producción no está, porque no me hace falta acceder directamente a producción por temas de seguridad, más que nada. Y después hay un docker que es idéntico al de PHP, pero que en vez de ser el PHP que ejecuta el NGINX, es el PHP que se ejecuta en las tallas Chrome. Lo tengo en un docker separado, ¿por qué? Porque por temas de rendimiento prefiero que las tallas Chrome se ejecuten en un docker aparte, independiente, al PHP que está ejecutando la web. Bueno, por eso, básicamente lo tengo todo dockerizado. Y esto ¿dónde lo subo? En mi caso todos son servidores virtuales, míos propios, y en mi caso están todos en Europa. Y yo, años atrás, probé Digital Ocean, Inode, Google Cloud, y Amazon creo que ni lo llegué a probar, no es mentira, sí lo probé, pero no fue ni con un Drupal. Pero por costes y por facilidad me quedé con Digital, después pasé a Inode, y del Inode ahora estoy con Herzner. Herzner es una empresa, creo que es alemana, que tiene servidores en Finlandia y Alemania. Y creo que hace poco habío alguno en Estados Unidos. Temas de precios es el más barato que he encontrado. Temas de potencia es más potente, por el mismo precio me refiero, que Digital Ocean o Inode. Y tema de backups me funciona mucho mejor que los que están en Digital Ocean, por ejemplo. Así que yo en mi caso lo tengo en Herzner, dejaré el link en las notas del programa. Que ya pasó, creo que tengo afiliación, o sea, con Digital, Inode y Herzner. Bueno, tengo un artículo, voy a poner en caso el enlace al artículo explicando los tres, y ya está. Y así también veis la compatibilidad que hice yo en su día hace como un año y medio. Bueno, total, yo en mi caso, servidor virtual, Herzner, Inode, Digital Ocean o Google Cloud o Amazon, no te dan el servidor configurado como tal, aunque sí que pueden haber herramientas que te lo autoconfiguren un poco, pero igualmente es recomendable que tengas a alguien, si no es tú, que sepas configurar servidores. Eso significa que si tú no sabes configurar servidores o no tienes a nadie, habrás de pagarle a alguien. Al cliente final yo le recomendaría de, o contratos a alguien para que te gestione servidores, si es que tienes una web que requiere muchos servidores, o lo más simple, la empresa que te paga, que pagas al hosting, que le pagas la infraestructura, le pagas el metal, el hierro, la máquina física, le contratos que quieres un servidor administrado y que te lo gestione alguien esto. Porque al final es un marrón. Esto ya depende de cada caso, si solo tienes una web digamos no muy grande, pues se da cuenta tener un servidor administrado y no tener que pagar a nadie para que lo gestione, pero si tienes una empresa donde tienes varias webs o webs muy grandes que tienen muchos servidores, tiene más sentido tener un tío en nómina que te haga, bueno, que te haga decir admin básicamente. Pero bueno, esto es mi opinión personal. ¿Qué punto me queda? Comentad lo que tengo yo en Babiso. En Babiso como he comentado tengo un servidor en Hexner, espérate voy a abrir el enlace que tengo aquí delante, para que os diga también precios y lo que tengo de potencia. En esta web, como comenté en el episodio pasado, es una web que está escrepeando constantemente otras webs de ofertas de empleo, con lo cual tiene un uso intensivo en temas de trias crón, lo que consume el patchepe y lo que consume también base de datos. Constantemente escribiendo y leyendo datos. Días, uy, pues debes pagar muchos servidores. Bueno, pues tengo un servidor de tres CPUs, un servidor virtual de tres CPUs, 4 GB de RAM y 20 TB de transferencia, porque claro, aquí también se incluye no solo la transferencia de usuarios que van a ver la web, sino la transferencia de lo que consume la web al ir a otras webs, coger su contenido y copiarlo a la mía. Aquí también, o sea es un gasto de transferencia. Tengo 20 TB, no me los voy a gastar. Pero bueno, con el precio que paga un Hexner me incluye pues esto, 20 TB, 4 GB y 3 CPUs. Y 80 GB de disco, que no lo he comentado. Que tampoco me lo voy a gastar porque esta web no tiene imágenes, es solo texto. Vale. Ah, y los 4 GB son básicamente por culpa de Elasticsearch, que tiene en el mismo servidor le metido Elasticsearch con un Docker y Elasticsearch consume bastante RAM. ¿Qué consume todo esto en precio? Son 6 euros 40. Se suma al tema de los backups que va a parte, que serán unos 7 euros en total. O sea, en total estoy pagando al mes 7 euros por tener una web que tiene Redis, un Elasticsearch, Jinx, MariaDB y que sea constantemente encendida, scrapeando contenidos de otras webs. Vale que no tiene excesivo tráfico esta web. Excesivo tráfico, tendré que ver las estadísticas, pero sí que me entra tráfico. De mis proyectos, hay personas que tienen más tráfico por temas de SEO, pero no tiene un millón de visitas al mes. El tema es que por 7 euros, pues me puedo permitir si tuviese muchas visitas, escalar esto, pagar 50 euros al mes y tener en vez de 3 CPUs tener 16 CPUs, por ejemplo. Y si aún así no pudiera, pues podría mover la base de datos y el Elasticsearch a servidores virtuales separados y reducir así el tema de la potencia. Pero lo que voy es, es un proyecto personal mío propio, no tiene un excesivo consumo de recursos, pues lo intenté ya en su día optimizado lo máximo posible. Y para que veáis que tener un servidor virtual es relativamente barato, son 7 euros al mes. El problema que me lo gestiono yo, yo he de arreglar todos los problemas que tenga, yo he de configurar el Docker con todo lo que tenga, y esto si no lo sabes hacer tú, has de contratar a alguien. Aquí el coste que tiene es contratar a alguien que sepa hacerte esto. Bueno, básicamente es la parte más cara. Por eso los servidores administrados son más caros que los servidores no administrados, que es como en este caso. Y por poca cosa más, básicamente esto, comentar de que no me preocupo excesivamente del tema de performance escalabilidad, por así llamarlo, porque ya intento optimizar el tema del código y veo de que pagando esto, una cantidad no excesivamente cara, o sea, es muy barato, puedo llegar a escalar si voy separando esto en varios servidores, pero que de momento, por el tipo de coste que tiene y por el tipo de visitas que obtiene la web, no me estoy matando a meter Kubernetes y estas cosas. Y me digas, bueno, ¿por qué es este proyecto? Vale, pues es que otro proyecto que yo he comentado otro día, tiene 70 gigas ahora mismo, ya veremos de que unos días, en base de datos. Tengo un MySQL con 70 gigas. No me va a aviso en otro proyecto. Y lo mismo, tengo un servidor con todo puesto allí. No es la mejor práctica, no, pero es un proyecto en el que estoy haciendo pruebas, ya vaya hasta donde llega hasta que reviente MySQL, o MyAdeve en este caso. Pero la web no se cae de momento y va bastante más rápida que muchas webs de otros clientes que sí que llevo. A final de esto, son proyectos que uso como laboratorio de ideas y probar cosas e intentar exprimir un poco hasta donde llega Drupal. En el caso de aviso, era temas de mapas y búsquedas geolocalizadas. En este caso del proyecto con 70 gigas de datos, es más por temas de búsquedas y también sacado un poco de jugo al tema de las tic-tac. Bueno, volviendo al tema. Temas de servidores. Es importante que tengas un conocimiento mínimo. Es importante que el servidor sea de cliente, que nunca sea del desarrollador. Como desarrollador puedes hacer recomendaciones de cuál es mejor usar, pero te diría que es siempre responsabilidad de cliente qué es lo que quiera instalar. Hay una cosa que se me olvidaba. Ahí me saca un poco de quicio que en muchos clientes no me dan acceso a mí al servidor de producción. Pero una parte es buena, porque si se jode algo en producción, como tú no tienes acceso, no puedes hacer nada. En ese sentido, yo no he tocado nada para romper esto. Pero la parte mala es que cuando se rompe algo y hay una urgencia para arreglarlo, tener acceso al servidor por SSH simplificaría muchas cosas. Y cuando tienes varios servidores y son todos de cliente y cliente no te da acceso, a lo máximo es que tienes un Jenkins por allí que con interacción continua te hace el despliegue automático, pero tú no tienes acceso físico, ni siquiera a los logs, pues dificulta mucho el trabajo. Esto es más un apunte para cliente, que intento varios clientes decirles a menos darme acceso a los logs, o darme acceso a New Relic, o darme acceso a algún lado para ver qué está pasando. Pero bueno, también es una dificultad en ese tipo de proyectos tan grandes, donde digamos, cliente a veces es reticente a darte acceso a SSH directamente al servidor de producción. Que como digo, por una parte es bueno y por otra parte es malo. Y nada más, creo que me ha dado mucho en este episodio. La semana que viene sí que sí, porque lo voy a grabar ahora mismo, pero se puede publicar aquí una semana. Voy a hablar de otro proyecto, en este caso es un Tinder de podcasters. Así que, estad atentos la semana que viene. Chao.