Antes de nada pedir perdón por la tardanza en subir este post que se ha ido elaborando a fuego lento y que ha costado bastante saber cómo plantearlo, pues el tema es amplio y siempre hay cosas que comentar y que tener en cuenta, sin embargo he optado por reducir (dentro de lo posible) y comentar los aspectos más básicos. Además recuerdo que esta configuración no debe ser aplicada siempre en cualquier servidor, todo dependerá de nuestras características y, sobre todo, de lo que necesitemos en cada momento.

Además también comentar que lo que se va a comentar en esta serie de artículos ya se ha expuesto en una serie de charlas que di el 19 de diciembre en el CES Lope de Vega de Córdoba ante alumnos y alumnas de Grado Medio y Superior de Informática. Dar las gracias desde aquí al centro por confiar en mí y por cómo me acogieron.

Espero que os resurte de interés y útil este “manual”. Ya sabéis que cualquier apreciación o corrección, es bienvenida. Podéis escribirme sobre el tema en:

– manualen@protonmail.com
– @hippi3c0w

Un abrazo!

Configurar un servidor GNU/Linux con Apache (Mysql | MariaDB) y PHP es una tarea que depende del proyecto que tengamos y de las circunstancias. No se puede dar una regla general para configurar de una forma relativamente correcta nuestros servidores. Este artículo es en entorno GLAMP, pero no es el único entorno, por lo que las opciones de configuración son aún más amplias. Por ejemplo, también existen otros entornos como Nginx+Django+Gunicorn+Rabbitmq+Celery (este entorno nos lo encontraremos frecuentemente con Docker). Yo personalmente este último entorno no lo termino de ver, pues la mayoría de proyectos que se pueden realizar, son perfectamente realizables con un entorno GLAMP pero debidamente configurado. Por esta razón, yo me voy a centrar en este artículo únicamente en entornos GLAMP, aunque también se dejarán caer otras opciones al final del artículo.

Vamos a ir de menos a más, pasando primero por la propia instalación del servidor e iremos avanzando hasta realizar configuraciones que nos permitan tener un gran rendimiento y disponibilidad en nuestros servidores.

Instalación

Puede parecer una tontería o que no tiene más importancia más allá de escoger un servidor para montar nuestro proyecto web, pero realmente esta es una de las partes más importantes de nuestro proyecto y esto es algo que mucha gente no entiende.

Primero tenemos que saber para qué va a ser nuestro proyecto. Puede parecer obvio, pero no sería la primera vez que escucho: “Necesitamos un servidor, compra uno y mete este proyecto de Github”.Y esa es la información que muchas veces recibe un Sysadmin. Esto se traduce en hacer las cosas mal desde el principio.

Se debe saber muy bien si es un proyecto interno de la empresa (lo que requiere de unas medidas extra de seguridad) o si es un proyecto para exponerlo al público. Si es un proyecto web para exponerlo al público, tendremos que considerar siempre que puede darse un caso de éxito y que de repente nuestra web sea muy visitada. Es mejor tener esta mentalidad para realizar configuraciones pensadas para este escenario (o al menos con la capacidad y rapidez suficiente para adaptarse a este escenario). Así pues, pasemos a escoger un servidor.

No vale el: “Cualquier servidor para cualquier proyecto” o “Pilla un servidor cualquiera”. No, hay que ser cuidadosos y escoger muy bien entendiendo los tipos de servidores y de hosting.

  • Hosting compartido : Es cierto que es barato, pero también se comparten recursos con otros clientes, la IP es la misma para todos los proyectos de ese hosting. Esto es algo fácilmente comprobable si simplemente hacemos un nslookup a un dominio y posteriormente lo buscamos en servicios online como viewdns.info

Esto implica que ante un fallo de seguridad en un proyecto de terceros pero que comparta la misma IP, no sería muy complicado pivotar y que tu proyecto se vea igualmente afectado. O no hace falta siquiera que suceda un fallo, pueden existir otros
proyectos de ese dominio que lancen spam, lo que te perjudicaría a ti también al compartir la misma IP. Puede ser una buena idea para proyectos personales, pero ya está, no debería pasar de ahí por los riesgos que supone llevarlo a producción (en adelante PROD).


Servidor VPS . Aquí ya disponemos de recursos propios en el que un servidor virtualizada cada VPS. La IP ya es propia. Imaginemos que tenemos un servidor bastante potente y en el que nos limitamos a virtualizar con KVM desatendido (un proyecto muy interesante y que recomiendo que probéis) en función de las necesidades del cliente ¿Dónde nos encontramos el problema? Pues entendiendo que son sistemas virtualizados, en las lecturas y escrituras de disco. Si no está bien montada la anfitriona, el VPS no tiene por qué ir bien ¿ventaja? Para mí la principal son las snapshots, las copias de seguridad en caliente del VPS.

Bonus. Es importante que os cercioréis si el VPS está o no administrado. Pongo un ejemplo. Cuando sucede un fallo de seguridad, ese parche hay que aplicarlo, no tiene por qué ser una actualización periódica. Esta es la razón fundamental por la que hay que asegurarse si nuestro VPS está o no administrado. Si no está administrado, entonces tenemos que tener a alguien que sepa (un sysadmin). Sed insistentes, es mejor eso que por no incidir en cuestiones claves, después ocurran fallos que hubiesen sido sencillos de evitar.

  • Servidor dedicado . Para mí es el ideal. En un principio, es una máquina propia en la que tenemos el 100% de los recursos. Como es evidente, esto supone un mayor conocimiento sobre el servidor. Múltiples IPs y un mayor espacio y ancho de banda. Todo suena idílico, pero es fundamental entender que para esto, se requieren de un mayor conocimiento en servidores, pues no es raro que determinadas empresas contraten un nuevo dedicado por éxito en su web. No es lo ideal. Como he dicho al principio, mucho de esto (en este caso costes extra) nos los podríamos evitar realizando simplemente configuraciones de nuestros
    servicios y no dejándolos por defecto como muchas veces se encuentra un sysadmin. Es posible un mayor rendimiento, simplemente optimizando el servidor.

Un ejemplo claro es la Apache Software Foundation, quienes entienden que un servidor Apache debe ser posible ejecutarse y montarse en cualquier máquina independientemente de sus recursos. Por este mismo motivo, los archivos de configuración de Apache vendrán por defecto con opciones básicas y de no cambiarlos, da igual que contratemos una máquina con más recursos, las opciones del Apache van a seguir igual y no va a mejorar nada. Hay muchas formas de mejora.
Es necesario entender también, que esto va a conllevar paradas de servicio. Para estas
configuraciones tendremos que parar servicios y volverlos a levantar (y que se levanten). Como he hecho alusión, requiere de más conocimientos que, de aplicarlos, obtendremos un rendimiento mucho mayor, por lo que (para mí) merece mucho más la pena un dedicado.

Servidor Cloud . Viene pisando fuerte y ya, en muchas empresas, es la mejor opción.
Simplemente pensemos en la Cloud de Amazon, la cual garantiza una gran disponibilidad del servicio. Se emplea el concepto de el servidor como servicio. Son fácilmente escalables (en la mayoría de los casos, con un simple botón). No sólo eso, sino que además se pueden ampliar en caliente (gran ventaja). Otra ventaja es la misma que la del VPS, aquí también tenemos snapshots de nuestro servidor. Podemos gestionar el autoescalado.

Es el cielo de los sysadmins. Ahora lleva esa idea al departamento de comercial donde aquí se paga por uso, por operaciones de entrada y salida, tráfico entrante/saliente,etc. No hay precio fijo. Bien es cierto que esto cada vez se está fijando más y existen muchos cloud de precio fijo, pero simplemente pensemos que con un dedicado de 100-200€ al mes, a lo mejor tenemos un rendimiento mayor que en cloud.

De nuevo, depende de las circunstancias, del proyecto, del conocimiento,etc. Y que no se nos olvide que un cloud no tiene por qué estar optimizado, por lo que es igualmente necesarios estos conocimientos tanto en cloud como en el dedicado. Es una buena opción, repito; pero para mí aún hay cuestiones que mejorar en los clouds.

Llega el momento de decantarnos por un servidor. En mi caso va a ser un servidor dedicado. Otro tema es con quién lo contratas. Toca leer contratos y, si hace falta, llamar. (Tratad de evitar 1&1). OVH (cuidado con los discos), Hetzner o proveedores de este tipo son buenas opciones, aunque como digo, la experiencia es buena amiga (si tenéis otras recomendaciones, ¡simplemente hacedlas!).

Antes de continuar, me detengo para decir que he obviado los CMS, pero no porque no los considere una buena opción, al revés, puede ser que, si el proyecto así lo requiere, un CMS sea la mejor opción. Reitero, depende del proyecto y de las circunstancias. Pero un CMS (WordPress {gran opción} o Blooger) del que sólo nos preocupamos del contenido y en el que la administración es delegada, puede ser una gran vía de escape dependiendo de lo que requiera nuestro proyecto. Aún así, yo me centraré en este artículo en un servidor dedicado (con el suficiente tiempo, ya iré publicando qué hacer en cada uno de los distintos servidores). Una vez que tengamos decidido el servidor, nos toca instalar. De nuevo, vamos con ejemplos prácticos:

Servidor a contratar: Vamos a Utilizar el SX132 de Hetzner (por poner un ejemplo)

Sus características son:
– Intel® Xeon® E5-1650 v3 Hexa-Core (Comprobad un Benchmark de la CPU donde se ha puesto en cabeza en el mes de Octubre https://www.cpubenchmark.net/cpu.php? cpu=Intel+Xeon+E5-1650+v3+%40+3.50GHz&id=2389)
– 128GB DDR4 ECC de RAM
– 10 X 10 TB de disco.
– Precio: 192.39€/mes
– Solamente habilitado el modo rescue

Tenemos una máquina potente de recursos y que, si se va a implantar un proyecto pequeño, a lo mejor es excesivo. Pero la idea que se quiere transmitir es como, con una máquina potente y unas cuantas optimizaciones/hardening del servidor, podemos obtener un gran rendimiento y disponibilidad. Cuando la compremos y Hetzner (en este caso) nos envíe las credenciales (mal porque la envían en texto claro, por cierto), accederemos pero veremos que tenemos el modo rescue y con esto no podemos hacer nada. Tenemos que instalar la distro, montar particiones separadas (yo siempre prefiero LVM con particiones cifradas), un sistema RAID (con un RAID 1 en muchos casos nos bastará y más con el que tenemos 10 X 10TB al que le haremos mirroring),etc.

Si es la primera vez, recomiendo que sea a mano y se entienda lo que se está haciendo, pero conforme se vaya adquiriendo experiencia, recomiendo ser eficientes y automatizar esta tarea. Yo tiro de los playbooks de Ansible. Para instalar nuestra distro, con particiones básicas y RAID 1. Para un ejemplo sencillo, hemos creado un un repositorio en nuestro Github con el playbook y el archivo installimage.

Explicaré lo principal. Lo primero es que tenemos que especificar el host con la directiva “hosts”. Posteriormente, yo añado algunas variables que en el yml file voy a reutilizar. En este caso el servercode y el username ¿Qué es el servercode? Pues el código que voy a utilizar cuando se ejecute la tarea Upload config file for installimage que es (installimage) el mecanismo que Hetzner utiliza para instalar las imágenes ISOs. Para esto utilizará un archivo j2 con el servercode el servidor y realizar las configuraciones correspondientes.

Este es un ejemplo de un servidor con 4 particiones y lo más importante es

SWRAID 1
SWRAIDLEVEL 1

Donde SWRAID indica si se habilita o no la opción RAID y SWRAIDLEVEL indica de qué tipo queremos el RAID. Raid 1 en este caso.

Otra cuestión importante es

IMAGE /root/images/Debian-10-buster-64-minimal.tar.gz

Esto lo que nos va a hacer va a ser instalar la distro, que no podía ser otra que Debian 10 Buster.

Volviendo a nuestro playbook, lo que hará será reiniciar el servidor, crear el grupo para nuestro usuario que conteníamos en nuestra variable, crear el usuario, asignarle una contraseña, asignaremos permisos, instalaremos algunos paquetes básicos, configuraremos locales,etc. Todo lo que se nos ocurra. Incluso podríamos pasar las SSH Keys del usuario a su directorio. Sinceramente, es una gran forma de automatizar este proceso, os recomiendo que miréis un poco sobre los playbooks de Ansible. Nosotras ya publicamos un artículo explicando brevemente qué era Ansible y cómo podríamos utilizar sus playbooks.

Por el momento esto es todo, este es un artículo extenso, por lo que lo hemos separado en partes para que sea más fácil de seguir. Próximamente seguiremos publicando las siguientes partes de esta serie.

Manu Alén
@hippi3c0w
manualen@protonmail.com

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: