Arquitecto: qué vamos a desplegar

Buena

s noches a todos, y bienvenidos una vez más a este pequeño pero ambicioso proyecto que quiero montar.

Os prometí que la siguiente entrada tendría miga, así que poneos cómodos, coged de beber, respirad hondo y vamos a ello.

Porque poco a poco vamos a montar e integrar todos los sistemas de un departamento de IT.

(Por algún motivo, os estoy imaginando como un conejo al que le das las largas).

Si has seguido leyendo es posible que tengas alguna de estas cosas en la cabeza:

1. Es muy difícil.
2. No vas a poder hacerlo solo.
3. Hay muchísimas cosas que tener en cuenta.

Y casi todo ello es verdad, pero no vamos a atacar todo el problema a la vez, eso es imposible. Es como mover una piedra de 2000 toneladas cuesta arriba uno solo: como no podemos hacerlo todo a la vez, vamos a coger el mazo gigante de los Looney Tunes y vamos a darle golpes a la roca hasta reducirla a trozos que podamos transportar hasta arriba de la colina.

Pero no este tipo de martillo...

Voy a seguir dos formas de enfrentar los problemas que aprendí de dos profesores diferentes. La primera, atacar el problema de frente, en toda su complejidad, y hacerlo sin miedo. Mirarlo con curiosidad, respirar hondo y ponerse a ello hasta haberlo resuelto. No pararnos por decir "esto no sé hacerlo", sino porque estemos estudiando eso que no sabemos hacer. Y si sabemos hacerlo, afrontar el problema y seguir. Este profesor nos decía que "si quieres arar un campo, la única manera de hacerlo es coger el arado y hacer un surco recto y sin parar hasta el final. Y cuando llegas al final, darte media vuelta y hacer otro surco recto y paralelo al anterior. Así hasta que lo has arado entero".

La segunda forma consiste en que siempre que te enfrentes a un problema nuevo lo resuelvas entero por ti mismo, paso a paso, sin dejarte nada ni copiar de ningún sitio. Enfréntate al problema, resuélvelo y obtén la solución. Pero una vez tengas la solución, no vuelvas a resolver el mismo problema: copia la solución y sigue adelante.

Así que vamos a enfrentar los problemas de frente, no los vamos a abandonar hasta haberlos resuelto y, si tenemos que dejarlos a medias, que sea porque estamos resolviendo otros problemas que nos hacen más sencillo el original. Y una vez resueltos los problemas, copiaremos la solución cada vez que nos encontremos otra vez con él.

Vamos a montar muchos sistemas, y habrá cosas que resolveremos una vez y daremos por resueltas para siempre: no voy a explicar todas las veces cómo se despliega una máquina virtual, sólo qué hay diferente respecto a la primera explicación, si lo hay.

Eso me lleva a otra idea importante: creo que, como técnicos, nuestro trabajo consiste en responder a dos preguntas:

1. ¿Qué quiero hacer?
2. ¿Cómo se hace eso?

Hay que tener claro qué es lo que vamos a hacer, ponerlo en palabras, por escrito, saber sin lugar a dudas cuál es nuestro objetivo: quiero montar un sistema de backup, quiero correr una maratón, quiero ponerme un cubata...

Una vez sabemos lo que queremos, tenemos que saber cómo se hace: ¿cómo se monta el backup? ¿Cómo se entrena para una maratón? ¿Cómo me preparo el cubata para que me guste?

A veces nos encontraremos que un "cómo" nos lleva a un "qué". Esto puede ser frustrante, pero resolveremos la nueva pregunta y volveremos a la pregunta original, un poco más cerca de la solución.

Mi intención es que cada post plantee una pregunta más o menos sencilla y la resuelva, tratando de resolver poco a poco problemas grandes: no voy a configurar todo un sistema de monitorización en una entrada. Primero, bajaremos el código del repositorio, veremos qué flags de compilación usar y compilaremos; en el siguiente post veremos cómo configurar algunos componentes; en el siguiente, cómo añadir sistemas para monitorizar... Y así, tendremos un sistema de monitorización funcionando poco a poco al que ir añadiendo funciones.

En pocas palabras, modelo incremental: haremos que las cosas funcionen primero, y luego iremos añadiendo más cosas. A veces dejaremos cosas sin funcionar del todo, pero es porque el proceso tenga varias etapas que necesitemos ver por separado.

Pero volvamos a nuestro problema. Ya hemos visto qué métodos vamos a seguir y qué perspectivas vamos a usar, pero eso no nos sirve todavía. Necesitamos algo más concreto: hemos roto el problema en problemas más pequeños, pero aún no hemos resuelto nada. La mayoría de lo que veremos consistirá en cómo hacer aún más pequeños esos problemas y cómo resolverlos. Quiero que cada entrada plantee y resuelva un problema pequeño, que puede ser:

• De arquitectura: romperemos la piedra en trozos más pequeños y veremos cómo volver a montar la piedra original con ellos. Veremos el departamento en general, dónde y cómo incluir los nuevos sistemas dentro del conjunto, especificaciones y requisitos generales, razonaremos cómo y por qué tomamos esas decisiones y nos atreveremos a hacer cosas sobre todos los sistemas. Como en este post.
• De administración de sistemas: cogeremos las piedras más manejables que saquemos de arquitectura y las haremos más pequeñas o nos las echaremos a la espalda. Sabiendo qué queremos montar, veremos cómo llevarlo a cabo y lo haremos: veremos dentro de cada máquina qué es lo que podemos hacer, qué requisitos concretos deben cumplir y cómo pasar de la idea general a algo que funcione.
• Técnico: en estas entradas nos vamos a pegar con problemas de "bajo nivel": máquinas que no arrancan, procesos que se caen, scripting, lectura de logs... Problemas comunes y no tan comunes donde veremos trucos prácticos de cómo mantener nuestros equipos. Hay quien dice que son "labores menores", pero eso no significa que sean triviales o que podamos descuidarlas: si hay una habilidad que te abrirá puertas en este gremio es leer logs, entender lo que dicen y lo que realmente hay detrás de ese log. Y si crees que me equivoco, espero que este blog te haga cambiar de opinión.

Habrá algunas cosas que os dejaré para que averigüeis, pero no serán difíciles de encontrar u os dejaré directamente el enlace para que lo leáis. Por ejemplo, cómo montar una máquina virtual (aunque lo veremos con detalle en la siguiente entrada) o leer las ayudas de los comandos.

La entrada de hoy (que empieza a ser larga) consiste en llegar a la puerta de nuestro departamento, echarla abajo de un mazazo y tratar de ver algo entre el polvo del departamento vacío. ¿Qué es lo primero que nos vamos a encontrar? ¿Qué conceptos y problemas nos vamos a encontrar?

Creo que hay una idea y dos conceptos con las que podemos empezar a trabajar: un departamento de IT se encarga de gestionar y administrar redes de ordenadores.

Redes y ordenadores. Puede parecer trivial, pero tenemos que hacer que nuestras máquinas virtuales puedan comunicarse entre ellas y con el exterior. 

Es posible que estés pensando "seguro que el software de virtualización que vas a usar tiene alguna herramienta para hacerlo" y tendrás razón, la hay. Pero no la vamos a usar. O, mejor dicho, vamos a administrarlo todo nosotros: vamos a crear nuestra propia red, con nuestra propia máquina proxy-firewall-enrutador.

¿Estabas pensando en "configuro la máquina virtual en modo NAT o puente y ya está"? ¿Y dónde está el interés en eso? ¿Cómo vamos a aprender a manejar un enrutador con DNS, un proxy y un firewall si todo lo hace el software de virtualización? Hemos venido a jugar, a aprender a tomar decisiones y a llevarlas a cabo enfrentándonos a los problemas que puedan aparecer.

Así que nuestra primera máquina (que montaremos el próximo día) será también nuestro enlace con el mundo exterior: todo el tráfico de nuestra red va a pasar por aquí, y aprovecharemos esto para poner en marcha algunos sistemas y configuraciones más complicadas (pero también más interesantes) que lo necesitarán más adelante (monitorización entre redes, control de tráfico, alta disponibilidad de bases de datos...).

Tengo que avisaros que nunca he montado un enrutador como el que abrirá la siguiente entrada, así que es posible que tardéis unos días en verla. Os prometo que cuando lo haga, tendréis una buena guía como referencia.

Por último, dos cosas importantes: la primera, todo lo que voy a montar lo voy a hacer en mi ordenador, no voy a depender de nubes ni de equipos de terceras personas. Tengo bastante buen hardware y me lo puedo permitir. Pero si no es tu caso, no pasa nada si no lo montas todo: intentaré que esto sea modular para que puedas montar sólo una parte de ello.

Segundo, todo el software que usaré será siempre gratuito (o su versión gratuita) y software libre siempre que sea posible. Por un lado está el precio, pero por otro creo que hay grandes herramientas de software libre que funcionan extraordinariamente bien (Linux es software libre) y que el software libre te obliga a saber lo que quieres hacer antes de hacerlo, y precisamente de eso se trata: de pensar, de usar la cabeza y resolver el problema antes de dárselo al ordenador. Como decía al principio de la entrada, afrontar el problema, no buscar atajos.

Y con esto termino por hoy. Igual esperabais un post más técnico, más "manual de operaciones", pero tenía que contaros todo esto antes de empezar a trabajar. El próximo lo será bastante más, porque nunca he hecho antes lo que os voy a contar.

Hasta entonces, mucho ánimo y nos vemos en la próxima entrada.