3 pasos para identificar candidatos para la automatización del sistema Linux

Automatizar las tareas que realizamos es una de las partes más importantes de nuestro trabajo como administrador de sistemas. No se trata solo de realizar las numerosas tareas necesarias para mantener en funcionamiento los sistemas a los que damos soporte. Se trata de hacerlo más fácil para nosotros y para otros administradores de sistemas que podrían reemplazarnos mientras estamos de vacaciones o enfermos; se trata de asegurarnos de que podamos hacer nuestro trabajo rápida y fácilmente con un mínimo de mano de obra e intervención de nuestra parte; se trata de, hmmm, realmente debería decir esto, ser el administrador de sistemas perezoso.

He escrito mucho sobre automatización en mis libros y artículos, y mi mantra siempre es "automatizar todo". Pero, ¿cómo saber por dónde empezar?

Índice

    el punto de dolor

    Empecé en el camino de la automatización al reducir un problema importante para una de las tareas más importantes que realizan los administradores de sistemas: las copias de seguridad. Empecé con una red muy pequeña: un ordenador y una conexión a Internet. Las copias de seguridad fueron fáciles, aunque la tecnología consistía en una serie de unidades de cinta que finalmente fallaron.

    Inicialmente, escribí un comando el viernes por la noche para hacer una copia de seguridad de todos mis directorios importantes y, ocasionalmente, verifiqué para verificar que las copias de seguridad se crearon correctamente. Fueron, en su mayoría, a causa de la pandilla.

    A medida que mi red creció y se hizo responsable de redes distintas a la mía, descubrí que usar la línea de comandos para realizar múltiples copias de seguridad se volvió bastante tedioso. Sin embargo, la tecnología ha evolucionado y también he descubierto que los discos duros USB externos son un excelente medio de copia de seguridad y que un script hace que sea mucho más fácil realizar copias de seguridad de varias ordenadores. El uso de trabajos cron o temporizadores systemd también me permite programar copias de seguridad.

    Mi sistema de respaldo actual usa un script Bash que usa rsync para crear respaldos de hasta una docena de ordenadores en mi red doméstica existente. Las copias de seguridad se crean primero en un disco duro interno de 4 TB, luego se escriben en uno de los discos duros USB externos de 4 TB. Puedo llevar fácilmente las unidades externas en mi caja fuerte para realizar copias de seguridad fuera del sitio. Puede leer los detalles de este sistema de copia de seguridad en mi artículo, Use rsync para hacer una copia de seguridad de su sistema Linux. La clave es encontrar tu punto de dolor más intenso y comenzar con eso.

    mi estrategia

    Realmente solo tengo una estrategia para determinar qué automatizar primero o después. Es solo una cuestión de determinar qué tarea me está doliendo más en este momento. Cette douleur pourrait être de devoir passer beaucoup de temps à taper à plusieurs reprises les mêmes commandes, à attendre que des choses se produisent avant d'entrer la commande suivante, à se souvenir de la syntaxe appropriée pour les commandes que j'utilise fréquemment, u otro.

    Probablemente ya conozca la fuente del mayor dolor en su vida como administrador de sistemas. Esto es lo primero que debe considerar automatizar, especialmente si es relativamente pequeño y no tan grande como un sistema de copia de seguridad completo y avanzado. Comencé con un sistema de copia de seguridad simple que usaba tar y algunas funciones divertidas de SSH, de las que hablé en Mejor pareja de 2015: tar y ssh.

    Otros problemas para mí han sido las actualizaciones de Fedora, incluidas las correcciones funcionales y de seguridad, así como las mejoras de funciones. Esto también incluye actualizaciones de una versión de Fedora a la siguiente, como de Fedora 32 a Fedora 33.

    También hay muchas opciones para implementar la automatización, sea cual sea la tarea. Parte de mi estrategia ha sido comenzar usando scripts para comprender completamente las soluciones y los problemas que podrían surgir. Voy a escribir un script para solucionar un problema en un host, copiarlo en todos los hosts de la red y luego escribir programas Bash en la línea de comandos para realizar esta tarea en todos los hosts. Toma la forma:

    for host-name in `cat ~/list-of-hosts` ; do ssh host-name "script-name"; done

    Pero incluso eso se convierte en una tarea y otro problema con suficientes hosts en suficientes redes. También puede ser problemático cuando algunos hosts deben recibir un trato diferente a los demás. Descubrí que herramientas más avanzadas, como Ansible, pueden automatizar tareas en muchos hosts en una red mientras tratan ciertos tipos, como servidores, de manera diferente a los escritorios estándar. Ansible no requiere distribuir scripts a cada host para hacer su trabajo; ni siquiera necesita instalarse en cada host, solo en el sistema utilizado como "hub".

    El punto de dolor de PHB

    todos tuvimos Jefes con pelo puntiagudo (PHB) y, a veces, son el punto de dolor. Suponga que un PHB solicita una lista de todos los RPM en una máquina Linux en particular y una breve descripción de cada uno. Esto me sucedió mientras trabajaba en el estado de Carolina del Norte. El código abierto no estaba "aprobado" para su uso por las agencias estatales en ese momento, y solo estaba usando Linux en mi ordenador de escritorio. Los PHB necesitaban una lista de todos los programas instalados en mi sistema para poder "aprobar" una excepción.

    Me tomó alrededor de cinco minutos escribir un script rápido que pudiera ejecutarse tantas veces en el futuro que me hicieran la misma pregunta. Enumera los paquetes RPM instalados en mi host y extrae la descripción de cada paquete. Este script produjo una lista de más de 1900 paquetes con una breve descripción de cada uno. Envié esta lista al PHB que la solicitó y nunca más supe de ella, nunca más.

    A veces, el punto de dolor se resuelve fácil y rápidamente. Pero los PHB generalmente requieren atención inmediata.

    Pensamientos finales

    Empecé por crear un script de automatización simple para hacer frente a la tarea que más me dolía. Luego pasé al siguiente punto doloroso, y así sucesivamente. Eventualmente, esos puntos dolorosos originales regresan y necesitan ser refinados usando herramientas más avanzadas como Ansible. Este es un proceso iterativo que nunca terminará.

    Artículos de interés

    Subir