Gestión y administración centralizada

Nos encaminamos hacia la computación en la nube como la mejor solución para el manejo diario de aplicaciones que requieren soluciones flexibles, plataformas que evolucionan y adaptabilidad de servicios. Además, el Software Libre se desarrolla a velocidades sorprendentes para satisfacer esta necesidad de cloud computing, generando continuamente nuevos proyectos y comunidades.

El Software Libre y la computación de nube han elevado el número de nodos como nunca antes; si bien se pueden aplicar algunas políticas generales, siempre hay que llegar a impactar cambios a nivel de cada nodo o máquina virtual. Se ha vuelto necesario disponer de herramientas que permitan aplicar esas políticas rápidamente: desde una nueva regla para el sistema de monitoreo, una tarea programada o la instalación de un nuevo software. Esta presentación aborda algunas de las alternativas disponbiles con Software Libre que permiten convertirse en el Director del centro de datos: para que los nodos actúen al unísono y las políticas estén siempre aplicadas.

Público objetivo: Técnicos encargados de administración de servidores, SysOps y DevOps, administradores de centros de datos.

Requisitos: Conocimientos de sistemas operativos (Unix), administración de servidores. Cloud computing

Conferencia dictada en:

Video de la presentación realziada en el marco de Avanza 2014:

Avanza 2014

Ejecutar un script bash remoto sin instalar

Me ha sido muy útil ejecutar scripts remotos sin instalarlos localmente. Esto me permite, por ejemplo, hacer la instalación inicial del cliente Puppet o poner Ansible para completar la configuración del sistema hasta llevarlo a estado de producción.

Para descargar el script se puede usar tanto el comando curl como wget. Uno u otro suelen venir instalados por defecto en cualquier distribución Linux.

La idea es simple: correr el comando (wget o curl) y obtener la salida (script) limpia (es decir, sin datos extra de transferencia o ejecución) y pasarlo como entrada a bash para su interpretación y ejecución local.

He armado un simple script, cuyo código puede ser visto aqui: script-remoto.txt (la terminación txt es solamente para que lo muestre el navegador, pero no necesita ninguna extensión en particular), que puede ser ejecutado con cualquiera de estos comandos:

con curl:

source <(curl -s http://pilas.guru/wp-content/uploads/script-remoto.txt)

bash <(curl -s http://pilas.guru/wp-content/uploads/script-remoto.txt)

curl -s http://pil.as/1h1n | source /dev/stdin

curl -sL http://pilas.guru/wp-content/uploads/script-remoto.txt | bash -s

con wget:

source <(wget -qO- http://pilas.guru/wp-content/uploads/script-remoto.txt)

bash <(wget -qO- http://pilas.guru/wp-content/uploads/script-remoto.txt)

wget -qO- http://pil.as/1h1n | source /dev/stdin

wget -qO- http://pilas.guru/wp-content/uploads/script-remoto.txt | bash -s

Pueden ver que he creado un enlace corto que redirecciona al mismo archivo http://pil.as/1h1n, pero ATENCION, no se debe confiar en los enlaces cortos livianamente y MENOS con la intención de ejecutar comandos ajenos en el equipo propio.

Puppet para hacer el trabajo por ti en el Datacenter

Para manejar un número importante de servidores en un datacenter, originalmente contábamos con un conjunto de scripts que ajustaban la instalación a nuestras políticas; con la virtualización comenzamos a usar templates; pero hoy día con el advenimiento de la nube y las aplicaciones que crean servidores, necesitamos mayor flexibilidad para atender requisitos variables y muy particulares, pero además se necesita un método que permita asegurar que cualquier cambio de políticas pueda ser impactado rápidamente en toda la granja. Puppet hace ese trabajo por ti en el Datacenter. En esta presentación se aborda también algunos ejemplos prácticos en los que Puppet está siendo utlizando con éxito.

Público Objetivo: Técnicos encargados de administración de servidores, SysOps y DevOps, administradores de centros de datos.

Requisitos: Conocimientos de sistemas operativos (Unix), administración de servidores.

Conferencia dictada en:

¿Qué es un DevOps?

220px-Devops.svg DevOps MVD es un grupo de MeetUP que se ha formado en Montevideo con la idea es compartir entre desarrolladores y sysadmins distintas experiencias que mejoren nuestras capacidades DevOps; pero ¿qué es ser un DevOps?

En estos días llegó a mis manos un artículo que responde exactamente esa pregunta, así que esta es la traducción del artículo What Is a DevOps Engineer? publicado el 23.mayo.2013 en el Blog de Puppet Labs.

¿Qué es ser un DevOps?

(Por: Aliza Earnshaw – Traducción: Rodolfo Pilas)

La demanda de las personas con habilidades de DevOps está creciendo rápidamente porque las empresas están obteniendo grandes resultados de ellos.

Las organizaciones que utilizan prácticas de DevOps son abrumadoramente eficientes: actualizan código hasta 30 veces más frecuentemente que sus competidores, con un 50 por ciento menos de posibilidades que sus instalaciones fracasen, según muestra nuestra encuesta El Estado de DevOps del 2013.

Con todas estas ventajas, se podría pensar que había un montón de ingenieros DevOps por ahí. Sin embargo, sólo el 18 por ciento de los encuestados dijo que alguien en su organización realmente tenía este título.

¿Por qué sucede esto?

En parte, es porque la definición de lo que es un DevOps está aun en evolución. Sin embargo, esto no impide la contratación de DevOps. Entre enero de 2012 y enero de 2013, los listados de empleos para DevOps en Indeed.com aumentaron 75 por ciento. En LinkedIn.com, menciones de DevOps como una habilidad aumentó 50 por ciento durante el mismo período.

Nuestra encuesta reveló la misma tendencia. La mitad de los encuestados de más de 4.000 (en más de 90 países) dijeron que sus empresas tienen en cuenta las habilidades DevOps la hora de contratar.

¿Cuáles son las habilidades DevOps?

Los encuestados identificaron las tres principales áreas de habilidades para el personal DevOps:

  • Codificación o scripting
  • Reingeniería de procesos
  • Comunicarse y colaborar con los demás

Estas habilidades, apuntan a un creciente reconocimiento de que la complejidad del software de hoy en día se encuentra  en la creación y también en garantizar que el nuevo software funciona a través de un conjunto diverso de sistemas operativos y plataformas.

Del mismo modo, actualmente las pruebas e instalación se hacen con mucha más frecuencia. Es decir, pueden ser más frecuentes: si los desarrolladores se comunican rápido y regularmente con el equipo de operaciones, y si los operadores aportan su conocimiento del entorno de producción para el diseño de las pruebas y puesta en producción.

La discusión de lo que distingue a los ingenieros DevOps sobrepasa lo que se ha escrito en blogs y foros, y ocurre cuando los técnicos se reúnen.

Hay un montón de cosas para hablar, por ejemplo, cómo impulsar la codificación -no sólo el código- por encima del muro en las operaciones. Werner Vogels, el CTO de Amazon, dijo en una entrevista que cuando los desarrolladores asumen más responsabilidad de las operaciones, mejora la tecnología y el servicio a los clientes.

«El modelo tradicional trata de pasar el software por encima de la pared que separa el desarrollo de las operaciones y una vez del otro lado, olvidarse de él. No en Amazon. Usted lo construye, Usted lo corre. Esto hace que los desarrolladores estén en contacto con la operación del día a día. También quedan en contacto día a día con el cliente».

Sobre el bucle de realimentación con el cliente, Vogels dijo, «es esencial para la mejora de la calidad del servicio.»

Desde hace mucho tiempo desarrollador y empresario rico Pelavin de Reactor8 también ve los beneficios de la cultura DevOps en términos de una mayor responsabilidad de todos:

«He visto a las organizaciones donde los ingenieros tienen beepers, por lo que ellos son advertidos por el beep si algo sale mal [en la instalación y ejecución]. Eso los empuja hacia el resto del ciclo de vida del software. Creo que es una gran idea».

Eso es un cambio real para entornos no-DevOps, en los que los desarrolladores impactan los últimos cambios del día y se van a sus casas… o a la sala de ping-pong.

Y al final ¿qué es un DevOps? ¿Y quién los contrata?

No hay una carrera formal para convertirse en un ingeniero de DevOps. Ellos suelen ser los desarrolladores que se interesen en el despliegue de sus aplicaciones y en la red de operaciones; o los administradores de sistemas que tienen una pasión por secuencias de comandos y codificación e intervienen pasar a la parte de desarrollo, donde pueden mejorar la planificación de la prueba e instalación. De cualquier manera, se trata de personas que han empujado más allá de sus áreas de competencia definidas y que tienen una visión más integral de sus entornos técnicos.

Los DevOps siguen siendo un grupo muy pequeño, por lo que es razonable que pocas compañías tengan ese cargo. Kelsey Hightower, que dirige las operaciones aquí en Puppet Labs, describe a estas personas como las «Fuerzas Especiales» en una organización.

«El ingeniero DevOps encapsula profundidad de conocimientos y años de experiencia práctica», dijo Kelsey. «Está probado batalla. Es la persona que combina las habilidades del analista de negocios con las plantillas técnicas para construir la solución – además de que conoce bien el negocio, y puede ver cómo cualquier problema afecta a toda la empresa «.

Si DevOps se entiende como una forma de pensar, puede resultar confuso. Por suerte, muchas personas han probado definiciones como para permitirnos hacer una lista de los atributos principales del DevOps:

  • Capacidad para utilizar una amplia variedad de tecnologías y herramientas de código abierto
  • Capacidad para codificar y hacer scripts
  • La experiencia sistemas y operaciones de TI
  • Comodidad con las frecuentes pruebas de código incrementales e instalaciones
  • Buen conocimiento de las herramientas de automatización
  • Capacidad de gestión de datos
  • Un fuerte enfoque en los resultados del negocio
  • Confort con la colaboración, la comunicación abierta y pasar a través de fronteras funcionales

Incluso con un amplio acuerdo acerca de los atributos fundamentales del DevOps, nace la controversia alrededor  del término «ingeniero DevOps.» Algunos dicen que el término en sí mismo contradice los valores DevOps.

Jez Humble, el co-autor de Continuous Delivery, señala que sólo con llamar a alguien un ingeniero DevOps puede crear un tercer compartimento además de dev y ops«… claramente es una forma inadecuada (e irónica) para tratar de resolver estos problemas.»

Dice que DevOps propone «estrategias para crear una mejor colaboración entre los compartimentos funcionales, o acabar con esos compartimentos funcionales en conjunto y la creación de equipos multifuncionales (o alguna combinación de estos métodos).» Al final, Humble cede terreno al decir que está bien llamar a la gente haciendo DevOps por este término, si Usted quiere.

Para convertirse en un ingeniero DevOps: ¿Qué se necesita?

¿Se ha convencido de que DevOps es su futuro? Si es así, querrá empezar a ampliar sus habilidades y experiencia para competir por estos nuevos puestos de trabajo.

Por un lado, está bien reforzar sus habilidades de codificación, familiarizarse con las herramientas de automatización, pero también buscar proyectos y nuevas funciones que permitan ejercitar las habilidades «accesibles» que se encuentran en la esencia del DevOps. Además encontrar oportunidades para colaborar dentro y fuera de su equipo. Tal vez, ayudar en  su empresa para pasar a un régimen de pruebas rápidas y alto ritmo de instalación. Y estar abierto a escuchar las ideas de los demás. Tenga en cuenta que DevOps se trata tanto de hacer las cosas de una manera particular, y más acerca de cómo mover el negocio hacia adelante y darle una ventaja tecnológica más fuerte.

Más información sobre DevOps:

How Do You Make $100K in IT? Look to the DevOps Shops
Bridging the Two Worlds: IT and Networking
Hiring for the DevOps Toolchain: The Need for Generalists
DevOps Resources

 

Ahorro de energía eléctrica

Nuestro gobierno ha decretado el «plan coyuntural de ahorro de energía eléctrica para reducir consumo«, debido a que, como dice el propio decreto, las centrales hidroeléctricas han reducido su producción energética a su mínimo histórico…. o sea que está seca la cosa.

Con el fin de adaptar los PC de escritorio a condiciones de bajo consumo, se decidió que cuando no sea usado se apague el monitor a los 2 minutos, el disco a los 9 y suspender todo el PC a los 10. El problema es configurar esto en más de 150 PC distribuídas en varios pisos, por lo que cree el script que aquí publico.

La idea es un script para ejecutar en el $HOME/.profile de cada usuario cuando ingresa al sistema y distribuirlo mediante puppet a cada una de las PC de escritorio.

Aun estamos en pruebas de usabilidad de los resultados de la aplicación de estas medidas, para establecer las políticas de soporte, así que hay posibilidades de cambios y/o correcciones. Y, en todos los casos, sugiero que quién lo quiera usar haga sus propias pruebas:

#!/bin/sh
# Configuración para ahorro de energía para aplicar en Gnome2/Ubuntu-10.04
# 2 minutos apaga monitor
# 9 minutos apaga disco, 10 minutos suspende PC

GC=/usr/bin/gconftool-2
B=/apps/gnome-power-manager

#########
# DISCO #
#########
# Activar modo bajo consumo cuando está conectado AC
$GC –type bool -s $B/disks/spindown_enable_ac true

# Segundos de inactividad para reducir velocidad de rotación en AC
$GC –type init -s $B/disks/spindown_timeout_ac 1120

###########
# MONITOR #
###########
# Evita pedir clave cuando apaga monitor
$GC –type bool -s /apps/gnome-screensaver/lock_enabled false

# Tiempo de reposo cuando está en AC
$GC –type init -s $B/timeout/sleep_display_ac 120

# Brillo del monitor
$GC –type bool -s $B/backlight/idle_dim_ac true
$GC –type init -s $B/backlight/brightness_ac 80

######
# PC #
######
# Tiempo para reposo de la computadora
$GC –type init -s $B/timeout/sleep_computer_ac 1200

exit 0

Si tienen sugerencias, adelante con los comentarios!

Foto: senza_nick