Infraestructura de MercadoLibre

La entrevista de Pelado Neerd a dos administradores de sistemas de MercadoLibre (familiarmente y en adelante ML) aporta el estímulo de conocer qué se hace en otros entornos, sus diferencias con los nuestros, por tamaño o por decisiones para retos de infraestructura. Destaco unos pocos asuntos que me han llamado la atención y porqué:

  • Servidores: 10.000, aparentemente todo máquinas virtuales y no se menciona que haya infraestructura en centro de datos propio.
  • Equipo: 300 personas en mantenimiento de la infraestructura y 7.000 desarrolladores. Dividido en equipos de comunicaciones, creación y mejora de la propia infraestructura, operación de la infraestructura.
  • Nubes empleadas: emplean AWS y GCE para evitar dependencias, realizan movimiento de infraestructura de una a otra aunque determinados servicios está atados a una de ellas.
  • Machine Learning para optimización de la infraestructura: han empleado machine learning para diagnosticos de la infraestructura, si proyectan crecimientos, dónde optimizar, etc. Coinciden con Pelado Nerd que un acercamiento menos ambicioso es más efectivo. Hay herramientas de machine learning en el mercado que ofrecen ahorros como resultados de sus diagnósticos y el coste de la herramienta es superior al ahorro que propone.
  • Infraestructura para pruebas: las pruebas de desarrollo se realizan automatizadamente (CI / CD vía Git, sin necesidad del equipo de infraestructura) en una infraestructura que se despliega a propósito para cada prueba sin afectar al resto de los entornos, cuando finaliza la prueba se destruye.
  • Modelos de despliegue: “blue-green” es empleado mayoritariamente, en ocasiones “rolling

Acotando el comando top para un proceso concreto

El comando top ofrece opciones para casi todo. La administración de Linux requiere, a veces, fijarse en uno o unos pocos procesos concretos. Hay otras maneras de hacerlo (es una de las ventajas de Linux).

Resulta fácil recordar esta opción, en la que a continuación del comando top añadimos “-p” de process y podemos poner tantos PID separados por coma como sean necesarios.

# top -p659

Un ejemplo de cómo se ve un solo proceso, en este caso el demonio de fail2ban:

Otro ejemplo de cómo ver más de un proceso, en este caso, dos procesos de nginx:

# top -p487,488

(Des)habilitar una aplicación al inicio de Gnome

Al iniciar sesión en Gnome pueden iniciarse aplicaciones automáticamente. Se trata de una aplicación, cualquiera, no de un demonio del sistema, y que solamente se arranca cuando el usuario inicia su sesión.

¿De qué manera se habilita o deshabilita el auto arranque de una aplicación? El directorio /home/usuario/.config/autostart/ del usuario contiene un fichero oculto con el nombre de la aplicación que se está iniciando automáticamente.

Una instalación de Microsoft Teams en Linux creará un fichero como el que sigue y tanto para este ejemplo como para el resto, la línea a modificar es evidente, destaco en negrita:

user@host:~/.config/autostart$ cat teams.desktop
[Desktop Entry]
Version=1.0
Type=Application
Encoding=UTF-8
Name=Microsoft Teams - Preview
Exec=/usr/bin/teams %U
Icon=teams
Terminal=false
StartupNotify=false
Categories=Network;Application;
MimeType=x-scheme-handler/msteams;
X-GNOME-Autostart-enabled=false
X-KDE-Protocols=teams

No need to reboot

This week in a -almost- desperate way of trying to solve an effect because no root cause is detected a machine reboot has been scheduled. When I was starting at Linux system administration I realized that there’s no need to reboot s Linux system in general, only in very specific scenarios.

Although production environments at job are now over a year of uptime I feel particularly proud that a humble -and quite old- RaspberryPi for testing purposes at home has reached 76 days of uptime. It’s needs to be told that I never take care of power supply and reboot that little one every time this is the shortest path to solve anything in there.

Administrar 2.500 estaciones de trabajo Linux según Mercedes-Benz

Aprendo en una de las comunicaciones de The Chemnitz Linux Days sobre el porqué de las herramientas que Mercedes-Benz ha empleado en 2.500 estaciones de sus desarrolladores, sobre Linux obviamente.

Las comunicación trataba sobre cómo se despliega, configura, se recupera en caso de regresión, una estación de trabajo. También gestionan los test de calidad y funcionalidad.

Se puede aprender de las decisiones de otros, tanto si las compartes como si no, la cuestión es estar “abierto al cambio“. Por ejemplo la no elección de Ansible obedeció a que otra herramienta sí ofrece una cola que procesará si el equipo destino no está disponible, el peaje es que requiere un agente.

Incluso aprendes cuando preguntas y te responden distinto a lo que esperabas. En este caso me interesaban aspectos de funcionalidad y la respuesta ha ido orientada a “las necesidades de los clientes que utilizan las máquinas…” es otro punto de vista igual de válido para decidir qué criterio seguir ante un problema.