martes, 20 de noviembre de 2018

Los 10 mandamientos de un servidor | 1. Amarás las nuevas máquinas sobre todas las cosas

Cuando vamos a migrar un servidor porque vamos a actualizar la máquina y realizar importantes cambios, nos tenemos que hacer la idea que tendremos  mucho trabajo que hacer, sobre todo si hay muchos datos que migrar y la aplicación del proyecto es muy grande. No obstante, deberemos tener en cuenta una serie de "mandamientos" que son importantes a tener en cuenta durante nuestro trabajo de migrado de servidores. Aquí va el primer mandamiento. Amarás las nuevas máquinas sobre todas las cosas.



Sí, me he llamado a mí mismo San MaGnu. Me he autodenominado santo al ser un mártir por la Iglesia protestante Gnu/Linuxterana. Junto a San IGnucio de Richard Stallman, esta Iglesia (la buena de verdad) crece. Pero como esta serie de posts van sobre "religión", qué mejor que ponernos cerdis como Rick y Morty en un capítulo de la segunda temporada que trataba el tema de le Religión.



Antes de nada, voy a comentar brevemente qué escenario he montado, para que así sepáis qué voy a migrar. Decir que es un escenario de pruebas para esta serie de posts, por lo que no esperéis algo muy grande tampoco.


Voy a contar con 2 servidores, uno de PROD y otro de BACKUP. Como imaginaréis, el servidore principal es el de PROD, y es ahí donde ocurrirá "todo lo gordo". El servidor de BACKUP realizará la función de almacenar backup de los datos de PROD y estar ahí listo con todos los datos de PROD al día por si en cualquier momento falla PROD, que tengamos listo otro servidor que podamos tratar como "Fake temporal PROD" hasta que solventemos el problema que tengamos en el servidor.

Por supuesto que esto no es ideal, lo suyo sería tener más, ya que en el de BACKUP también podríamos testear cosas que no testearíamos en PROD, por lo que el escenario ideal sería tener un server más como mínimo para testear ahí y después pasar esas pruebas al de BACKUP con datos de backup de PROD para ver cómo funciona esos testeos en un servidor con y sin datos de PROD. Así pues, cuando estemos seguros de que todo funciona correctamente, pasaremos y aplicaremos esos cambios al main server.


Ahora vamos con los servers. Como os podéis fijar, BACKUP no está correctamente configurado, ya que en PROD tiene datos en /applications/ProjectGID/data que no tiene en su /applications/ProjectGID/data(Antes de empecéis a pensar mal, decir que ProjectGID no es un proyecto real de mi empresa, simplemente son las siglas de God is Dead).

Esto es algo que durante el monitoreo necesitaremos a tener en cuenta, ya que os adelanto que nuestro entorno girará alrededor de /applications/ProjectGID/{data,save}. El archivo interesante a copiar sería copyfiles, ya que será el script que meteremos en nuestro crontab para que, a una hora determinada, copie los reports bajo /data a la carpeta /save del servidor BACKUP. Primero cifrará con gpg ese archivo y posteriormente lo enviará.

¿Pero qué es ese reports.csv? Pues un ejemplo de un archivo donde tendremos los reports de los clientes, de ahí que sea interesante cifrarlo.


Podríamos tener más datos, es más, a poco que una aplicación de este tipo tenga 3 meses, la cantidad de datos sería ingente. Imaginad un banco los datos que puede recopilar en 3 meses con todos los clientes que tiene.

Tiene sentido que pasemos a save/ los datos al servidor de BACKUP, ya que ahí vamos a guardar las copias de seguridad de los reports que es lo importante ya que al fin y al cabo son los datos de los clientes, que es lo que nos debe preocupar.



Como he mencionado antes, otro aspecto importante es el crontab, y más para nuestro caso en el que vamos a enviar a las 12:15 de todos los días los reports. Por supuesto esto tiene que funcionar correctamente para tener los datos actualizados en el servidor. Esto no puede fallar. Pero claro, tenemos que pensar que al estar en una migración de servidores, este crontab es importante tenerlo también en el nuevo servidor de PROD.

Durante un migrado (o simplemente por hacer backup) podemos encontrar los crontan que creemos en /var/spool/cron/crontabs, por lo que sabiendo esto, podremos tenerlo en cuenta para migrarlo también y así no tener que crearlo de nuevo en los nuevos servidores. Live Hack muy útil.

Ah, casi se me olvidaba. Por si os lo preguntabais porque sois inocentes y aún no me conocéis, estoy con un Debian en ambos servidores. Ambos son Debian 8 y migraré al Debian 9 para estos posts.

Visto esto, ahora lo que nos queda es de lo que se trata este post, de instalar las nuevas máquinas. Yo voy a instalar solamente una, ya que la otra es seguir los mismos pasos. Es más, si estáis con máquinas virtuales podéis clonarlas y después cambiar la MAC y su nombre en /etc/hostname.


Seleccionaremos la Instalación típica, nada de interfaz gráfica, aquí vamos a pelo. Tras esto nos pedirá que seleccionemos el idioma, uso horario,etc. En esto no me detengo ya que es fácil. Lo que sí nos pedirá es introducir un usuario y aquí tendremos que tener en cuenta los usuarios que tengamos creados en nuestro server.



Introducimos un usuario cualquiera y pasamos a otro de los pasos importantes.




Aquí tendremos que decidir cómo queremos realizar la instalación. Yo recomiendo la de utilizar todo el disco y configurar LVM cifrado. Sobre esto de LVM nos detendremos en futuros posts.


Y vamos a separar también en distintas particiones /home, /var y /tmp.


Tras unos minutos instalando y cifrando LVM, nos pedirá qué software instalar. Como vamos a utilizar un servidor, yo no voy a instalarle ningún escritorio, pero sí el web server y SSH.


Una vez instalado ya nuestro nuevo Debian 9, lo que tendremos que hacer es instalar todo el software que tengamos en nuestro servidor antiguo. En mi caso me he cerciorado de tener:


  • rsync
  • tree
  • gpg

Ahora tendríamos que añadir los usuarios, y aquí tenemos varias opciones:

  • Si son pocos usuarios como mi es mi caso, podemos crearlos con el mismo ID de usuario (opción -u) y listo
  • Utilizar netgroups con un servidor intermedio de Red Hat o cualquier otra arquitectura de LDAP.

Y ahora ojo, que en los servidores actuales accedemos de PROD a BACKUP sin introducir ninguna password y eso es por una cuestión. Estoy utilizando un par de claves privada y pública para esto. Si queréis saber cómo hacer esto, os dejo este post donde lo explico, ahora no me voy a detener mucho en explicar de nuevo cómo se configura.

Y hasta aquí la parte de la instalación. Por supuesto queda otra máquina que es la de BACKUP, pero es seguir los mismos pasos al fin y al cabo y tener en cuenta que sería bueno separar en distintas particiones /home, /var y /tmp y tener LVM cifrado.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...