{"id":1395,"date":"2026-09-01T14:02:53","date_gmt":"2026-09-01T20:02:53","guid":{"rendered":"https:\/\/folken-it.com\/?p=1395"},"modified":"2026-09-01T14:02:55","modified_gmt":"2026-09-01T20:02:55","slug":"comandos-de-ansible-mas-utilizados-para-administrar-100-servidores-linux","status":"publish","type":"post","link":"https:\/\/folken-it.com\/?p=1395","title":{"rendered":"Comandos de Ansible m\u00e1s utilizados para administrar 100 servidores Linux"},"content":{"rendered":"\n<figure class=\"wp-block-image size-large\"><img data-recalc-dims=\"1\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"576\" src=\"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=1024%2C576&#038;ssl=1\" alt=\"\" class=\"wp-image-1396\" srcset=\"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=1024%2C576&amp;ssl=1 1024w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=300%2C169&amp;ssl=1 300w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=768%2C432&amp;ssl=1 768w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=229%2C129&amp;ssl=1 229w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=348%2C196&amp;ssl=1 348w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=480%2C270&amp;ssl=1 480w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=999%2C562&amp;ssl=1 999w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?resize=1536%2C864&amp;ssl=1 1536w, https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?w=1672&amp;ssl=1 1672w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Administrar decenas o cientos de servidores manualmente puede convertirse r\u00e1pidamente en una tarea complicada. Ejecutar un comando mediante SSH en un servidor es sencillo; ejecutarlo de manera controlada sobre 100 servidores es otro problema completamente diferente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aqu\u00ed es donde <strong>Ansible<\/strong> se convierte en una herramienta extremadamente \u00fatil para administradores Linux, ingenieros DevOps, SRE y equipos de Production Support.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En este art\u00edculo veremos algunos de los comandos de Ansible que m\u00e1s utilizo o considero \u00fatiles para tareas administrativas sobre un inventario de aproximadamente <strong>100 hosts Linux<\/strong>, organiz\u00e1ndolos por <strong>m\u00f3dulos y tipo de actividad administrativa<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">1. Preparando el inventario<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Supongamos que tenemos 100 servidores distribuidos entre servidores web, aplicaciones y bases de datos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nuestro archivo <code>inventory.ini<\/code> podr\u00eda tener esta estructura:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;webservers]\nweb01\nweb02\nweb03\n...\nweb30<\/code><\/pre>\n\n\n<p>[appservers]<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">app01 app02 app03 &#8230; app50<\/p>\n\n\n<p>[databases]<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">db01 db02 db03 &#8230; db20<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tenemos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>30 Web Servers\n50 Application Servers\n20 Database Servers\n-----------------------\n100 Hosts\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos verificar c\u00f3mo interpreta Ansible nuestro inventario:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-inventory -i inventory.ini --graph\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para obtener todos los detalles:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-inventory -i inventory.ini --list\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Y para consultar un host determinado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-inventory -i inventory.ini --host app01\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">2. M\u00f3dulo ping \u2014 comprobar conectividad<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de realizar cualquier actividad sobre 100 servidores, normalmente lo primero que debemos hacer es verificar que Ansible pueda conectarse correctamente.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini -m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Una respuesta correcta ser\u00e1 similar a:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>app01 | SUCCESS =&gt; {\n    \"changed\": false,\n    \"ping\": \"pong\"\n}\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Es importante recordar que <code>ansible.builtin.ping<\/code> <strong>no ejecuta un ICMP ping tradicional<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ansible intenta conectarse al servidor y comprobar que existe un entorno Python utilizable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comprobar \u00fanicamente servidores de aplicaciones<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini -m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Conectar con otro usuario<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini -u ansible -m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Utilizar sudo<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini -u ansible --become \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esta es una excelente comprobaci\u00f3n previa antes de iniciar patching, reinicios o cambios importantes.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">3. M\u00f3dulo command \u2014 ejecutar comandos Linux<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><code>ansible.builtin.command<\/code> probablemente sea uno de los m\u00f3dulos m\u00e1s utilizados durante actividades de soporte.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, obtener el uptime de los 100 servidores:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"uptime\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Consultar memoria:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"free -m\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Consultar versi\u00f3n del kernel:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"uname -r\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verificar filesystem:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"df -h\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Comprobar procesos Java:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"pgrep -a java\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El m\u00f3dulo <code>command<\/code> debe utilizarse cuando \u00fanicamente necesitamos ejecutar un programa o comando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para pipes, redirecciones y otras funciones del shell utilizaremos el m\u00f3dulo <code>shell<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">4. M\u00f3dulo shell \u2014 troubleshooting avanzado<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">El m\u00f3dulo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible.builtin.shell\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">permite utilizar pipes, variables, redirecciones y otras caracter\u00edsticas del shell.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, encontrar filesystems superiores al 80%:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"df -P | awk 'NR&gt;1 &amp;&amp; \\$5+0 &gt; 80 {print}'\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Buscar procesos Java:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"ps -ef | grep java | grep -v grep\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Consultar los procesos que consumen m\u00e1s memoria:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"ps aux --sort=-%mem | head\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Consultar puertos escuchando:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"ss -lntp\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Buscar archivos grandes:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"find \/var -type f -size +1G -ls 2&gt;\/dev\/null\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este m\u00f3dulo es especialmente \u00fatil durante troubleshooting de incidentes.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">5. M\u00f3dulo setup \u2014 obtener informaci\u00f3n de los servidores<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Ansible puede recolectar autom\u00e1ticamente informaci\u00f3n del sistema mediante:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible.builtin.setup\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para obtener todos los facts:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.setup\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, para 100 servidores la informaci\u00f3n puede ser enorme.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es mejor utilizar filtros.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Obtener sistema operativo<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.setup \\\n-a \"filter=ansible_distribution*\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Obtener memoria<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.setup \\\n-a \"filter=ansible_memtotal_mb\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Obtener procesadores<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.setup \\\n-a \"filter=ansible_processor*\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Obtener direcciones IP<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.setup \\\n-a \"filter=ansible_default_ipv4\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto resulta particularmente \u00fatil para inventarios, auditor\u00edas y troubleshooting.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">6. M\u00f3dulo service \u2014 administrar servicios<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">En Production Support constantemente necesitamos verificar, iniciar, detener o reiniciar servicios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para comprobar operaciones sobre Apache:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible webservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.service \\\n-a \"name=httpd state=started\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Reiniciar servicio<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible webservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.service \\\n-a \"name=httpd state=restarted\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Detener servicio<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible webservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.service \\\n-a \"name=httpd state=stopped\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Habilitar el servicio durante el boot<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible webservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.service \\\n-a \"name=httpd state=started enabled=yes\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto puede utilizarse igualmente para servicios de middleware, agentes de monitorizaci\u00f3n u otros componentes.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">7. M\u00f3dulo systemd_service \u2014 servidores Linux con systemd<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando sabemos que nuestros servidores utilizan systemd podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible.builtin.systemd_service\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.systemd_service \\\n-a \"name=myapp state=restarted\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Recargar configuraci\u00f3n de systemd:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.systemd_service \\\n-a \"daemon_reload=true\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Consultar el estado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.command \\\n-a \"systemctl status myapp\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">8. M\u00f3dulo package \u2014 instalaci\u00f3n y patching<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Una de las principales ventajas de Ansible es poder realizar mantenimiento sobre muchos servidores simult\u00e1neamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para instalar un paquete:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.package \\\n-a \"name=vim state=present\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Actualizar un paquete:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.package \\\n-a \"name=openssl state=latest\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Eliminarlo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.package \\\n-a \"name=telnet state=absent\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para servidores Red Hat\/Oracle Linux tambi\u00e9n podemos utilizar m\u00f3dulos espec\u00edficos del gestor de paquetes cuando necesitemos funcionalidades adicionales.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">9. M\u00f3dulo reboot \u2014 reinicios controlados<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Durante actividades de patching normalmente ser\u00e1 necesario reiniciar algunos servidores.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En lugar de ejecutar simplemente:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>reboot\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">podemos utilizar el m\u00f3dulo dedicado:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.reboot\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.reboot \\\n-a \"reboot_timeout=600\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La ventaja es que Ansible puede esperar hasta que el servidor vuelva a estar disponible.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">10. M\u00f3dulo copy \u2014 distribuir archivos a 100 servidores<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Supongamos que necesitamos distribuir un archivo de configuraci\u00f3n.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.copy \\\n-a \"src=application.conf dest=\/etc\/application.conf\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n podemos establecer permisos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.copy \\\n-a \"src=application.conf dest=\/opt\/app\/application.conf owner=appuser group=appgroup mode=0644\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Un uso habitual ser\u00eda distribuir:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Configuraciones\nCertificados\nScripts\nAgentes\nArchivos de propiedades\nConfiguraciones de monitoreo\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Para configuraciones din\u00e1micas y reutilizables normalmente ser\u00e1 mejor utilizar templates y playbooks.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">11. M\u00f3dulo file \u2014 permisos, directorios y archivos<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Crear un directorio en los servidores:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.file \\\n-a \"path=\/opt\/application\/logs state=directory owner=appuser group=appgroup mode=0755\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Modificar permisos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.file \\\n-a \"path=\/opt\/application\/start.sh mode=0755\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Eliminar un archivo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.file \\\n-a \"path=\/tmp\/old_file.log state=absent\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">12. M\u00f3dulo fetch \u2014 recolectar logs<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Esta funci\u00f3n resulta extremadamente \u00fatil para Production Support.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Supongamos que necesitamos descargar un log desde los servidores:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n-m ansible.builtin.fetch \\\n-a \"src=\/var\/log\/messages dest=.\/logs\/\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ansible almacenar\u00e1 los archivos manteniendo informaci\u00f3n del host correspondiente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos utilizar este mecanismo para recolectar r\u00e1pidamente evidencia de diferentes servidores durante un incidente.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">13. M\u00f3dulo user \u2014 administraci\u00f3n de usuarios<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Crear un usuario:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.user \\\n-a \"name=monitor state=present\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Eliminarlo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.user \\\n-a \"name=monitor state=absent\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Agregar un usuario a un grupo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n--become \\\n-m ansible.builtin.user \\\n-a \"name=appuser groups=application append=yes\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">14. Ejecutar comandos en paralelo<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando administramos 100 hosts resulta importante controlar el paralelismo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ansible utiliza la opci\u00f3n:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>--forks\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">o:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>-f\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.ping \\\n-f 20\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto permite procesar hasta 20 hosts simult\u00e1neamente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para una consulta sencilla:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"uptime\" \\\n-f 20\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">No siempre debemos utilizar el m\u00e1ximo paralelismo posible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En tareas sensibles como reinicios de cl\u00fasteres, bases de datos o middleware es mejor controlar cuidadosamente cu\u00e1ntos servidores se procesan simult\u00e1neamente.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">15. Ejecutar solamente contra determinados servidores<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Esta capacidad es fundamental cuando administramos grandes inventarios.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo, solamente servidores web:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible webservers -i inventory.ini -m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Solamente application servers:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini -m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Excluir un servidor:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible 'appservers:!app01' \\\n-i inventory.ini \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ejecutar contra dos grupos:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible 'webservers:appservers' \\\n-i inventory.ini \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ejecutar contra hosts determinados:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible 'app01:app02:app03' \\\n-i inventory.ini \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">16. Comprobar cambios antes de ejecutarlos<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">En producci\u00f3n siempre debemos intentar reducir el riesgo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Algunos m\u00f3dulos soportan:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>--check\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n--become \\\n-m ansible.builtin.copy \\\n-a \"src=application.conf dest=\/etc\/application.conf\" \\\n--check\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Esto permite comprobar qu\u00e9 cambios intentar\u00eda realizar Ansible sin aplicarlos.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No todos los m\u00f3dulos y comandos pueden simular completamente una operaci\u00f3n, por lo que <code>--check<\/code> nunca debe sustituir nuestros procedimientos de cambio, pruebas y respaldos.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">17. Ejecutar Playbooks<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Los comandos ad hoc son excelentes para diagn\u00f3stico y tareas puntuales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para operaciones repetibles debemos utilizar Playbooks.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ejecutar uno:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Limitarlo solamente a application servers:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml \\\n--limit appservers\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Limitarlo a un servidor:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml \\\n--limit app01\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Simular cambios:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml \\\n--check\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ver qu\u00e9 hosts ser\u00e1n afectados:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml \\\n--list-hosts\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ver las tareas:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml \\\n--list-tasks\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">18. Ejemplo real: revisi\u00f3n de 100 servidores antes de mantenimiento<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de una ventana de mantenimiento podr\u00edamos ejecutar varias comprobaciones.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Verificar conectividad<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">2. Verificar uptime<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"uptime\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">3. Revisar filesystem<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"df -h\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">4. Revisar memoria<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"free -m\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">5. Revisar aplicaciones<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n-m ansible.builtin.shell \\\n-a \"ps -ef | grep java | grep -v grep\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">6. Ejecutar mantenimiento<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible-playbook -i inventory.ini maintenance.yml\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">7. Verificar conectividad nuevamente<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible all -i inventory.ini \\\n-m ansible.builtin.ping\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">8. Verificar aplicaciones<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible appservers -i inventory.ini \\\n-m ansible.builtin.command \\\n-a \"systemctl status myapp\"\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con estas operaciones podemos realizar una validaci\u00f3n pre-check \u2192 mantenimiento \u2192 post-check sobre decenas o cientos de servidores.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">19. Cheat sheet<\/h1>\n\n\n\n<pre class=\"wp-block-code\"><code># Inventario\nansible-inventory -i inventory.ini --graph\n\n# Conectividad\nansible all -i inventory.ini -m ansible.builtin.ping\n\n# Uptime\nansible all -i inventory.ini -m ansible.builtin.command -a \"uptime\"\n\n# Filesystem\nansible all -i inventory.ini -m ansible.builtin.command -a \"df -h\"\n\n# Memoria\nansible all -i inventory.ini -m ansible.builtin.command -a \"free -m\"\n\n# Facts\nansible all -i inventory.ini -m ansible.builtin.setup\n\n# Procesos\nansible all -i inventory.ini -m ansible.builtin.shell -a \"ps -ef\"\n\n# Reiniciar servicio\nansible appservers -i inventory.ini --become \\\n-m ansible.builtin.service -a \"name=myapp state=restarted\"\n\n# Copiar archivo\nansible all -i inventory.ini \\\n-m ansible.builtin.copy \\\n-a \"src=file.conf dest=\/tmp\/file.conf\"\n\n# Crear directorio\nansible all -i inventory.ini \\\n-m ansible.builtin.file \\\n-a \"path=\/opt\/application state=directory\"\n\n# Reboot\nansible appservers -i inventory.ini \\\n--become -m ansible.builtin.reboot\n\n# Playbook\nansible-playbook -i inventory.ini maintenance.yml\n\n# Limitar hosts\nansible-playbook -i inventory.ini maintenance.yml --limit appservers\n\n# Simulaci\u00f3n\nansible-playbook -i inventory.ini maintenance.yml --check\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Conclusi\u00f3n<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando administramos 100 servidores, Ansible deja de ser simplemente una herramienta DevOps y se convierte en una herramienta de operaci\u00f3n.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un administrador puede pasar de conectarse manualmente mediante SSH a decenas de servidores a ejecutar una misma comprobaci\u00f3n de manera centralizada, consistente y repetible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para tareas puntuales, los comandos <strong>ad hoc<\/strong> son extraordinariamente \u00fatiles. Para actividades repetitivas como patching, failover, reinicios de cl\u00faster, deployments o mantenimiento programado, es mucho mejor convertir esas operaciones en <strong>Playbooks reutilizables<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El verdadero beneficio de Ansible no consiste solamente en ejecutar un comando en 100 m\u00e1quinas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Consiste en conseguir que <strong>100 m\u00e1quinas reciban una operaci\u00f3n controlada, repetible y verificable desde un \u00fanico punto de administraci\u00f3n<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Administrar decenas o cientos de servidores manualmente puede convertirse r\u00e1pidamente en una tarea complicada. Ejecutar un comando mediante SSH en un servidor [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":1396,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"Comandos de Ansible m\u00e1s utilizados para administrar","jetpack_seo_html_title":"Comandos de Ansible m\u00e1s utilizados para administrar","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[62,63],"tags":[],"class_list":["post-1395","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automatizacion","category-configuracion"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/09\/ansible.png?fit=1672%2C941&ssl=1","_links":{"self":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1395"}],"version-history":[{"count":1,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1395\/revisions"}],"predecessor-version":[{"id":1397,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1395\/revisions\/1397"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/media\/1396"}],"wp:attachment":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1395"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1395"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}