Admin Prac Linux Azure v2

Descargue
Administración
práctica de Linux en
Azure: segunda edición
Desarrolle, mantenga y automatice aplicaciones en
la plataforma en la nube de Azure
Kamesh Ganesan, Rithin Skaria y Frederik Vos

Descargue Administración práctica de Linux en Azure: segunda edición
Copyright © 2019 Packt Publishing
Todos los derechos reservados. No está permitida la reproducción, el almacenamiento
en un sistema de recuperación ni la transmisión en cualquier formato o por cualquier
medio de una parte de este libro sin la autorización previa y por escrito del editor,
salvo en el caso de citas breves introducidas en artículos o revistas de opinión crítica.
Durante la preparación de este libro, se hizo todo lo posible por asegurar la exactitud
de la información presentada. Sin embargo, los datos que contiene este libro se
venden sin garantía, ya sea expresa o implícita. Ni los autores ni Packt Publishing,
sus concesionarios y distribuidores, se considerarán responsables de cualquier daño
causado o presuntamente causado de manera directa o indirecta por el contenido de
este libro.
PACKT Publishing intentó proporcionar información de marca de todas las empresas
y los productos mencionados en este libro mediante el uso adecuado de mayúsculas.
Sin embargo, Packt Publishing no garantiza la exactitud de esta información.
Autores: Kamesh Ganesan, Rithin Skaria y Frederik Vos
Revisores técnicos: Ashvith Bangera, Janaka Channa Bandara Rangama y Toni Willberg
Editor general: Afzal Shaikh
Editora de adquisiciones: Alicia Wooding y Clint Rodricks
Editor de producción: Deepak Chavan
Comité editorial: Sonali Anubhavne, Vishal Bodwani, Ewan Buckingham, Alex
Mazonowicz y Jonathan Wray
Fecha de primera publicación: agosto de 2018
Segunda edición: diciembre de 2019
Referencia de producción: 1020320
ISBN: 978-1-83921-552-0
Publicado por Packt Publishing Ltd.
Livery Place, 35 Livery Street
Birmingham B3 2PB, Reino Unido.
Tabla de contenido
Prólogo   i
Capítulo 1: Exploración de la nube de Microsoft Azure   1
Conceptos básicos de la informática en la nube ................................................  2

Virtualización .................................................................................................................. 3
SDDC ................................................................................................................................ 4
SOA .................................................................................................................................. 6
Servicios en la nube ....................................................................................................... 7
Tipos de nube ................................................................................................................. 8
Definición de la nube de Microsoft Azure ...........................................................  9
Una breve historia de la nube de Microsoft Azure .................................................... 9
Arquitectura de Azure ................................................................................................. 10
Azure en su organización ............................................................................................ 11
Azure y Open Source ................................................................................................... 12
Resumen ................................................................................................................  12
Preguntas ...............................................................................................................  13
Lectura adicional ..................................................................................................  13
Capítulo 2: Introducción a la nube de Azure   15
Requisitos técnicos ...............................................................................................  16

Cómo obtener acceso a Azure .............................................................................  17
Inicio de sesión con Azure Portal ............................................................................... 17
Cómo obtener acceso de línea de comandos a Azure ............................................ 18
Instalación de la CLI de Azure .................................................................................... 18
Inicio de sesión con la CLI de Azure ........................................................................... 19
PowerShell .................................................................................................................... 24
Inicio de sesión con PowerShell ................................................................................. 25
Azure Resource Manager ............................................................................................ 28
Linux y Azure .........................................................................................................  30
Distribuciones de Linux .............................................................................................. 30
Distribuciones de Linux avaladas por Microsoft ..................................................... 31
Implementación de una máquina virtual Linux ...............................................  32
Su primera máquina virtual ....................................................................................... 32
Imágenes ....................................................................................................................... 33
Tamaño de la máquina virtual ................................................................................... 38
Redes de máquinas virtuales ..................................................................................... 39
Información de la máquina virtual ............................................................................ 41
Conexión a Linux ..................................................................................................  43
Inicio de sesión en la máquina virtual Linux mediante
autenticación de contraseña  ..................................................................................... 43
Inicio de sesión en su máquina virtual Linux con una clave privada SSH  ........... 43
Resumen ................................................................................................................  45
Preguntas ...............................................................................................................  45
Capítulo 3: Administración básica de Linux   47
El shell de Linux .....................................................................................................  48

Ejecución de comandos ............................................................................................... 49
Edición de línea de comandos .................................................................................... 51
Cómo trabajar con el historial .................................................................................... 53
Finalización automática .............................................................................................. 54
Englobamiento ............................................................................................................. 55
Redireccionamientos ................................................................................................... 56
Cómo trabajar con variables ...................................................................................... 58
Archivos de configuración de Bash  .......................................................................... 60
Cómo obtener ayuda ............................................................................................  62
Uso de las páginas man .............................................................................................. 62
Uso de documentos de información ......................................................................... 65
Otra documentación ................................................................................................... 66
Cómo trabajar con archivos de texto .................................................................  66
Lectura de texto ........................................................................................................... 67
Búsquedas en archivos de texto ................................................................................ 69
Edición de archivos de texto ....................................................................................... 73
Cómo encontrar su camino en el sistema de archivos ....................................  74
El Estándar de jerarquía del sistema de archivos .................................................... 75
Cómo montar sistemas de archivos .......................................................................... 79
Cómo encontrar archivos en el sistema de archivos .............................................. 80
Administración de procesos ................................................................................  82
Visualización de los procesos ..................................................................................... 82
Envío de señales a un proceso ................................................................................... 85
Control de acceso discrecional ...........................................................................  86
Administración de usuarios ........................................................................................ 86
Administración de grupos .......................................................................................... 91
Administración de inicio de sesión ............................................................................ 92
Resumen ................................................................................................................  94
Preguntas ...............................................................................................................  95
Capítulo 4: Administración de Azure   97
Administración de recursos de Azure con la CLI de Azure y PowerShell .......  98

Requisitos técnicos ...............................................................................................  99
Administración de los recursos de almacenamiento .....................................  100
Cuentas de almacenamiento ................................................................................... 101
Managed Disks ........................................................................................................... 104
Azure Files ................................................................................................................... 107
Blob de Azure ............................................................................................................. 111
Administración de recursos de red ..................................................................  114
Red virtual ................................................................................................................... 115
Subredes ..................................................................................................................... 116
Grupo de seguridad de red ....................................................................................... 118
Dirección IP pública e interfaz de red ..................................................................... 122
Administración de recursos de proceso ..........................................................  125
Recursos de máquina virtual .............................................................................  126
Perfil de Azure ........................................................................................................... 126
Grupo de recursos .................................................................................................... 126
Cuenta de almacenamiento ................................................................................... 126
Redes virtuales .......................................................................................................... 127
Grupo de seguridad de red ...................................................................................... 127
Dirección IP pública e interfaz de red ................................................................... 128
Resumen ..............................................................................................................  128
Preguntas .............................................................................................................  129
Lectura adicional ................................................................................................  129
Capítulo 5: Administración avanzada de Linux   131
Requisitos técnicos .............................................................................................  132

Administración de software ..............................................................................  132
El administrador de software RPM .......................................................................... 133
Administración de software con YUM ..................................................................... 135
Administración de software con DNF ..................................................................... 137
El administrador de software DPKG ........................................................................ 138
Software de administración con apt ....................................................................... 140
Administración de software con ZYpp .................................................................... 141
Redes ....................................................................................................................  144
Identificación de las interfaces de red .................................................................... 145
Identificación de la dirección IP  .............................................................................. 146
Visualización de la tabla de rutas ............................................................................ 147
Configuración de la red ............................................................................................. 147
Cambios en la configuración de la red .................................................................... 150
Nombre de host ......................................................................................................... 151
DNS .............................................................................................................................. 152
Almacenamiento .................................................................................................  154
Almacenamiento proporcionado por dispositivos de bloque .............................. 154
Cómo agregar un disco de datos ............................................................................. 155
Creación de particiones ............................................................................................ 158
Sistemas de archivos en Linux ................................................................................. 160
El sistema de archivos ext4 ..................................................................................... 160
El sistema de archivos XFS ...................................................................................... 161
El sistema de archivos ZFS ....................................................................................... 162
Linux Software RAID .................................................................................................. 167
Stratis .......................................................................................................................... 168
systemd ................................................................................................................  171
Cómo trabajar con unidades .................................................................................... 172
Servicios ...................................................................................................................... 173
Destinos ...................................................................................................................... 176
Tareas programadas ................................................................................................. 176
Cómo montar un sistema de archivos local ........................................................... 178
Cómo montar un sistema de archivos remoto ...................................................... 178
Resumen ..............................................................................................................  180
Preguntas .............................................................................................................  180
Capítulo 6: Administración de seguridad e identidades de Linux   183
Sugerencias de seguridad para Linux ..............................................................  184

DAC .......................................................................................................................  186
Introducción a DAC .................................................................................................... 186
Permisos de archivo en Linux .................................................................................. 186
Método simbólico ...................................................................................................... 190
Nodo absoluto (numérico) ........................................................................................ 192
MAC ......................................................................................................................  194
LSM .............................................................................................................................. 195
SELinux ........................................................................................................................ 195
Configuración de SELinux ......................................................................................... 196
Contexto de SELinux en archivos ............................................................................. 200
SELinux Boolean ......................................................................................................... 203
AppArmor  .................................................................................................................. 203
Estado de AppArmor ................................................................................................. 204
Generación de perfiles de AppArmor ...................................................................... 205
firewalld y systemd .............................................................................................  209
Zonas de firewalld ..................................................................................................... 212
Servicios de firewalld ................................................................................................. 214
Orígenes de red de firewalld .................................................................................... 216
Seguridad de systemd ............................................................................................... 217
Restricción del acceso al sistema de archivos ........................................................ 218
Restricción del acceso a la red ................................................................................. 219
Administración de identidades y acceso en Azure: IAM ................................  221
Azure AD Domain Services ....................................................................................... 221
Configuración de Azure AD Domain Services ......................................................... 221
Configuración de Linux ............................................................................................. 222
Nombre de host ......................................................................................................... 222
Servidores DNS ........................................................................................................... 222
Instalación de dependencias .................................................................................... 223
Unión al dominio: Ubuntu y RHEL/CentOS ............................................................. 223
Unión al dominio: SUSE ............................................................................................. 226
Inicio de sesión con las credenciales de Azure AD en la VM Linux ...................... 229
Otras soluciones de seguridad en Azure ................................................................ 230
Resumen  .............................................................................................................  231
Preguntas .............................................................................................................  232
Capítulo 7: Implementación de sus máquinas virtuales   233
Escenarios de implementación .........................................................................  234

¿Qué necesita? ........................................................................................................... 235
Opciones de implementación automatizada en Azure ..................................  236
Creación de scripts .................................................................................................... 237
Implementación automatizada con Azure Resource Manager ............................ 241
Implementación de plantillas de ARM con PowerShell ........................................ 247
Implementación de plantillas de ARM con Bash ................................................... 247
Configuración inicial ...........................................................................................  248
Configuración inicial con la extensión de script personalizado ........................... 248
Configuración inicial con cloud-init ......................................................................... 252
Vagrant .................................................................................................................  255
Instalación y configuración de Vagrant .................................................................. 256
Implementación de una VM con Vagrant ............................................................... 258
Aprovisionadores de Vagrant ................................................................................... 260
Packer ...................................................................................................................  261
Instalación y configuración de Packer .................................................................... 261
VHD y máquinas virtuales personalizadas ......................................................  267
Creación de una imagen administrada ................................................................... 268
Un método alternativo que usa instantáneas ....................................................... 272
VHD personalizados ................................................................................................... 273
Resumen ..............................................................................................................  277
Preguntas .............................................................................................................  278
Capítulo 8: E
xploración de la automatización de la
configuración continua   281
Requisitos técnicos .................................................................................................... 284
Definición de la administración de la configuración ......................................  284
Uso de Ansible .....................................................................................................  285
Instalación de Ansible ............................................................................................... 285
Configuración de SSH ................................................................................................ 286
Configuración mínima indispensable ..................................................................... 287
Archivo de inventario ................................................................................................ 288
Manuales y módulos de Ansible .............................................................................. 289
Autenticación en Microsoft Azure ........................................................................... 292
Grupo de recursos ..................................................................................................... 293
Máquina virtual .......................................................................................................... 294
Administración de inventario de Azure en Ansible ............................................... 296
Uso de Terraform ................................................................................................  301
Instalación .................................................................................................................. 301
Autenticación en Azure ............................................................................................. 302
Implementación en Azure ........................................................................................ 303
Implementación de una máquina virtual ............................................................... 306
Uso de DSC de PowerShell .................................................................................  312
DSC de Azure Automation ........................................................................................ 313
Instalación de DSC de PowerShell en Linux ........................................................... 314
Creación de estado deseado .................................................................................... 316
Recursos de DSC de PowerShell ............................................................................... 317
Configuración de invitado de Azure Policy ......................................................  318
Extensión de configuración de invitado para Linux .............................................. 319
Comandos ................................................................................................................... 320
Otras soluciones .................................................................................................  322
Resumen ..............................................................................................................  322
Preguntas .............................................................................................................  323
Capítulo 9: Virtualización de contenedores en Azure   325
Introducción a la tecnología de contenedores ...............................................  326

Historia de los contenedores ................................................................................... 328
El entorno chroot ...................................................................................................... 329
OpenVZ ....................................................................................................................... 329
LXC ............................................................................................................................... 330
systemd-nspawn .................................................................................................  330
Creación de un contenedor con debootstrap ........................................................ 331
Creación de un contenedor con yum ...................................................................... 332
systemd-firstboot ...................................................................................................... 332
Implementación del primer contenedor ................................................................ 334
Habilitación de un contenedor en el momento del arranque ............................. 335
Docker ..................................................................................................................  336
Instalación de Docker ................................................................................................ 337
Creación de imágenes de Docker ............................................................................ 341
Docker Machine ......................................................................................................... 344
Docker Compose ........................................................................................................ 348
Registro de Docker .................................................................................................... 349
Azure Container Instances ................................................................................  352
Azure Container Registry ...................................................................................  355
Uso de Azure Portal ................................................................................................... 356
Uso de la CLI de Azure ............................................................................................... 357
Buildah, Podman y Skopeo ................................................................................  360
Historia ........................................................................................................................ 360
Instalación  ................................................................................................................. 361
Buildah ........................................................................................................................ 362
Podman ....................................................................................................................... 364
Skopeo ......................................................................................................................... 365
Contenedores y almacenamiento ....................................................................  366
Resumen ..............................................................................................................  369
Preguntas .............................................................................................................  370
Lectura adicional  ................................................................................................  370
Capítulo 10: Cómo trabajar con Azure Kubernetes Service   371

Uso de WSL y VS Code ............................................................................................... 374
Instalación de dependencias .................................................................................... 374
Instalación de kubectl ............................................................................................... 377
Cómo empezar a usar AKS .................................................................................  379
Creación de un clúster con la CLI de Azure ............................................................ 380
Primera implementación en AKS ............................................................................. 383
Creación de servicios ................................................................................................. 384
Pods de varios contenedores ................................................................................... 386
Cómo trabajar con Helm ....................................................................................  388
Instalación de Helm ................................................................................................... 388
Administración de repositorios de Helm ................................................................ 390
Instalación de aplicaciones con Helm ..................................................................... 391
Creación de gráficos de Helm ................................................................................... 396
Cómo trabajar con Draft ....................................................................................  398
Instalación de Draft ................................................................................................... 399
Uso de Draft ................................................................................................................ 401
Administración de Kubernetes .........................................................................  405
Actualización de aplicaciones ................................................................................... 405
Escalado de aplicaciones .......................................................................................... 407
Actualización de Kubernetes .................................................................................... 408
Almacenamiento persistente ............................................................................  410
Azure Disks para Kubernetes ................................................................................... 410
Azure Files para Kubernetes .................................................................................... 412
Resumen ..............................................................................................................  414
Preguntas .............................................................................................................  415
Capítulo 11: S
olución de problemas y supervisión de sus
cargas de trabajo   417

Acceso al sistema ................................................................................................  420
Sin acceso remoto ...................................................................................................... 420
Cómo trabajar en el puerto ...................................................................................... 421
Uso de nftables .......................................................................................................... 423
Diagnóstico de arranque .......................................................................................... 424
Inicio de sesión en Linux ........................................................................................... 425
Azure Log Analytics .............................................................................................  431
Configuración del servicio Log Analytics ................................................................ 431
Instalación del agente de Azure Log Analytics ....................................................... 432
Cómo obtener los datos ............................................................................................ 436
Log Analytics y Kubernetes ....................................................................................... 439
Log Analytics para la red ........................................................................................... 440
Supervisión del rendimiento .............................................................................  441
Visualización de procesos de Linux con top ........................................................... 443
Alternativas para top ................................................................................................. 445
Sysstat: una colección de herramientas para la supervisión del rendimiento ....  448
dstat ............................................................................................................................. 451
Estadísticas de red con iproute2 .............................................................................. 452
Supervisión de redes con IPTraf-NG ........................................................................ 453
tcpdump ...................................................................................................................... 454
Resumen ..............................................................................................................  456
Preguntas .............................................................................................................  456
Capítulo 12: Apéndice   459

Prólogo
>
Acerca de
En esta sección se presenta brevemente al autor, el alcance de este curso, las aptitudes técnicas
que necesitará para empezar y los requisitos de hardware y software necesarios para completar
todas las actividades y ejercicios incluidos.
ii | Prólogo
Acerca de Administración práctica de Linux en Azure:

segunda edición
Gracias a su flexibilidad en la entrega de soluciones escalables en la nube, Microsoft
Azure es una plataforma adecuada para administrar todas sus cargas de trabajo. Puede
usarla para implementar máquinas virtuales y contenedores de Linux, y para crear
aplicaciones en lenguajes open source con API abiertas.
Este libro de administración de Linux primero lo lleva a través de los conceptos
básicos de Linux y Azure para prepararlo para las características de Linux más
avanzadas en capítulos posteriores. Con la ayuda de ejemplos del mundo real,
aprenderá a implementar máquinas virtuales (VM) en Azure, ampliar sus capacidades
y administrarlas de manera eficiente. Administrará contenedores y los usará para
ejecutar aplicaciones de forma confiable, y en el capítulo final, explorará las técnicas
de solución de problemas con una variedad de herramientas de open source.
Al final de este libro, será experto en administrar Linux en Azure y en aprovechar las
herramientas necesarias para la implementación.
Acerca de los autores

Kamesh Ganesan es un consultor de la nube y un experimentado profesional de la
tecnología con casi 23 años de experiencia en TI en todas las principales tecnologías
de la nube, incluidas Azure, AWS, GCP y Alibaba Cloud. Tiene más de 45 certificaciones
de TI, incluidas 5 certificaciones de AWS, 3 de Azure y 3 de GCP. Ha desempeñado
muchos cargos, como arquitecto de varias nubes certificado, arquitecto de aplicaciones
nativas de la nube, administrador de bases de datos de clientes potenciales y analista
de programadores. Diseñó, construyó, automatizó y entregó soluciones tecnológicas
de alta calidad, críticas e innovadoras que ayudaron a sus clientes empresariales,
comerciales y gubernamentales a tener un gran éxito y a mejorar significativamente su
valor empresarial, con estrategia de varias nubes.
Rithin Skaria es un evangelista de open source con más de 7 años de experiencia en
la administración de cargas de trabajo de open source en Azure, AWS y OpenStack.
Actualmente trabaja en Microsoft y es parte de varias actividades comunitarias de open
source realizadas en Microsoft. Es un instructor certificado de Microsoft, ingeniero
y administrador de la Fundación Linux, desarrollador y administrador de aplicaciones
de Kubernetes, y también administrador de OpenStack certificado. Con respecto
a Azure, tiene 4 certificaciones, incluida arquitectura de soluciones, administración
de Azure, DevOps y seguridad, y también está certificado en la administración de
Office 365. Ha desempeñado un papel fundamental en varias implementaciones de
open source y en la administración y migración de estas cargas de trabajo a la nube.
Acerca de Administración práctica de Linux en Azure: segunda edición | iii
Frederik Vos, que vive en Purmerend (una ciudad cerca de Ámsterdam en los Países
Bajos), trabaja como entrenador técnico sénior de tecnologías de virtualización, como
Citrix XenServer y VMware vSphere. Se especializa en infraestructuras de centros
de datos (hipervisor, red y almacenamiento) e informática en la nube (CloudStack,
CloudPlatform, OpenStack y Azure). También es instructor y consultor de Linux. Tiene
el conocimiento de un profesor y la experiencia en el mundo real de un administrador
de sistemas. Durante los últimos 3 años, ha trabajado como entrenador y consultor
independiente dentro de ITGilde Cooperation, entregando muchas sesiones de
capacitación de Linux, como la capacitación de Linux en Azure para la Fundación Linux.
Objetivos de aprendizaje
Al final de este curso, será capaz de:
• Conocer los conceptos básicos de la virtualización y la informática en la nube
• Comprender la jerarquía de archivos y montar nuevos sistemas
• Mantener el ciclo de vida de la aplicación en Azure Kubernetes Service
• Administrar recursos con la CLI de Azure y PowerShell
• Administrar usuarios, grupos y permisos del sistema de archivos
• Utilizar Azure Resource Manager para volver a implementar máquinas virtuales
• Implementar la administración de configuración para configurar correctamente
una VM
• Compilar un contenedor con Docker
Público
Si es un administrador de Linux o un profesional de Microsoft que busca implementar
y administrar su carga de trabajo en Azure, este libro es para usted. Aunque no es
necesario, conocer Linux y Azure ayudará a comprender los conceptos básicos.
Enfoque
Este libro proporciona una combinación de conocimientos prácticos y teóricos. Abarca
escenarios del mundo real que demuestran cómo los administradores de Linux trabajan
en la plataforma de Azure. Cada capítulo está diseñado para facilitar la aplicación
práctica de cada habilidad nueva.
iv | Prólogo
Requisitos de hardware
Para una experiencia óptima de estudio, recomendamos esta configuración de hardware:
• Procesador: Intel Core i5 o equivalente
• Memoria: 4 GB de RAM (8 GB preferido)
• Almacenamiento: espacio disponible de 35 GB
Requisitos de software
También se recomienda tener instalado con antelación lo siguiente:
• Un equipo instalado con el sistema operativo Linux, Windows 10 o macOS
• Una conexión a Internet para que pueda conectarse a Azure
Convenciones
Palabras de código en el texto, nombres de la tabla de base de datos, nombres de
carpetas, nombres de archivos, extensiones de archivos, nombres de ruta, direcciones
URL ficticias, entrada del usuario e identificadores de Twitter se muestran como sigue:
“El siguiente fragmento de código crea un grupo de recursos con el nombre MyResource1
y especifica la SKU como Standard_LRS que es la opción de redundancia en este
contexto”.
Este es un bloque de ejemplo de código:
New-AzStorageAccount -Location westus '
-ResourceGroupName MyResource1'
-Name "<NAME>" -SkuName Standard_LRS
En muchos casos, hemos usado los corchetes angulares, <>. Debe reemplazarlos con el
parámetro real y no usar estos corchetes dentro de los comandos.
Recursos para descargar

El paquete de código de este libro también se encuentra en GitHub, en https://github.
com/PacktPublishing/Hands-On-Linux-Administration-on-Azure---Second-Edition.
Puede ver el YAML y otros archivos utilizados en este libro a los que se hace referencia
en las instancias pertinentes.
También tenemos otros paquetes de código de nuestro catálogo enriquecido de libros
y videos disponibles en https://github.com/PacktPublishing/. ¡Deles un vistazo!
Exploración de la nube
1
de Microsoft Azure
A menudo, las personas se confunden debido a la ambigüedad que rodea al término
informática en la nube. Aquí, no nos referimos a las soluciones de almacenamiento
en la nube, como OneDrive y Dropbox, entre otras. Nos referimos a las soluciones
informáticas reales, que utilizan las organizaciones, las empresas o, incluso, las personas.
Microsoft Azure (antes conocida como Windows Azure) es la plataforma de informática
en la nube pública de Microsoft. Ofrece una amplia gama de servicios en la nube, que
incluyen procesos, análisis, almacenamiento, redes y mucho más. Si revisa la lista de
servicios que ofrece Azure, verá que puede trabajar con prácticamente cualquier cosa,
desde máquinas virtuales hasta inteligencia artificial y “machine learning”.
A partir de una breve historia de la virtualización, explicaremos cómo la transformación
del hardware físico en hardware virtualizado permitió ir más allá de los límites de los
centros de datos clásicos de muchas maneras.
2 | Exploración de la nube de Microsoft Azure
Después de eso, explicaremos la distinta terminología que se usa en la tecnología de nube.

Esta es la lista de temas clave que abordaremos:
• Virtualización de procesos, redes y almacenamiento
• Servicios en la nube
• Tipos de nube
Conceptos básicos de la informática en la nube

Cuando comienza a aprender un tema nuevo en Tecnología de la información (TI),
habitualmente comienza por estudiar los conceptos subyacentes (es decir, la teoría).
A continuación, se familiarizará con la arquitectura y, tarde o temprano, empezará
a probar y a practicar para ver cómo funciona en la práctica.
Sin embargo, en la informática en la nube, realmente es útil no solo comprender los
conceptos y la arquitectura, sino también de dónde proviene. No queremos darle una
lección de historia, sino que queremos mostrarle que las invenciones y las ideas del
pasado aún se utilizan en los entornos de nube modernos. Esto le ayudará a entender
mejor qué es la nube y cómo usarla dentro de su organización.
Los siguientes son los conceptos básicos clave de la informática en la nube:
• Virtualización
• Centro de datos definido por software (SDDC)
• Arquitectura orientada al servicio (SOA)
• Servicios en la nube
• Tipos de nube
Demos un vistazo a cada uno de estos conceptos y comprendamos a qué se refieren.

Conceptos básicos de la informática en la nube | 3
Virtualización
En informática, la virtualización se refiere a la creación de una forma virtual de un
dispositivo o un recurso, como un servidor, un dispositivo de almacenamiento, una
red o incluso un sistema operativo. El concepto de virtualización apareció en escena
cuando IBM desarrolló sus soluciones de tiempo compartido a finales de la década
de 1960 y comienzos de la década de 1970. El tiempo compartido se refiere al uso
compartido de recursos informáticos entre un grupo grande de usuarios, lo que
aumenta su productividad y elimina la necesidad de comprar un equipo para cada
usuario. Este fue el comienzo de una revolución en la tecnología informática, donde
el costo de comprar equipos nuevos disminuyó significativamente y fue posible para
las organizaciones utilizar los recursos informáticos subutilizados que ya tenían.
Hoy en día, este tipo de virtualización ha evolucionado a la virtualización basada en
contenedores. Las máquinas virtuales tienen su propio sistema operativo, que se
virtualiza sobre un servidor físico; por otro lado, todos los contenedores en una máquina
(ya sea física o virtual) comparten el mismo sistema operativo subyacente. Hablaremos
más sobre los contenedores en el Capítulo 9, Virtualización de contenedores en Azure.
Pasemos rápidamente al año 2001, cuando empresas como VMware introdujeron
otro tipo de virtualización, llamada virtualización de hardware. En su producto,
VMware Workstation, agregaron una capa sobre un sistema operativo existente que
proporcionaba un conjunto de hardware estándar y software integrado, en lugar de
elementos físicos para ejecutar una máquina virtual. Esta capa se conoce como un
hipervisor. Posteriormente, crearon su propio sistema operativo, que se especializaba
en la ejecución de máquinas virtuales: VMware ESXi (antes conocido como ESX).
En 2008, Microsoft ingresó al mercado de virtualización de hardware con el producto
Hyper-V, como un componente opcional de Windows Server 2008.
En la virtualización de hardware, se trata de separar el software del hardware y derribar
los límites tradicionales entre hardware y software. Un hipervisor es responsable de la
asignación de recursos virtuales en recursos físicos.
Este tipo de virtualización propició una revolución en los centros de datos:

• Debido al conjunto estándar de hardware, toda máquina virtual puede ejecutarse
en cualquier máquina física donde esté instalado el hipervisor.
• Dado que las máquinas virtuales están aisladas entre sí, si una máquina virtual
específica se bloquea, esto no afectará a ninguna otra máquina virtual que se
ejecute en el mismo hipervisor.
• Debido a que una máquina virtual es solo un conjunto de archivos, tiene nuevas
posibilidades para realizar copias de seguridad, migrar máquinas virtuales, etcétera.
• Se dispuso de nuevas opciones para mejorar la disponibilidad de las cargas de
trabajo, con alta disponibilidad (HA) y la posibilidad de migrarlas a una máquina
virtual, aunque aún se estén ejecutando.
• También se proporcionaron nuevas opciones de implementación, por ejemplo,
mediante plantillas.
• También había nuevas opciones para la administración central, la orquestación
y la automatización, porque todo se definía con software.
• Se utilizó el aislamiento, la reserva y la limitación de recursos donde era necesario,
y se compartían los recursos cuando era posible.
SDDC
Claro está que, si se puede transformar el hardware en software para procesamiento,
es solo cuestión de tiempo antes de que alguien se dé cuenta de que puede hacer lo
mismo para las redes y el almacenamiento.
En el caso de las redes, todo comenzó con el concepto de conmutadores virtuales. Al
igual que cualquier otra forma de virtualización de hardware, solo se trata de crear un
conmutador de red en software en lugar de hardware.
El Grupo de trabajo de ingeniería de Internet (IETF) comenzó a trabajar en un
proyecto llamado Forwarding and Control Element Separation (separación del
elemento de control y reenvío), que era una interfaz estándar propuesta para
separar el plano de control y el plano de datos. En 2008, la primera implementación
de conmutador real que logró este objetivo se llevó a cabo mediante el protocolo
OpenFlow en la Universidad de Stanford. Las redes definidas por software (SDN)
se asociaron comúnmente con el protocolo OpenFlow.
Con SDN, tiene ventajas similares a las de la virtualización de informática:

• Administración central, automatización y orquestación
• Seguridad más detallada a través del aislamiento del tráfico y la provisión de
directivas de seguridad y firewall
• Moldear y controlar el tráfico de datos
• Nuevas opciones disponibles para HA y escalabilidad
En 2009, se inició el desarrollo del almacenamiento definido por software (SDS) en

varias empresas, como Scality and Cleversafe. Una vez más, se trata de la abstracción:
separar servicios (volúmenes lógicos, etc.) de elementos de almacenamiento físico.
Si revisa los conceptos de SDS, algunos proveedores agregaron una nueva característica
a las ventajas ya existentes de la virtualización. Puede agregar una directiva a una
máquina virtual y definir las opciones que desea: por ejemplo, la replicación de datos
o un límite en la cantidad de operaciones de entrada y salida por segundo (IOPS). Esto
es transparente para el administrador; hay comunicación entre el hipervisor y la capa
de almacenamiento para proporcionar la funcionalidad. Más adelante, este concepto
también fue adoptado por algunos proveedores de SDN.
En realidad, puede ver que la virtualización convirtió lentamente la administración de
diferentes capas de centros de datos en un enfoque más orientado a los servicios.
Si puede virtualizar cada componente de un centro de datos físico, tiene un SDDC.
La virtualización de las redes, el almacenamiento y las funciones informáticas permitió
ir más allá de los límites de una sola pieza de hardware. Al abstraer el software del
hardware, los SDDC hacen que sea posible ir más allá de los límites de un centro de
datos físico.
En un entorno de SDDC, todo está virtualizado y, a menudo, totalmente automatizado
por el software. Se cambia por completo el concepto tradicional de los centros de datos.
En realidad, no importa dónde se hospeda el servicio ni cuánto tiempo está disponible
(en todo momento o a petición). Además, hay posibilidades de supervisar el servicio, tal
vez incluso agregar opciones, como la facturación y los informes automáticos, lo que
hace que el usuario final esté satisfecho.
Un SDDC no es lo mismo que la nube, ni siquiera una nube privada que se ejecuta en
su centro de datos, pero se podría argumentar que, por ejemplo, Microsoft Azure es
una implementación a escala completa de un SDDC: Azure es, por definición, definido
por software.
SOA
En el mismo período en que la virtualización de hardware se volvió popular en los
centros de datos y se inició el desarrollo de SDN y SDS, surgió algo nuevo en el mundo
del desarrollo de software para aplicaciones basadas en web: el SOA, que ofrece varios
beneficios. Estos son algunos de los puntos clave:
• Servicios mínimos que pueden comunicarse entre sí, mediante un protocolo
como el Protocolo simple de acceso a objetos (SOAP). En conjunto, ofrecen una
aplicación completa basada en web.
• La ubicación del servicio no importa; el servicio debe conocer la presencia del otro
servicio, y eso es todo.
• Un servicio es una especie de caja negra; el usuario final no necesita saber qué hay
dentro de la caja.
• Cada servicio puede reemplazarse por otro.
Para el usuario final, no importa dónde resida la aplicación o que la formen varios
servicios más pequeños. En cierta manera, es como la virtualización: lo que parece ser
un recurso físico, por ejemplo, un almacenamiento LUN (Número de unidad lógica)
realmente podría incluir varios recursos físicos (dispositivos de almacenamiento) en
varias ubicaciones. Como se mencionó antes, si un servicio conoce la presencia de
otro servicio (que podría estar en otra ubicación), actuarán en conjunto y entregarán la
aplicación. Muchos sitios web con los que interactuamos a diario se basan en el SOA.
El poder de la virtualización en combinación con el SOA le ofrece aún más opciones en
términos de escalabilidad, confiabilidad y disponibilidad.
Hay muchas similitudes entre el modelo de SOA y el de SDDC, pero hay una diferencia:
el SOA tiene que ver con la interacción entre diferentes servicios; el SDDC tiene más
que ver con la entrega de servicios al usuario final.
La implementación moderna del SOA son los microservicios, proporcionados
por entornos de nube como Azure, que se ejecutan de forma independiente o en
contenedores de virtualización como Docker.
Servicios en la nube
La palabra mágica es: nube. Un servicio en la nube es cualquier servicio disponible para
organizaciones, empresas o usuarios proporcionado por una solución en la nube o un
proveedor informático, como Microsoft Azure. Los servicios en la nube son apropiados
si desea proporcionar un servicio con las siguientes características:
• Tiene alta disponibilidad y es del tipo “siempre a petición”.
• Se puede administrar a través de autoservicio.
• Tiene escalabilidad, lo que permite a un usuario escalar verticalmente
(lo que hace que el hardware sea más sólido) o escalar horizontalmente
(agregar nodos adicionales).
• Tiene elasticidad: la capacidad de expandir o reducir de forma dinámica la
cantidad de recursos en función de los requisitos empresariales.
• Ofrece una implementación rápida.
• Puede automatizarse y organizarse completamente.
Además de eso, hay servicios en la nube para supervisar sus recursos y nuevos tipos de
opciones de facturación: la mayoría de las veces solo paga por lo que usa.
La tecnología de nube tiene que ver con la entrega de un servicio a través de Internet,
con el fin de proporcionar a una organización acceso a recursos como software,
almacenamiento, red y otros tipos de componentes e infraestructura de TI.
La nube puede ofrecerle muchos tipos de servicios. Los siguientes son los más importantes:
• Infraestructura como servicio (IaaS): una plataforma para hospedar sus máquinas
virtuales. Las máquinas virtuales implementadas en Azure son un buen ejemplo de
este servicio.
• Plataforma como servicio (PaaS): una plataforma para desarrollar, compilar
y ejecutar sus aplicaciones, sin la complejidad de crear y ejecutar su propia
infraestructura. Por ejemplo, está Azure App Service, donde puede insertar
su código y Azure hospedará la infraestructura por usted.
• Software como servicio (SaaS): aplicaciones listas para usar, que se ejecutan en la
nube, como Office 365.
Aunque los servicios mencionados son los pilares clave de la nube, es posible que también
haya escuchado de los siguientes FaaS (Función como servicio), CaaS (Contenedores
como servicio), SECaaS (Seguridad como servicio) y la lista continúa a medida que la
cantidad de ofertas de servicio en la nube aumentan día a día. Function App en Azure sería
un ejemplo de FaaS, Azure Container Service de CaaS y Azure Active Directory de SECaaS.
Tipos de nube
Los servicios en la nube se pueden clasificar en función de su ubicación o de la
plataforma en la que se hospeda el servicio. Como se mencionó en la sección anterior,
en función de la plataforma, podemos clasificar las ofertas de nube como IaaS, PaaS,
SaaS y así sucesivamente. Sin embargo, en función de la ubicación, podemos clasificar
la nube de la siguiente forma:
• Nube pública: todos los servicios son hospedados por un proveedor de servicios.
Azure de Microsoft es una implementación de este tipo.
• Nube privada: su propia nube en su centro de datos. Microsoft desarrolló
recientemente una versión especial de Azure para esto: Azure Stack.
• Nube híbrida: una combinación de una nube pública y una privada. Un ejemplo es
combinar el poder de Azure y Azure Stack, pero también puede pensar en nuevas
opciones de recuperación ante desastres o en trasladar los servicios de su centro
de datos a la nube y viceversa si se necesitan más recursos de forma temporal.
• Nube de comunidad: una nube de comunidad es cuando varias organizaciones trabajan
en la misma plataforma compartida, dado que tienen objetivos o metas similares.
Seleccionar una de estas implementaciones en la nube depende de varios factores.

A continuación, se nombran solo algunos:
• Costos: según el uso de los recursos, hospedar sus servicios en la nube puede ser más
costoso que hospedarlos localmente. Por otro lado, puede ser más barato. Por ejemplo,
no es necesario implementar opciones de disponibilidad complejas y costosas.
• Restricciones legales: algunas organizaciones no podrán usar la nube pública. Por
ejemplo, el gobierno de los Estados Unidos tiene su propia oferta de Azure llamada
Azure Government. Asimismo, Alemania y China tienen sus propias ofertas de Azure.
• Conectividad a Internet: todavía hay países donde el ancho de banda necesario
o incluso la estabilidad de la conexión es un problema.
• Complejidad: los entornos de nube híbrida, en especial, pueden ser difíciles
de administrar. El soporte técnico para las aplicaciones y la administración de
usuarios pueden ser un desafío.
Definición de la nube de Microsoft Azure | 9
Definición de la nube de Microsoft Azure

Ahora que sabe más sobre la virtualización y la informática en la nube, es el momento
de presentarle la implementación de la nube de Microsoft: Azure.
En esta sección, que empezará nuevamente con algo de historia, descubrirá la tecnología
detrás de Azure y que Azure puede ser una solución muy buena para su organización.
Una breve historia de la nube de Microsoft Azure

En 2002, Microsoft inició un proyecto llamado Whitehorse para agilizar el desarrollo
y la implementación de una aplicación dentro de un modelo de SOA. Este proyecto se
centraba en entregar aplicaciones web pequeñas y precompiladas, y poder transformarlas
en servicios. Este proyecto desapareció silenciosamente alrededor del año 2006.
Muchas de las lecciones aprendidas en ese proyecto y la aparición de Amazon Web
Services (AWS) fueron los impulsores para que Microsoft, en 2006, iniciara un proyecto
llamado RedDog.
Después de un tiempo, Microsoft agregó otros tres equipos de desarrollo a este proyecto:
• .NET Services: servicios para desarrolladores que utilizan el modelo de SOA.
.NET Services ofrecía Service Bus como una infraestructura de mensajería segura
y basada en estándares.
• Servicios Live y Live Mesh: un proyecto de SaaS para permitir que los PC y otros
dispositivos se comuniquen entre sí a través de Internet.
• SQL Services: un proyecto SaaS para ofrecer Microsoft SQL a través de Internet.
En 2008, Microsoft anunció el inicio de Azure, y con su lanzamiento público en 2010,

Azure estaba listo para ofrecer soluciones de IaaS y PaaS. El nombre RedDog sobrevivió
por un tiempo: el portal clásico también se conocía como RedDog Front-End (RDFE).
El portal clásico se basaba en el Modelo de administración de servicios. Por otro lado,
Azure Portal se basa en Azure Resource Manager (ARM). Estos dos portales se basan en
dos API diferentes.
Hoy en día, Azure es una de las tres nubes de Microsoft (las otras son Xbox y Office 365)
para proporcionar diferentes tipos de servicios, como máquinas virtuales, aplicaciones
web y móviles, Active Directory y bases de datos, entre otros.
Y aún está creciendo, en términos de cantidad de características, clientes y disponibilidad.
Azure se encuentra disponible en más de 54 regiones. Esto es muy importante para la
escalabilidad, el rendimiento y la redundancia.
Tener varias regiones también ayuda a cumplir con las leyes y las directivas de seguridad
y privacidad. Se encuentran disponibles información y documentos relacionados con la
seguridad, la privacidad y el cumplimiento a través del Centro de confianza de Microsoft:
https://www.microsoft.com/es-xl/TrustCenter.
Arquitectura de Azure
Microsoft Azure se ejecuta en una versión personalizada, básica y reforzada de Hyper‑V,
también conocida como Hipervisor de Azure.
Por encima de este hipervisor, hay una capa de nube. Esta capa, o tejido, es un clúster
de muchos hosts hospedados en el centro de datos de Microsoft y es responsable de la
implementación, administración y estado de la infraestructura.
Esta capa de nube es administrada por el controlador de tejido, que es responsable de la
administración de los recursos, la escalabilidad, la confiabilidad y la disponibilidad.
Esta capa también proporciona la interfaz de administración a través de una API
compilada en REST, HTTP y XML. Azure Portal y software como la CLI de Azure
proporcionan otra forma de interactuar con el controlador de tejido a través de Azure
Resource Manager.
La siguiente es una representación gráfica de la arquitectura de Azure:
Figura 1.1: Arquitectura de Azure

Definición de la nube de Microsoft Azure | 11
Estos servicios de interfaz de usuario (Azure Portal, PowerShell, CLI de Azure y API)
se comunicarán con el tejido a través de proveedores de recursos. Por ejemplo, si un
usuario desea crear, eliminar o actualizar un recurso informático, este interactuará con el
proveedor de recursos de Microsoft.Compute, que también se conoce como Proveedor
de recursos de Compute (CRP). Asimismo, los recursos de red se comunican a través del
Proveedor de recursos de red (NRP) o el proveedor de recursos de Microsoft.Network
y los recursos de almacenamiento se comunican a través del Proveedor de recursos de
almacenamiento (SRP) o el proveedor de recursos de Microsoft.Storage.
Estos proveedores de recursos crearán los servicios requeridos, por ejemplo, una
máquina virtual.
Azure en su organización
Azure puede ofrecer IaaS: es fácil implementar máquinas virtuales, de forma manual
o automática, y usarlas para desarrollar, probar y hospedar sus aplicaciones. Hay
muchos servicios adicionales disponibles para hacer que su vida como ingeniero
de sistemas sea más fácil, como opciones de copia de seguridad y restauración,
almacenamiento adicional y opciones de disponibilidad. En el caso de las aplicaciones
web, incluso es posible ofrecer el servicio sin crear una máquina virtual.
Por supuesto, Azure también se puede utilizar para soluciones de PaaS. Tal como
IaaS, PaaS incluye todos los componentes de su infraestructura, pero agrega soporte
para el ciclo de vida completo de sus aplicaciones en la nube: compilación, pruebas,
implementación, administración y actualización. También se encuentran disponibles
componentes de la aplicación predefinidos; puede ahorrar tiempo mediante la
transformación de estos componentes junto con su código en el servicio que desea
ofrecer. Los contenedores pueden ser otra parte de su solución de PaaS. Azure
Container Service simplifica la implementación, la administración y las operaciones
en contenedores que usan Kubernetes u otro orquestador, como Mesos.
Si tiene una empresa u organización que desea hospedar una solución SaaS en Azure,
lo puede hacer con AppSource. Incluso puede proporcionar integración con otros
productos de Microsoft, como Office 365 y Dynamics.
En 2017, Microsoft anunció Azure Stack. Puede ejecutar Azure ahora en su centro de
datos o ejecutarlo en un centro de datos del proveedor de servicios que elija para que
proporcione IaaS y PaaS. Esto le brinda el poder de Azure en términos de escalabilidad
y disponibilidad, sin preocuparse de la configuración. Solo necesita agregar más
recursos físicos si es necesario. Además, si lo desea, puede usarlo en una solución
híbrida con Azure público para recuperación ante desastres o cargas de trabajo
coherentes en implementaciones en la nube y en el entorno local.
Azure Stack no es la única opción que puede usar para entornos híbridos. Por ejemplo,
puede conectar su Active Directory local con Azure Active Directory, o usar la
aplicación de Azure Active Directory para proporcionar inicio de sesión único (SSO)
a las aplicaciones web locales y hospedadas.
Azure y Open Source

En 2009, incluso antes de que Azure se hiciera público, Microsoft comenzó a agregar
compatibilidad con marcos de open-source, como PHP, y en 2012, Microsoft agregó
compatibilidad para máquinas virtuales Linux, debido a las solicitudes de muchos clientes.
En ese momento, Microsoft no era un gran amigo de la comunidad de open source
y es justo decir que realmente no le gustaba el sistema operativo Linux. Esto cambió
alrededor del año 2014, cuando Satya Nadella reemplazó a Steve Ballmer como CEO de
Microsoft. En octubre de ese año, él anunció incluso en una conferencia de Microsoft
en San Francisco que a Microsoft le gusta Linux.
Desde ese momento, Azure se ha transformado en un entorno muy amigable para
open source:
• Ofrece una plataforma para muchas soluciones de open source, como instancias
de Linux, tecnología de contenedores y marcos de aplicaciones y desarrollo.
• Ofrece integración con soluciones de open source mediante API abiertas
y compatibles. Por ejemplo, el servicio Cosmos DB ofrece una API compatible
con MongoDB.
• La documentación, los Kits de desarrollo de software (SDK) y los ejemplos son
todos open source y están disponibles en GitHub: https://github.com/Azure.
• Microsoft está trabajando en conjunto con proveedores y proyectos de open
source, y también es uno de los principales contribuyentes de código en muchos
proyectos de open source.
En 2016, Microsoft ingresó a la organización Linux Foundation como un miembro

Platino para confirmar su interés y compromiso cada vez mayor con el desarrollo
de open source.
En octubre de 2017, Microsoft señaló que más del 40 % de todas las máquinas
virtuales de Azure está ejecutando el sistema operativo Linux, y Azure está ejecutando
muchas cargas de trabajo en contenedores. Si se observan las estadísticas actuales,
el número de cargas de trabajo ha alcanzado más del 60 %. Además de eso, todos los
microservicios usan interfaces y lenguajes de programación de open source.
Microsoft toma muy en serio la tecnología de open source, usa open source en
PowerShell y en muchos otros productos. No todos los productos de Microsoft en
Azure son open source, pero al menos puede instalar y ejecutar Microsoft SQL en
Linux o puede obtener una imagen de contenedor para Microsoft SQL.
Resumen
En este capítulo, analizamos la historia de la virtualización y el concepto de la nube,
y explicamos la terminología utilizada en los entornos de nube.
Preguntas | 13
Algunas personas piensan que Microsoft ingresó un poco tarde en el mundo de la nube,
pero en realidad, comenzó a investigar y desarrollar técnicas en 2006, y muchas partes
de ese trabajo sobrevivieron en Azure. Algunos de los proyectos desaparecieron, porque
eran demasiado prematuros y muchas personas eran escépticas con respecto a la nube
en esos días.
También abarcamos la arquitectura de la nube de Azure y los servicios que Azure puede
ofrecerle a su organización.
En la última parte de este capítulo, vimos que Azure es un entorno muy apto para open
source y que Microsoft se esfuerza mucho por hacer que Azure sea una solución de
nube abierta y estándar que tiene en cuenta la interoperabilidad.
En el siguiente capítulo, comenzaremos a usar Azure y aprenderemos cómo
implementar y usar Linux en Azure.
Preguntas
1. ¿Qué componentes de su centro de datos físico se pueden transformar en software?
2. ¿Cuál es la diferencia entre la virtualización de contenedores y la virtualización
de hardware?
3. Si desea hospedar una aplicación en la nube, ¿qué tipo de servicio es la mejor solución?
4. Supongamos que una de sus aplicaciones necesita directivas de privacidad estrictas.
¿Sigue siendo una buena idea usar la tecnología de nube para su organización?
5. ¿Por qué hay tantas regiones disponibles en Azure?
6. ¿Cuál es el propósito de Azure Active Directory?
Lectura adicional
Si desea obtener más información sobre Hyper-V y cómo puede usar Azure junto con
Hyper-V para la recuperación de sitios y la protección de sus cargas de trabajo, consulte
el Manual de Hyper-V en Windows Server 2016, Segunda edición de Packt Publishing.
Hay muchos artículos técnicos geniales sobre la historia de la virtualización, la informática
en la nube y su relación. Uno que realmente nos gustaría mencionar es Formal Discussion
on Relationship between Virtualization and Cloud Computing (Análisis formal sobre la
relación entre la virtualización y la informática en la nube) (ISBN 978-1-4244-9110-0).
No olvide visitar el sitio web de Microsoft y el repositorio de GitHub, como se mencionó
en este capítulo.
Introducción a la
2
nube de Azure
En el primer capítulo, abordamos la historia de la virtualización y la informática en la

nube, y las ideas detrás de ellas. Después de eso, obtuvo más información sobre la nube
de Microsoft Azure. Este capítulo lo ayudará a dar sus primeros pasos en el mundo de
Azure, obtener acceso a Azure, explorar las diferentes ofertas de Linux e implementar
su primera máquina virtual Linux.
Después de la implementación, necesitará acceso a su máquina virtual mediante Secure
Shell (SSH) con autenticación de contraseña o mediante un par de claves SSH.
16 | Introducción a la nube de Azure
Para dar los primeros pasos en su recorrido a la nube de Azure, es importante completar
todos los ejercicios y examinar los resultados. En este capítulo, usaremos PowerShell
y la CLI de Azure. Puede utilizar el método con el que se sienta cómodo; sin embargo,
aprender ambos sería beneficioso. Los objetivos clave de este capítulo son los siguientes:
• Configurar su cuenta de Azure.
• Iniciar sesión en Azure con la CLI de Azure y PowerShell.
• Interactuar con Azure Resource Manager (ARM) para crear recursos de red
y almacenamiento.
• Comprender las distribuciones de Linux y las distribuciones avaladas por Microsoft.
• Implementar su primera máquina virtual Linux.
Nota
Todo lo que se muestra en este capítulo está probado en macOS, Subsistema de
Windows para Linux y las versiones más recientes de CentOS y openSUSE LEAP.
Requisitos técnicos
Si desea probar todos los ejemplos de este capítulo, necesitará por lo menos un explorador.
Por motivos de estabilidad, es importante utilizar la versión más reciente. Microsoft ofrece
una lista de exploradores compatibles en la documentación oficial de Azure:
• Microsoft Edge (la versión más reciente)
• Internet Explorer 11
• Safari (la versión más reciente, solo Mac)
• Chrome (la versión más reciente)
• Firefox (la versión más reciente)
En función de la experiencia personal, recomendamos usar Google Chrome o un

explorador basado en una versión reciente de su motor, como Vivaldi.
Puede hacer todos los ejercicios en su explorador, incluso los ejercicios que involucran
la línea de comandos. En la práctica, es una buena idea usar una instalación local de la
CLI de Azure o PowerShell. Es más rápido y fácil copiar y pegar código, y puede guardar
el historial y la salida de los comandos.
Cómo obtener acceso a Azure | 17
Cómo obtener acceso a Azure

Para comenzar a usar Azure, lo primero que necesita es una cuenta. Vaya a
https://azure.microsoft.com y obtenga una cuenta gratuita para comenzar o use una
cuenta corporativa activa. Otra posibilidad es usar Azure con una suscripción a Visual
Studio Professional o Enterprise, que le dará créditos de Microsoft Developer Network
(MSDN) para Azure. Si su organización ya tiene un Contrato Enterprise con Microsoft,
puede usar su suscripción Enterprise o registrarse para obtener una suscripción de
pago por uso (si ya utilizó su prueba gratuita).
Si está utilizando una cuenta gratuita, obtendrá algunos créditos para comenzar,
algunos de los servicios populares por un tiempo limitado y algunos servicios que
siempre serán gratuitos, como el servicio de contenedores. Puede consultar la lista más
reciente de servicios gratuitos en https://azure.microsoft.com/es-xl/free. No se le
cobrará durante el período de prueba, salvo por las máquinas virtuales que necesitan
licencias adicionales, pero necesitará una tarjeta de crédito para identificarse.
Inicio de sesión con Azure Portal

En su explorador, vaya a https://portal.azure.com y use sus credenciales para iniciar
sesión. Está listo para comenzar a usar Azure o, en otras palabras, comenzar a usar
su subscripción. En Azure, una suscripción le permite crear e implementar recursos
mediante Azure Portal, la CLI de Azure o PowerShell con su cuenta. También se utiliza
para la contabilidad y la facturación.
Azure Portal lo lleva a un panel que puede modificar para satisfacer sus necesidades
de supervisión. Ahora puede hacer lo siguiente:
• Inspeccionar sus recursos.
• Crear recursos nuevos.
• Visitar Marketplace, que es una tienda en línea donde puede comprar
e implementar aplicaciones o servicios creados para la nube de Azure.
• Obtener información sobre su facturación.
Puede utilizar la interfaz web y hacer todo gráficamente, o usar Azure Cloud Shell
a través de la interfaz web, que proporciona una interfaz de Bash o PowerShell.
Cómo obtener acceso de línea de comandos a Azure

Hay muchas buenas razones para usar la línea de comandos. Es por eso que, en este
libro, abordaremos principalmente el acceso de línea de comandos de Azure:
• Puede ayudarlo a entender la arquitectura de Azure. En la interfaz gráfica, con
frecuencia puede hacer muchas cosas en una ventana de configuración sin
comprender las relaciones entre los diferentes campos y componentes.
• Es el primer paso en la automatización y la orquestación.
• La interfaz web todavía está en desarrollo activo y puede cambiar con el tiempo
(y lo hará):
Algunas características y opciones aún no están disponibles.
Es posible que Microsoft reubique características y opciones en la interfaz web.
• La interfaz de línea de comandos, por otro lado, es muy estable en cuanto a la
sintaxis y la salida.
En este libro, utilizaremos la CLI de Azure en el shell de Bash y PowerShell con el

módulo PowerShell Az. Ambas opciones son muy adecuadas, independientes de la
plataforma, y no hay ninguna diferencia entre ellas en términos de características, salvo
una o dos excepciones. Elija su favorita porque ya está familiarizado con ella o dé una
oportunidad a ambas interfaces y elija una después.
Nota
Tenga en cuenta que copiar y pegar comandos de este libro podría generar
algunos errores debido a los espacios y las sangrías. Para obtener mejores
resultados, siempre escriba los comandos. Además, esto le ayudará a
acostumbrarse a ellos.
Instalación de la CLI de Azure

Si utiliza la interfaz Bash dentro de Azure Cloud Shell, hay una instalación de interfaz
de línea de comandos de Azure del entorno Linux bastante completa disponible para
probar. También proporciona comandos específicos de Azure, como el comando az.
Además, puede instalar esta utilidad en Windows, macOS y Linux. También se
encuentra disponible un contenedor Docker. Puede encontrar instrucciones de
instalación detalladas para todas estas plataformas en https://docs.microsoft.com/
es-xl/cli/azure.
Usemos CentOS/Red Hat Enterprise Linux (RHEL) 7 como un ejemplo para instalar la
CLI de Azure:
1. Importe la clave de GNU Privacy Guard (GPG) del repositorio de Microsoft:
sudo rpm --import \ https://packages.microsoft.com/keys/microsoft.asc
2. Agregue el repositorio:
sudo yum-config-manager --add-repo= \
https://packages.microsoft.com/yumrepos/azure-cli
3. Instale el software:
sudo yum install azure-cli
4. Para instalar la CLI de Azure en un sistema basado en Ubuntu o Debian, utilice
este comando:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
En macOS, tiene que instalar primero Homebrew, un sistema de administración de
paquetes gratuito y open-source que simplifica la instalación de software open-
source, en su mayoría.
5. Abra una terminal y ejecute lo siguiente:
ruby -e "$(curl -fsSL \
https://raw.githubusercontent.com/Homebrew/install/master/install)"
6. Actualice Homebrew e instale la CLI de Azure:
brew update && brew install azure-cli
7. Después de instalar la CLI de Azure, puede comprobar la versión instalada con
este comando:
az -v
Inicio de sesión con la CLI de Azure

La CLI de Azure es una herramienta de línea de comandos que se utiliza para acceder
o administrar los recursos de Azure, y lo bueno es que está disponible para plataformas
macOS, Linux y Windows. Antes de poder utilizar la CLI, tiene que iniciar sesión:
az login
Este comando abrirá un explorador y le solicitará que inicie sesión con su cuenta de
Microsoft. Si recibe un error que indica que el shell no pudo abrir el explorador interactivo,
utilice az login –use-device-code. Este comando generará un código que puede utilizar en
https://www.microsoft.com/devicelogin para completar la autenticación.
Si esta acción tiene éxito, generará alguna salida en formato JSON relacionada con su
suscripción, por ejemplo, su nombre de usuario:
[
{
"cloudName": "AzureCloud",
"id": "....",
"isDefault": true,
"name": "Pay-As-You-Go",
"state": "Enabled",
"tenantId": "....",
"user": {
"name": "....",
"type": "user"
}
}
]
Para obtener esta información nuevamente, escriba el siguiente código:
az account list
Siempre puede formatear la salida en formatos JSON, JSONC, TABLE o TSV mediante
parámetros adicionales.
El formato JSON (o JSONC, la variante de color) es más fácil de analizar en los lenguajes
de programación y scripting:
Figura 2.1: Detalles de la suscripción en formato JSONC

Se recomienda usar valores separados por tabulaciones (TSV) si la salida es un valor

único, si desea usar utilidades de filtrado de texto como AWK, o si desea exportar la
salida a una hoja de cálculo:
Figura 2.2: Detalles de la suscripción separados por tabulaciones
La salida de tabla es muy legible, pero es más limitada que la salida predeterminada:
Figura 2.3: Detalles de la suscripción en formato tabular
Para obtener una lista de las suscripciones a las que tiene acceso la cuenta en la que se
inició sesión en un formato de tabla, ejecute el siguiente comando:
az account list -o table
A fin de facilitar la lectura de la salida JSON, también puede consultar campos

específicos:
az account list -o table --query '[].[user.name]'
Si ya tiene una gran cantidad de recursos o cuentas, será muy difícil revisar toda la
lista. Afortunadamente, existe una forma de examinar a fondo la salida y obtener
solo la información que necesita. Encadenar el comando con el parámetro --query lo
ayudará a hacerlo, mediante un poderoso lenguaje de consulta llamado JMESPATH
(http://jmespath.org). Observe nuevamente la salida JSON del comando az account
list. Esta consulta busca el campo user y la propiedad name.
Volvamos al procedimiento de inicio de sesión. Hacer esto cada vez, una y otra vez,
puede no ser el procedimiento más fácil para el usuario. Una mejor manera de hacerlo
es mediante la creación de una entidad de servicio, también conocida como registro de
aplicación, a fin de proporcionar una credencial para una aplicación específica:
az ad sp create-for-rbac --name <APP_NAME>
Puede proporcionar un nombre para la aplicación, pero no se permiten algunos

caracteres especiales. El motivo es que APP_NAME crea una URL, por lo que todos los
caracteres que se prohíben en las URL no se pueden agregar a APP_NAME (por ejemplo,
@ y %). La salida, que estará una vez más en formato JSON, proporcionará un ID de la
aplicación (el parámetro appID):
{
"appID": "....",
"displayName": "APP_NAME",
"name": "http://APP_NAME",
"password": "....",
"tenant": "...."
}
Anote la salida en un bloc de notas, porque usaremos estos valores para la autenticación.
Una entidad de servicio o una aplicación representa un objeto en el inquilino de Azure.
Un inquilino se refiere a una organización, a menudo, señalada como <yourcompany/
yourname>.onmicrosoft.com, que administra y posee una instancia de los servicios en la
nube de Microsoft. Si lo consideramos desde la perspectiva de Azure, todos los servicios
implementados se asociarán a una suscripción y la suscripción se asignará a un inquilino.
Un inquilino puede tener varias suscripciones que hospedan diferentes servicios.
A partir de la salida anterior, obtenemos los siguientes valores:
• appID: el ID de la aplicación es similar al nombre de usuario de la aplicación.
Utilizaremos este ID como el nombre de usuario cuando iniciemos sesión.
• displayName: un nombre descriptivo dado a la aplicación cuando la creamos.
Establecemos el nombre a través del parámetro name.
• name: una URL basada en el nombre que asignamos.
• password: esta es la contraseña de la entidad de servicio que creamos. Cuando
iniciemos sesión, usaremos este valor en el campo de la contraseña.
• tenant: la ID de inquilino. Hablamos de los inquilinos en el párrafo anterior.
Una aplicación que requiere acceso debe estar representada por una entidad de
seguridad. La entidad de seguridad define los permisos y la directiva de acceso para
el usuario o la aplicación en el inquilino. Esto permite la autenticación del usuario o la
aplicación durante el inicio de sesión y la autorización basada en roles durante el acceso
a los recursos. En resumen, puede usar appID para iniciar sesión.
Enumere los roles que se asignan a la appID recién creada:
az role assignment list --assignee <appID> --o table
De forma predeterminada, se utiliza el rol de colaborador. Este rol tiene permisos

completos de lectura y escritura en su cuenta de Azure.
Ahora, es una buena idea probar esto y cerrar sesión:
az logout
Vuelva a iniciar sesión con la appID. Puede usar los valores que copió antes para
completar la autenticación:
az login --service-principal --username <appID> --tenant <tenant id>
Lamentablemente, no hay una forma de almacenar el nombre de usuario, appID o tenant

id, en un archivo de configuración. También puede agregar --password al comando:
az login --service-principal --username <appID> --tenant <tenant id>
--password <app_password>
En lugar de escribir comandos completos con el comando az, también puede abrirlo en
modo shell interactivo:
az interactive
Una de las principales características de este shell es que divide el terminal en dos
ventanas. En la pantalla superior, puede escribir sus comandos. En la pantalla inferior,
obtendrá ayuda mientras escribe los comandos. También hay compatibilidad con la
función de autocompletar para comandos, parámetros y, a menudo, valores de parámetro.
PowerShell
PowerShell es un lenguaje de scripting desarrollado por Microsoft que se integra en .NET
Framework. Fue diseñado por Jeffrey Snover, Bruce Payette y James Truher en 2006.
PowerShell no solo está disponible para Windows, sino también para Linux y macOS.
Puede encontrar instrucciones detalladas para usar PowerShell con estos sistemas
operativos en el repositorio de GitHub para PowerShell: https://github.com/PowerShell.
Por ejemplo, para instalarlo en RHEL o CentOS, siga estos pasos:
1. Importe la clave de GPG del repositorio de Microsoft si no lo hizo mientras seguía
el procedimiento de instalación de la CLI de Azure:
sudo rpm –import \ https://packages.microsoft.com/keys/microsoft.asc
2. Agregue el repositorio:
sudo yum-config-manager --add-repo= \https://packages.microsoft.com/rhel/7/
prod/
3. Instale el software:
sudo yum install -y powershell
4. Utilice pwsh -v para mostrar la versión instalada.
5. Ingrese en PowerShell:
pwsh
En macOS, necesitará Homebrew y Homebrew Cask. Cask amplía Homebrew para
instalar aplicaciones más grandes y en mayor cantidad:
1. Instale Homebrew Cask:
brew tap caskroom/cask
2. Instale PowerShell:
brew cask install powershell
3. Utilice pwsh -v para mostrar la versión instalada.
4. Para ingresar en PowerShell:
pwsh
Después de la instalación de PowerShell, está listo para instalar el módulo Az. La

descarga del módulo puede tardar cierto tiempo, dependiendo de la velocidad de
su Internet. Podrá ver el progreso de la descarga en el shell:
Install-Module -Name Az -AllowClobber -Scope CurrentUser -Force
PowerShell utiliza el cmdlet PowerShellGet para descargar el módulo y sus dependencias

de la Galería de PowerShell, un repositorio que hospeda muchos módulos. Tenga en
cuenta que para ello necesitará privilegios de administrador en Windows y Linux.
La Galería de PowerShell no está configurada como un repositorio de confianza:
Untrusted repository
You are installing the modules from an untrusted repository. If you trust
this
repository, change its InstallationPolicy value by running the Set-
PSRepository
cmdlet. Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "N"): A
Responda la pregunta de la lista con [A] Yes to All.

Debido al parámetro force, ahora es posible que tenga instaladas varias versiones del
módulo Az. Puede comprobar la existencia de varias versiones con el siguiente comando:
Get-InstalledModule -Name Az -AllVersions | ' select Name,Version
De forma predeterminada, se utilizará la versión más reciente, a menos que use el

parámetro -RequiredVersion cuando importe el módulo.
Inicio de sesión con PowerShell

Una vez finalizada la instalación, importe el módulo:
Import-Module -name Az
Si no crea un script de PowerShell y solo ejecuta comandos dentro del entorno

de PowerShell cuando utilice Azure, tendrá que volver a ejecutar este comando.
Pero si lo desea, puede cargar automáticamente los módulos.
En primer lugar, averigüe dónde está su perfil de PowerShell en el sistema de archivos.

Para ello, ejecute el siguiente comando:
$profile
Abra o cree este archivo en un editor de texto y agregue la siguiente línea:

Import-Module -name Az
Nota
Puede que sea necesario crear la estructura de directorios antes de poder crear
este archivo.
Ahora puede ejecutar todos los comandos disponibles para Azure.

Inicie sesión con el siguiente cmdlet:
Connect-AzAccount
Este abrirá una ventana interactiva del explorador, donde puede usar sus credenciales
para autenticarse. Si el resultado no muestra un ID de inquilino, ejecute este comando:
Get-AzContext -ListAvailable | select Tenant
Ahora, vuelva a iniciar sesión con el ID de inquilino que encontró:

Connect-AzAccount -Tenant <tenantID>
Si tiene varias suscripciones, también puede agregar el parámetro -Subscription y el

ID de suscripción. Como se analizó antes, es posible que sea una buena idea crear una
entidad de servicio:
$newsp = New-AzADServicePrincipal ' -DisplayName "APP_NAME" -Role Contributor
Si no menciona DisplayName, que es el nombre descriptivo de la entidad de servicio,

Azure generará un nombre en el formato azure-powershell-MM-dd-yyyy-HH-mm-ss.
A continuación, necesita recuperar el ID de la aplicación para la entidad de servicio
recién creada:
$newsp.ApplicationId
La contraseña se puede almacenar en una variable, que se cifrará y debemos descifrarla:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($newsp.
Secret)
$UnsecureSecret = [System.Runtime.InteropServices.
Marshal]::PtrToStringAuto($BSTR)
La variable $UnsecureSecret contiene la contraseña de la entidad de servicio.
Para poder autenticarse, se necesitan las credenciales de la entidad de servicio:
$creds = Get-Credential
Proporcione el ApplicationID y la contraseña, que se almacenan en las variables

$newsp.ApplicationId y $UnsecureSecret respectivamente. Ahora tenemos todo lo
que necesitamos para conectarnos a Azure con estas credenciales:
Connect-AzAccount -Credential $creds '
-Tenant <tentant id> '
-ServicePrincipal
Ahora, guarde el contexto:
Save-AzContext -Path $HOME/.Azure/AzureContext.json
Sobrescriba el contenido existente si es necesario. Salga del entorno de PowerShell

y ejecute PowerShell. Asegúrese de que inició sesión en Azure y compruebe el contexto
mediante el siguiente comando:
Get-AzContext
Azure Resource Manager

Antes de que pueda comenzar la implementación de su primera máquina virtual Linux,
es importante que conozca más sobre Azure Resource Manager (ARM).
Básicamente, ARM le permite trabajar con recursos como el almacenamiento y las
máquinas virtuales. Para ello, tiene que crear uno o más grupos de recursos para que
pueda ejecutar operaciones del ciclo de vida, como implementar, actualizar y eliminar
todos los recursos de un grupo de recursos, en una sola operación.
Nota
Un grupo de recursos se debe crear en una región, también conocida como
ubicación. Tenga en cuenta que puede haber diferencias entre los servicios
ofrecidos en diferentes regiones. Para obtener más información sobre estas
diferencias, visite https://azure.microsoft.com/es-xl/global-infrastructure/services/.
Azure tiene más de 54 regiones. Si una ubicación no está disponible, debe estar en la lista
de permitidos de su cuenta. Para eso, puede ponerse en contacto con el soporte técnico
de Microsoft. Si desea obtener una lista de las ubicaciones disponibles y los proveedores
de recursos compatibles para su cuenta, ejecute el siguiente comando en PowerShell:
Get-AzLocation | Select-Object Location
También puede ejecutar lo siguiente en Bash:

az account list-locations --query '[].name'
A continuación, cree un grupo de recursos en una de las regiones:

New-AzResourceGroup -Location westus2 -Name 'MyResource1'
Ahora, compruebe el resultado:

Get-AzResourceGroup | Format-Table
Esta es la versión Bash del comando anterior:

az group create --location westus2 --name MyResource2
Para comprobar el resultado de este comando de Azure Resource Manager (ARM),

ejecute lo siguiente:
az group list -o table
Además de trabajar con regiones y grupos de recursos, debe comprender el

concepto de redundancia de almacenamiento. Las siguientes son las opciones
de replicación disponibles:
• Standard_LRS: almacenamiento con redundancia local
Premium_LRS: igual que LRS, pero también es compatible con almacenamiento
de archivos
Standard_GRS: almacenamiento con redundancia geográfica
Standard_RAGRS: almacenamiento con redundancia geográfica con acceso de lectura
• Standard_ZRS: almacenamiento con redundancia de zona. ZRS no admite
almacenamiento de blobs
Nota
Encontrará más información disponible en el sitio web de Microsoft:
https://docs.microsoft.com/es-xl/azure/storage/common/storage-redundancy.
Entender este concepto es importante porque, junto con su grupo de recursos, se

necesita una cuenta de almacenamiento en una región. Una cuenta de almacenamiento
proporciona un espacio de nombre único en Azure para almacenar datos (como
diagnósticos) y la posibilidad de usar servicios como Azure Files. Para configurar la
redundancia de estos datos, debe especificar la SKU que representa la opción de
redundancia en este contexto:
New-AzStorageAccount -Location westus '
-ResourceGroupName MyResource1'
-Name "<NAME>" -SkuName Standard_LRS
O puede hacerlo a través de la CLI de Azure:
az storage account create --resource-group MyResource2
--sku Standard_LRS --name <NAME>
El nombre de la cuenta de almacenamiento debe ser único en Azure, tener una longitud
de entre 3 y 24 caracteres, y solo usar números y letras minúsculas.
Linux y Azure
Linux está en casi todas partes, en muchos dispositivos diferentes y en muchos
entornos diferentes. Hay muchas variedades distintas y usted elige cuál utilizar.
Entonces, ¿cuál elegir? Hay muchas preguntas y son posibles muchas respuestas
diferentes. Pero algo es seguro: en los entornos corporativos, el soporte es importante.
Distribuciones de Linux
Como se indicó antes, existen muchas distribuciones de Linux diferentes. Pero hay
motivos por los cuales existen tantas opciones:
• Una distribución de Linux es una colección de software. Algunas colecciones tienen
un objetivo específico. Un excelente ejemplo de una distribución de este tipo es
Kali Linux, que es una distribución Linux de prueba de penetración avanzada.
• Linux es un sistema operativo multipropósito. Gracias a la gran cantidad de opciones
de personalización que tenemos para Linux, si no desea un paquete o característica
específicos en su sistema operativo, puede eliminarlos y agregar los suyos. Esta es
una de las principales razones por las que existen tantas distribuciones.
• Open source es darwiniano por naturaleza. A veces, un proyecto se divide, por
ejemplo, porque a otros desarrolladores no les gusta el objetivo del proyecto
o piensan que pueden hacerlo mejor y no se aceptan revisiones del proyecto.
Solo los proyectos más fuertes sobrevivirán.
• Es cuestión de gustos. Diferentes personas tienen diferentes gustos y opiniones.
A algunas personas les gusta el administrador de paquetes apt de Debian. A otras,
puede gustarles la herramienta Zypper de SUSE.
• Otra gran diferencia es que algunas distribuciones son recopiladas y admitidas por
proveedores como Red Hat, SUSE y Canonical, mientras que otras, como Debian,
son impulsadas por la comunidad.
En los entornos de producción, el soporte es importante. Antes de insertar sus cargas

de trabajo de producción en una distribución, las organizaciones se preocuparán
de ciertos factores, como el SLA, el tiempo de inactividad y las actualizaciones de
seguridad, y podrían surgir las siguientes preguntas:
• ¿Quién es responsable de las actualizaciones y qué tipo de información incluyen?
• ¿Quién es responsable del soporte y a quién llamaré si hay un problema?
• ¿Quién me aconsejará si hay problemas legales con las licencias de software?
Linux y Azure | 31
Distribuciones de Linux avaladas por Microsoft

En Azure Marketplace, hay imágenes de Linux proporcionadas por terceros, también
denominados socios de Microsoft. Estas son distribuciones de Linux avaladas por Microsoft.
Microsoft trabaja conjuntamente con las distribuciones de Linux avaladas por Microsoft
y estos socios y la comunidad de Linux para asegurarse de que estas distribuciones
funcionen bien en Azure.
Es posible importar su propia imagen, o incluso su propia distribución de Linux,
a Azure. Microsoft contribuye directamente al kernel de Linux, que ofrece servicios
de integración de Linux para Hyper-V y Azure. Debido a esto, puede ejecutar todas las
distribuciones de Linux en Azure, siempre y cuando el soporte se compile en el kernel.
Además, en cada imagen de Linux en Azure Marketplace, está instalado el agente para
Linux de Azure. También el código fuente de este agente está disponible en GitHub, así
que puede instalarlo en su imagen. Microsoft incluso está dispuesto a orientarlo si tiene
problemas con Linux. Simplemente, compre un plan de soporte técnico.
Existen excelentes opciones de soporte disponibles para algunas distribuciones
comerciales de Linux:
• Red Hat: el soporte de Microsoft lo ayudará a usar la plataforma o los servicios
de Azure, y también le brindará soporte para problemas en Red Hat, pero esto
requiere un plan de soporte.
• Oracle Linux: Microsoft ofrece un plan de soporte. Puede comprar soporte
comercial adicional de Oracle.
• SUSE: hay imágenes Premium respaldadas por Microsoft. Si es necesario, se
llamará a SUSE por usted. Esta imagen premium de SUSE incluye todo: el software,
las actualizaciones y las revisiones.
• Otros proveedores: hay planes de soporte de Microsoft que abarcan a otros
proveedores. No tiene que comprar un plan por separado para esto. Los detalles
del plan de Microsoft están disponibles en https://azure.microsoft.com/es-xl/
support/plans/.
Nota
Visite el sitio web de Microsoft para obtener una lista reciente de distribuciones
y versiones avaladas, además de detalles sobre el soporte disponible para
una distribución:
https://docs.microsoft.com/es-xl/azure/virtual-machines/linux/endorsed-distros
Implementación de una máquina virtual Linux

Ya hablamos de las distribuciones de Linux disponibles en Azure y el nivel de soporte
que puede obtener. En la sección anterior, configuramos el entorno inicial mediante
la creación del grupo de recursos y el almacenamiento. Ahora es el momento de
implementar nuestra primera máquina virtual.
Su primera máquina virtual

Se creó el grupo de recursos, donde se creó una cuenta de almacenamiento, y ahora
está listo para crear su primera máquina virtual Linux en Azure.
En PowerShell, use el siguiente comando:
New-AzVM -Name "UbuntuVM" -Location westus2 '
-ResourceGroupName MyResource1 '
-ImageName UbuntuLTS -Size Standard_B1S
El cmdlet le pedirá que proporcione un nombre de usuario y una contraseña para la
máquina virtual:
Figura 2.4: Provisión de credenciales de usuario para la máquina virtual

Implementación de una máquina virtual Linux | 33
En Bash, puede usar el siguiente comando:

az vm create --name UbuntuVM --resource-group MyResource2 \
--image UbuntuLTS --authentication-type password \
--admin-username student --size Standard_B1S
Esto fue muy fácil, pero si crea una instancia de máquina virtual de esta forma, la
cantidad de opciones que puede establecer es muy limitada. Este proceso creará
varios recursos requeridos por la máquina virtual, como el disco, la NIC y la IP pública,
mediante la configuración predeterminada.
Profundicemos un poco más en los detalles y obtenga información sobre las decisiones
que se tomaron.
Imágenes
En nuestro ejemplo, implementamos una máquina virtual con el nombre de imagen
UbuntuLTS. Puede elegir entre varias imágenes de Linux:
• CentOS
• Debian
• RHEL
• UbuntuLTS
• CoreOS
• openSUSE
• SUSE Linux Enterprise
Sin embargo, existen muchas más imágenes ofrecidas por diferentes proveedores,
llamados publicadores.
Obtengamos una lista de estos publicadores. En PowerShell, use este comando:
Get-AzVMImagePublisher -Location <REGION>
Como puede ver en la siguiente captura de pantalla, Azure tiene muchos publicadores.
Seleccionaremos uno de ellos para la demostración:
Figura 2.5: Lista de publicadores de imágenes en PowerShell
En Bash, puede ejecutar el siguiente comando para obtener la lista de publicadores:

az vm image list-publishers --location <REGION> --output table
La lista es la misma:
Figura 2.6: Lista de publicadores de imágenes en Bash
Ahora que conoce a los publicadores, puede obtener una lista de las imágenes
proporcionadas por un publicador mediante el siguiente comando:
Get-AzVMImageOffer -Location <REGION> '
-PublisherName <PUBLISHER> | select offer
Seleccionamos Canonical como el publicador y ahora tratamos de obtener la lista de las
ofertas disponibles. UbuntuServer es una de las ofertas. Usaremos esta:
Figura 2.7: Lista de ofertas para el publicador Canonical

Como alternativa, en la CLI de Azure, ejecute el siguiente comando:

az vm image list-offers --location <REGION> '
--publisher <PUBLISHER> --output table
El resultado es una lista de las denominadas ofertas. Una oferta es el nombre de un
grupo de imágenes relacionadas creadas por un publicador.
Ahora necesitamos saber qué SKU están disponibles para la imagen. La SKU se refiere
a la versión principal de una distribución. A continuación, se presenta un ejemplo que
usa Ubuntu:
Get-AzVMImageSku -PublisherName <publisher> -Offer <offer>'
-Location <location>
Ahora que tenemos los valores para el publicador y la oferta, sigamos adelante y veamos
las principales distribuciones (SKU) que están disponibles para UbuntuServer publicado
por Canonical:
Figura 2.8: Lista de SKU para UbuntuServer publicadas por Canonical

Como alternativa, en la CLI de Azure, ejecute el siguiente comando:

az vm image list-skus --location <LOCATION> \
--publisher <PUBLISHER> --offer <OFFER> -o table
Consulte una instancia específica dentro de esta oferta:
Get-AzureVMImage -Location <REGION>'
-PublisherName <PUBLISHER> -Offer <OFFER> '
-Skus <SKU> | select Version -last 1
Revisemos nuevamente los valores que tenemos. Por lo tanto, con el nombre del
publicador, la oferta y la SKU, obtendremos la versión que está disponible. En la
siguiente captura de pantalla, puede ver que está disponible la versión de la imagen
19.10.201912170. Tomemos esta imagen para nuestra máquina virtual:
Figura 2.9: Selección de la versión de imagen disponible en la CLI de Azure
Esta era la última versión disponible en el momento de escribir este capítulo. Si hay
versiones nuevas, es posible que vea otro número de versión.
Como alternativa, en la CLI de Azure, utilice el siguiente comando:
az vm image list --location <REGION> --publisher <PUBLISHER> \
--offer <OFFER> --sku <SKU> --all --query '[].version' \
--output tsv | tail -1
A fin de reducir la salida a la versión más reciente, se agregaron parámetros para
seleccionar la última línea. La información recopilada contiene parámetros para el
cmdlet Set-AzVMSourceImage. Sin embargo, antes de usar este comando, tenemos que
crear una nueva configuración de máquina virtual con New-AzVMConfig:
$vm = New-AzVmConfig -VMName <name> -VMSize "Standard_A1"
Set-AzVMSourceImage -PublisherName <PUBLISHER>'
-Offer <OFFER> -Skus <SKU> -Version <VERSION>
Por último, estamos creando una nueva máquina virtual con un tamaño Standard_A1
y ordenamos a PowerShell que use la versión de imagen 19.10.201912170 de la
distribución principal 19_10-daily-gen2 en la oferta de UbuntuServer publicada
por Canonical:
Figura 2.10: Creación de una máquina virtual de tamaño Standard_A1
En Bash, la información recopilada contiene parámetros para el comando az vm create:

az vm create --name UbuntuVM2 --resource-group Packt-Testing-2 --image
canonical:UbuntuServer:19_10-daily-gen2:19.10.201912170 --authentication-
type password --admin-username pacman --size Standard_B1S
Nota
Tanto en Bash como en PowerShell, se puede usar la palabra latest, en lugar de
una versión específica. Sin embargo, la información recopilada no es suficiente
para crear la máquina virtual. Se necesitan más parámetros.
Tamaño de la máquina virtual

Otro aspecto que debe considerar es tomar una decisión respecto al tamaño
de la máquina virtual en función de sus necesidades y costos. Encontrará más
información sobre los tamaños disponibles y el precio en el siguiente vínculo
https://azure.microsoft.com/es-xl/pricing/details/virtual-machines/linux.
La lista de este sitio web, que incluye los precios de las instancias, cambia a menudo.
Puede obtener una lista (que no muestra los costos) en la línea de comandos:
Get-AzVMSize -Location <REGION> | Format-Table
az vm list-sizes --location <REGION> -o table
Para ejecutar los ejercicios de este libro, es suficiente una máquina virtual pequeña.
En el momento en que se escribió este libro, Standard_B1ls es ideal para el rendimiento
básico necesario. Sin embargo, es una buena idea volver a revisar la lista de tamaños
y precios de máquina virtual, como se mencionó anteriormente.
En PowerShell, el cmdlet New-AzVM puede tomar el parámetro -size o puede usarlo en el

cmdlet New-AzVMConfig:
New-AzVMConfig -VMName "<VM NAME>" -VMSize <SIZE>
En Bash, agregue el parámetro --size del comando az vm create.
Redes de máquinas virtuales

Las redes virtuales de Azure permiten la comunicación entre máquinas virtuales,
Internet y otros servicios de Azure a través de una red segura. Cuando creamos la
primera máquina virtual al principio de este capítulo, se crearon automáticamente
varios elementos relacionados con la red:
• Red virtual
• Subred virtual
• Interfaz de red virtual conectada a la máquina virtual y a la red virtual
• Dirección IP privada configurada en la interfaz de red virtual
• Dirección IP pública
Los recursos de red se tratarán en el Capítulo 4, Administración de Azure. Por ahora,

solo consultaremos las direcciones IP privadas y públicas de las máquinas virtuales.
Utilice este comando para obtener la lista de direcciones IP públicas:
Get-AzPublicIpAddress -ResourceGroupName <RESOURCE GROUP>'
| select Name,IpAddress
A fin de obtener la lista de direcciones IP privadas de todas sus máquinas virtuales, use
este comando:
Get-AzNetworkInterface -ResourceGroupName <resource group name> | ForEach
{ $interface = $_.Name; $ip = $_ | Get-AzNetworkInterfaceIpConfig | Select
PrivateIPAddress; Write-Host $interface $ip.PrivateIPAddress }
El comando anterior puede parecer un poco complicado, pero es un script práctico para
obtener la lista de IP privadas. Si desea obtener la dirección IP privada de las máquinas
virtuales en un grupo de recursos, puede usar este comando:
Get-AzNetworkInterface -ResourceGroup <resource group name>
La salida obtenida estará en formato JSON. Puede ver la dirección IP privada en

IpConfigurations:
Figura 2.11: Dirección IP privada de las máquinas virtuales en el grupo de recursos
Esto también se puede lograr con la CLI de Azure. Para obtener una lista de las
direcciones IP privadas de las máquinas virtuales, use este comando:
az vm list-ip-addresses --resource <RESOURCE GROUP> --output table
La dirección IP pública es la dirección IP que hace que se pueda acceder a la máquina

virtual a través de Internet. El tráfico entrante de red de máquina virtual en esta
dirección IP se somete a traducción de direcciones de red (NAT) a la dirección IP
privada configurada en la interfaz de red de la máquina virtual Linux.
Información de la máquina virtual

Después de la implementación de la máquina virtual, toda la información vinculada
a la máquina virtual está disponible mediante PowerShell y Bash, por ejemplo, el estado.
Consultar el estado es importante. Hay varios estados:
• En ejecución
• Detenido
• Con error
• Desasignado
Si no se cancela la asignación de una máquina virtual, Microsoft se la cobrará. El estado

Failed (Con error) se refiere a que la máquina virtual no puede arrancar. Para consultar
el estado, ejecute el siguiente comando:
Get-AzVM -Name <VM NAME> -Status -ResourceGroupName <RESOURCE GROUP>
En Bash, es posible recibir el estado de las máquinas virtuales implementadas, pero

si necesitamos reducir la salida a una sola instancia, esto no es posible sin usar
consultas complejas:
az vm list --output table
Para desasignar una máquina virtual, primero deténgala:

Stop-AzVM -ResourceGroupName <RESOURCE GROUP> -Name <VM NAME>
Ahora puede desasignarla:

az vm deallocate --name <VM NAME> --resource-group <RESOURCE GROUP>
Puede obtener mucha más información sobre las máquinas virtuales implementadas. En
PowerShell, es bastante difícil recibir las propiedades de la máquina virtual. En primer
lugar, cree una variable:
$MYVM=Get-AzVM -Name <VM NAME> -ResourceGroupName <RESOURCE GROUP>
Ahora pregunte por las propiedades y métodos de este objeto MYVM:

$MYVM | Get-Members
Vea la propiedad HardwareProfile para conocer el tamaño de esta instancia:

$MYVM.HardwareProfile
O bien, para obtener información más precisa de la máquina virtual, use el

siguiente comando:
$MYVM.HardwareProfile | Select-Object -ExpandProperty VmSize
También puede probar los comandos NetworkProfile, OSProfile y StorageProfile.

ImageReference.
Si desea utilizar el comando az en Bash, le recomendamos probar primero con el
siguiente comando:
az vm list –-resource-group <RESOURCE GROUP>
El único problema con esto es que muestra toda la información sobre todas las
máquinas virtuales al mismo tiempo. Afortunadamente, también hay un comando
show, que reduce la salida a una sola máquina virtual:
az vm show --name <VM NAME> --resource-group <RESOURCE GROUP>
Además, es una buena idea limitar la salida mediante el uso de consultas. Por ejemplo,
si desea ver el perfil de almacenamiento de una máquina virtual específica, puede
realizar consultas de la siguiente manera:
az vm show --name <VM NAME> --resource-group <RESOURCE GROUP>\
--query 'storageProfile'
El comando anterior debería mostrarle la siguiente salida:
Figura 2.12: Perfil de almacenamiento de la máquina virtual de SUSE

Conexión a Linux | 43
Conexión a Linux
La máquina virtual se está ejecutando, lista para que inicie sesión de forma remota
con las credenciales (nombre de usuario y contraseña) que proporcionó durante
la implementación de su primera máquina virtual. Otro método más seguro para
conectarse a la máquina virtual Linux es mediante pares de claves SSH. Las claves SSH
son más seguras debido a su complejidad y longitud. Además de esto, Linux en Azure
admite el inicio de sesión con Azure Active Directory (Azure AD), donde los usuarios
podrán autenticarse con sus credenciales de AD.
Inicio de sesión en la máquina virtual Linux mediante autenticación de

contraseña
En la sección Redes de máquinas virtuales, se consultó la dirección IP pública de una
máquina virtual. Usaremos esta IP pública para conectarnos a la máquina virtual
a través de SSH mediante un cliente SSH instalado localmente.
SSH, o Secure Shell, es un protocolo de red cifrado que se utiliza para administrar
y comunicarse con los servidores. Linux, macOS, Subsistema de Windows para Linux
(WSL) y la actualización reciente de Windows 10 vienen con el cliente OpenSSH basado
en la línea de comandos, pero hay clientes más avanzados disponibles. Estos son
algunos ejemplos:
• Windows: PuTTY, MobaXterm y Bitvise Tunnelier
• Linux: PuTTY, Remmina y Pac Manager
• macOS: PuTTY, Termius y RBrowser
Conéctese a la máquina virtual con el cliente de línea de comandos OpenSSH:

ssh <username>@<public ip>
Inicio de sesión en su máquina virtual Linux con una clave privada SSH
Utilizar un nombre de usuario y una contraseña no es la mejor manera de iniciar sesión en
una máquina remota. No es una operación completamente insegura; aun así, está enviando
su nombre de usuario y contraseña a través de la conexión. También es difícil de usar si
desea ejecutar scripts de forma remota, realizar operaciones de copia de seguridad, etc.
Una forma alternativa y más segura de iniciar sesión en su sistema es mediante pares
de claves SSH. Este es un par de dos claves criptográficamente protegidas: una clave
privada y una pública.
El cliente conserva la clave privada y no debe copiarse a ningún otro equipo. Debe
mantenerse absolutamente en secreto. Se recomienda proteger la clave privada con una
frase de contraseña durante la creación del par de claves.
Por otro lado, la clave pública se puede copiar en todos los equipos remotos que desee
administrar. Esta clave pública se utiliza para cifrar los mensajes que solo la clave
privada puede descifrar. Cuando intenta iniciar sesión, el servidor comprueba que el
cliente posea la clave privada mediante esta propiedad de funcionar con claves. No se
envía ninguna contraseña a través de la conexión.
Existen varias formas de crear un par de claves SSH. Por ejemplo, PuTTY y MobaXterm
proporcionan herramientas para crearlo. Debe hacerlo desde todas las estaciones de
trabajo que necesitan acceso a la máquina remota. En este libro, utilizamos ssh-keygen,
porque está disponible para cada sistema operativo:
ssh-keygen
La salida del comando anterior debería ser similar al siguiente:
Figura 2.13: Uso de ssh-keygen para crear un par de clave SSH
No olvide ingresar una frase de contraseña.

Para entender cómo usar el par de claves SSH a fin de acceder a sus máquinas virtuales,
crearemos una nueva máquina virtual. Si lo recuerda, cuando creamos la máquina
Linux anteriormente, usamos el comando az vm create y authentication-type como
contraseña, pero en el siguiente comando, usamos un parámetro --generate-ssh-keys.
Esto generará un par de claves SSH y se agregará al directorio .ssh en la carpeta de
inicio, que se puede usar para acceder a la máquina virtual:
az vm create --name UbuntuVM3 --resource-group MyResource2 \
--admin-username student --generate-ssh-keys --image UbuntuLTS
Si desea hacerlo en PowerShell, use el cmdlet Add-AzVMSshPublicKey. Para obtener más
información sobre el comando, consulte https://docs.microsoft.com/es-xl/powershell/
module/azurerm.compute/add-azurermvmsshpublickey?view=azurermps-6.13.0.
Una vez creada la máquina virtual, podrá acceder a ella con este comando:
ssh student@<IP ADDRESS>
Resumen | 45
Resumen
En este capítulo, se abordaron los primeros pasos en Microsoft Azure. El primer paso
siempre implica crear una cuenta nueva o usar una cuenta existente de la empresa.
Con una cuenta, puede iniciar sesión y comenzar a descubrir la nube de Azure.
En este capítulo, el descubrimiento de la nube de Azure se realizó mediante el comando
az de la CLI de Azure o a través de PowerShell. Mediante los ejemplos, obtuvo información
acerca de lo siguiente:
• El proceso de inicio de sesión de Azure
• Las regiones
• La cuenta de almacenamiento
• Las imágenes proporcionadas por los publicadores
• La creación de máquinas virtuales
• Cómo consultar información vinculada a una máquina virtual
• Qué es Linux y el soporte disponible para las máquinas virtuales Linux
• Cómo acceder a la máquina virtual Linux mediante SSH y un par de claves SSH
El siguiente capítulo comienza aquí, con un nuevo recorrido: el sistema operativo Linux.
Preguntas
1. ¿Cuáles son las ventajas de utilizar la línea de comandos para acceder
a Microsoft Azure?
2. ¿Cuál es el propósito de una cuenta de almacenamiento?
3. ¿Puede pensar en una razón por la que obtendría el siguiente mensaje de error?
Code=StorageAccountAlreadyTaken
Message=The storage account named mystorage is already taken.
4. ¿Cuál es la diferencia entre una oferta y una imagen?
5. ¿Cuál es la diferencia entre una máquina virtual detenida y una desasignada?
6. ¿Cuál es la ventaja de usar la clave SSH privada para la autenticación en su
máquina virtual Linux?
7. El comando az vm create tiene un parámetro --generate-ssh-keys. ¿Qué claves se
crean y dónde se almacenan?
Lectura adicional
Este capítulo de ninguna manera es un tutorial sobre cómo usar PowerShell. Pero
si desea comprender mejor los ejemplos o desea obtener más información sobre
PowerShell, podemos recomendarle que lea Dominar la creación de scripts en
Windows PowerShell, Segunda edición (ISBN: 9781787126305), de Packt Publishing. Le
sugerimos que comience con el segundo capítulo, Trabajar con PowerShell, y continúe,
al menos, hasta el cuarto capítulo Trabajar con objetos en PowerShell.
Puede encontrar una gran cantidad de documentación en línea sobre cómo usar SSH. Un
buen lugar para comenzar es este wikibook: https://en.wikibooks.org/wiki/OpenSSH.
Si desea explorar más sobre la administración de Linux, el Manual de administración de
Linux de Packt Publishing es un excelente recurso, en especial, para ingenieros de sistemas.
Si desea profundizar en las tareas de seguridad y administración, esta es una
buena lectura: Mastering Linux Security and Hardening (Dominar la seguridad
y el fortalecimiento de Linux) de Donald A. Tevault y publicado por Packt Publishing.
Administración
3
básica de Linux
Después de la implementación de su primera máquina virtual (VM) Linux, iniciaremos

sesión, analizaremos algunos comandos básicos de Linux y aprenderemos cómo
encontrar nuestro camino en el entorno de Linux. En este capítulo, abordaremos la
administración básica de Linux. Comenzaremos con el shell de Linux, que se utiliza
para interactuar con el sistema Linux. Analizaremos cómo usar el shell para cumplir
con nuestras tareas diarias de administración, tales como el acceso al sistema de
archivos, la administración de procesos, como iniciar y terminar programas, entre otros.
En la última parte de este capítulo, analizaremos el modelo de Control de acceso
discrecional (DAC) y cómo crear, administrar y comprobar a los usuarios y los grupos
en Linux y obtener los permisos para los archivos y directorios en función del nombre
de usuario y la pertenencia a grupos. También abordaremos cómo cambiar la propiedad
de un archivo para un usuario/grupo y cambiaremos y comprobaremos los permisos
básicos y las listas de control de acceso.
48 | Administración básica de Linux
Estos son los temas clave de este capítulo:

• Interactuar con el shell y configurarlo
• Obtener ayuda con páginas man
• Trabajar con archivos de texto y editarlos a través del shell
• Comprender la jerarquía de archivos, administrar el sistema de archivos y montar
nuevos sistemas
• Administrar procesos
• Administración de usuarios y grupos
El shell de Linux
En el capítulo anterior, creamos la VM e iniciamos sesión con SSH, pero ¿cómo
interactuamos con la máquina Linux y le ordenamos realizar tareas? Como
mencionamos al comienzo de este capítulo, usaremos el shell.
Exploraremos el shell de Bash que se utiliza ampliamente, su configuración y uso.
Un shell es una interfaz de usuario en la que puede hacer lo siguiente:
• Interactuar con el kernel, el sistema de archivos y los procesos
• Ejecutar programas, alias e integraciones de shell
Un shell proporciona características como las siguientes:

• Creación de scripts
• Finalización automática
• Historial y creación de alias
Hay muchos shells diferentes disponibles, como el KornShell, Bash y el Z shell (Zsh).
Bash es el shell predeterminado en casi todos los sistemas Linux. Su desarrollo comenzó
en 1988 como un reemplazo para uno de los shells más antiguos: el shell Bourne. Bash
se basó en el shell Bourne y en las lecciones aprendidas de otros shells, como KornShell
y C shell. Bash se ha transformado en el shell más popular y está disponible en muchos
sistemas operativos diferentes, incluido Windows 10, FreeBSD, macOS y Linux.
El shell de Linux | 49
Estas son algunas de las características más importantes que se agregaron a la

versión 2.05a de Bash (lanzada en 2001) que hicieron que Bash sea el shell más destacado:
• Edición de línea de comandos
• Soporte de historial
• Finalización automática
• Cálculos de enteros
• Declaración de función
• Here documents (Documentos-aquí) (una forma de obtener la entrada de texto
en un archivo independiente)
• Variables nuevas, como $RANDOM y $PPID
Por último, el Z shell es cada vez más popular. Su desarrollo comenzó en 1990 y se puede
considerar como una extensión de Bash. También existe un modo de compatibilidad
con Bash. Tiene una compatibilidad con la función de autocompletar aún mejor, que
incluye la corrección automática y la expansión más avanzada del nombre de ruta. Su
funcionalidad se puede ampliar con módulos, por ejemplo, para obtener más ayuda con
los comandos. Vale la pena mencionar los proyectos Oh-My-ZSH (https://github.com/
robbyrussell/oh-my-zsh) y Prezto (https://github.com/sorin-ionescu/prezto): estos
proporcionan temas, configuración avanzada y administración de complementos para
hacer que Z shell sea muy fácil de usar. Todas estas características interesantes vienen
con un precio: Z shell definitivamente consume más recursos que Bash.
Ejecución de comandos
Una de las características más importantes de un shell es que puede ejecutar comandos.
Un comando puede ser del siguiente tipo:
• Integrado en el shell (un comando proporcionado por el shell en cuestión)
• Ejecutable en un sistema de archivos
• Alias
Para saber qué tipo de comando está ejecutando, existe el comando type:
type echo
Cuando se agrega el parámetro -a se muestran todas las ubicaciones que contienen

un ejecutable llamado echo. En la siguiente captura de pantalla, podemos ver que
cuando agregamos el parámetro -a, el shell también da una referencia al directorio
/usr/bin/echo, debido a la presencia del ejecutable:
Figura 3.1: Ubicaciones que contienen el ejecutable echo
Hagamos lo mismo con ls:

type ls
Entonces, obtendrá una salida similar para type ls:
Figura 3.2: Ubicaciones que contienen el ejecutable ls
Aquí, podemos ver que ls es un alias para el comando ls --color=auto con algunos
parámetros agregados. Un alias puede reemplazar un comando existente o crear uno
nuevo. El comando alias sin parámetros le dará alias que ya están configurados:
Figura 3.3: Uso del comando alias

El alias ll es un ejemplo de un comando recientemente creado. El comando mv es un

ejemplo de un reemplazo. Cree un nuevo alias con el siguiente comando:
alias <command>='command to execute'
Por ejemplo, para reemplazar el comando grep con search, ejecute el siguiente comando:
alias search=grep
El alias que está creando se agregará al archivo .bashrc. Si desea eliminar un alias que
creó, puede usar el comando unalias:
unalias <alias name>
Si desea eliminar todos los alias definidos, puede usar unalias-a.

El comando which identifica la ubicación de un programa en la variable $PATH. Esta
variable contiene una lista de directorios que se utilizan para encontrar un ejecutable.
De esta manera, no tiene que proporcionar la ruta completa:
which passwd
La salida le indica que está disponible en el directorio /usr/bin:
Figura 3.4: Ubicación del directorio del programa en la variable $PATH
Edición de línea de comandos

En muchos sentidos, ingresar comandos en el shell de Bash es lo mismo que trabajar
en un editor de texto. Esa es probablemente la razón por la que hay accesos directos
para acciones como ir al principio de una línea y por la que los accesos directos son los
mismos que en los dos editores de texto más famosos y más utilizados: Emacs y vi.
De forma predeterminada, Bash está configurado para estar en el modo de edición

Emacs. Si desea comprobar el modo de edición actual, ejecute set -o. La salida indicará
si Emacs o vi están configurados en on. A continuación, se muestran algunos accesos
directos muy importantes:
Figura 3.5: Lista de accesos directos del shell de Bash
Si desea utilizar el modo vi, ejecute el siguiente comando:

set -o vi
Para volver al modo Emacs, use el siguiente comando:

set -o emacs
Nota
El editor vi se aborda en una próxima sección de este capítulo, Cómo trabajar con
archivos de texto. Por ahora, puede utilizar casi cualquier comando en el modo de
comando, incluidos navigation, yank y put.
El comando set es un comando integrado de Bash que alterna los atributos específicos
de Bash. Sin parámetros, vuelca las variables del entorno.
Cómo trabajar con el historial

El shell de Bash proporciona herramientas de línea de comandos que puede usar para
trabajar con el historial de comandos del usuario. Todos los comandos que ejecuta se
registran en un archivo de historial en el directorio principal: ~/.bash_history. Para ver
el contenido de este historial, ejecute el siguiente comando:
history
La salida muestra una lista numerada de los comandos utilizados antes. Puede rehacer
un comando de forma sencilla mediante las siguientes opciones:
• !<number>: ejecuta el comando según el número de la lista del historial.
• !<-number>: por ejemplo, !-2 ejecuta el comando que se ejecutó dos comandos
antes del último del historial.
• !<first characters of the command>: esto ejecutará el último elemento que
comienza con este carácter.
• !!: rehace el último comando. Puede combinar esta opción con otros comandos.
Por ejemplo, sudo !!.
Puede realizar una búsqueda retroactiva en el historial con Ctrl + R (modo Emacs) o utilizar
la barra diagonal (modo de comando vi). Se puede explorar con las teclas de flecha.
El archivo del historial no se escribe directamente después de la ejecución de un
comando, sino al final de una sesión de inicio de sesión. Si trabaja en varias sesiones,
puede ser una buena idea escribir el historial de forma directa. Para hacerlo, ejecute
el siguiente comando:
history -a
A fin de leer el historial recién guardado en otra sesión, ejecute el siguiente comando:
history -r
Para borrar el historial de la sesión actual, utilice este comando:

history -c
Si desea guardar el historial en un archivo, puede ejecutar el siguiente comando:

history -w <filename>
Por lo tanto, cuando guarda el historial borrado, vacía el archivo del historial.
Otra característica interesante de trabajar con el historial es que puede editarlo.
Supongamos que ejecuta el comando ls -alh, pero necesita ls -ltr. Simplemente escriba:
^alh^ltr
En realidad, esto es lo mismo que:

!!:s/ltr/alh/
Por supuesto, puede hacer esto para cada entrada en el historial. Por ejemplo, para el
número 6 de la lista del historial, utilice:
!6:s/string/newstring/
A veces, necesita más flexibilidad y quiere editar una línea grande que contiene muchos
errores tipográficos. Ingrese el comando fc. Corrija el comando con lo siguiente:
fc <history number>
Esto abre un editor de texto (vi de forma predeterminada) y, después de guardar la

modificación, ejecutará el comando modificado.
Finalización automática
Todo el mundo comete errores tipográficos; nadie puede recordar cada parámetro.
La finalización automática puede evitar muchos errores y le ayuda de muchas maneras
cuando ingresa comandos.
Funciona para lo siguiente:
• Ejecutables
• Alias
• Integraciones de shell
• Programas en el sistema de archivos
• Nombre de archivo
• Parámetros, si la utilidad es compatible con ellos y se encuentra instalado el
paquete bash-completion
• Variables
Si el shell está configurado en modo Emacs, utilice Ctrl + I para activar autocompletar.
Si el shell se configura en modo vi, puede usar también Ctrl + P.
Nota
Si existe más de una posibilidad, debe presionar Ctrl + I o Ctrl + P dos veces.
Englobamiento
El englobamiento es expandir un nombre de archivo no específico que contiene un
comodín en uno o más nombres de archivo específicos en el shell de Linux. Otro
nombre común para el englobamiento es expansión del nombre de ruta.
Los siguientes comodines se reconocen en el shell de Bash:
• ?: un solo carácter.
• *: varios caracteres. Tenga en cuenta que, si usa este comodín como el primer
carácter, los nombres de archivo que comiencen con un punto no coincidirán.
Por supuesto, puede usar .*.
• [a-z], [abc]: un carácter del rango.
• {a,b,c}: a o b o c.
Los siguientes son algunos ejemplos interesantes del uso de comodines:

• echo *: enumerará los archivos o directorios en el directorio de trabajo actual.
• cd /usr/share/doc/wget*: esto cambiará el directorio al nombre del directorio que
comience con wget y que resida en /usr/share/doc.
• ls /etc/*/*conf: esto enumerará todos los archivos .conf en todos los directorios
en /etc. Aquí hay un ejemplo de este comando:
Figura 3.6: Lista de todos los archivos. conf de todos los directorios
• mkdir -p /srv/www/{html,cgi-bin,logs}: esto creará directorios html, cgi-bin y log

dentro de /srv/www con un solo comando.
Redireccionamientos
En los primeros días de Unix, uno de los desarrolladores, Ken Thompson, definió
una filosofía de Unix, un enfoque basado en la experiencia para hacer que todo sea lo
más modular posible y reutilizar el código y los programas tanto como sea posible.
Particularmente en aquellos días, la reutilización era importante por motivos de
rendimiento y para proporcionar un método que permitiera un fácil mantenimiento
del código.
En una versión de esta filosofía de Unix modificada por Peter H. Salus, los objetivos del
redireccionamiento son los siguientes:
• Escribir programas que hagan algo y lo hagan bien.
• Escribir programas que trabajen en conjunto.
• Escribir programas que manejen secuencias de texto, puesto que es una
interfaz universal.
A fin de hacer posible esta filosofía, se desarrollaron programas con soporte para
descriptores de archivos o, en lenguaje moderno, canales de comunicación. Cada
programa tiene, por lo menos, tres canales de comunicación:
• Entrada estándar (0)
• Salida estándar (1)
• Error estándar (2)
Una de las características interesantes de esta implementación es que puede redirigir

los canales.
Para redirigir la salida estándar a un archivo, use lo siguiente:
command > filename
Para redirigir la salida estándar y anexarla a un archivo existente, utilice lo siguiente:

command >> filename
Redirija el error y la salida estándares a un archivo de la siguiente manera:

command &> filename
Para redirigir la salida estándar primero a un archivo y, a continuación, redirigir

también el error estándar, utilice el siguiente comando:
command 2>&1 filename
Para redirigir la entrada estándar, utilice lo siguiente:

filename < command
Realicemos una actividad que nos ayude a entender el concepto de redirección.

Ejecute el comando primero, compruebe la salida y, a continuación, rediríjala al
archivo con los siguientes métodos. Por ejemplo, ejecute ls y compruebe la salida,
luego, utilice > para redirigir la salida a /tmp/test.list. Siempre puede comprobar
el archivo mediante cat /tmp/test.list:
ls > /tmp/test.list
echo hello > /tmp/echotest
echo hallo again >> /tmp/echotest
ls -R /proc 2> /tmp/proc-error.test
ls -R /proc &> /tmp/proc-all.test
sort < /etc/services

heredoc.txt es una versión especial de redireccionamiento de la entrada:
cat << EOF >> /tmp/heredoc.txt
this is a line
this is another line
EOF
El comando cat concatena la salida estándar y la anexa al archivo /tmp/heredoc.txt.

No hay manera de interrumpir o detener el comando, porque el teclado no es la entrada
estándar hasta que encuentra una etiqueta, en este ejemplo, EOF. Este método se utiliza
con frecuencia para crear archivos de configuración a partir de scripts.
Otra posibilidad es tomar la salida estándar de un comando y redirigirla a la entrada

estándar de otro comando mediante el símbolo |:
command | other command
Por ejemplo:
ls | more
Con el comando tee, puede combinar el poder del redireccionamiento y la canalización.

Hay ocasiones en las que desea asegurarse de que la salida de command 1 se escriba en
un archivo para solucionar problemas o iniciar sesión y, al mismo tiempo, la canaliza a la
entrada estándar de otro comando:
command 1 | tee file.txt | command 2
También es posible la anexión a un archivo con el parámetro -a.

El siguiente es otro caso de uso de tee:
<command> | sudo tee <file>
De esta manera, se puede escribir en un archivo sin utilizar construcciones de su difíciles.
Cómo trabajar con variables

Cada interfaz de línea de comandos, incluso aquellas sin posibilidades avanzadas de
scripting, tiene el concepto de variables. En Bash, hay dos tipos de variables:
• Variables integradas o internas que afectan el comportamiento de Bash o dan
información sobre Bash. Algunos ejemplos incluyen BASH_VERSION, EDITOR y PATH.
• Variables de entorno que una o más aplicaciones conocen, incluidas las variables
integradas y las variables definidas por el usuario.
A fin de enumerar las variables de entorno para su shell actual, puede usar el comando
env o printenv. printenv también puede mostrar el contenido de una variable específica:
Figura 3.7: Visualización del contenido de una variable específica mediante el comando printenv
La siguiente es otra forma de ver el contenido de una variable:

echo $VARNAME
Para declarar una variable de entorno, ejecute var=value. Por ejemplo:

animal=cat
echo $animal
Para agregar más caracteres al valor, utilice lo siguiente:
animal=$animal,dog
echo $animal
La variable animal solo la conoce su shell actual. Si desea exportarlo a procesos
secundarios, debe exportar la variable:
export animal
Bash también puede realizar cálculos simples:

a=$(( 4 + 2 ))
Opcionalmente, puede usar este comando:

let a=4+2
echo $a
Otra característica es colocar la salida de un comando en una variable, una técnica
llamada anidación:
MYDATE=$(date +"%F")
echo $MYDATE
Por supuesto, esto es solo un atisbo de lo que Bash es capaz de hacer, pero debería
ser suficiente para que aprenda a manejar los archivos de configuración de Bash
y modificarlos para el entorno que necesita, de manera que se comporten de la
forma que desea.
Archivos de configuración de Bash

Hay tres archivos de configuración importantes en todo el sistema para el shell de
Bash: /etc/profile, /etc/bashrc y /etc/environment. El propósito de estos archivos
es almacenar información sobre el shell, como los colores, los alias y las variables.
Por ejemplo, en la sección anterior, agregamos un par de alias que se almacenan en
un archivo llamado bashrc, que es un archivo de configuración. Cada archivo tiene su
propio propósito, que analizaremos ahora.
/etc/profile es un script que se ejecuta una vez que un usuario inicia sesión en un
sistema. No es conveniente modificar este archivo. En su lugar, utilice el directorio
/etc/profile.d del complemento. Los archivos de este directorio se ejecutan en orden
alfabético y su extensión de archivo debe ser .sh. Como nota al margen, el shell de Bash
no es el único que utiliza /etc/profile, también lo usan todos los shells para Linux,
salvo PowerShell. También puede crear un script de perfil específico del usuario en el
directorio principal, ~/.bash_profile, que también es específico de Bash.
El siguiente es contenido típico de un script de perfil:
set -o vi
alias man="pinfo -m"
alias ll="ls -lv --group-directories-first"
shopt -u mailwarn
unset MAILCHECK
Nota
Si utiliza Ubuntu o una distribución similar, pinfo no está instalado de forma
predeterminada. Ejecute apt install pinfo para instalarlo.
El comando shopt cambia parte de la conducta de Bash predeterminada, como la

comprobación de correo o el comportamiento de englobamiento. El comando unset
es lo opuesto del comando set. En nuestro ejemplo, de forma predeterminada, Bash
comprueba el correo cada minuto. Después de ejecutar el comando unset MAILCHECK,
se elimina la variable MAILCHECK.
El script /etc/bashrc se inicia cada vez que un usuario invoca un shell o un script de
shell. Por motivos de rendimiento, manténgalo lo más mínimo posible. En lugar del
archivo /etc/bashrc, puede utilizar el archivo ~/.bashrc específico del usuario y el
script ~/.bash_logout se ejecuta si sale de un shell. Los archivos de configuración
bashrc a menudo se utilizan para modificar la solicitud (la variable PS1):
DARKGRAY='\e[1;30m'
GREEN='\e[32m'
YELLOW='\e[1;33m'
PS1="\n$GREEN[\w] \n$DARKGRAY(\t$DARKGRAY)-(\u$DARKGRAY)-($YELLOW-> \e[m"
Analicemos los parámetros de la variable PS1:

• Los colores (como GREEN, DARKGRAY que se pasan a la variable PS1) se definen en
código de color ANSI.
• \e: carácter de escape en ANSI.
• \n: nueva línea.
• \w: directorio de trabajo actual.
• \t: hora actual.
• \u: nombre de usuario.
El archivo /etc/environment (vacío de forma predeterminada en las distribuciones

basadas en Red Hat) es el primer archivo que se ejecuta en el inicio de sesión. Contiene
variables para cada proceso, no solo para el shell. No es un script, solo una variable en
cada línea.
Aquí hay un ejemplo de /etc/environment:
EDITOR=/usr/bin/vim
BROWSER=/usr/bin/elinks
LANG=en_US.utf-8
LC_ALL=en_US.utf-8
LESSCHARSET=utf-8
SYSTEMD_PAGER=/usr/bin/more
La variable EDITOR es importante. Muchos programas pueden invocar un editor. A veces,

es vi de forma predeterminada, otras no. Establecer un valor predeterminado garantiza
que siempre pueda usar su editor favorito.
Nota
Si no desea cerrar la sesión e iniciarla nuevamente, puede utilizar el comando
source, por ejemplo, source /etc/environment. De esta manera, las variables se
leerán en su shell actual.
Cómo obtener ayuda

Independientemente de si es nuevo en Linux o lo utiliza desde hace tiempo, necesitará
ayuda de vez en cuando. Es imposible recordar todos los comandos y sus parámetros.
Casi todos los comandos tienen un parámetro --help y, a veces, hay documentación
instalada en el directorio /usr/share/doc, pero las fuentes de información más
importantes son los documentos de información y las páginas man.
Uso de las páginas man

Hay un dicho, Lea el buen manual (RTFM) y, a veces, la gente reemplaza la palabra
buen con una palabra menos amigable. Casi todos los comandos tienen un manual: una
página man le proporciona toda la información que necesita. Y sí, no todas las páginas
man son fáciles de leer, en especial, las más antiguas, pero si usa páginas man con
frecuencia, se acostumbrará a ellas y podrá buscar la información que necesita con
la suficiente rapidez. Normalmente, las páginas man se encuentran instaladas en su
sistema y están disponibles en línea: http://man7.org/linux/man-pages.
Tenga en cuenta que las páginas man se eliminan en las imágenes de Azure para
openSUSE Leap y SUSE Linux Enterprise Server. Debe volver a instalar cada paquete
para que estén disponibles de nuevo:
sudo zypper refresh
for package in $(rpm -qa);
do sudo zypper install --force --no-confirm $package;
done
Cómo obtener ayuda | 63
Las páginas man se instalan en el directorio /usr/share/man en archivos comprimidos

GZIP. Las páginas man son archivos de texto con formato especial que puede leer con el
comando man o pinfo. La utilidad pinfo actúa como un explorador de texto, de forma muy
similar a un explorador web basado en texto. Agrega compatibilidad con hipervínculos
y la capacidad de navegar entre diferentes páginas man con las teclas de flecha.
Nota
Si desea reemplazar el comando man con pinfo, le recomendamos crear un alias
con el comando alias man="pinfo -m".
Todas las páginas man siguen una estructura similar y siempre están formateadas
y divididas en secciones:
• Name (Nombre): el nombre del comando y una breve explicación de este. Por
lo general, es una línea. Puede encontrar información detallada en la sección
Description (Descripción) de la página man.
• Synopsis (Sinopsis): información general con todos los parámetros disponibles.
• Description (Descripción): una descripción (larga) del comando, que a veces
incluye su estado. Por ejemplo, la página man del comando ifconfig establece
explícitamente que este comando está obsoleto.
• Options (Opciones): todos los parámetros disponibles de un comando, que a veces
incluyen ejemplos.
• Examples (Ejemplos): si los ejemplos no están en la sección Options, es posible que
haya una sección independiente.
• Files (Archivos): archivos y directorios que son importantes para este comando.
• See also (Consultar también): se refiere a otras páginas man, páginas de
información y otras fuentes de documentación. Algunas páginas man contienen
otras secciones, como notas, errores, historial, autores y licencias.
Las páginas man son páginas de ayuda que se dividen en varias secciones. Estas
secciones se describen en la sección Description de la página man. Puede usar el
comando man man para obtener más información sobre las secciones. La siguiente
captura de pantalla muestra las diferentes secciones:
Figura 3.8: Diferentes secciones de una página man
Es importante conocer esta sección, en especial, si desea buscar documentación. Para

poder buscar documentación, deberá indexar las páginas man:
sudo mandb
Nota
Normalmente, después de instalar un paquete, el índice se actualiza de forma
automática. A veces, es posible que el empaquetador no haya agregado un script
después de la instalación para ejecutar el comando mandb. Se recomienda ejecutar
el comando de forma manual si no puede encontrar la información y está bastante
seguro de que debe ser una página man.
Después de eso, puede usar los comandos apropos o man -k para encontrar la
información que necesita. No importa cuál elija; la sintaxis es la misma:
man -k -s 5 "time"
En el comando anterior, buscamos la palabra time y limitamos la búsqueda a la sección 5

de la página man.
Cómo obtener ayuda | 65
Uso de documentos de información

Los documentos de información son otra fuente importante de información. La
diferencia entre las páginas man y las páginas de información es que las páginas
de información tienen un formato más libre, mientras que las páginas man son una
especie de manual de instrucciones para un comando específico. Los documentos de
información son, la mayoría de las veces, manuales completos.
Los documentos de información están, al igual que las páginas man, comprimidos y se
instalan en el directorio /usr/share/info. Para leerlos, puede usar el comando info o el
más moderno pinfo. Ambos comandos actúan como un explorador basado en texto. Si
usted es fanático del editor Emacs, puede usar InfoMode (https://www.emacswiki.org/
emacs/InfoMode) para leer los documentos de información.
Una de las características interesantes es que puede ir directamente a uno de los
hipervínculos del documento con pinfo o info:
pinfo '(pinfo) Keybindings'
Nota
Si utiliza Ubuntu o una distribución similar, pinfo no está instalado de forma
predeterminada. Ejecute apt install pinfo para instalarlo.
En el ejemplo anterior, se abre la página man de pinfo y se va directamente a la

sección Keybindings.
El comando pinfo tiene una opción de búsqueda, -a. Si hay una coincidencia,
automáticamente se abre el documento info o la página man correspondiente. Por
ejemplo, si quiere obtener información sobre el comando echo, utilice pinfo -a echo.
Esto lo llevará a la sección de ayuda del comando echo.
El comando info también tiene una opción de búsqueda: -k. Con -k, el comando
info buscará la palabra clave en todos los manuales disponibles. Por ejemplo, aquí
comprobamos la palabra clave paste y se mostraron todas las coincidencias posibles:
Figura 3.9: Comprobación de la palabra clave paste con el comando info

Otra documentación
Otra fuente de documentación es la documentación proporcionada por el proveedor de
distribución de Linux. Los sitios web de Red Hat, SUSE, Canonical y Debian hospedan
manuales útiles, wikis, etcétera. Pueden ser muy útiles, en especial, para los temas que
son específicos de la distribución, como la administración de software.
Hay dos distribuciones que no son avaladas por Microsoft, Gentoo y Arch Linux,
y tienen excelentes wikis en sus sitios web. Y, por supuesto, parte de la información
de estas wikis es específica de estas distribuciones, pero muchos artículos son útiles
y funcionarán en cada distribución.
Linux Foundation presenta una wiki en https://wiki.linuxfoundation.org con
documentación sobre temas como redes y estándares, como Linux Standard Base
(Base Estándar para Linux, LSB), que se abordará más adelante en este capítulo. Otros
estándares se abordan en freedesktop.org (https://www.freedesktop.org). También son
responsables del sistema init de Linux, systemd y el firewall (firewalld) de Linux. Estos
temas se analizan en el Capítulo 5, Administración avanzada de Linux.
Por último, puede encontrar el Linux Documentation Project en https://www.tldp.org.
Aunque muchos de los documentos que puede encontrar allí son muy antiguos, sigue
siendo un buen punto de partida.
Cómo trabajar con archivos de texto

La filosofía de Unix iniciada por Ken Thompson tenía como objetivo crear un sistema
operativo capaz con un uso de espacio pequeño y una interfaz de usuario limpia. Debido
a que parte de la filosofía de Unix es escribir programas para manejar secuencias de
texto, porque esa es una interfaz universal, la comunicación entre programas, archivos
de configuración y muchas otras cosas se implementa en texto sin formato. En esta
sección, abordamos cómo manejar texto sin formato.
Cómo trabajar con archivos de texto | 67
Lectura de texto
En el nivel más fundamental, leer el contenido de un archivo en texto sin formato
significa tomar el contenido de este archivo y redireccionarlo a la salida estándar. El
comando cat es una utilidad que puede hacerlo: concatenar el contenido de uno o más
archivos (u otro canal de entrada) a la salida estándar:
Figura 3.10: Uso del comando cat para generar la salida estándar
Los siguientes son algunos parámetros interesantes de esta utilidad:

• -A: muestra todos los caracteres no imprimibles
• -b: numera las líneas, incluidas las vacías
• -n: numera las líneas, excepto las vacías
• -s: suprime las líneas vacías repetidas (!)
Hay otra utilidad como cat: la utilidad tac. Esta imprime el archivo en orden inverso:
Figura 3.11: Uso de la utilidad tac para imprimir archivos en orden inverso

El problema con el comando cat es que simplemente vuelca el contenido a la salida

estándar sin paginarlo y la funcionalidad de desplazamiento hacia atrás para los
terminales no es muy buena.
La utilidad more es un filtro para la paginación. Muestra el texto en una pantalla a la vez
y proporciona un motor de búsqueda básico que se puede activar mediante la barra
diagonal. Al final del archivo, more saldrá, con o sin el mensaje Press space to continue
(Presione Espacio para continuar).
La utilidad less es más avanzada que la utilidad more. Tiene las siguientes
características:
• Capacidad para desplazarse hacia delante, hacia atrás y horizontalmente
• Navegación avanzada
• Motor de búsqueda avanzado
• Administración de varios archivos
• Capacidad de mostrar información sobre el archivo, como el nombre de archivo
y la longitud
• Capacidad de invocar comandos de shell
En more y less, el comando v permite cambiar a un editor, de forma predeterminada al

editor vi.
Nota
Tanto more como less están disponibles en cada distribución. Sin embargo, en
algunas distribuciones, more es un alias para less. Utilice el comando type para
realizar la comprobación.
Si desea ver solo un número específico de líneas en la parte superior de un archivo, hay
una utilidad llamada head. De forma predeterminada, muestra las primeras 10 líneas de
un archivo. Puede modificar este comportamiento con el parámetro -n para el número
de líneas y el parámetro -c para el número de bytes/kilobytes.
La utilidad head es lo opuesto a tail; muestra las primeras 10 líneas de forma

predeterminada. Por ejemplo, tenemos un archivo llamado states.txt que contiene
los nombres de estados de EE. UU. en orden alfabético. Si usamos el comando head,
se imprimirán las primeras 10 líneas del archivo, y si usamos el comando tail se
imprimirán las últimas 10 líneas. Revisemos esto:
Figura 3.12: Uso de las utilidades head y tail para enumerar las primeras y las últimas 10 entradas del archivo
Reconoce los mismos parámetros que head para modificar ese comportamiento. Sin
embargo, hay un parámetro adicional que hace que esta utilidad sea extremadamente útil
para fines de registro. -f anexa la salida a medida que crece el archivo. Es una forma de
seguir y supervisar el contenido de un archivo. El siguiente es un ejemplo muy bien conocido:
sudo tail -f /var/log/messages
Búsquedas en archivos de texto
Es posible que haya escuchado que todo en Linux es un archivo. Además, muchos
aspectos en Linux se administran mediante secuencias de texto y archivos de texto.
Tarde o temprano, tendrá que buscar el texto para realizar modificaciones. Esto se
puede hacer mediante el uso de expresiones regulares. Una expresión regular (regex
para abreviar) es un patrón de caracteres especiales y texto que se utiliza para hacer
coincidir cadenas cuando se realiza una búsqueda. Las expresiones regulares se usan
en muchas aplicaciones con un procesador integrado, como los editores Emacs y vi,
y utilidades como grep, awk y sed. Muchos lenguajes de scripting y programación son
compatibles con las expresiones regulares.
En este libro, solo trataremos los aspectos básicos de este tema, lo suficiente como para
que pueda usarlos en sus tareas diarias de administración del sistema.
Cada expresión regular se construye en torno a un elemento atom. El elemento atom
identifica qué texto coincidirá y dónde se encontrará cuando se realice una búsqueda.
Podría ser un elemento de un solo carácter conocido (o un punto si no conoce el
carácter), una clase o un rango, como:
Figura 3.13: Ejemplos de atom
Una expresión regular también se puede expresar en forma de una clase abreviada. Aquí
hay algunos ejemplos de clases abreviadas:
Figura 3.14: Ejemplos de clases abreviadas
Podemos usar delimitadores de posición para determinar dónde encontrar el siguiente

carácter. Algunos de los más populares son los siguientes:
Figura 3.15: Lista de delimitadores de posición

Con un operador de repetición, puede especificar cuántas veces debe aparecer

un carácter:
Figura 3.16: Lista de operadores de repetición
Los siguientes son algunos ejemplos:

• Si busca el carácter b y encuentra la palabra boom, coincidirá con la letra b. Si busca
bo, la palabra coincidirá con estos caracteres en este orden.
• Si busca bo{,2}m, las palabras bom y boom coincidirán. Pero si existe la palabra booom,
no coincidirá.
• Si busca ^bo{,2}m, solo habrá una coincidencia si la palabra boom está al principio
de una línea.
Se puede encontrar una referencia para las expresiones regulares mediante el

siguiente comando:
man 7 regex
Una utilidad que ya mencionamos es la utilidad grep, que se utiliza para buscar en
archivos de texto. Existen varias versiones de esta utilidad. Actualmente, egrep es la
versión más utilizada porque tiene la compatibilidad con expresiones regulares más
completa, incluidos los rangos de abreviatura y el operador de alternancia OR, |.
Las siguientes son opciones comunes de egrep y grep:
Figura 3.17: Opciones de egrep y grep
También puede revisar la página man para dar un vistazo a las otras opciones.
Aquí hay un ejemplo sencillo de grep:
Figura 3.18: Ejemplo de grep
Otra utilidad muy útil es awk. Ahora, awk es una utilidad creada por los desarrolladores
Alfred Aho, Peter Weinberger y Brian Kernighan. Es un lenguaje de scripting utilizado
para archivos de texto que se usan para generar y manipular archivos de registro
o informes. awk no requiere ninguna compilación, y puede mencionar los campos
requeridos en el informe.
Veamos un ejemplo:
awk -F: '/^root/ {print "Homedir of root:", $6}' /etc/passwd
Analiza el archivo /etc/passwd y divide el contenido mediante el separador de campos,

los dos puntos. Busca la línea que comienza con la cadena root e imprime algo de texto
(Homedir of root:) y la sexta columna.
Edición de archivos de texto

Debido a que los archivos de texto son tan importantes en Linux, un editor de texto es
muy importante. Cada distribución tiene uno o más editores en sus repositorios, tanto
para entornos gráficos como no gráficos. Puede estar seguro de que al menos vim, una
implementación de vi moderna, y Emacs están disponibles. Hoy en día, hay una guerra
entre los amantes de vi y los de Emacs: se han estado insultando mutuamente durante
décadas y lo harán durante muchas décadas más.
No tomaremos la decisión por usted. En su lugar, si ya está familiarizado con una de
estas implementaciones, quédese con ella. Si no conoce vi o Emacs, pruébelos por un
tiempo y tome su decisión.
También hay otros editores disponibles:
• nano, un clon gratuito de la red patentada Pico, el componente de editor de texto
del cliente de correo electrónico Pine
• mcedit, una parte del administrador de archivos Midnight Commander (MC) que
también puede ejecutarse de forma independiente
• joe, que puede emular los enlaces de teclado de nano, Emacs, y un procesador de
textos muy antiguo llamado WordStar (tenga en cuenta que, para CentOS, este
editor no está disponible en el repositorio estándar, sino que se encuentra en un
repositorio de terceros).
Nota
Si desea obtener información sobre vi, ejecute el comando vimtutor, un tutorial
incluido con vim. Es un excelente punto de partida para aprender todos los
aspectos básicos de la navegación, los comandos y la edición de texto en vi.
Emacs viene con una excelente función de ayuda a la que puede acceder en Emacs
mediante Ctrl + H + R.
Otra forma de editar secuencias de texto y archivos es mediante el editor de texto no

interactivo sed. En lugar de editar archivos de texto abriendo un archivo en una ventana
del editor de texto, se procesa un archivo o secuencia desde el shell. Es útil si desea
hacer lo siguiente:
• Realizar ediciones en archivos automáticamente
• Hacer los mismos cambios en varios archivos
• Escribir un programa de conversión, por ejemplo, para cambiar entre minúsculas
y mayúsculas, o incluso conversiones más complejas
La sintaxis del editor sed es muy similar a los comandos del editor vi y se puede hacer
un script.
El comportamiento predeterminado de sed no es editar el archivo en sí, sino volcar
los cambios en la salida estándar. Puede redirigir esta salida a otro archivo o usar el
parámetro -i, que significa in-place edit (edición en contexto). Este modo cambiará
el contenido del archivo. El siguiente comando es, por lejos, el comando sed más
conocido:
sed -i 's/string/newstring/g' filename.txt
Buscará una cadena, la reemplazará y continuará realizando búsquedas y reemplazos

hasta el final del archivo.
Junto con un poco de creación de scripts, puede editar varios archivos de la misma manera:
for files in *conf; do sed -i 's/string/newstring/g' $files; done
Puede limitar la búsqueda a una sola línea:

sed -i '10 s/string/newstring/g' <filename>
La página info de sed es un excelente recurso para todos los comandos y, lo que es más
importante, tiene una sección de ejemplos si desea saber más.
Cómo encontrar su camino en el sistema de archivos

Ahora que sabe cómo manipular y editar archivos de texto, es el momento de ver cómo
se almacenan estos archivos en el sistema. Como administrador del sistema, tendrá que
comprobar, montar o incluso desmontar las unidades. Ahora demos un vistazo al sistema
de archivos de Linux. El diseño del sistema de archivos de Linux es como todos los
demás miembros de la familia Unix: muy diferente de Windows. No existe un concepto
de letras de unidad. En su lugar, hay un sistema de archivos raíz (/), y todo lo demás está
disponible en el sistema de archivos raíz, incluidos otros sistemas de archivos montados.
En esta sección, aprenderá dónde puede encontrar archivos y por qué están allí.
Cómo encontrar su camino en el sistema de archivos | 75
El Estándar de jerarquía del sistema de archivos

En 2001, Linux Foundation comenzó el Linux Standard Base Project (LSB). Basado en la
especificación POSIX, la idea detrás de este proceso era tener un sistema estandarizado
para que las aplicaciones pudieran ejecutarse en cualquier distribución compatible
con Linux.
El Estándar de jerarquía del sistema de archivos (Filesystem Hierarchy Standard,
FHS) es parte de este proyecto y define la estructura y el contenido del directorio.
Por supuesto, todavía hay algunas pequeñas diferencias entre las distribuciones con
respecto a la estructura de directorios, pero incluso en las distribuciones que no están
dispuestas a admitir completamente la LSB, como Debian, la estructura de directorios
sigue el FHS.
Las siguientes capturas de pantalla se tomaron de un sistema CentOS, con la utilidad
tree para mostrar la estructura del directorio. Si tree no está instalada en su sistema,
el shell le solicitará el comando para instalarla. Hágalo.
En el sistema de archivos raíz, están disponibles los siguientes directorios:
Figura 3.19: Visualización de la estructura de directorios mediante la utilidad tree

El comando tree ordenará el sistema de archivos en una estructura similar a un árbol.

Como alternativa, puede usar ls -lah / para ver la estructura en un formato de lista.
Los siguientes directorios están presentes en la captura de pantalla:
• /bin: contiene programas que necesita en un sistema mínimo para que lo ejecute
un usuario sin privilegios, como un shell. En sistemas basados en Red Hat, este
directorio es un vínculo simbólico a /usr/bin. Aquí se almacenan comandos como
ps, ls y ping.
• /sbin: contiene programas que necesita en un sistema mínimo para que lo ejecute
un usuario privilegiado (root), como utilidades de reparación de sistemas de
archivo. En sistemas basados en Red Hat Enterprise Linux, este directorio es un
vínculo simbólico a /usr/sbin. Entre los ejemplos se incluyen iptables, reboot,
fdisk, ifconfig y swapon.
• /dev: los dispositivos se montan en un sistema de archivos especial llamado devfs.
Todos los dispositivos periféricos están aquí, como el puerto serie, los discos y las
CPU, excepto la interfaz de red. Ejemplos: /dev/null, /dev/tty1.
• /proc: los procesos se montan en un sistema de archivos especial llamado procfs.
• /sys: información de hardware en el sistema de archivos sysfs.
• /etc: consta de archivos de configuración de texto editables requeridos por todos
los programas.
• /lib: biblioteca para controladores y archivos de configuración de texto no
editables. Los archivos de nombres de la biblioteca son ld* o lib*.so.*, por
ejemplo, libutil-2.27.so o libthread_db-1.0.so.
• /lib64: bibliotecas para controladores, pero sin archivos de configuración.
• /boot: kernel y cargador de arranque. Ejemplos: initrd.img-2.6.32-24-generic,
vmlinuz-2.6.32-24-generic.
• /root: datos de usuario para el usuario root. Solo el usuario root tiene derecho
a escribir en este directorio. /root es el directorio principal del usuario root, que
no es el mismo que /.
• /home: datos de usuario para usuarios sin privilegios. Similar a la carpeta C:\Users\
username de Windows.
• /media: aquí se montan los medios extraíbles, como las unidades de CD-ROM
y USB. Al menos de solo lectura para cada usuario. Los ejemplos incluyen /media/
cdrom para CD-ROM, /media/floppy para unidades de disquete y /media/cdrecorder
para grabadores de CD.
• /mnt: medios no extraíbles, incluido el almacenamiento remoto. Al menos de solo
lectura para cada usuario.
• /run: archivos específicos para un usuario o proceso, por ejemplo, controladores

USB que deben estar disponibles para un usuario específico o información de
tiempo de ejecución para un demonio.
• /opt: software opcional que no forma parte de la distribución, como software
de terceros.
• /srv: datos del servidor estático. Se puede utilizar para sitios web estáticos, los
servidores de archivos y el software de orquestación, como Salt o Puppet.
• /var: datos dinámicos. Abarca desde las colas de impresión y el registro hasta
sitios web dinámicos.
• /tmp: archivos temporales, no persistentes durante los reinicios. Hoy en día,
con frecuencia se monta un sistema de archivos RAM (tmpfs) en este directorio.
El directorio en sí está más o menos obsoleto, y desde una perspectiva de la
aplicación, se reemplaza con un directorio en /var o /run.
• /usr: contiene todos los archivos binarios, la documentación y el código fuente
adicionales relacionados con el software.
Vuelva a usar el comando tree para mostrar la estructura del directorio en /usr:
Figura 3.20: Estructura de directorio en el directorio /usr

La estructura de directorio de /usr es muy similar a la estructura de /. Se agregaron

algunos directorios adicionales:
• /usr/etc: si vuelve a compilar el software que ya es parte de la distribución, los
archivos de configuración deberían estar en /usr/etc, de manera que no entren
en conflicto con los archivos en /etc.
• /usr/games: datos para juegos antiguos, como fortune, figlet y cowsay.
• /usr/include: encabezados de desarrollo.
• /usr/libexec: scripts contenedores. Supongamos que necesita varias versiones
de Java. Todas necesitan diferentes bibliotecas, variables de entorno, y así
sucesivamente. Un script contenedor se usa para llamar a una versión específica
con la configuración correcta.
• /usr/share: datos del programa, como fondo de pantalla, elementos de menú,
iconos y documentación.
• /usr/src: fuentes de kernel de Linux y fuentes de software que se incluyen en
la distribución.
• /usr/local: software que instala y compila usted mismo.
La estructura de directorio de /usr/local es la misma que la de /usr:
Figura 3.21: Estructura del directorio /usr/local

Este directorio se usa para desarrollo de software. No es necesario tenerlo en un

entorno de producción.
El software opcional se coloca en /opt. La estructura de directorios principal es
/opt/<vendor>/<software>/, por ejemplo, /opt/google/chrome. Linux Assigned
Names And Numbers Authority (LANANA) mantiene una lista de los nombres de
posibles proveedores en su sitio web, http://www.lanana.org/lsbreg/providers/.
Para el software de Linux, la estructura es la misma que la de /usr y /usr/local, con
una excepción: puede elegir entre /conf y /etc en el directorio de software o en el
directorio /etc/opt. El software de Linux no nativo, como PowerShell, puede usar su
propia estructura dentro del directorio de software.
Cómo montar sistemas de archivos

Puede ser recomendable definir el sistema de archivos raíz de forma más precisa.
El sistema de archivos raíz es el sistema de archivos donde se ubica el directorio raíz, /.
Todos los demás sistemas se montan en los directorios creados en este sistema de
archivos raíz. Para averiguar qué directorios son locales para el sistema de archivos raíz
y cuáles son los puntos de montaje, ejecute el comando findmnt:
Figura 3.22: Uso del comando findmnt para encontrar puntos de montaje
Agregar el parámetro -D mostrará el tamaño del sistema de archivos y la cantidad de

espacio que está disponible:
Figura 3.23: Enumeración del tamaño del archivo y el espacio disponible con el comando findmnt -D
El comando findmnt es una excelente manera de averiguar dónde se monta un

dispositivo, por ejemplo:
findmnt /dev/sda1
Si un directorio no es un punto de montaje, utilice el parámetro -T:

findmnt -T /usr
En el Capítulo 5, Administración avanzada de Linux, se tratan en detalle los diferentes

sistemas de archivos y cómo montar automáticamente los sistemas de archivos locales
y remotos.
Cómo encontrar archivos en el sistema de archivos

La búsqueda de archivos en el sistema de archivos se puede realizar con el comando
find. Desafortunadamente, si aún no está familiarizado con este comando, la página
man puede ser abrumadora y difícil de leer. Sin embargo, si entiende los conceptos
básicos de este comando, la página man lo ayudará a agregar parámetros para buscar
cada propiedad de un archivo o directorio, o ambos.
Los primeros parámetros posibles del comando find son opciones. Esto afecta el
comportamiento del comando find, es decir, si debe seguir vínculos simbólicos
y depurar y acelerar las opciones de optimización. Las opciones son optativas,
la mayoría de las veces no las necesita.
Después de las opciones, el siguiente parámetro indica al comando find dónde se inicia
el proceso de búsqueda. No se recomienda comenzar en el directorio raíz (/); demora
demasiado y consume demasiada actividad de CPU en sistemas de archivos grandes.
Recuerde el FHS: por ejemplo, si desea buscar archivos de configuración, comience
a buscar en el directorio /etc:
find /etc
El comando anterior le mostrará todos los archivos de /etc.

Después de la ubicación, el siguiente parámetro es una expresión que contiene una o
más pruebas. Para enumerar las pruebas más comunes, use los siguientes comandos:
• -type, f para el archivo, d para el directorio, b para el bloque de dispositivo
• -name <pattern>
• -user y -group
• -perm
• -size
• -exec
Puede realizar una combinación de estas pruebas. Por ejemplo, para buscar archivos
con nombres de archivo que terminen en conf, utilice lo siguiente:
find /etc -type f -name '*conf'
Para algunas pruebas, como size y atime, se puede agregar un elemento que se
denomina comparación con un parámetro proporcionado:
• +n: mayor que n
• -n: menor que n
• n: exactamente n
El comando find busca archivos y directorios y los compara con el valor n:

find / -type d -size +100M
En este ejemplo, se buscan directorios con contenido que supere los 100 MB.
El último parámetro es la acción que se debe ejecutar en los archivos que se
encontraron. Algunos ejemplos son:
• -ls, la salida es similar al comando ls.
• -print para imprimir los nombres de archivo.
• -printf para formatear la salida del comando -print.
• -fprintf para escribir la salida formateada en un archivo.
El parámetro -printf puede ser extremadamente útil. Por ejemplo, este comando
buscará archivos y mostrará su tamaño en bytes y el nombre de archivo. Después de
eso, puede usar el comando sort para ordenar los archivos por tamaño:
find /etc -name '*conf' -printf '%s,%p\n' | sort -rn
También hay acciones más peligrosas, como -delete para eliminar los archivos
encontrados y -exec para ejecutar un comando externo. Debe estar muy seguro del
resultado de su acción de búsqueda antes de usar estos parámetros. La mayor parte
del tiempo, en lo que respecta al rendimiento, es mejor utilizar la utilidad xargs.
Esta utilidad toma los resultados y los convierte en argumentos para un comando.
El siguiente es un ejemplo de un comando de este tipo: la utilidad grep se utiliza para
buscar el contenido del resultado:
find /etc/ -name '*' -type f| xargs grep "127.0.0.1"
Administración de procesos
En la sección anterior, analizamos el sistema de archivos de Linux. Desde la perspectiva
de un administrador del sistema, la administración de los procesos es crucial. Habrá
situaciones en las que deberá iniciar, detener o incluso terminar procesos. Además,
para evitar limitar su máquina, debe tener cuidado con los procesos que se ejecutan
en el sistema. Analicemos con mayor detalle el proceso de administración de Linux.
El kernel de Linux ejecuta los procesos. Este es iniciado por un usuario o creado por
otros procesos. Todos los procesos son procesos secundarios de un proceso principal
y se abordarán en el siguiente capítulo. En esta sección, aprenderemos a identificar los
procesos y cómo enviar una señal a un proceso.
Visualización de los procesos

Si inicia un programa, se asigna un ID de proceso (PID) al proceso y se crea el directorio
correspondiente en /proc.
En Bash, puede encontrar el PID del shell actual con el siguiente comando:
echo $$
También puede encontrar el PID del shell principal:

echo $PPID
A fin de encontrar el PID de un programa en el sistema de archivos, use la utilidad pidof:

pidof sshd
Es posible que vea varios PID devueltos por el shell. Si desea devolver solo un PID, use el
parámetro -s, que significa disparo único:
pidof -s sshd
Administración de procesos | 83
Veamos el directorio proc del shell actual:
Figura 3.24: Directorio proc del shell actual
Puede ver todas las propiedades de este proceso. Revisemos algunas de ellas:
• cmdline: el comando que se ejecuta para crear este proceso
• environ: las variables de entorno que están disponibles para este proceso
• status: el estado del archivo, el UID (Identificador de usuario) y el GID
(Identificador de grupo) del usuario/grupo que es propietario del proceso
Si ejecuta cat environ, la salida es difícil de leer porque el carácter de final de línea es
\0 en lugar de \n. Puede solucionar esto con el comando tr para traducir \0 a \n:
cat /proc/$$/environ | tr "\0" "\n"
El directorio proc es muy interesante para solucionar problemas, pero también hay
muchas herramientas que utilizan esta información a fin de producir una salida más
fácil de usar para las personas. Una de estas utilidades es el comando ps. Hay algo
extraño en este comando, admite tres tipos diferentes de parámetros:
• Estilo Unix: precedido por un guion. Los comandos se pueden agrupar. ps -ef es
lo mismo que ps -e -f.
• Estilo BSD: no es precedido por un guion. Los comandos se pueden agrupar. ps ax
es lo mismo que ps a x.
• Estilo GNU: precedido por un guion doble y una opción con nombre largo. Los
comandos no se pueden agrupar.
El formato de salida para los tres estilos no es el mismo, pero puede modificar el
comportamiento con opciones. A continuación, se muestra una comparación:
Figura 3.25: Uso de la utilidad ps con sus parámetros
Los procesos entre corchetes son los procesos del kernel.

Puede consultar valores específicos, por ejemplo:
ps -q $$ -o comm
Esto es lo mismo que:

cat /proc/$$/cmdline
Otra utilidad que puede ayudarlo a buscar un proceso es pgrep. Busca en valores como
el nombre y el usuario, y muestra el PID de forma predeterminada. La salida se puede
formatear mediante parámetros como -l para mostrar el nombre del proceso o -o para
agregar el comando completo a la salida.
Una forma interactiva de supervisar los procesos utiliza el comando top:
Figura 3.26: Supervisión de procesos mediante el comando top

Administración de procesos | 85
Los valores en las columnas de un proceso visible en top son los mismos que en ps. En la
página man de top, puede encontrar una explicación apropiada de lo que significan. En
los próximos capítulos, se hablará de algunos de ellos.
El comando top o el comando htop más sofisticado, puede ayudar a identificar
rápidamente procesos que ocupan demasiada memoria o CPU, y enviar una señal al
proceso. Si desea una supervisión del proceso y solución de problemas detalladas
y avanzadas, es mejor usar las herramientas disponibles en Azure. Hablamos de esto
en el Capítulo 11, Solución de problemas y supervisión de sus cargas de trabajo.
Envío de señales a un proceso

En el mundo real, es posible que encuentre un problema en el que un proceso
específico consume mucha memoria. En este punto, es posible que desee enviar una
señal de término al proceso. Asimismo, puede encontrar diferentes escenarios mientras
se ocupa de los procesos. En esta sección, exploraremos diferentes señales que se
pueden enviar al proceso. Puede obtener más información sobre las señales en la
página man para señales, sección 7. Una señal es un mensaje que se envía a un proceso,
por ejemplo, para cambiar la prioridad o terminarla. Hay muchas señales diferentes
descritas en este manual, pero solo algunas son realmente importantes:
• Señal 1: bloquea el proceso, recargará todo lo que está vinculado a un proceso.
Se utiliza comúnmente para volver a leer un archivo de configuración cambiado.
• Señal 2: es lo mismo que Ctrl + C y Ctrl + Interrumpir.
• Señal 3: abandono normal de un proceso, es lo mismo que Ctrl + D.
• Señal 15: señal predeterminada, que se utiliza para terminar un comando, lo que le
da tiempo al terminal para limpiarlo todo bien.
• Señal 9: termina un comando sin limpieza. Esto es peligroso y puede hacer que su
sistema sea inestable y, a veces, incluso vulnerable.
Si desea ver la lista de señales que se pueden enviar a un proceso, ejecute:

kill -l
Para enviar una señal a un proceso, puede usar el comando top (abreviado k) o kill:
kill -HUP <PID>
Hay una utilidad interesante que puede usar para buscar un proceso o grupo de
procesos con grep, esta envía una señal a la vez: pkill. Es similar a pgrep. Se puede
seleccionar en valores como name y uid.
Control de acceso discrecional

Ahora que ya abordamos el sistema de archivos y la administración de procesos, debe
existir una forma de restringir los permisos a los archivos que está creando. En otras
palabras, no debe otorgar acceso total a todos. La mayoría de las organizaciones sigue
el principio de otorgar los permisos más detallados. El Control de acceso discrecional
(DAC) es una implementación de seguridad que restringe el acceso a objetos como
archivos y directorios. Un usuario o un grupo de usuarios obtiene acceso en función
de la propiedad y los permisos en los objetos.
En los entornos de nube, es posible que la administración de usuarios y grupos no
sea parte de su trabajo diario. A menudo, se delega a los sistemas de administración
de identidades, como Active Directory (AD), y no se necesitan muchas cuentas de
usuario. Hoy en día, la autenticación y la autorización en el nivel de la aplicación son
más importantes. Sin embargo, sigue siendo una buena idea poder comprobar a los
usuarios y saber cómo funciona el sistema subyacente.
Administración de usuarios
Si implementa una VM en Azure, en el asistente especificará un usuario, que la
administración de usuarios del agente de Azure creará en la VM, por ejemplo,
si implementa una VM con PowerShell:
Figura 3.27: Implementación de una VM con PowerShell

Control de acceso discrecional | 87
Puede utilizar esta cuenta para iniciar sesión. Es un usuario normal, también llamado
usuario sin privilegios, que no tiene privilegios administrativos. Para adquirir privilegios
administrativos, necesita el comando sudo. sudo significa acción de superusuario
(o actuar como superusuario). Sin parámetros, el comando su cambia su usuario actual
a otro usuario, raíz: la cuenta de administrador en Linux.
Nota
Si desea privilegios raíz, en algunas imágenes de Linux en Azure no puede usar el
comando su. Está desactivado de forma predeterminada. Para obtener un shell
raíz, puede usar sudo -s. De forma predeterminada, el comando sudo le pedirá su
contraseña.
Si desea obtener más información sobre esta cuenta de usuario, utilice el comando
getent para obtener una entidad de la base de datos passwd, donde se almacena la
información del usuario. Esta base de datos passwd puede ser local, estar almacenada en
un archivo /etc/passwd o ser remota, donde un servidor remoto concederá autorización
mediante la comprobación de la base de datos del usuario, Protocolo ligero de acceso
a directorios (LDAP), por ejemplo:
sudo getent passwd <username>
Para obtener los detalles del usuario linvirt:
Figura 3.28: Uso de getent para obtener detalles de linvirt
La salida de este comando es una lista separada por dos puntos:

• Nombre de la cuenta de usuario
• Contraseña
• ID de usuario
• ID de grupo
• Campo General Electric Comprehensive Operating System (GECOS) para
información adicional de la cuenta
• Directorio principal para este usuario
• Shell predeterminado
En los primeros días de la familia de sistemas operativos Unix, la contraseña se

almacenaba en el archivo /etc/passwd, pero por razones de seguridad, la contraseña con
algoritmo hash se cambió a /etc/shadow. La contraseña se puede cambiar con el comando:
sudo passwd <username>
Si desea cambiar la contraseña del usuario actual, no es necesario utilizar sudo

y no es necesario especificar el nombre de usuario. Puede ver la entrada en el
archivo /etc/shadow con getent:
Figura 3.29: Comprobación del ingreso de contraseña mediante el comando getent
Las columnas después de la contraseña con hash contienen información de antigüedad

que se puede ver (y cambiar) con el comando chage. La notación en la base de datos
de instantáneas se anota por el número de días desde el “tiempo Unix” (el cumpleaños
virtual de Unix: 1 de enero de 1970). El comando chage lo traduce a un formato que es
más fácil de leer para las personas:
Figura 3.30: Uso del comando chage para obtener información de antigüedad

Volvamos a la base de datos passwd. La numeración del ID de usuario se define en

el archivo /etc/login.defs. El ID 0 se reserva para la cuenta raíz. Los ID 1 a 200 se
reservan para las cuentas admin que ya no se usan en los sistemas Linux modernos.
En las distribuciones basadas en Red Hat, el rango de 201 a 999 está reservado para las
cuentas del sistema, y los demonios se ejecutan en estas cuentas. El rango de cuentas
sin privilegios está entre 1000 y 60 000 para los usuarios locales y más de 60 000 para
los usuarios remotos (por ejemplo, usuarios de AD o LDAP). Hay pequeñas diferencias
entre las distribuciones de Linux. Resumamos los valores:
Figura 3.31: ID de usuario con sus tipos de usuario reservado
Muchas distribuciones se configuran con el llamado esquema de Grupo privado de

usuario (UPG), gracias a la directiva del archivo /etc/login.defs:
USERGROUPS_ENAB yes
Esto significa que, si crea un usuario, se crea automáticamente un grupo principal

con el mismo nombre que el inicio de sesión. Si deshabilita esta funcionalidad,
un usuario recién creado pasará a ser miembro de otro grupo automáticamente,
definido en /etc/default/useradd:
GROUP=100
El campo GECOS se puede cambiar con el comando chfn:
Figura 3.32: Cambio del campo GECOS con el comando chfn
Nota:
El comando chfn (change finger) se refiere a una utilidad antigua, finger, que
no está instalada de forma predeterminada, pero que sigue estando disponible
en los repositorios. También está disponible un demonio finger que hace que
la información de GECOS esté disponible a través de la red, pero se considera un
riesgo para la seguridad.
El shell predeterminado durante la creación de un usuario se define en /etc/default/

useradd. Puede cambiar el shell predeterminado por otro mediante el comando chsh.
El shell debe aparecer en el archivo /etc/shells:
chsh -s /bin/tcsh linvirt
Para el propósito de este libro, mantenga Bash como el shell predeterminado.

En esta sección, aprendió cómo comprobar y cambiar las propiedades de un usuario
local existente. Por supuesto, también puede agregar usuarios adicionales:
sudo useradd <username>
El comando useradd tiene muchas opciones de personalización. Puede obtener

más información acerca de esto con man useradd. Opcionalmente, puede usar el
comando adduser:
Figura 3.33: Adición de un usuario con el comando adduser
Administración de grupos
Como se analizó en el capítulo anterior, un usuario formará parte de un grupo principal.
Cuando cree un usuario, si no especifica un grupo, se creará un grupo con el mismo
nombre que el nombre de usuario. Si revisa la captura de pantalla anterior, puede ver
un grupo llamado john para el usuario john.
Además de ser miembro de un grupo principal, se pueden agregar membresías grupales
adicionales. Esto es necesario para obtener acceso a un directorio/recurso compartido
de grupo o para delegar privilegios en la configuración sudo. Puede agregar grupos
adicionales existentes con el parámetro --groups del comando useradd durante la
creación de un usuario, o después con usermod o groupmems.
Crearemos un usuario y un grupo nuevos y comprobaremos los resultados:

sudo useradd student
sudo passwd student
sudo getent passwd student
sudo groupadd staff
sudo getent group staff
Haga que el usuario student sea miembro del grupo staff:
sudo groupmems -g staff -a student
Opcionalmente:
sudo usermod –aG staff student
sudo groupmems -g staff -l
sudo getent group staff
Puede cambiar su grupo principal temporalmente con switch group (sg):
su student
id -g
sg staff
Nota:
No es muy común, pero puede agregar una contraseña a una cuenta de grupo
con el comando gpasswd. De esta manera, un usuario que no es miembro de este
grupo todavía puede usar sg e ingresar la contraseña para el grupo.
Un grupo muy especial es el grupo wheel. En la configuración sudo, un usuario que

es miembro de este grupo puede ejecutar comandos que necesitan privilegios
administrativos. En Ubuntu, este grupo no está disponible. En cambio, hay un grupo
llamado sudo que se puede utilizar para el mismo propósito.
Administración de inicio de sesión

En un entorno empresarial, los administradores deben recopilar información,
como el número de usuarios que iniciaron sesión, el número de inicios de sesión no
válidos y si los usuarios autorizados intentaron iniciar sesión con fines de auditoría de
seguridad. En este capítulo, trataremos la administración de inicio de sesión en Linux,
que es crucial desde el punto de vista de la seguridad.
Un servicio llamado systemd-logind y su comando correspondiente loginctl registran,

hacen seguimiento y administran cualquier inicio de sesión en un sistema Linux. Este
comando está disponible para todas las distribuciones de Linux. Sin embargo, si está
utilizando el Subsistema de Windows para Linux (WSL), no estará disponible debido
a la falta del systemd.
Los parámetros de este comando se dividen en secciones para usuarios, sesiones
y puestos. Para hacer algunos ejercicios con estos parámetros, abra una segunda sesión
de ssh en su VM con las credenciales de la cuenta de estudiante. Ejecute los comandos
en la primera sesión de ssh.
En primer lugar, enumere las sesiones:
loginctl list-sessions
Anote los ID de sesión y los detalles de una sesión específica:

loginctl show-session <session number>
En mi caso, el ID de sesión es 27, por lo que revisaremos los detalles de la sesión

con loginctl:
Figura 3.34: Comprobación de los detalles de la sesión para el ID de sesión 27
Vea las propiedades del usuario:

loginctl show-user <username>
Cambie a la segunda sesión de SSH y ejecute el comando man man.

Ahora cambie la administración de inicio de sesión a la primera sesión de SSH y vea el
estado del estudiante con el parámetro user-status:
Figura 3.35: Uso del parámetro user-status
Por último, finalice la sesión:

sudo loginctl terminate-session <session id>
También hay un parámetro terminate-user que puede ser útil si hay varios usuarios en
una sesión.
Resumen
Este capítulo fue una especie de curso intensivo sobre cómo sobrevivir en Linux si
no está familiarizado con el sistema operativo. En él no se pretendía enseñar cómo
transformarse en un administrador sénior de Linux.
En su vida cotidiana como administrador de Azure, es posible que no utilice todos los
pasos que se indican en este capítulo. Por ejemplo, puede que no cree usuarios en una
VM. Sin embargo, debe ser capaz de comprobar a los usuarios configurados en un sistema
de administración de identidades, como AD, y comprobar que pueden iniciar sesión.
En este capítulo, se abordó el uso de shells, la estructura del sistema de archivos
y la búsqueda de archivos. Analizamos el rol de los archivos de texto en Linux
y cómo procesarlos y editarlos. Trabajamos con procesos y abordamos cómo
verlos y terminarlos. Y, por último, pero no menos importante, analizamos la
administración de usuarios y grupos.
En el próximo capítulo, analizaremos la administración de recursos en Azure.
Preguntas | 95
Preguntas
En este capítulo, en lugar de responder algunas preguntas, quiero que haga un ejercicio:
1. Cree los usuarios Lisa, John, Karel y Carola.
2. Configure la contraseña welc0meITG para estos usuarios.
3. Compruebe la existencia de estos usuarios.
4. Cree los grupos finance y staff.
5. Haga que Lisa y Carola sean miembros de finance, y Karel y John miembros de staff.
6. Cree los directorios /home/staff y /home/finance y establezca la propiedad del
grupo de estos directorios en staff y home, respectivamente.
7. Otorgue al grupo “staff” acceso de lectura al directorio “finance”.
8. Asegúrese de que los archivos recién creados reciban la propiedad y los permisos
correctos del grupo.
Lectura adicional
Hay muchos libros que se publican para los usuarios que usan el sistema operativo
Linux por primera vez. Estos son algunos de mis favoritos:
Working with Linux - Quick Hacks for the Command Line (Trabajar con Linux: trucos
rápidos para la línea de comandos) (ISBN 978-1787129184) de Petru Işfan y Bogdan
Vaida es una colección curiosa de consejos y trucos interesantes y, a veces, eso es
todo lo que necesita.
Si puede leer en alemán, todos los libros de Michael Kofler (https://kofler.info) deberían
estar en su biblioteca, aunque usted sea un usuario experimentado de Linux.
El sitio web de Microsoft tiene documentación muy buena sobre las expresiones
regulares: https://docs.microsoft.com/es-xl/dotnet/standard/base-types/
regular-expressions. Y me gusta http://regexone.com si desea practicar el uso de
las expresiones regulares.
La utilidad awk tiene un gran manual (https://www.gnu.org/software/gawk/manual/
gawk.html), pero quizá no es lo más apropiado para comenzar. Shiwang Kalkhanda
realizó un trabajo muy bueno en Learning AWK Programming (Aprender programación
de AWK) (ISBN 978-1788391030), con un libro muy fácil de leer. No se asuste con
la palabra programación en este título, en especial, si no es un desarrollador. Le
recomiendo leer este libro.
Administración
4
de Azure
En el Capítulo 2, Introducción a la nube de Azure, dimos nuestros primeros pasos en
nuestro viaje al mundo de Azure. Descubrimos que hay muchas formas de administrar
un entorno de Azure y que estas incluyen Azure Portal y las interfaces de línea de
comandos. Puede usar las interfaces de línea de comandos dentro de Azure Portal para
ejecutarlas en la estación de trabajo. Más adelante en este libro, veremos que hay otras
excelentes posibilidades mediante soluciones de automatización y orquestación. Al final
del Capítulo 3, Administración básica de Linux, creamos una VM de Linux y exploramos
los aspectos básicos del entorno de Linux.
Antes de continuar nuestro viaje y abordar temas más avanzados, en este capítulo, se
tratan los componentes de la infraestructura de Azure que se necesitan para nuestras
cargas de trabajo, VM y contenedores. Analizamos el sistema de archivos en Linux, pero
¿cómo agregaremos más discos de datos a la VM? Como administrador del sistema,
es posible que deba permitir o denegar el tráfico a la VM en función de sus requisitos
empresariales, pero ¿cómo se puede hacer esto en Azure? Hay escenarios en los que
se necesitan varias interfaces de red conectadas a la VM. ¿Cómo se logrará eso? En esta
sección, se responderá a todas sus preguntas sobre cómo administrar los recursos de
Azure que están relacionados con su VM. Hablamos de componentes que ya hemos
usado en capítulos anteriores, a veces, incluso sin saber que lo hicimos.
98 | Administración de Azure
Básicamente, este capítulo se trata sobre los recursos de Azure. Recuerde que todos
forman parte de un grupo de recursos, un contenedor lógico donde se implementan
y se administran los recursos. Los siguientes son algunos de los temas principales de
este capítulo:
• Administración de recursos de almacenamiento en Azure y diferentes opciones de
almacenamiento disponibles
• Administración de recursos de red en Azure y comprensión de su rol en las VM
• Uso de comandos prácticos en PowerShell y la CLI de Azure para administrar
recursos en Azure
Nota
En este libro, tratamos de ser lo más independientes posibles con respecto a las
interfaces disponibles. Debido a que este capítulo se trata más de la teoría que de
las interfaces, usaremos PowerShell como ejemplo.
Administración de recursos de Azure con la CLI de Azure y PowerShell

En este capítulo, veremos cómo podemos administrar los recursos de Azure con
PowerShell y la CLI de Azure. Cada tarea que realizaremos también se puede hacer
desde Azure Portal. Sin embargo, como administrador del sistema que realiza las tareas
cotidianas desde el terminal, debería poder administrar sus recursos mediante la CLI
o PowerShell. Casi todos los comandos de este capítulo se escriben en PowerShell. Sin
embargo, al final de este capítulo, encontrará el comando equivalente de la CLI de Azure
para cada comando de PowerShell. La lista de comandos es demasiado larga, por lo
que es mejor consultar la documentación oficial de Microsoft o utilizar los respectivos
comandos de ayuda.
En algunos casos, incluso en los próximos capítulos, utilizaremos Azure Portal. Esto es
para simplificar el proceso y presentar un método alternativo. Puede usar el portal si
lo prefiere, pero cuando se trata de automatizar tareas y orquestar la implementación,
tener experiencia con la CLI o PowerShell es un requisito previo. Por lo tanto, invitamos
a todos los lectores a seguir los comandos de PowerShell en este capítulo e invertir
tiempo en probar los comandos equivalentes con la CLI de Azure.
Estos son algunos de los requisitos técnicos para completar las tareas de este capítulo.
Requisitos técnicos | 99
Para este capítulo, se requieren conocimientos básicos de almacenamiento y redes.
En la sección Lectura adicional, puede encontrar algunas sugerencias para prepararse.
No es necesario, pero se recomienda tener al menos una VM en funcionamiento.
De esta manera, no solo podrá crear nuevos recursos en este capítulo, sino también
examinar las propiedades de una VM existente. En esta sección, crearemos una VM
de Ubuntu llamada ubuntu01 en el grupo de recursos chapter4 para los ejemplos.
Defina las variables para el grupo de recursos y la ubicación:
$myRG = "chapter4"
$myLocation = "westus"
$myTestVM = "ubuntu01"
Cree el grupo de recursos:
New-AzResourceGroup -Name $myRG -Location $myLocation
Cree la VM:
New-AzVm '
-ResourceGroupName $myRG '
-Name $myTestVM '
-ImageName UbuntuLTS '
-Location $myLocation '
-VirtualNetworkName "$myTestVM-Vnet" '
-SubnetName $myTestVM-Subnet '
-SecurityGroupName "$myTestVM-NSG" '
-PublicIpAddressName $myTestVM-pip
Por ahora, los parámetros utilizados en este ejemplo no son importantes. Al final de este
capítulo, podrá comprenderlos todos.
No es un requisito real, pero es conveniente tener la utilidad Explorador de Azure
Storage, que está disponible gratis en https://azure.microsoft.com/es-xl/features/
storage-explorer. Esta es una utilidad independiente para instalar en su estación de
trabajo. Esta utilidad le ayudará a cargar, descargar y administrar blobs, archivos, colas
y tablas de Azure. También es compatible con Azure Cosmos DB y Azure Data Lake.
Otra ventaja es que puede acceder a los discos conectados a las VM. El Explorador de
Storage también está disponible como una opción en Azure Portal.
Administración de los recursos de almacenamiento

La solución en la nube de Microsoft para manejar el almacenamiento de datos es Azure
Storage. Azure Storage ofrece alta disponibilidad, seguridad, escalabilidad y accesibilidad.
En Azure, tenemos diferentes tipos de datos o servicios de almacenamiento. Son
los siguientes:
• Blobs de Azure
• Azure Files
• Azure Queue
• Tabla de Azure
Analicemos de forma más detallada cada uno de estos servicios para comprender qué son:
• Blobs de Azure: objetos optimizados para almacenar cantidades masivas de datos
no estructurados, como texto o datos binarios. Con frecuencia se usan a fin de que
los datos estén disponibles para otros recursos, por ejemplo, con el objetivo de
almacenar archivos VHD que se pueden usar para crear discos virtuales. Otro caso
de uso es utilizarlos como almacenamiento para archivos de audio y video. Incluso
es posible hacer que un blob sea de acceso público para transmitir datos.
• Azure Files: Azure Files son recursos compartidos de archivos hospedados en
Azure a los que se puede acceder a través de un Bloque de mensajes del servidor
(SMB) y que se pueden montar en su equipo local. Es posible que se pregunte de
qué forma se diferencian de los recursos compartidos de archivos normales. Aquí
la ventaja adicional es que la URL que se generará incluirá una firma de acceso
compartido (SAS) y se podrá acceder al recurso compartido de archivos desde
cualquier parte del mundo.
• Azure Queue: se utiliza para transmitir mensajes de un recurso a otro, en especial,
para servicios sin servidor, como Azure Web Apps y Functions. También se puede
utilizar a fin de crear un trabajo pendiente para procesar de forma asincrónica.
• Tabla de Azure: esta es para el servicio Azure Cosmos DB.
• Azure Disk: este servicio es para almacenamiento de disco administrado y discos
no administrados.
Administración de los recursos de almacenamiento | 101
En este capítulo, solo trataremos el almacenamiento de blobs, Azure Files y el

almacenamiento en disco, porque el almacenamiento en Azure Queue y Tablas es para
soluciones específicas que solo son importantes para los desarrolladores de aplicaciones.
Nota
Si tiene una cantidad enorme de datos que desea almacenar en la nube, la carga
puede tardar mucho tiempo. Microsoft tiene un servicio llamado Azure Data Box
Disk, que le permite enviar SSD cifrados a su centro de datos, copiar los datos
y enviarlos de vuelta. Para obtener más información, visite https://docs.microsoft.
com/es-xl/azure/databox/data-box-disk-overview.
Cuentas de almacenamiento
Una cuenta de almacenamiento proporciona un espacio de nombre que es único en
Azure para contener objetos de almacenamiento, como blobs, archivos, tablas y colas,
entre otros. Se necesita una cuenta para acceder al almacenamiento. También define
el tipo de almacenamiento que se está utilizando.
Hay tres tipos diferentes de cuentas de almacenamiento:
• Storage: este tipo de almacenamiento antiguo y obsoleto no admite todas las
características (por ejemplo, no hay opción de archivo). A menudo, es más costoso
que el V2 más reciente.
• StorageV2: este es un tipo más reciente de cuenta de almacenamiento. Admite
todos los tipos de almacenamiento y las características más recientes para blobs,
archivos, colas y tablas.
• BlobStorage: este aún no está obsoleto, pero no hay ninguna razón para seguir
usándolo. El mayor problema con este tipo de cuenta es que no puede almacenar
archivos, como VHD.
Nota
No es necesario crear una cuenta de almacenamiento para los discos administrados.
Sin embargo, si desea almacenar datos de diagnóstico de arranque de VM,
necesitará una. Una cuenta de diagnóstico de arranque es muy útil si las VM se
colocan en un estado en que el arranque no es posible. Los registros almacenados
en esta cuenta se pueden usar para buscar la causa principal del estado de no
arranque de la VM. En el caso de las pruebas, esta no es una opción obligatoria, pero
para las cargas de trabajo de producción, se recomienda habilitar los diagnósticos
de arranque, lo que le ayudará a entender qué salió mal durante un error.
Otra propiedad es la SKU, como se trató en el Capítulo 2, Introducción a la nube de

Azure. Especifica qué tipo de replicación se aplica a la cuenta de almacenamiento.
Estos son los tipos disponibles y, como recordará, ya los analizamos:
• Standard_LRS: cuentas de almacenamiento con redundancia local
• Premium_LRS: similares a LRS, pero son compatibles con FileStorage
y BlockBlobStorage
• Standard_GRS: cuentas de almacenamiento con redundancia geográfica
• Standard_RAGRS: cuentas de almacenamiento con redundancia geográfica con
acceso de lectura
• Standard_ZRS: cuentas de almacenamiento con redundancia de zona
La última propiedad importante es el nivel de acceso. Este especifica la optimización del
almacenamiento. Existen tres tipos disponibles:
• Nivel de almacenamiento de acceso frecuente: los datos a los que se debe tener
acceso con frecuencia se almacenarán en el nivel de acceso frecuente.
• Nivel de almacenamiento de acceso esporádico: datos a los que se accede con
poca frecuencia y que se almacenan por, al menos, 30 días.
• Nivel de almacenamiento de archivo: datos a los que se accede con poca
frecuencia y que se almacenan por un período de, al menos, 180 días con
requisitos de latencia flexibles.
El establecimiento de un nivel de acceso de nivel de objeto solo es compatible con las
cuentas Standard LRS, GRS, RA-GRS BlobStorage y General Purpose V2. Las cuentas
General Purpose V1 (GPv1) no admiten la estratificación.
La elección del nivel de acceso también afecta al costo. Por ejemplo, el almacenamiento
de archivos ofrece los costos de almacenamiento más bajos, pero también los costos de
acceso más altos.
El nombre de la cuenta de almacenamiento debe tener una longitud de entre 3 y
24 caracteres, y solo usar números y letras minúsculas. Los nombres de las cuentas de
almacenamiento deben ser únicos en Azure. Microsoft sugiere utilizar un nombre único
global y un número aleatorio:
New-AzStorageAccount '
-ResourceGroupName <resource group> '
-SkuName <sku> '
-Location <location> '
-Kind StorageV2 '
-AccessTier <access tier> '
-name <storage account>
Creemos una cuenta de almacenamiento con redundancia como Standard_LRS:

$mySA = New-AzStorageAccount '
-SkuName Standard_LRS '
-Kind StorageV2 '
-AccessTier Hot '
-name chapter4$(Get-Random -Minimum 1001 -Maximum 9999)
Compruebe las cuentas de almacenamiento disponibles en su suscripción:

Get-AzStorageAccount | Select StorageAccountName, Location
Figura 4.1: Cuentas de almacenamiento disponibles
En la captura de pantalla, puede ver que hay tres cuentas de almacenamiento

disponibles en tres regiones diferentes para esta suscripción.
Las cuentas de almacenamiento están protegidas por claves. Necesitará la clave si desea
tener acceso a una cuenta de almacenamiento. Durante la creación de una cuenta, se
crea automáticamente un conjunto de dos claves. Si aún está en la misma sesión que
cuando creó la cuenta, puede recibir la clave:
$mySA | Get-AzStorageAccountKey | Format-Table -Wrap
De lo contrario, puede usar lo siguiente:

Get-AzStorageAccountKey '
-ResourceGroupName <resource group>'
-Name <storage account name>
En la siguiente captura de pantalla, la cuenta de almacenamiento chapter42298

disponible en el grupo de recursos $MyRG tiene un conjunto de claves protegidas:
Figura 4.2: Obtención de claves para la cuenta de almacenamiento chapter42298
Managed Disks
Antes, cuando implementábamos una VM, necesitábamos crear una cuenta de
almacenamiento donde pudiéramos guardar el disco duro virtual (VHD) de la VM.
Más tarde, Microsoft presentó Managed Disks donde simplemente podemos crear un
disco y Microsoft se ocupa de la cuenta de almacenamiento subyacente. Además de
eso, los clientes obtienen ventajas adicionales, como un redimensionamiento fácil, más
opciones de cifrado y un mejor rendimiento.
Cuando crea una VM con un disco administrado, se conectan dos discos a la VM: un
disco del SO y un disco temporal. Todos los discos están en formato VHD. Los datos
almacenados en el disco temporal se borrarán cuando se reinicie la VM, por lo que
Microsoft no recomienda almacenar datos importantes en el disco temporal, puesto
que no es persistente.
También puede agregar discos de datos administrados adicionales. En primer lugar,
cree la configuración del disco:
New-AzDiskConfig -Location <location>'
-DiskSizeGB <size> -OsType Linux -SkuName <sku> '
-CreateOption empty
Veamos cómo crear una configuración de disco de ejemplo con un tamaño de 5 GB
y una redundancia como Standard_LRS:
$diskconfig = New-AzDiskConfig -Location $myLocation '
-DiskSizeGB 5 -OsType Linux -SkuName Standard_LRS '
-CreateOption empty
Ahora, puede crear el disco real:
New-AzDisk -ResourceGroupName <resource group name> '
-DiskName <disk name> -Disk <disk configuration>
Por ejemplo, esta es una implementación del comando anterior:

$Disk01 = New-AzDisk -ResourceGroupName $myRG '
-DiskName 'Disk01' -Disk $diskconfig
Mediante la ejecución del comando $Disk01, verá el disco recién creado. En la siguiente
captura de pantalla, la salida está limitada para que sea más legible:
Figura 4.3: Salida del comando $Disk01
El siguiente paso es conectar el disco de datos administrado. Para ello, necesitaremos

el ID de disco. Por lo tanto, ejecutaremos el siguiente comando con el nombre del disco
para encontrar el ID:
Get-AzDisk -DiskName <disk name> | select Id
Agregue el disco de datos:

Add-AzVMDataDisk -VM $myVM -Name <disk name> '
-ManagedDiskId <disk id> -Lun <lun number> -CreateOption Attach
Un Número de unidad lógica (LUN) es un número que se utiliza para identificar el
almacenamiento en la VM. Puede comenzar la numeración desde cero. Por último,
actualice la configuración de la VM:
Update-AzVM '
-ResourceGroupName <resource group> '
-VM <virtual machine>
Ahora puede agregar el disco de datos a la VM. Para resumir con un ejemplo completo,
primero necesitará todas las propiedades de la VM. A fin de obtener las propiedades
de la VM, usaremos el siguiente comando y guardaremos las propiedades en una
variable, $myVM:
$myVM = Get-AzVM -ResourceGroupName $myRG -Name $myTestVM
El siguiente comando es para agregar el disco que se creó antes a la VM:

Add-AzVMDataDisk -VM $myVM -Name Disk01 '
-ManagedDiskId $Disk01.Id -Lun 1 -CreateOption Attach
El comando anterior le mostrará las propiedades configuradas de la VM, como se

muestra en esta captura de pantalla:
Figura 4.4: Adición del disco creado en la VM
Como podemos ver en la salida, la información se agrega a StorageProfile, pero el

cambio aún no está activo.
Para activarlo, use Update-AzVM. La salida debería darle el StatusCode como OK:
Update-AzVM -ResourceGroupName $myRG -VM $myVM
Como puede ver en la siguiente captura de pantalla, IsSuccessStatusCode le indica que

se recibió la solicitud. StatusCode es el resultado de la solicitud:
Figura 4.5: Uso del comando Update-AzVM para actualizar StatusCode
Compruebe el resultado:
$myVM.StorageProfile.DataDisks
O, lo que es incluso mejor, en lugar de reutilizar las variables, solo consulte toda la
información en una sola línea:
$(Get-AzVM -Name $myTestVM '
-ResourceGroupName $myRG).StorageProfile.DataDisks
Puede ver el nombre, el tamaño y el LUN:
Figura 4.6: Perfil de almacenamiento de disco
Azure Files
En lugar de agregar discos de datos a una VM, puede usar Azure Files. Si lo recuerda,
hablamos de Azure Files al principio de este capítulo y mencionamos que es diferente
de un recurso compartido de archivos normal. Azure Files es un recurso compartido de
archivos en la nube completamente administrado, al que se puede acceder a través del
Bloque de mensajes del servidor (SMB) y se puede montar en Linux, Windows y macOS.
Azure Files necesita una cuenta de almacenamiento y admite tipos de SKU de
Standard_LRS, Standard_ZRS, Standard_GRS y Standard_ZRS (solo en regiones
seleccionadas). No hay almacenamiento premium ni otros niveles de acceso distintos del
estándar (activo) disponible. (En el momento de escribir este libro, fuentes de Microsoft
afirman que no hay un plazo disponible para la introducción de estas características).
Tenga en cuenta que realmente requerirá el protocolo SMB 3.0 por motivos de
rendimiento. Esto significa que necesita una distribución de Linux reciente, como una
de estas que se mencionan aquí:
• Distribuciones basadas en RHEL 7.5 o superior
• Ubuntu 16.04 o superior
• Debian 9
• SUSE SLE 12 SP3/OpenSUSE LEAP 42.3 o superior
También debe forzar la versión 3 con la opción de montaje: vers=3.0.

El primer paso consiste en crear el recurso compartido de Azure Files:
New-AzStorageShare '
-Name <share name> -Context <storage account context>
Para el contexto de la cuenta de almacenamiento, puede usar la variable que se usó a fin
de crear la cuenta de almacenamiento o volver a crear la variable:
$mySA = (Get-AzStorageAccount | Where-Object {$_.StorageAccountName -Like
"chapter*"})
Implementemos esto y creemos un nuevo recurso compartido de archivos:

$myShare01 = New-AzStorageShare '
-Name "myshare01-staff" -Context $mySA.Context
Revisemos el valor de $myShare01. La salida muestra claramente la dirección URL del
almacenamiento, cuándo lo creó y si hay instantáneas disponibles o no:
Figura 4.7: Salida de myShare01
Para revisar las propiedades del recurso compartido creado, ejecute el siguiente comando:
(Get-AzStorageShare -Context $mySA.Context).Uri
Como puede ver en la siguiente captura de pantalla, obtendrá la misma salida con un
poco más de información, lo que no es importante en absoluto para nuestros propósitos:
Figura 4.8: Propiedades del recurso compartido creado
En Linux, puede montar el recurso compartido de archivos de forma manual con el

siguiente código:
mount -t cifs \
-o vers=3.0,username=<storage account>,password=<storage key>\
//<storage account name>.file.core.windows.net/<share> \
/<mount point>
Tenga en cuenta que no estamos usando el esquema de HTTPS porque CIFS no usa URI.
Azure se encargará de la asignación entre los diferentes esquemas.
Continuemos y montemos el recurso compartido de archivos. Su contraseña y recurso
compartido de archivos de almacenamiento serán diferentes del ejemplo, puesto que el
nombre es único en Azure:
mkdir /mnt/staff

mount -t cifs -o vers=3.0,username=chapter42585,password=.... \
//chapter42585.file.core.windows.net/myshare-01.staff /mnt/staff
Además, puede usar la opción de conexión en Azure Portal (https://portal.azure.com/)

para el recurso compartido de archivos y Azure generará los comandos para montar el
recurso compartido en Linux, además de los sistemas de Windows y macOS.
En la siguiente captura de pantalla, puede ver que cuando se hace clic en Conectar,
Azure genera el código para conectar el recurso compartido de archivos al sistema
Linux. Puede copiar este código y pegarlo en su sistema Linux:
Figura 4.9: Conexión del recurso compartido de archivos al sistema Linux
Se encuentra disponible más información sobre cómo montar recursos compartidos

con Azure Files en el Capítulo 5, Administración avanzada de Linux, en la sección
Montaje de sistemas de archivos remotos. El siguiente es un ejemplo de una unidad
de montaje para Azure Files:
[Unit]
Description = Staff Share
[Mount]
What = //chapter42585.file.core.windows.net/myshare-01.staff
Where = /mnt/staff
Type = cifs
Options = vers=3.0,credentials=/root/.staff
Aquí el archivo /root/.staffs contiene las siguientes entradas:

username=<storage account>
password=<key>
Otra excelente manera de comprobar el recurso compartido y administrar el contenido

es con el Explorador de Azure Storage. Inicie el Explorador de Azure Storage en su
estación de trabajo y conecte su cuenta de Azure. Si no desea agregar toda la cuenta,
también tiene la opción de agregar solo la cuenta de almacenamiento mediante la
clave de SAS. El Explorador de Storage mostrará diferentes tipos de recursos en el lado
izquierdo, como se muestra en esta captura de pantalla:
Figura 4.10: Explorador de Azure Storage
Blob de Azure
El almacenamiento en Blob de Azure es un servicio de almacenamiento que almacena
datos no estructurados (imágenes, video, audio, datos de copia de seguridad, entre
otros, que no adhieren a un modelo de datos) en la nube como objetos. Blob es un
almacenamiento basado en objetos que puede almacenar cualquier tipo de datos.
Dentro de una cuenta de almacenamiento, puede tener contenedores. Los
contenedores son muy similares a los directorios o carpetas de su equipo. Por ejemplo,
si almacena sus archivos de música favoritos en Azure, puede establecer el nombre
de la cuenta como Música y, dentro de ella, puede crear un contenedor basado en
el género o los artistas, y los archivos de música reales son los blobs. Una cuenta de
almacenamiento puede tener un número ilimitado de contenedores y un contenedor
puede tener un número ilimitado de blobs.
Los recursos compartidos de archivos de Azure son una excelente forma de mantener
sus datos fuera de una VM. Pero se basan en archivos, y esa no es la opción más rápida
para cada tipo de datos. Por ejemplo, la transmisión desde Azure Files, si bien es
posible, no funciona muy bien. Cargar archivos muy grandes también puede ser muy
difícil. El almacenamiento en blob es una solución para este problema y escala mucho
mejor: 5 TB para un recurso compartido de archivos de Azure y 500 TB para un solo
contenedor de blobs.
Para poder cargar un blob, primero debe crear un contenedor:
New-AzStorageContainer -Name <container name> '
-Context <context of storage account> -Permission blob
Este es un ejemplo de cómo crear una lista de contenedores:
$myContainer = New-AzStorageContainer '
-Name container01 '
-Context $mySA.context -Permission blob
Figura 4.11: Creación de una lista de contenedores
Existen tres tipos de permisos disponibles cuando se crea un contenedor:

• Container: proporciona acceso de lectura completo a un contenedor y sus blobs.
Los clientes pueden enumerar blobs en el contenedor a través de solicitudes
anónimas. Otros contenedores no son visibles.
• Blob: proporciona acceso de lectura a los datos del blob en un contenedor a través
de solicitudes anónimas, pero no proporciona acceso a los datos del contenedor.
Otros blobs no son visibles.
• Off: restringe el acceso solo al propietario de la cuenta de almacenamiento.
Puede volver a usar el Explorador de Azure Storage para ver el contenedor:
Figura 4.12: Visualización del contenedor con el Explorador de Azure Storage
Con PowerShell, puede crear un blob:

Set-AzStorageBlobContent -File <filename> '
-Container <container> -Blob <blobname> '
-Context $mySA.context
Puede comprobar el resultado con el siguiente comando:
Get-AzStorageBlob -Container <container name> '
-Context $mySA.context | select Name
Ahora puede cargar un archivo en el contenedor y convertirlo en un blob, por ejemplo:

Set-AzStorageBlobContent -File "/Pictures/image.jpg" '
-Container $myContainer.Name ' -Blob "Image1.jpg" '
-Context $mySA.context
También puede mostrar el resultado:
Get-AzStorageBlob -Container <container> '
-Context $mySA.context | select Name
Todas estas operaciones también se pueden realizar desde Bash.
Puede montar el blob desde el vínculo de referencia de Blobfuse de Linux con Blobfuse.
Para obtener más información, visite https://github.com/Azure/azure-storage-fuse
y https://docs.microsoft.com/es-xl/azure/storage/blobs/storage-how-to-mount-
container-linux.
Una solución alternativa para copiar datos en un blob es AzCopy (encontrará más
información disponible sobre esta alternativa en https://docs.microsoft.com/es-xl/
azure/storage/common/storage-use-azcopy-linux).
Pero, francamente, la mayoría de las veces, esta no es la forma en que usará el
almacenamiento de blobs. El almacenamiento de blobs no es algo a lo que desea
tener acceso en el nivel de un sistema operativo, sino en el nivel de la aplicación,
para almacenar objetos, por ejemplo, imágenes, y hacer que estén disponibles
públicamente. Microsoft proporciona excelentes ejemplos para comenzar a utilizarlo
en https://github.com/Azure-Samples?q=storage-blobs.
En el Capítulo 7, Implementación de la máquina virtual, hay un buen ejemplo de una
excepción: cargar un archivo VHD para crear una imagen personalizada con ese VHD.
Administración de recursos de red

Como se analizó antes, en el Capítulo 3, Administración básica de Linux, las redes
son muy importantes. Azure Virtual Network es un servicio de Azure que proporciona
lo siguiente:
• Conectividad para la carga de trabajo
• Conectividad de su carga de trabajo al mundo exterior
• Conectividad entre VM
• Otras opciones de conectividad, como los túneles VPN
• Filtrado de tráfico
• Opciones de enrutamiento avanzadas, incluidas rutas BGP a través de un túnel VPN
Administración de recursos de red | 115
Red virtual
En Azure, el componente más importante de las redes virtuales es la red virtual o VNet
para abreviar. Una red virtual es crucial, puesto que proporciona un entorno aislado
altamente seguro para que sus VM se ejecuten.
El siguiente proceso podría parecer un poco confuso y extenso, pero la intención aquí
es hacer que entienda el proceso y los comandos. Comencemos con la creación de una
red virtual:
AzVirtualNetwork -Name <vnet name> '
-ResourceGroupName <resource group> -Location <location>'
-AddressPrefix <network>
Entonces, si quisiéramos crear una red virtual con el nombre MyVirtualNetwork y el
espacio de direcciones 10.0.0.0/16, usaríamos lo siguiente:
$myVnet = New-AzVirtualNetwork -Name MyVirtualNetwork '
-ResourceGroupName $myRG -Location $myLocation '
-AddressPrefix "10.0.0.0/16"
La ejecución de la variable que acaba de crear le mostrará todas las propiedades:
Figura 4.13: Propiedades de la red virtual
El AddressSpace o la dirección es la red que una o más subredes pueden usar. Es posible
agregar espacios de direcciones adicionales.
Subredes
Como ya se indicó, una subred se crea en una red virtual. Todo el tráfico entre
diferentes subredes en la misma red se enruta en Azure para que las subredes puedan
comunicarse entre sí. Por supuesto, puede modificar ese comportamiento, por ejemplo,
cuando desee utilizar un equilibrador de carga.
Una vez más, tomaremos el comando más simple posible por la misma razón que para
las redes virtuales:
Add-AzVirtualNetworkSubnetConfig '
-AddressPrefix <subnet> -Name <subnet> '
-VirtualNetwork <vnet>
Para crear una subred con el nombre MySubnet con el grupo de direcciones 10.0.1.0/24,
ejecute el siguiente comando:
$mySubnet = Add-AzVirtualNetworkSubnetConfig '
-AddressPrefix 10.0.1.0/24 -Name MySubnet '
-VirtualNetwork $myVnet
Nota
Es posible que reciba una advertencia de que algunos objetos están obsoletos.
Puede pasarla por alto de forma segura.
Si ejecuta $mysubnet, verá que se agregó la subred:
Figura 4.14: Detalles de la subred
Como puede ver en la captura de pantalla anterior, no usamos la red completa, solo una
parte de ella.
Como alternativa, la comprobación se puede realizar con el siguiente comando:
Get-AzVirtualNetworkSubnetConfig '
-VirtualNetwork $myVnet -Name MySubnet
La salida será exactamente la misma que la captura de pantalla anterior.
La primera dirección IP de la subred es el gateway para el tráfico de red procedente de
la VM. Proporciona lo siguiente:
• Un gateway predeterminado, con Traducción de direcciones de red de origen
(SNAT) para obtener acceso a Internet. Para poder hacerlo, se debe configurar
una dirección IP pública. SNAT le permite enviar el tráfico generado desde su VM
(o cualquier recurso) en la red privada a Internet a través del gateway.
• El servidor DNS, si no está configurado de otro modo.
• El servidor DHCP.
La última parte de la configuración de la red virtual implica conectar la subred recién

creada:
Set-AzVirtualNetwork -VirtualNetwork $myVnet
En la salida, entre otra información, puede ver el espacio de direcciones y la subred en

que se encuentra:
Figura 4.15: Conexión de la subred recién creada
Grupo de seguridad de red

El grupo de seguridad de red (NSG) es el siguiente componente del que tenemos
que ocuparnos. Se trata esencialmente de listas de control de acceso asociadas a una
subred. También proporciona reenvío de puertos a las VM o los contenedores. Las
reglas se aplican a todas las interfaces que están conectadas a la subred.
El primer paso es crear un NSG:

New-AzNetworkSecurityGroup '
-ResourceGroupName <resource group>'
-Location <location> -Name <nsg name>
Por ejemplo, puede crear un NSG de esta manera:
$myNSG = New-AzNetworkSecurityGroup '
-ResourceGroupName $myRG -Location $myLocation -Name myNSG1
En la salida extensa, encontrará varias acciones. Una de las secciones se llama Default
Security Rules (Reglas de seguridad predeterminadas). Esta sección contiene un
conjunto de reglas, que se indican en orden de prioridad:
• Permitir tráfico entrante desde todas las VM en la red virtual (AllowVnetInBound)
• Permitir tráfico entrante de Azure Load Balancer (AllowAzureLoadBalancerInBound)
• Denegar todo el tráfico entrante (DenyAllInBound)
• Permitir el tráfico saliente de todas las VM a todas las VM de la red virtual
(Allowvnetoutbound)
• Permitir el tráfico saliente de todas las VM a Internet (AllowInternetOutBound)
• Denegar todo el tráfico saliente (DenyAllOutBound)
Antes de abordar las reglas, asociemos la subred con el NSG:

Set-AzVirtualNetworkSubnetConfig -Name <subnet name> '
-VirtualNetwork <vnet> -NetworkSecurityGroupID <nsg id> '
-AddressPrefix <subnet>
Por ejemplo, esta es una implementación del comando anterior:
$NSGSubnet = Set-AzVirtualNetworkSubnetConfig '
-Name $myVnet.Subnets.Name '
-VirtualNetwork $myVnet '
-NetworkSecurityGroupID $myNSG.Id '
-AddressPrefix 10.0.1.0/24
Es posible que reciba las mismas advertencias de obsolescencia que vio antes. Puede
pasarlas por alto de nuevo. Conecte el NSG a la red:
$NSGSubnet | Set-AzVirtualNetwork
La salida de este comando estará en JSON y es larga debido a todos los parámetros.
Si observa la salida, verá que NetworkSecurityGroup se menciona como myNSG1, que es
el NSG que creamos:
Figura 4.16: NSG conectado a la red
Si queremos tener acceso a nuestra VM mediante SSH, entonces, necesitamos agregar

una regla de seguridad:
$myNSG | Add-AzNetworkSecurityRuleConfig -Name SSH '
-Description "Allow SSH" '
-Access Allow -Protocol Tcp -Direction Inbound '
-Priority 100 '
-SourceAddressPrefix Internet -SourcePortRange * '
-DestinationAddressPrefix * '
-DestinationPortRange 22 | Set-AzNetworkSecurityGroup
El parámetro -SourceAddressPrefix es una especie de abreviatura para todo lo que esté

fuera de la red virtual y que sea accesible a través de la Internet pública. Otros valores
son los siguientes:
• VirtualNetwork: todo lo que está dentro de esta red virtual y otras redes conectadas.
• AzureLoadBalancer: si utiliza Azure Load Balancer, esta opción proporciona acceso
a sus VM.
• *: todo.
Priority (Prioridad) de 100 a 4096. Azure crea números más altos y se pueden anular.
Cuanto menor sea el número de prioridad, mayor será la prioridad de la regla.
La salida del comando anterior puede tener demasiada información, lo que es un poco
confuso de interpretar. Para confirmar si se permite el tráfico del puerto 22, filtraremos
la salida con el siguiente comando:
$myNSG | select SecurityRules
$myNSG.SecurityRules
La salida, como se muestra en la siguiente captura de pantalla, comprueba que el puerto
TCP 22 esté abierto para el tráfico entrante. Este puerto tiene una prioridad de 100,
pero dado que es la única regla, eso no importa:
Figura 4.17: Enumeración de las reglas de seguridad establecidas para el NSG
Opcionalmente, puede usar el siguiente comando:

$myNSG | Get-AzNetworkSecurityRuleConfig
Como puede ver, la salida es la misma.

Dirección IP pública e interfaz de red

Para poder tener acceso a la VM desde Internet, se necesita una dirección IP pública
junto con una etiqueta DNS, que es el nombre DNS que se da a nuestra VM.
La IP pública puede ser estática o dinámica. En el caso de una IP pública dinámica,
cada vez que desasigne y reinicie la VM, la IP se liberará y se desasociará de la VM. La
próxima vez que inicie la VM, se asociará a ella una nueva IP pública. Por lo tanto, cada
vez que desasigne y reinicie la VM, debe comprobar la IP pública desde la CLI o el portal
para conectarse a la VM.
Aquí viene la parte importante sobre la etiqueta DNS: si ya agregó una etiqueta DNS
a su VM, siempre puede usarla para conectarse a la VM, independientemente de la IP
pública que tenga la VM. La etiqueta DNS no cambia cuando se desasigna y reinicia la
VM. Además, la etiqueta DNS es única en Azure.
En el caso de una IP pública estática, la IP se reservará para usted. Aunque desasigne
y, luego, reinicie la VM, la IP no cambiará. Tener una IP estática asignada a la VM no le
impide agregar una etiqueta DNS. Si es necesario, también puede agregar la etiqueta.
Cree una nueva IP pública dinámica con el siguiente comando:
$pip = New-AzPublicIpAddress '
-Location $myLocation -AllocationMethod Dynamic '
-Name "$(Get-Random)"
Para comprobarla vea el contenido de la variable $pip. Si el método de asignación es

Dynamic (Dinámica), la dirección IP no se asigna hasta que la dirección IP se asigne a una
interfaz de red:
Figura 4.18: Comprobación de la nueva IP pública dinámica
Por lo tanto, es por eso que en la captura de pantalla anterior el campo IpAddress dice
Not Assigned (No asignada).
Para crear la interfaz de red, use el siguiente comando:
$nic = New-AzNetworkInterface -Name myNic '
-ResourceGroupName $myRG -Location $myLocation '
-SubnetId $myVnet.Subnets[0].Id -PublicIpAddressId $pip.Id '
-NetworkSecurityGroupId $myNSG.Id
Si recibe un error en SubnetId, vuelva a intentar establecer la variable myVnet y ejecute el

siguiente comando:
$myVnet = Get-AzVirtualNetwork -Name $myVnet.Name '
-ResourceGroupName $myRG
Para comprobar el resultado, ejecute el siguiente comando:
$nic.ipConfigurations
Figura 4.19: Comprobación de la dirección IP asignada a la interfaz de red
En la salida, como puede ver en la captura de pantalla anterior, se asigna una dirección
IP, que esta vez es 10.0.1.4.
Administración de recursos de proceso | 125
Administración de recursos de proceso

Resumamos los componentes abordados en este capítulo que necesita como requisito,
antes de poder implementar una VM. En el caso de la cuenta de almacenamiento, este
no es un requisito real, pero ¿desea trabajar sin poder recibir diagnósticos de arranque
en tiempos difíciles? Como se mencionó anteriormente, una cuenta de diagnóstico
de arranque es muy útil si las VM entran en un estado de no arranque. Los registros
almacenados en esta cuenta se pueden usar a fin de buscar la causa principal del estado
de no arranque de la VM. En el caso de las pruebas, esta no es una opción obligatoria,
pero para las cargas de trabajo de producción, se recomienda habilitar los diagnósticos
de arranque, lo que le ayudará a comprender qué salió mal durante un error.
Nota
Azure Container Service y Azure Kubernetes Service también usan todos los
recursos que se mencionan aquí.
Si lo recuerda, en la sección Requisitos técnicos, analizamos el código de PowerShell

para crear una nueva VM, donde la mayoría de las variables no se definieron. Aquí está
el código nuevamente:
New-AzVm '
-Name $myTestVM '
-ImageName UbuntuLTS '
-VirtualNetworkName "$myTestVM-Vnet" '
-SubnetName $myTestVM-Subnet '
-SecurityGroupName "$myTestVM-NSG" '
-PublicIpAddressName $myTestVM-pip
Ahora, espero que pueda comprender lo que significa cada uno de estos parámetros y
de qué forma son cruciales para su VM.
Recursos de máquina virtual

En esta sección, proporcionaremos algunas tablas con los componentes necesarios y los
comandos correspondientes en PowerShell y Bash. Se pueden usar junto con la ayuda
disponible en PowerShell (help <cmdlet>), la CLI de Azure (agregue el parámetro --help
al comando) o la documentación en línea de Azure.
Perfil de Azure
El perfil de Azure incluye la configuración necesaria para describir su entorno de Azure:
Figura 4.20: Comandos de configuración del perfil de Azure
Grupo de recursos
El grupo de recursos se necesita para contener y administrar recursos:
Figura 4.21: Comandos de grupo de recursos de Azure
Cuenta de almacenamiento
La cuenta de almacenamiento se necesita si desea almacenar datos fuera de su VM/
contenedor:
Figura 4.22: Comandos de la cuenta de almacenamiento de Azure

Recursos de máquina virtual | 127
Redes virtuales
La red virtual se necesita para la comunicación entre VM/contenedores y la
comunicación con el mundo exterior:
Figura 4.23: Comandos de la red virtual de Azure
Grupo de seguridad de red

El NSG consta de listas de control de acceso (ACL) para proteger sus cargas de trabajo
y permitir el acceso donde sea necesario. Junto con la dirección IP pública, también se
necesita para el reenvío de puertos a la VM y el contenedor:
Figura 4.24: Comandos de NSG para Azure

Dirección IP pública e interfaz de red

La dirección IP pública proporciona acceso desde el mundo exterior a la VM y el
contenedor. Se necesita para la Traducción de direcciones de puertos (PAT) y SNAT:
Figura 4.25: Comandos de interfaz de red y dirección IP pública de Azure
Resumen
Con el conocimiento adquirido en este capítulo, ahora debería comprender mejor los
elementos que encontró en el Capítulo 2, Introducción a la nube de Azure.
En este capítulo, exploramos todos los componentes de Azure que se necesitan antes
de que pueda crear su carga de trabajo en Azure:
• Necesitará una cuenta de almacenamiento para la extensión de diagnóstico de
arranque de la VM.
• Se recomienda tener una cuenta de almacenamiento para almacenar datos fuera
de la VM.
• Los componentes de red son necesarios para poder comunicarse con la VM, habilitar
la comunicación entre sus máquinas y para que la VM pueda conectarse a Internet.
Los pasos que hemos analizado hasta ahora le serán muy útiles para que comprenda los
componentes relacionados con las VM y también cómo se implementa cada uno de esos
componentes en Azure. Comenzamos con las soluciones de almacenamiento de Azure
y, luego, abordamos también las redes. Esperamos que esto le haya dado una idea de
cómo estos componentes se unen para proporcionar la prestación de servicios.
En el próximo capítulo, utilizaremos el conocimiento que obtuvimos en este capítulo
para identificar y configurar los componentes de red y almacenamiento en el sistema
operativo Linux. Además de los temas de red y almacenamiento, exploraremos otras
tareas de administración del sistema, como la administración de software y servicios.
Preguntas | 129
Preguntas
1. ¿Qué recursos se requieren antes de que pueda crear la VM?
2. ¿Qué recursos se recomiendan para una VM?
3. En los ejemplos, se usó varias veces un generador de números aleatorios, ¿por qué?
4. ¿Cuál es el propósito del AddressPrefix en una red?
5. ¿Cuál es el propósito del AddressPrefix en una subred?
6. ¿Cuál es el propósito del NSG?
7. ¿Por qué se necesita la dirección IP pública para comunicarse con el mundo exterior?
8. ¿Cuál es la diferencia entre una dirección IP pública estática y una asignada
dinámicamente?
Lectura adicional
El libro Implementación de soluciones de infraestructura de Microsoft Azure de Microsoft
Press está concebido como una guía de referencia de estudio para el examen 70-533.
Aunque el examen está obsoleto, el contenido sigue siendo una excelente referencia.
Explica cada parte de la infraestructura de Azure en detalle, mediante Azure Portal y las
interfaces de línea de comandos.
Si es la primera vez que trabaja con redes, otro libro recomendado, que también está
escrito como guía de estudio para un examen, es la Comptia Network+ Certification
Guide (Guía de certificación de Comptia Network+) de Glen D. Singh y Rishi
Latchmepersad.
Mucho más antiguo y difícil de leer es el libro TCP/IP Redbook de IBM, disponible
de forma gratuita, (https://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf).
Abarca mucho más de lo que necesita saber, pero si le interesa el tema es una lectura
obligatoria. Incluso si no le interesa rendir el examen Cisco ICND1, Neil Anderson grabó
un video en https://www.packtpub.com, que, además de la parte que trata de Cisco,
proporciona una excelente introducción a las redes.
Nota
Tenga en cuenta que el entorno de Azure está cambiando continuamente, en
especial, en lo que se refiere al almacenamiento y las redes. Es importante
validar las fuentes con la documentación disponible en el sitio web de Microsoft.
Probablemente, lo primero que debería revisar es la fecha de publicación.
Administración
5
avanzada de Linux
En el Capítulo 3, Administración básica de Linux, se analizaron algunos comandos
básicos de Linux y aprendió a hallar su camino en el entorno de Linux. Después,
en el Capítulo 4, Administración de Azure, profundizamos en la arquitectura de Azure.
Con el conocimiento obtenido a partir de ambos capítulos, estamos listos para
continuar nuestro viaje en Linux. Vamos a explorar los siguientes temas:
• Administración de software, donde veremos cómo se pueden agregar nuevos
paquetes a una máquina Linux y cómo actualizar los existentes.
• Administración del almacenamiento. En el capítulo anterior, analizamos cómo
conectar discos de datos a la máquina virtual(VM) de Azure, pero ahora
analizaremos la administración de estos discos en Linux.
• Administración de redes. Anteriormente, hablamos sobre cómo agregar una tarjeta
de interfaz de red (NIC) a una VM y cómo se administran los recursos de red en
Azure. En este capítulo, analizaremos cómo se administran estos recursos en Linux.
• Administración del sistema, donde analizaremos cómo administrar los servicios
y los elementos esenciales del sistema.
132 | Administración avanzada de Linux
Para el propósito de este capítulo, tendrá que implementar una VM de Linux en Azure,
con la distribución de su elección.
En términos de tamaño, necesitará al menos 2 GB de almacenamiento temporal y la
capacidad de agregar un mínimo de tres discos adicionales. Por ejemplo, el tamaño de
VM B2S es un buen punto de partida. En este capítulo, compartí los pasos para sistemas
Ubuntu, Red Hat y SUSE, por lo que puede elegir qué distribución seguir.
Administración de software
En cualquier sistema operativo, es necesario instalar algún software que nos ayude
a hacer el trabajo diario. Por ejemplo, si está escribiendo scripts, es posible que el software
o la aplicación de existencias que se incluye con el sistema operativo no sean suficientes.
En ese caso, instalar software como Visual Studio Code le facilitará el trabajo. Del mismo
modo, en un entorno corporativo, es posible que deba agregar un nuevo software o
incluso actualizar el software existente para satisfacer sus requisitos empresariales.
En los viejos tiempos, instalar software era cuestión de extraer un archivo a un sistema
de archivos. Sin embargo, hubo varios problemas asociados con este enfoque:
• Era difícil quitar el software si los archivos se copiaban en directorios que también
usaba otro software.
• Era difícil actualizar el software; tal vez los archivos todavía estaban en uso o se les
había cambiado el nombre por cualquier motivo.
• Era difícil manejar bibliotecas compartidas.
Es por eso que las distribuciones de Linux inventaron los administradores de software. Con
estos administradores de software, es posible instalar los paquetes y las aplicaciones que
necesitamos para completar nuestras tareas. Estos son algunos administradores de software:
• RPM
• YUM
• DNF
• DPKG
• APT
• ZYpp
Examinemos más de cerca cada uno de estos para entender cómo se pueden usar para
administrar el software en su sistema Linux.
Administración de software | 133
El administrador de software RPM

En 1997, Red Hat lanzó la primera versión de su administrador de paquetes, RPM. Otras
distribuciones, como SUSE, adoptaron este administrador de paquetes. RPM es el nombre
de la utilidad rpm, así como también del formato y la extensión de nombre de archivo.
El paquete RPM contiene lo siguiente:
• Un archivo CPIO (Copia de entrada, copia de salida) de archivos de configuración
y binarios empaquetados. CPIO es una utilidad que se utiliza para combinar varios
archivos y crear un archivo.
• Metadatos con información sobre el software, como una descripción y dependencias.
• Scriptlets para scripts previos y posteriores a la instalación.
En el pasado, los administradores de Linux usaban la utilidad rpm para instalar,

actualizar y quitar software de un sistema Linux. Si hubiera una dependencia, el
comando rpm podría indicarle exactamente qué otros paquetes necesitaría instalar.
La utilidad rpm no puede corregir dependencias ni posibles conflictos entre paquetes.
Actualmente, la utilidad rpm ya no se usa para instalar ni quitar software, aun cuando
todavía está disponible. En su lugar, usamos instaladores de software más avanzados.
Después de la instalación de software con yum (en Red Hat/CentOS) o zypper (en SUSE),
todos los metadatos van a una base de datos. Consultar esta base de datos de rpm con el
comando rpm puede resultar muy útil.
La siguiente es una lista de los parámetros de consulta rpm más comunes:
Figura 5.1: Parámetros de consulta rpm comunes

La siguiente captura de pantalla es un ejemplo de cómo obtener información sobre el

paquete de servidor SSH instalado:
Figura 5.2: Información sobre el paquete de servidor SSH
La salida del parámetro -V nos puede informar sobre los cambios que se realizan en el
software instalado. Hagamos un cambio en el archivo sshd_config:
sudo cp /etc/ssh/sshd_config /tmp
sudo sed -i 's/#Port 22/Port 22/' /etc/ssh/sshd_config

Si comprueba el paquete instalado, se agregó una S y una T a la salida, lo que indica que
la marca de tiempo cambió y el tamaño del archivo es distinto:
Figura 5.3: Las letras S y T indican un cambio en la marca de tiempo y en el tamaño del archivo
Otros posibles caracteres en la salida son los siguientes:
Figura 5.4: Posibles caracteres en la salida y su descripción
En el caso de los archivos de texto, el comando diff puede ayudar a mostrar las
diferencias entre la copia de seguridad que se encuentra en el directorio /tmp y la
configuración en el directorio /etc/ssh:
sudo diff /etc/ssh/sshd_config /tmp/sshd_config
Restaure el archivo original de la siguiente manera:

sudo cp /tmp/sshd_config /etc/ssh/sshd_config
Administración de software con YUM

Yellowdog Updater Modified (YUM) es una moderna herramienta de administración
de software que Red Hat introdujo en la versión 5 de Enterprise Linux y que reemplazó
a la utilidad up2date. Actualmente se usa en todas las distribuciones basadas en Red
Hat, pero se reemplazará por dnf, que es la que usa Fedora. La buena noticia es que la
sintaxis de dnf es compatible con yum.
YUM es responsable de lo siguiente:
• Instalar software, incluidas las dependencias
• Actualizar software
• Quitar software
• Enumerar y buscar software
Los parámetros básicos importantes son los siguientes:
Figura 5.5: Parámetros básicos de YUM
También puede instalar patrones de software; por ejemplo, el grupo o patrón Servidor
de archivo e impresión es una forma muy conveniente de instalar los servidores
de archivos Samba y el Recurso compartido de red (NFS) junto con el servidor de
impresión Cups en lugar de instalar uno a uno los paquetes:
Figura 5.6: Comandos del grupo YUM y su descripción
Otra buena característica de yum es que trabaja con el historial:
Figura 5.7: Comandos del historial de YUM y su descripción

El comando yum usa repositorios para poder realizar toda la administración de software.
Para enumerar los repositorios actualmente configurados, use el siguiente comando:
yum repolist
Para agregar otro repositorio, necesitará la herramienta yum-config-manager, que crea

y modifica los archivos de configuración en /etc/yum.repos.d. Por ejemplo, si desea
agregar un repositorio para instalar Microsoft SQL Server, use el siguiente comando:
yum-config-manager --add-repo \
https://packages.microsoft.com/config/rhel/7/\
mssql-server-2017.repo
La funcionalidad yum se puede extender con complementos, por ejemplo, para
seleccionar el reflejo más rápido, lo que habilita las instantáneas / LVM del sistema
de archivos y permite ejecutar yum como tarea programada (cron).
Administración de software con DNF

En Red Hat Enterprise Linux 8 y todas las distribuciones basadas en esta distribución
y también en Fedora, DNF reemplaza el comando yum. La sintaxis es la misma, por
lo que solo tiene que reemplazar tres caracteres. En lo que respecta al comando
yum-config-manager, se reemplaza por dnf config-manager.
En lugar de una utilidad independiente, se integra con el comando dnf mismo.
También hay una nueva funcionalidad. RHEL 8 incluye modularidad de software,
también conocida como AppStreams. Como concepto de empaquetado, permite
a los administradores del sistema seleccionar la versión de software deseada de
varias versiones disponibles. Por cierto, es posible que en este momento solo haya una
versión disponible, pero pronto aparecerán versiones nuevas. Por ejemplo, uno de los
AppStreams disponibles es el intérprete de programación de Ruby. Echémosle un
vistazo al módulo:
sudo dnf module list ruby
Figura 5.8: Módulo de interpretación de programación de Ruby

En la salida anterior, puede observar que en el momento de escribir este libro, solo está
disponible la versión 2.5. Se agregarán más versiones más adelante. Esta es la versión
predeterminada, pero no está habilitada ni está instalada.
Ejecute estos comandos para habilitar e instalar AppStreams:
sudo dnf module enable ruby:2.5
sudo dnf module install ruby
Si vuelve a enumerar AppStreams, se modifica la salida:
Figura 5.9: Ruby 2.5 instalado y habilitado
Sugerencia: Para saber qué paquetes instala AppStreams, puede usar el siguiente comando:
sudo dnf module info ruby
Nota
Para obtener más información sobre el Administrador de suscripciones, visite
https://access.redhat.com/ecosystem/ccsp/microsoft-azure.
El administrador de software DPKG

La distribución de Debian no utiliza el formato RPM; en cambio, usa el formato DEB,
que se inventó en 1995. El formato está en uso en todas las distribuciones basadas en
Debian y Ubuntu.
Un paquete DEB contiene lo siguiente:
• Un archivo, debian-binary, con la versión del paquete.
• Un archivo de almacenamiento, control.tar, con metadatos (el nombre del
paquete, la versión, las dependencias y el mantenedor).
• Un archivo de almacenamiento, data.tar, con el software real.
La administración de paquetes DEB se puede hacer con la utilidad dpkg. Al igual que rpm,
la utilidad dpkg ya no se usa para instalar software, aun cuando esa funcionalidad está
disponible. En cambio, se usa el comando apt, que es más avanzado. Sin embargo, es
bueno conocer los conceptos básicos de los comandos de dpkg.
Todos los metadatos van a una base de datos que se puede consultar con dpkg o dpkg-query.
Los parámetros importantes de dpkg-query son los siguientes:
Figura 5.10: Parámetros dpkg-query importantes
La primera columna de la salida de dpkg -l también muestra si el paquete está instalado

o no, si no está empaquetado o si se instaló a medias, etc.:
Figura 5.11: Salida del comando dpkg -l

El primer carácter de la primera columna es la acción deseada, el segundo es el estado
real del paquete y un tercer carácter posible indica una marca de error (R). ii significa
que el paquete está instalado.
Los posibles estados deseados son los siguientes:
• u: desconocido
• i: instalación
• h: espera
• r: eliminación
• p: purga
Los estados importantes del paquete son los siguientes:

• n (Not): el paquete no está instalado.
• i (Inst): el paquete se instaló correctamente.
• c (Cfg-files): están presentes los archivos de configuración.
• u (Unpacked): el paquete todavía no está empaquetado.
• f (Failed-cfg): no se pudieron eliminar los archivos de configuración.
• h (Half-inst): el paquete solo se instaló de manera parcial.
Software de administración con apt

En las distribuciones basadas en Debian y Ubuntu, la administración de software se
hace mediante la utilidad apt, que es un reemplazo reciente de las utilidades apt-get
y apt-cache.
Entre los comandos que se utilizan con más frecuencia se incluyen los siguientes:
Figura 5.12: Comandos apt comunes y su descripción

Los repositorios se configuran en el directorio /etc/apt/sources.list y los archivos,
en el directorio /etc/apt/sources.list.d/. De manera alternativa, está disponible el
comando apt-add-repository:
apt-add-repository \
'deb http://myserver/path/to/repo stable'
Los repositorios apt tienen el concepto de clases de versión, algunas de las cuales se
muestran aquí:
• oldstable: el software se probó en la versión anterior de una distribución, pero no
se volvió a probar con la actual.
• stable: el software se lanzó oficialmente.
• testing: el software todavía no tiene un estado stable, pero está en curso.
• unstable: el software está en desarrollo, principalmente por parte de
los desarrolladores.
Los repositorios además tienen el concepto de componentes, que también se conocen

como repositorios principales:
• main: se probó y se proporciona con soporte técnico y actualizaciones
• contrib: se probó y se proporciona con soporte técnico y actualizaciones, pero hay
dependencias que no tienen el estado main sino que, por ejemplo, tiene el estado
non-free
• non-free: se trata de software que no cumple con las Directrices de software libre
de Debian (https://www.debian.org/social_contract#guidelines)
Ubuntu agrega varios componentes o repositorios adicionales:

• Universe: proporcionado por la comunidad, sin servicio técnico ni
actualizaciones posibles
• Restricted: controladores de dispositivos exclusivos
• Multiverse: software restringido por derecho de autor o aspectos legales
Administración de software con ZYpp

SUSE, al igual que Red Hat, utiliza RPM para la administración de paquetes. Pero en lugar
de usar yum, se usa otro conjunto de herramientas con ZYpp (también conocido como
libzypp) como back-end. La administración de software se puede hacer con el software de
configuración gráfica YaST, o bien la herramienta de interfaz de línea de comandos, Zypper.
Nota
YUM y DNF también están disponibles en los repositorios de software de SUSE.
Puede usarlos para administrar (limitado a la instalación y eliminación) software en
su sistema local, pero no es por eso que están disponibles. La razón es Kiwi, una
aplicación para crear instaladores e imágenes del sistema operativo.
Los parámetros básicos importantes son los siguientes:
Figura 5.13: Comandos importantes de Zypper y su descripción
Hay una opción de búsqueda para buscar un comando, what-provides, pero es muy
limitada. Si no conoce el nombre del paquete, hay una utilidad llamada cnf en su lugar.
Antes de poder usar cnf, deberá instalar scout. De este modo, es posible buscar las
propiedades del paquete:
sudo zypper install scout
Después de eso, puede usar cnf:
Figura 5.14: Uso de la utilidad cnf

Si desea actualizar el sistema a una nueva versión de distribución, primero debe

modificar los repositorios. Por ejemplo, si quiere actualizar de SUSE LEAP 42.3, que
se basa en SUSE Linux Enterprise Server (SLES), a la versión 15.0, que se basa en
SUSE Linux Enterprise (SLE), ejecute el siguiente procedimiento:
1. En primer lugar, instale las actualizaciones disponibles para la versión actual:
sudo zypper update
2. Actualice a la versión más reciente en las versiones 42.3.x:
sudo zypper dist-upgrade
3. Modifique la configuración del repositorio:
sudo sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*.repo
4. Inicialice los repositorios nuevos:
sudo zypper refresh
5. Instale la distribución nueva:
sudo zypper dist-upgrade
Por supuesto, debe reiniciar después de actualizar la distribución.
Además de instalar paquetes, puede instalar lo siguiente:
• patterns: grupos de paquetes, por ejemplo, para instalar un servidor web
completo, incluido PHP y MySQL (también conocido como LAMP)
• patches: actualizaciones incrementales de un paquete
• products: instalación de un producto adicional
Para enumerar los patrones disponibles, use el comando siguiente:

zypper patterns
Para instalarlos, use este comando:

sudo zypper install --type pattern <pattern>
El mismo procedimiento se aplica a los parches y productos.

Zypper utiliza repositorios en línea para ver los repositorios actualmente configurados:
sudo zypper repos
Puede agregar repositorios addrepo; por ejemplo, para agregar un repositorio comunitario
para la versión más reciente de PowerShell en LEAP 15.0, ejecute este comando:
sudo zypper addrepo \
https://download.opensuse.org/repositories\
/home:/aaptel:/powershell-stuff/openSUSE_Leap_15.0/\
home:aaptel:powershell-stuff.repo
Si agrega un repositorio, siempre tendrá que actualizar los repositorios:

sudo zypper refresh
Nota
SUSE tiene el concepto de repositorios que son o no de confianza. Si un proveedor
no es de confianza, debe agregar el parámetro --from al comando install. También
puede agregar un archivo de configuración a /etc/vendors.d, como se muestra aquí:
[main]
vendors = suse,opensuse,obs://build.suse.de
El proveedor de un paquete se puede encontrar con zypper info.
Ahora que sabe cómo administrar el software en su distribución, sigamos adelante

y hablemos de las redes. En el capítulo anterior, analizamos los recursos de red en
Azure y ahora es momento de aprender sobre las redes en Linux.
Redes
En Azure, la configuración de red, como la dirección IP y la configuración de
DNS, se proporciona a través del Protocolo de configuración dinámica de host
(DHCP). La configuración es muy similar a la configuración de máquinas físicas
o VM que se ejecutan en otra plataforma. La diferencia es que Azure proporciona
la configuración y, por lo general, no se debe cambiar.
En esta sección, aprenderá a identificar la configuración de red en Linux y cómo
hacer coincidir esa información con la configuración de Azure que se analizó en el
capítulo anterior.
Redes | 145
Identificación de las interfaces de red

Durante y después del proceso de arranque, el kernel de Linux es responsable de la
identificación de hardware. Cuando el kernel identifica el hardware, lleva la información
recopilada a un proceso, un demonio en ejecución (proceso en segundo plano), llamado
systemd-udevd. Este demonio hace lo siguiente:
• Carga el controlador de red si es necesario.
• Puede asumir la responsabilidad de la nomenclatura de los dispositivos.
• Actualiza /sys con toda la información disponible.
La utilidad udevadm puede ayudarlo a mostrar el hardware identificado. Puede usar el

comando udevadm info para consultar la base de datos udev para obtener información
sobre los dispositivos:
Figura 5.15: Uso del comando udevadm info para recuperar información de los dispositivos
En lugar de usar udevadm, también puede llegar al directorio /sys/class/net y ver el
comando cat con los archivos disponibles, pero no se trata de un método muy fácil de
usar y, por lo general, no es necesario hacerlo de esta manera, porque hay utilidades
que analizan toda la información disponible.
La utilidad más importante es el comando ip. Comencemos con la lista de las interfaces
de red disponibles y la información relacionada:
ip link show
El comando anterior debería mostrarle la siguiente salida:
Figura 5.16: Uso de ip link show para enumerar las interfaces de red disponibles
Una vez que se enumeran las interfaces de red disponibles, puede ser más específico:
ip link show dev eth0
El significado de todas las marcas de estado, como LOWER_UP, se puede encontrar en
man 7 netdevice.
Identificación de la dirección IP
Una vez que se conoce el nombre de la interfaz de red, se puede usar la utilidad ip
para mostrar la dirección IP configurada en la interfaz de red, tal como aparece en la
siguiente captura de pantalla:
Figura 5.17: Uso de la utilidad ip para recuperar la dirección IP configurada

Redes | 147
Visualización de la tabla de rutas

Una tabla de rutas es una estructura que se almacena en el kernel de Linux con la
información sobre cómo enrutar los paquetes. Puede configurar la tabla de rutas
y hacer que los paquetes tomen una ruta según una regla o condición. Por ejemplo,
puede declarar que si el destino del paquete es 8.8.8.8, se debe enviar al gateway.
La tabla de rutas se puede mostrar por dispositivo o por subred:
Figura 5.18: Visualización de la tabla de rutas
Otra característica interesante es que puede consultar qué dispositivo y gateway se

utilizan para llegar a una dirección IP específica:
Figura 5.19: Consulta de dispositivo y gateway que se usa para una dirección IP específica
Configuración de la red
Ahora que sabemos identificar la dirección IP de la interfaz y las rutas definidas para la
interfaz, veamos cómo se configuran estas direcciones IP y rutas en el sistema Linux.
El comando ip se usa principalmente para comprobar la configuración. Por lo general,
otro demonio administra la configuración persistente. Las distintas distribuciones
tienen diferentes demonios para administrar la red:
• Las distribuciones RHEL usan NetworkManager.
• En SLE y OpenSUSE LEAP, se usa wicked.
• En Ubuntu 17.10 y versiones posteriores, se usan systemd-networkd y systemd-resolved,
y las versiones anteriores de Ubuntu se basan completamente en el cliente DHCP que
está configurado en los archivos /etc/network/interfaces.d/*cfg.
En Ubuntu, el agente invitado de Linux para Azure crea dos archivos en el directorio
/run/system/network. Uno es un archivo de vínculo denominado 10-netplan-eth0.link
para conservar el nombre del dispositivo, en función de la dirección MAC:
[Match]
MACAddress=00:....
[Link]
Name=eth0
WakeOnLan=off
El otro es 10-netplan-eth0.network para la configuración de red real:

[Match]
MACAddress=00:...
Name=eth0
[Network]
DHCP=ipv4
[DHCP]
UseMTU=true
RouteMetric=100
Si tiene más de una interfaz de red, se crean varios conjuntos de archivos.

En SUSE, el agente invitado de Linux para Azure crea un archivo, /etc/sysconfig/
network/ifcfg-eth0, con el siguiente contenido:
BOOTPROTO='dhcp'
DHCLIENT6_MODE='managed'
MTU=''
REMOTE_IPADDR=''
STARTMODE='onboot'
CLOUD_NETCONFIG_MANAGE='yes'
Redes | 149
El demonio wicked lee este archivo y lo usa para la configuración de la red. Del mismo
modo que en Ubuntu, se crean varios archivos si tiene más de una interfaz de red.
El estado de la configuración se puede ver con el comando wicked:
Figura 5.20: Comprobación del estado de la configuración con el comando wicked show
En RHEL y CentOS, los archivos ifcfg- se crean en el directorio /etc/sysconfig/

network-scripts:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
DHCP_HOSTNAME=...
Si NM_CONTROLLED se establece en no, NetworkManager no podrá controlar la conexión. La

mayoría de las máquinas Azure Linux lo tienen establecido en yes; sin embargo, puede
comprobarlo en los archivos ifcfg- que se encuentran en el directorio /etc/sysconfig/
network-scripts. Puede usar el comando nmcli para mostrar la configuración del
dispositivo, pero no puede usarlo para modificar esas configuraciones:
Figura 5.21: Uso del comando nmcli para mostrar la configuración del dispositivo
Cambios en la configuración de la red

Como se indicó anteriormente, el servidor DHCP de Azure proporciona cada
configuración de red. Todo lo que aprendimos hasta ahora trataba sobre la
comprobación de la configuración de la red configurada en Azure.
Si hizo alguna modificación en Azure, deberá reiniciar la red en Linux.
En SUSE y CentOS, puede hacerlo con este comando:
sudo systemctl restart network
En la versión más reciente de Ubuntu Server, use los siguientes comandos:

sudo systemctl restart systemd-networkd
sudo systemctl restart systems-resolved

Redes | 151
Nombre de host
El nombre de host actual de la VM se puede encontrar con la utilidad hostnamectl:
Figura 5.22: Recuperación del nombre de host con la utilidad hostnamectl
El servidor DHCP proporciona el nombre de host en Azure. Para ver el nombre de host
configurado en Azure, puede usar Azure Portal, la CLI de Azure o PowerShell. Como
ejemplo, en PowerShell, use el siguiente comando:
$myvm=Get-AzVM -Name CentOS-01 '
-ResourceGroupName MyResource1
$myvm.OSProfile.ComputerName
En Linux, puede cambiar el nombre de host con la utilidad hostnamectl:
sudo hostnamectl set-hostname <hostname>
sudo systemctl restart waagent #RedHat & SUSE
sudo systemctl restart walinuxagent #Ubuntu
Esto debería cambiar el nombre de host. Si no funciona, compruebe el archivo de
configuración del agente de la VM de Azure Linux, /etc/waagent.conf:
Provisioning.MonitorHostName=y
Si sigue sin funcionar, edite el archivo /var/lib/waagent/ovf-env.xml y cambie

el parámetro HostName. Otra causa posible es la línea DHCP_HOSTNAME del archivo
ifcfg-<interface>; simplemente quítela y reinicie NetworkManager.
DNS
La configuración DNS también se proporciona a través del servidor DHCP de Azure.
En Azure, la configuración se conecta a la interfaz de red virtual. Puede verla en Azure
Portal, PowerShell (Get-AZNetworkInterface) o en la CLI de Azure (az vm nic show).
Por supuesto, puede configurar su propia configuración DNS. En PowerShell, declare la
VM e identifique la interfaz de red:
$myvm = Get-AzVM -Name <vm name> '
-ResourceGroupName <resource group>
$nicid = $myvm.NetworkProfile.NetworkInterfaces.Id
El último comando le dará el ID completo de la interfaz de red necesaria; la última
parte de este ID es el nombre de la interfaz. Ahora dejemos la salida y solicitemos
las propiedades de la interfaz:
$nicname = $nicid.split("/")[-1]
$nic = Get-AzNetworkInterface '
-ResourceGroupName <resource group> -Name $nicname
$nic
Si observa el valor de la variable $nic, verá que tiene toda la información necesaria:
Figura 5.23: Obtención de las propiedades de la interfaz con la variable $nic

Redes | 153
El último paso es actualizar la configuración del servidor de nombres DNS. Para

el propósito de este libro, usamos 9.9.9.9, que es un servicio DNS público y de
libre disposición, llamado Quad9. También puede usar el servicio DNS de Google
(8.8.8.8 y 8.8.4.4):
$nic.DnsSettings.DnsServers.Add("9.9.9.9")
$nic | Set-AzNetworkInterface
$nic | Get-AzNetworkInterface | '
Select-Object -ExpandProperty DnsSettings
El método que usa la CLI de Azure es similar, pero implica menos pasos. Busque el
nombre de la interfaz de red:
nicname=$(az vm nic list \
--resource-group <resource group> \
--vm-name <vm name> --query '[].id' -o tsv | cut –d "/" -f9)
Actualice la configuración DNS:
az network nic update -g MyResource1 --name $nicname \
--dns-servers 9.9.9.9
Y luego compruebe la nueva configuración DNS:
az network nic show --resource-group <resource group> \
--name $nicname --query "dnsSettings"
En la VM Linux, debe renovar la concesión DHCP para recibir la nueva configuración.
Para hacerlo, puede ejecutar systemctl restart NetworkManager en RHEL o dhclient -r
en Ubuntu. La configuración se guarda en el archivo /etc/resolv.conf.
En las distribuciones de Linux que usan la implementación de red de systemd, como
Ubuntu, el archivo /etc/resolv.conf es un vínculo simbólico a un archivo del directorio
/run/systemd/resolve/ y el comando sudo systemd-resolve --status muestra la
configuración actual:
link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 9.9.9.9
DNS Domain: reddog.microsoft.com
Para probar la configuración DNS, puede usar dig, o bien la utilidad host, que es más
sencilla, como se muestra aquí:
dig www.google.com A
Almacenamiento
En el capítulo anterior, analizamos cómo crear discos y conectarlos a la VM, pero
nuestro trabajo no termina allí. Tenemos que dividir o montar el disco en la máquina
Linux. En esta sección, analizaremos la administración del almacenamiento en Linux.
Hay dos tipos de almacenamiento disponibles en Azure: discos virtuales conectados a la
VM y recursos compartidos de archivos de Azure. Este capítulo abarcará ambos tipos.
Se analizarán los siguientes temas:
• Agregar un disco virtual único a una VM.
• Trabajar con sistemas de archivos.
• Trabajar con varios discos virtuales mediante el software RAID y el Administrador
de discos lógicos (LVM).
Almacenamiento proporcionado por dispositivos de bloque

Los dispositivos de bloque pueden entregar almacenamiento local y remoto. En Azure,
casi siempre se trata de un disco duro virtual que está conectado a la VM, pero es
posible también usar volúmenes de Interfaz estándar de equipos pequeños de Internet
(iSCSI), que son proporcionados por Microsoft Azure StorSimple o terceros.
El kernel identifica cada disco conectado a una VM y, después de la identificación, lo
pasa a un demonio llamado systemd-udevd. Este demonio es responsable de crear una
entrada en el directorio /dev, de actualizar /sys/class/block y, si es necesario, de cargar
un controlador para tener acceso al sistema de archivos.
El archivo de dispositivo en /dev brinda una interfaz sencilla para el dispositivo de
bloque y es accesible mediante un controlador SCSI.
Existen varios métodos para identificar los dispositivos de bloque disponibles.
Una posibilidad implica el uso del comando lsscsi:
Figura 5.24: Uso del comando lsscsi para identificar los dispositivos de bloque
Almacenamiento | 155
El primer disco disponible se denomina Disco A sda—SCSI. Este disco se crea a partir
del disco de imagen usado durante el aprovisionamiento de la VM y también se conoce
como el “disco raíz”. Puede acceder a este disco a través de /dev/sda o de /dev/disk/
azure/root.
Otra forma de identificar el almacenamiento disponible es usar el comando lsblk.
Puede proporcionar más información sobre el contenido del disco:
Figura 5.25: Identificación del almacenamiento disponible con el comando lsblk
En este ejemplo hay dos particiones creadas en /dev/sda, sda1 y sda2 (o /dev/disk/
azure/root-part1 y root-part2). El número principal de la segunda columna, 8, significa
que se trata de un dispositivo SCSI; la parte secundaria es solo numeración. La tercera
columna nos dice que el dispositivo no es extraíble, lo que se indica con un 0 (si fuese
extraíble, aparecería un 1), y la quinta columna nos dice que los controladores y las
particiones no son de solo lectura; nuevamente, si aparece un 1 es de solo lectura
y un 0, lectura y escritura.
Hay otro disco disponible, el disco de recursos /dev/sdb (/dev/disk/azure/resource),
que es un disco temporal. Esto significa que los datos no son persistentes y que
desaparecen después de un reinicio y se utilizan para almacenar datos como una página
o un archivo de intercambio. El intercambio es como la memoria virtual en Windows,
que se utiliza cuando la RAM física está llena.
Cómo agregar un disco de datos

En esta sección, se recopilará todo lo que se hizo en el capítulo anterior para continuar
con el ejercicio y ayudarlo a familiarizarse con los comandos. Si ya tiene una VM con
discos de datos agregados, puede omitir esta sección.
Puede agregar un disco virtual adicional a una VM mediante Azure Portal o a través de
PowerShell. Agreguemos un disco:
1. En primer lugar, declare cómo quiere nombrar el disco y dónde se debe crear:
$resourcegroup = '<resource group>'
$location = '<location>'
$diskname = '<disk name>'
$vm = Get-AzVM '

-Name <vm name> '
-ResourceGroupName $resourcegroup
2. Cree la configuración del disco virtual: un disco administrado estándar y vacío de
2 GB de tamaño:
$diskConfig = New-AzDiskConfig '
-SkuName 'Standard_LRS' '
-Location $location '
-CreateOption 'Empty' '
-DiskSizeGB 2
3. Cree el disco virtual con esta configuración:
$dataDisk1 = New-AzDisk '
-DiskName $diskname '
-Disk $diskConfig '
4. Conecte el disco a la VM:
$vmdisk = Add-AzVMDataDisk '
-VM $vm -Name $diskname '
-CreateOption Attach '
-ManagedDiskId $dataDisk1.Id '
-Lun 1
Update-AzVM '
-VM $vm '
5. Por supuesto, también puede usar la CLI de Azure:

az disk create \
--name <disk name> \
--location <location> \
--size-gb 2 \
--sku Standard_LRS \
az vm disk attach \
--disk <disk name> \
--vm-name <vm name> \
--lun <lun number>
Nota
LUN es la abreviatura en inglés de “Número de unidad lógica”, un número
o identificador que se usa para etiquetar almacenamiento (en este caso,
almacenamiento virtual), lo que ayudará a los usuarios a distinguir el
almacenamiento. Puede empezar a enumerar desde cero.
Después de la creación, el disco virtual es visible en la VM como /dev/sdc (/dev/disk/

azure/scsi1/lun1).
Sugerencia: Si no está disponible, ejecute el comando rescan-scsi-bus, que forma parte
del paquete sg3_utils.
Vuelva a mirar la salida de lssci:
[5:0:0:1] disk Msft Virtual Disk 1.0 /dev/sdc
La primera columna tiene este formato:

<hostbus adapter id> : <channel id> : <target id> : <lun number>
hostbus adapter es la interfaz para el almacenamiento y la crea el controlador de

almacenamiento virtual de Microsoft Hyper-V. El ID de canal siempre es 0, a menos
que haya configurado varias rutas. El ID de destino identifica un destino SCSI en un
controlador, el que siempre es cero para los dispositivos de conexión directa en Azure.
Creación de particiones
Antes de poder usar el dispositivo de bloque, tendrá que particionarlo. Hay varias
herramientas disponibles para la creación de particiones y algunas distribuciones
vienen con sus propias utilidades para crear y manipular tablas de particiones.
Por ejemplo, SUSE tiene una en su herramienta de configuración YaST.
En este libro usaremos la utilidad parted. Esto se instala de manera predeterminada
en cada distribución de Linux y puede manejar todos los diseños de partición que se
conocen: msdos, gpt, sun, etc.
Puede usar parted como script en la línea de comandos pero, si no conoce parted,
resulta más sencillo usar el shell interactivo:
parted /dev/sdc
GNU Parted 3.1
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
1. El primer paso es mostrar la información disponible con respecto a este
dispositivo:
(parted) print
Error: /dev/sdc: unrecognised disk label
Model: Msft Virtual Disk (scsi)
Disk /dev/sdc: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
La línea importante aquí es unrecognised disk label. Esto significa que no se
creó ningún diseño de partición. Hoy en día, el diseño más común es Tabla de
particiones de GUID (GPT).
Nota
parted admite la característica de autocompletar después de un signo de
interrogación: presione Ctrl + I dos veces.
2. Cambie la etiqueta de partición a gpt:

(parted) mklabel
New disk label type? gpt
3. Para comprobar el resultado, vuelva a imprimir la tabla de particiones de disco:

(parted) print
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
4. El paso siguiente es crear una partición:
(parted) mkpart
Partition name? []? lun1_part1
File system type? [ext2]? xfs
Start? 0%
End? 100%
Los sistemas de archivo se tratarán más adelante en este capítulo. Para determinar
el tamaño, puede usar porcentajes o tamaños fijos. En general, en Azure, tiene más
sentido usar todo el disco.
5. Vuelva a imprimir la tabla de particiones de disco:
(parted) print
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 2146MB 2145MB lun1_part1
Tenga en cuenta que la columna del sistema de archivos sigue vacía, porque la
partición no tiene formato.
6. Use Ctrl + D o quit para salir de parted.
Sistemas de archivos en Linux

Los archivos de sistemas tienen su mecanismo para organizar los datos y esto diferirá
de un sistema de archivos a otro. Si comparamos los sistemas de archivos disponibles,
vemos que algunos son rápidos, otros están diseñados para un almacenamiento más
grande y otros, para manejar segmentos de datos más pequeños. Su elección del
sistema de archivos debe depender de los requisitos finales y del tipo de datos que está
almacenando. Linux admite muchos sistemas de archivos: sistemas de archivos de Linux
nativos, como ext4 y XFS, y sistemas de archivos de terceros, como FAT32.
Cada distribución admite los sistemas de archivos nativos, ext4 y XFS. Además, SUSE
y Ubuntu son compatibles con un sistema de archivos muy moderno: BTRFS. Ubuntu es
una de las pocas distribuciones que tienen compatibilidad con el sistema de archivos ZFS.
Después de dar formato al sistema de archivos, puede montarlo en el sistema de
archivos raíz. La sintaxis básica del comando mount es la siguiente:
mount <partition> <mountpoint>
Una partición se puede nombrar con el nombre del dispositivo, la etiqueta o el

identificador único universal (UUID). ZFS se puede montar con el comando mount
o a través de la utilidad zfs.
Otro sistema de archivos importante es el sistema de archivos de intercambio.
Además de los sistemas de archivos habituales, también hay otros especiales: devfs,
sysfs, procfs y tmpfs.
Comencemos con una breve descripción de los sistemas de archivos y las utilidades que
los rodean.
El sistema de archivos ext4

ext4 es un sistema de archivos nativo de Linux, desarrollado como el sucesor de
ext3, que fue (y, para algunas distribuciones, sigue siendo) el sistema de archivos
predeterminado durante muchos años. Ofrece estabilidad, alta capacidad, confiabilidad
y rendimiento, a la vez que requiere un mantenimiento mínimo. Además de eso, puede
cambiar el tamaño (aumentar/disminuir) del sistema de archivos sin ningún problema.
La buena noticia es que puede ofrecer esto con requisitos muy bajos. Por supuesto,
también hay malas noticias: es muy confiable, pero no puede garantizar por completo
la integridad de los datos. Si los datos se dañan mientras ya están en el disco, ext4 no
tiene ninguna forma de detectar o reparar tales daños. Afortunadamente, debido a la
arquitectura subyacente de Azure, esto no sucederá.
ext4 no es el sistema de archivos más rápido que existe pero, para muchas cargas de
trabajo, la brecha entre ext4 y la competencia es muy pequeña.
Las utilidades más importantes son las siguientes:

• mkfs.ext4: da formato al sistema de archivos
• e2label: cambia la etiqueta del sistema de archivos
• tune2fs: cambia los parámetros del sistema de archivos
• dump2fs: muestra los parámetros del sistema de archivos
• resize2fs: cambia el tamaño del sistema de archivos
• fsck.ext4: comprueba y repara el sistema de archivos
• e2freefrag: informa sobre la desfragmentación
• e4defrag: desfragmenta el sistema de archivos. Por lo general, no es necesario
Use este comando para crear un sistema de archivos ext4:

sudo mkfs.ext4 -L <label> <partition>
La etiqueta es opcional, pero permite reconocer más fácilmente un sistema de archivos.
El sistema de archivos XFS

XFS es un sistema de archivos altamente escalable. Se puede escalar a 8 EiB (exbibyte
= 2 ^ 60 bytes) con el cambio de tamaño en línea; el sistema de archivos puede crecer
siempre que haya espacio no asignado y puede abarcar varias particiones y dispositivos.
XFS es uno de los sistemas de archivos más rápidos, especialmente en combinación
con los volúmenes RAID. Sin embargo, esto tiene un costo: necesitará al menos 1 GB
de memoria en su VM si quiere usar XFS. Y si quiere reparar el sistema de archivos,
necesitará al menos 2 GB de memoria.
Otra buena característica de XFS es que puede desactivar el tráfico al sistema de archivos
para crear copias de seguridad coherentes de, por ejemplo, un servidor de base de datos.
• mkfs.xfs: da formato al sistema de archivos
• xfs_admin: cambia los parámetros del sistema de archivos
• xfs_growfs: disminuye el tamaño del sistema de archivos
• xfs_repair: comprueba y repara el sistema de archivos
• xfs_freeze: suspende el acceso a un sistema de archivos XFS. Esto permite facilitar
la creación de copias de seguridad coherentes
• xfs_copy: copia rápidamente el contenido de un sistema de archivos XFS
Use este comando para crear un sistema de archivos XFS:

sudo mkfs.xfs -L <label> <partition>
La etiqueta es opcional, pero permite reconocer más fácilmente un sistema de archivos.
El sistema de archivos ZFS

ZFS es un sistema de archivos combinado y administrador de volúmenes lógicos
desarrollado por SUN, propiedad de Oracle desde el año 2005, muy conocido por
su excelente rendimiento y sus características enriquecidas:
• Administración de volúmenes y RAID
• Protección contra datos dañados
• Desduplicación y compresión de datos
• Escalable a 16 exabytes
• Capaz de exportar sistemas
• Compatibilidad con instantáneas
ZFS se puede implementar en Linux con un controlador de espacio de usuario

(FUSE) o con un módulo de kernel de Linux (OpenZFS). En Ubuntu, es mejor usar el
módulo del kernel, porque funciona mejor y no tiene algunas de las limitaciones de la
implementación de FUSE. Por ejemplo, si utiliza FUSE, no puede exportar el sistema de
archivos con NFS.
La razón principal por la que OpenZFS no se adopta ampliamente es la concesión de
licencias. La Licencia común de desarrollo y distribución (CDDL) no es compatible
con la Licencia pública general del kernel de Linux. Otra razón es que ZFS puede
ocupar muchísima memoria: la VM requiere 1 GB de memoria adicional por TB de
almacenamiento, lo que significa que un almacenamiento de 16 TB requiere 16 GB
de RAM para las aplicaciones. Para ZFS, se recomienda tener al menos 1 GB de memoria.
Pero cuanto más tenga, mejor, porque ZFS utiliza mucha memoria.
• zfs: configura el sistema de archivos ZFS
• zpool: configura los grupos de almacenamiento ZFS
• zfs.fsck: comprueba y repara el sistema de archivos ZFS
En este libro, solo se describe la funcionalidad básica de ZFS.

Ubuntu es la única distribución compatible con ZFS. Para poder usar ZFS en Ubuntu,
tiene que instalar las utilidades de ZFS:
sudo apt install zfsutils-linux
Después de la instalación, puede empezar a usar ZFS. Supongamos que agregó tres
discos a una VM. Es buena idea usar RAID 0, porque ofrece un mejor rendimiento
y desempeño que un disco único.
Como primer paso, vamos a crear un grupo con dos discos:
sudo zpool create -f mydata /dev/sdc /dev/sdd
sudo zpool list mydata
sudo zpool status mydata
Ahora, agreguemos el tercer disco para mostrar cómo extender el grupo:
sudo zpool add mydata /dev/sde
sudo zpool list mydata
sudo zpool history mydata
Puede utilizar directamente este grupo o puede crear conjuntos de datos en él para un
control más detallado de características como las cuotas:
sudo zfs create mydata/finance
sudo zfs set quota=5G mydata/finance
sudo zfs list
Por último, pero igual de importante, deberá montar este conjunto de datos para
poder usarlo:
sudo zfs set mountpoint=/home/finance mydata/finance
findmnt /home/finance
Este montaje será persistente en los reinicios.
El sistema de archivos BTRFS

BTRFS es un sistema de archivos relativamente nuevo, desarrollado principalmente por
Oracle, pero con contribuciones de SUSE y empresas como Facebook.
Es muy similar a ZFS en términos de características, pero está en pleno desarrollo.
Esto significa que no todas las características se consideran estables. Antes de usar
este sistema de archivos, visite https://btrfs.wiki.kernel.org/index.php/Status.
Los requisitos de memoria son los mismos que para XFS: 1 GB de memoria en su VM.
No necesita memoria adicional si quiere reparar el sistema de archivos.
En este libro, solo se describe la funcionalidad básica de BTRFS. Puede utilizar BTRFS
en todas las distribuciones, pero tenga en cuenta que en RHEL y CentOS, el sistema
de archivos está etiquetado como obsoleto y, en RHEL 8, se quitó. Para obtener más
información, visite https://access.redhat.com/solutions/197643.
• mkfs.btrfs: da formato a los dispositivos con este sistema de archivos
• btrfs: administra el sistema de archivos
Supongamos que agregó tres discos a una VM. Es buena idea usar RAID 0 para mejorar
el rendimiento y permitir un mejor desempeño en comparación con el uso de un
disco único.
Como primer paso, cree un sistema de archivos BTRFS con dos discos subyacentes:
sudo mkfs.btrfs -d raid0 -L mydata /dev/sdc /dev/sdd
Por supuesto, puede extender el sistema de archivos con el tercer disco, pero antes de
que pueda hacerlo, tiene que montar el sistema de archivos:
sudo mkdir /srv/mydata
sudo mount LABEL=mydata /srv/mydata
sudo btrfs filesystem show /srv/mydata
Ahora, agregue el tercer disco:
sudo btrfs device add /dev/sde /srv/mydata
sudo btrfs filesystem show /srv/mydata
Al igual que ZFS, BTRFS tiene el concepto de conjuntos de datos, pero en BTRFS se
denominan subvolúmenes. Para crear un subvolumen, ejecute el siguiente comando:
sudo btrfs subvolume create /srv/mydata/finance
sudo btrfs subvolume list /srv/mydata
Puede montar un subvolumen independientemente del volumen raíz:
sudo mkdir /home/finance
sudo mount -o subvol=finance LABEL=mydata /home/finance
Puede ver el ID 258 en la salida del comando findmnt:
Figura 5.26: Creación de un subvolumen
El sistema de archivos de intercambio

Si no tiene suficiente memoria disponible para su aplicación, puede usar el sistema de
archivos de intercambio. Siempre es bueno usar el intercambio, incluso si tiene una
amplia cantidad de RAM en la máquina.
La memoria inactiva es una memoria que se usó antes, pero que una aplicación
no necesita actualmente. Si esta memoria inactiva no se utiliza durante un largo
período de tiempo, se intercambiará para que haya más memoria disponible para
las aplicaciones que se usan con más frecuencia.
Para mejorar el rendimiento general, se recomienda agregar un poco de espacio de
intercambio a la instalación de Linux. Es buena idea usar el almacenamiento más rápido
disponible, de preferencia en el disco de recursos.
Nota
En Linux, puede usar archivos de intercambio y particiones de intercambio. No
hay ninguna diferencia en el rendimiento. En Azure, no puede usar particiones
de intercambio. Esto hará que su sistema sea inestable, provocado por el
almacenamiento subyacente.
El agente de VM de Azure administra el intercambio en Azure. Puede comprobar si

el parámetro ResourceDisk.EnableSwap está establecido en y para confirmar que el
intercambio está habilitado en /etc/waagent.conf. Además, puede comprobar el tamaño
de intercambio en ResourceDisk.SwapSizeMB:
# Create and use swapfile on resource disk.
ResourceDisk.EnableSwap=y
# Size of the swapfile.
ResourceDisk.SwapSizeMB=2048
En general, un archivo de intercambio de 2048 MB de memoria es más que suficiente

para aumentar el rendimiento general. Si el intercambio no estaba habilitado, para crear
un archivo de intercambio, establezca estos tres parámetros para actualizar el archivo
/etc/waagent.conf:
• ResourceDisk.Format=y
• ResourceDisk.EnableSwap=y
• ResourceDisk.SwapSizeMB=xx
Y ejecute el siguiente comando para reiniciar el agente de VM de Azure para

Debian/Ubuntu:
sudo systemctl restart walinuxagent
Para Red Hat/CentOS, ejecute este comando:

service waagent restart
Compruebe el resultado:
ls -lahR /mnt | grep -i swap
swapon –s
Si descubre que no se crea el archivo de intercambio, reinicie la VM. Para hacerlo, use
cualquiera de estos comandos:
shutdown -r now
init 6
Linux Software RAID

La Matriz redundante de discos independientes (RAID), conocida originalmente como
Matriz redundante de discos económicos, es una técnica de redundancia donde los
mismos datos se almacenan en distintos discos, lo que permitirá recuperar los datos en
caso de un error de disco. Hay diferentes niveles disponibles para RAID. Oficialmente,
Microsoft afirma en https://docs.microsoft.com/es-xl/azure/virtual-machines/linux/
configure-raid que se necesitará RAID 0 para obtener un rendimiento óptimo, pero
no se trata de una implementación obligatoria. Si su infraestructura actual exige RAID,
puede implementarla.
Si su sistema de archivos no es compatible con RAID, puede usar Linux Software
RAID para crear un dispositivo RAID 0. Deberá instalar la utilidad mdadm, que está
disponible en cada distribución de Linux, pero probablemente no esté instalada de
manera predeterminada.
Supongamos que agregó tres discos a una VM. Vamos a crear un dispositivo RAID 0
denominado /dev/md127 (solo un número aleatorio que todavía no está en uso):
sudo mdadm --create /dev/md127 --level 0 \
--raid-devices 3 /dev/sd{c,d,e}
Compruebe la configuración de la siguiente manera:
cat /proc/mdstat
sudo mdadm --detail /dev/md127

Los comandos anteriores deberían mostrarle la siguiente salida:
Figura 5.27: Compruebe la configuración RAID
Haga que la configuración sea persistente:

mdadm --detail --scan --verbose >> /etc/mdadm.conf
Ahora, puede usar este dispositivo y darle formato con un sistema de archivos, como
se muestra aquí:
mkfs.ext4 -L BIGDATA /dev/md127
Stratis
Stratis se introdujo recientemente en RHEL 8 y se usa para crear un grupo de
almacenamiento de varios discos y de varios niveles, para supervisar el grupo
y administrarlo con facilidad y con una cantidad mínima de intervención manual.
No brinda compatibilidad con RAID, pero convierte varios dispositivos de bloque en
un grupo con un sistema de archivos sobre él. Stratis utiliza la tecnología ya existente:
LVM y el sistema de archivos XFS.
Si Stratis no está instalado en su RHEL, se puede instalar fácilmente mediante la

ejecución del siguiente comando:
sudo dnf install stratis-cli
Habilite el demonio con este comando:

sudo systemctl enable --now stratisd
Supongamos que agregó dos discos de datos a su VM: /dev/sdc y /dev/sdd. Cree el grupo:
sudo stratis pool create stratis01 /dev/sdc /dev/sdd
Compruebe el uso de este comando:

sudo stratis pool list
La salida muestra la cantidad total de almacenamiento; en el ejemplo anterior, 64 GB.

104 MiB de esos ya están ocupados por los metadatos requeridos para la administración
del grupo:
Figura 5.28: Detalles de almacenamiento del grupo stratis
Para obtener más detalles sobre los discos en el grupo y el uso, ejecute el siguiente comando:
sudo stratis blockdev list
Como puede ver en la siguiente captura de pantalla, obtenemos la misma salida, pero
con más detalles sobre los discos en el grupo y el uso. En la siguiente salida, puede ver
el estado y el nombre del grupo:
Figura 5.29: Estado y nombre del grupo
Aquí, el almacenamiento se utiliza para los datos, ya que también es posible tener un
disco configurado como memoria caché de lectura/escritura. Stratis forma un sistema
de archivos (que es xfs de forma predeterminada) sobre el grupo recién creado:
sudo stratis filesystem create stratis01 finance
El sistema de archivos tiene la etiqueta finance y es accesible a través del nombre del
dispositivo (/stratis/stratis01/finance) o UUID.
Con esta información, puede montarlo como lo haría con cualquier otro sistema de
archivos, como con los montajes de systemd, tal como lo analizaremos más adelante
en este capítulo.
Después de crear un sistema de archivos, puede crear instantáneas, que son
básicamente copias del sistema de archivos original. Se puede agregar una instantánea
mediante la ejecución de este comando:
sudo stratis filesystem snapshot stratis01 finance finance_snap
Para enumerar el sistema de archivos, se puede ejecutar el siguiente comando:

sudo stratis filesystem
Y tiene que montarlo como un sistema de archivos normal.

Agregar una memoria caché de lectura/escritura puede mejorar el rendimiento,
especialmente si se usa un disco con un mejor rendimiento que los discos SSD
estándar (o incluso discos que no son SSD). Digamos que este disco es /dev/sde:
sudo sudo stratis pool add-cache stratis01 /dev/sde
Y compruébelo de la misma manera, con el parámetro blockdev, tal como lo

hicimos anteriormente:
Figura 5.30: Adición de una memoria caché a /dev/sde disk

Para concluir la sección, analizamos varios sistemas de archivos; la elección dependerá
de sus requisitos. En primer lugar, debe asegurarse de que el sistema de archivos sea
compatible con su distribución; por ejemplo, BTRFS se quitó en RHEL 8. Por lo tanto,
siempre es mejor comprobar la compatibilidad antes de elegir.
systemd | 171
systemd
Después de que el kernel de Linux arranca, el primer proceso de Linux comienza el
primer proceso. Este proceso se conoce como un proceso init. En los sistemas Linux
modernos, este proceso es systemd. Observe la siguiente captura de pantalla, donde
se muestra el proceso en ejecución en un formato de árbol:
Figura 5.31: Vista de los procesos en ejecución en un formato de árbol
systemd es responsable de iniciar todos los procesos en paralelo durante el proceso de

arranque, excepto los procesos que crea el kernel. Después de eso, activa los servicios,
entre otras cosas, a petición. También hace un seguimiento de los puntos de montaje
y los administra, además de administrar configuraciones de todo el sistema, como el
nombre de host.
systemd es un sistema basado en eventos. Se comunica con el kernel y reaccionará a un
evento, como un momento específico o un usuario que introduce un nuevo dispositivo
o que presiona Ctrl + Alt + Supr.
Cómo trabajar con unidades

systemd trabaja con unidades, que son entidades administradas por systemd que
encapsulan información sobre cada objeto pertinente para systemd.
Los archivos de unidad son archivos de configuración que contienen directivas de
configuración, describen la unidad y definen su comportamiento. Estos archivos se
almacenan de la siguiente manera:
Figura 5.32: Archivos de unidad y su descripción
Las unidades se pueden administrar con la utilidad systemctl. Si desea ver todos los
tipos disponibles, ejecute el siguiente comando:
systemctl --type help
Para enumerar todos los archivos de unidad instalados, use el siguiente comando:
sudo systemctl list-unit-files
Para enumerar las unidades activas, use el comando siguiente:

sudo systemctl list-units
Tanto el parámetro list-unit-files como el parámetro list-units se pueden usar en

combinación con --type.
systemd | 173
Servicios
Las unidades de servicio están ahí para administrar scripts o demonios. Echémosle un
vistazo al servicio SSH:
Nota
Las capturas de pantalla se tomaron en Ubuntu 18.04. Los nombres de los
servicios pueden ser distintos en otras distribuciones.
Figura 5.33: Detalles del servicio ssh
Con el parámetro status de systemctl, puede ver que la unidad se carga, se habilita en
el arranque y ese es el valor predeterminado. Si no está habilitada, puede hacerlo con
este comando. Esto agregará el servicio a la cadena de inicio automático:
sudo systemctl enable <service name.service>
Para ver el estado del servicio, puede ejecutar este comando:

sudo systemctl status <service name>
En la salida, puede ver que el servicio SSH está en ejecución y que se muestran las
últimas entradas del registro:
Figura 5.34: Estado del servicio y entradas
Para ver el contenido del archivo unit, ejecute el siguiente comando:

sudo systemctl cat <service name.service>
Un archivo unit siempre tiene dos o tres secciones:

• [Unit]: descripción y administración de dependencias
• [<Type>]: configuración del tipo
• [Install]: sección opcional si quiere habilitar el servicio en el momento del arranque
Para manejar las dependencias, hay varias directivas disponibles; las más importantes
son las siguientes:
• before: la unidad especificada se retrasa hasta que se inicia esta unidad.
• after: la unidad especificada se inicia antes de que se inicie esta unidad.
• requires: si esta unidad está activada, la unidad que aparece aquí también lo
estará. Si se produjo un error en la unidad especificada, esta también presentará
un error.
• wanted: si esta unidad está activada, la unidad que aparece aquí también lo estará.
No hay consecuencias si se produce un error en la unidad especificada.
Nota
Si no especifica before o after, la unidad o las unidades que aparecen (separadas
por comas) se iniciarán al mismo tiempo que se inicia la unidad.
systemd | 175
A continuación, encontrará un ejemplo de un servicio ssh:

[Unit]
Description=OpenSSH Daemon After=network.target
[Service]
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
La mayoría de las opciones que aparecen en la sección Servicio son muy claras; si
no es así, consulte las páginas man de systemd.unit y systemd.service. En la sección
[Install], la directiva WantedBy indica que si habilita este servicio, se volverá parte de
la colección multi-user.target, que se activa en el arranque.
Antes de entrar en los destinos, lo último de lo que hay que hablar es cómo crear
invalidaciones. Las unidades systemd pueden tener muchas directivas distintas
y son muchas las opciones predeterminadas. Para mostrar todas las directivas posibles,
ejecute el siguiente comando:
sudo systemctl show
Si quiere cambiar uno de los valores predeterminados, use el siguiente comando:

sudo systemctl edit <service name.service>
Se inicia un editor. Agregue la entrada, por ejemplo, de la siguiente manera:

[Service]
ProtectHome=read-only
Guarde los cambios. Debe recargar los archivos de configuración de systemd y reiniciar
el servicio:
sudo systemctl daemon-reload
sudo systemctl restart sshd

Revise los cambios con systemctl cat sshd.service. Vuelva a iniciar sesión e intente
guardar algo en el directorio principal.
Nota
Si quiere otro editor para systemctl edit, agregue una variable, SYSTEMD_EDITOR,
al archivo /etc/environment, por ejemplo, SYSTEMD_EDITOR=/usr/bin/vim.
Destinos
Un destino es una colección de unidades. Existen dos tipos de destinos:
• No aislable: una colección normal de unidades; por ejemplo, timers.target, que
contiene todas las tareas programadas.
• Aislable: si ejecuta systemctl isolate <target name.target>, se apagarán todos
los procesos que no forman parte del destino y se iniciarán todos los que sí lo son.
Entre los ejemplos se incluyen las unidades rescue.target y graphical.target.
Para ver el contenido de un destino, use el siguiente comando:

systemctl list-dependencies <target name.target>
Tareas programadas
systemd se puede usar para programar tareas. A continuación, se muestra un ejemplo
de un archivo de unidad de temporizador:
[Unit]
Description=Scheduled backup task
[Timer]
OnCalendar=*-*-* 10:00:00
[Install]
WantedBy=timers.target
systemd | 177
Si guarda el contenido de este archivo en /etc/systemd/system/backup.timer, necesitará

un archivo correspondiente, /etc/systemd/system/backup.service, por ejemplo, con el
contenido siguiente:
[Unit]
Description = backup script
[Service]
Type = oneshot
ExecStart = /usr/local/bin/mybackup.sh
Habilite y active el temporizador:

sudo systemctl enable --now backup.timer
Para obtener información sobre las tareas programadas, use el siguiente comando:
sudo systemctl list-timers
Nota
Lea man 7 systemd.time para obtener más información sobre la sintaxis de los
eventos de calendario. Hay una sección especial en esta página man al respecto.
Si la tarea programada no es recurrente, puede usar el siguiente comando:

sudo systemd-run --on-calendar <event time> <command>
Por ejemplo, si queremos reflejar done en un archivo /tmp/done el 11 de octubre de 2019

a las 12:00 a. m., debemos hacerlo como se indica en la siguiente captura de pantalla:
Figura 5.35: Ejecución de una tarea programada al proporcionar la hora del evento
Cómo montar un sistema de archivos local

La unidad de montaje está disponible para montar sistemas de archivos. Hay algo
especial en el nombre de la unidad de montaje, porque debe corresponder al punto de
montaje. Por ejemplo, si quiere hacer un montaje en /home/finance, el archivo de unidad
del montaje se convierte en /etc/systemd/system/home-finance.mount:
[Unit]
Description = Finance Directory
[Mount]
What = /dev/sdc1
Where = /home/finance
Type = xfs
Options = defaults
[Install]
WantedBy = local-fs.target
Use systemctl start home-finance.mount para empezar el montaje y systemctl enable
home-finance.mount para hacer el montaje en el momento del arranque.
Cómo montar un sistema de archivos remoto

Si un sistema de archivos no es local, sino remoto, por ejemplo, si es un recurso
compartido de NFS, la mejor manera de montarlo es con automount. Si no usa
automount (el servicio autofs), debe montar manualmente el recurso compartido
remoto. Aquí la ventaja es que, si ya accedió al recurso compartido remoto, autofs se
montará de manera automática. De este modo, se montará el recurso compartido,
y si pierde la conexión con el recurso compartido, se intentará usar automount para
montar el recurso compartido a petición.
systemd | 179
Tiene que crear dos archivos. Tomemos como ejemplo un montaje NFS en /home/
finance. En primer lugar, cree /etc/systemd/system/home-finance.mount con el
siguiente contenido:
[Unit]
Description = NFS Finance Share
[Mount]
What = 192.168.122.100:/share
Type = nfs
Options = vers=4.2
Cree un archivo llamado /etc/systemd/system/home-finance.automount:
[Unit]
Description = Automount NFS Finance Share
[Automount]
[Install]
WantedBy = remote-fs.target
Inicie la unidad de montaje automático y no la unidad de montaje. Por supuesto, puede
habilitarla en el arranque.
Resumen
En este capítulo, profundizamos en Linux, explicando las tareas fundamentales
que tiene cada administrador de sistemas Linux: administrar software, la red, el
almacenamiento y los servicios.
Por supuesto, como administrador de sistema de Linux, esto no es algo que vaya a hacer
a diario. Lo más probable es que no lo haga manualmente, sino que lo automatice u
orqueste. Pero para poder orquestarlo, debe entender cómo funciona y tiene que poder
comprobar la configuración y solucionar los problemas relacionados. Esto se analizará
en el Capítulo 8, Exploración de la automatización de la configuración continua.
En el siguiente capítulo, exploraremos las opciones disponibles en Linux que limitan el
acceso al sistema:
• Control de acceso obligatorio
• Listas de control de acceso a la red
• Firewalls
También veremos cómo unir máquinas Linux al dominio mediante

Azure Active Directory Domain Services.
Preguntas
1. ¿Qué es responsable del reconocimiento de hardware?
2. ¿Qué es responsable de la nomenclatura de dispositivos?
3. ¿Cuáles son los métodos para identificar las interfaces de red?
4. ¿Quién mantiene la configuración de red?
5. ¿Cuáles son los métodos para identificar el almacenamiento conectado localmente?
6. ¿Por qué se usa RAID 0 en Azure?
7. ¿Cuáles son las opciones para implementar RAID 0 en Azure?
8. Intente implementar un dispositivo RAID 0 con tres discos y dele formato con XFS.
Móntelo y asegúrese de que se monta en el momento del arranque.
Lectura adicional | 181
Lectura adicional
Por un lado, este capítulo fue una revisión en profundidad, pero hay mucho más
que aprender en relación con todos los temas que se trataron en este capítulo.
Se recomienda leer las páginas man de todos los comandos utilizados.
Para el almacenamiento, además de la documentación que se encuentra en el sitio web
de Azure, algunos sistemas de archivos tienen sus propios sitios web:
• XFS: https://xfs.org
• BTRFS: https://btrfs.wiki.kernel.org
• ZFS: http://open-zfs.org
• Stratis: https://stratis-storage.github.io
Lennart Poettering, uno de los principales desarrolladores de systemd, tiene un muy buen
blog con muchas sugerencias e información general: http://0pointer.net/blog. Y hay más
documentación disponible en https://www.freedesktop.org/wiki/Software/systemd.
Como el comando systemctl status no proporciona información suficiente,
analizaremos más sobre el registro en el Capítulo 11, Solución de problemas y supervisión
de sus cargas de trabajo.
Administración
6
de seguridad
e identidades de Linux
En el capítulo anterior, analizamos el control del almacenamiento, junto con la
administración de redes y procesos. Sin embargo, como administrador del sistema,
su objetivo principal es proteger su máquina Linux para denegar cualquier acceso no
autorizado o limitar el acceso a los usuarios. En un entorno empresarial, las infracciones
de seguridad son una gran preocupación. En este capítulo, hablaremos sobre la seguridad:
la protección de su carga de trabajo en el nivel del sistema operativo; por ejemplo, si su
organización es una institución financiera en la que tratará con cargas de trabajo que se
ocupan de los compromisos monetarios e incluso la información de identificación personal
(PII) de los clientes, resulta fundamental asegurar la carga de trabajo para evitar cualquier
infracción. Por supuesto, Azure ya le proporciona servicios para proteger sus VM de muchas
maneras y en muchos niveles. A continuación, se muestran algunos de estos servicios:
• Azure Resource Manager, que proporciona características de seguridad, auditoría
y etiquetado
• Firewall de aplicaciones web, que protege contra muchos ataques, como la
inyección de código SQL
• La característica de filtrado de paquetes con estado de los grupos de seguridad de red
• Azure Firewall, que proporciona un firewall con estado estrechamente integrado
con las funciones de supervisión de Azure
184 | Administración de seguridad e identidades de Linux
También puede suscribirse al servicio Azure Security Center para la administración de

seguridad unificada con una serie de características atractivas, como la evaluación de
seguridad continua.
Con todas estas posibilidades, ¿todavía necesitamos protección en el nivel del sistema
operativo? En nuestra opinión, es buena idea contar con protección en varios niveles.
Un hacker tendrá que dedicar más esfuerzo y tiempo, lo que hará que sea más fácil
detectarlo. No existe un software sin errores: si una aplicación es vulnerable, debe
protegerse al menos el sistema operativo.
La administración de identidades es un tema que ciertamente está relacionado con
la seguridad. Puede integrar Linux con Azure Active Directory (Azure AD) para
centralizar sus cuentas de inicio de sesión, hacer que el acceso sea muy detallado
mediante el uso del control de acceso basado en roles, revocar el acceso y habilitar
la autenticación multifactor.
Al final de este capítulo, podrá:
• Implementar un sistema de control de acceso obligatorio (MAC), como SELinux
o AppArmor.
• Comprender los conceptos básicos del control de acceso discrecional (DAC).
• Usar los sistemas de administración de identidades disponibles en Azure.
• Mejorar la seguridad de Linux con systemd y el demonio de firewall.
Sugerencias de seguridad para Linux

Antes de profundizar en todas las grandes medidas de seguridad que puede adoptar,
compartimos algunas sugerencias con respecto a la seguridad.
La implementación de seguridad en varios niveles es, en general, una buena idea.
De esta manera, un hacker requiere distintos enfoques para obtener acceso, lo que
les cuesta tiempo. Debido a este momento y, con suerte, también por el registro
y la supervisión, tiene una mayor probabilidad de detectar accesos no autorizados.
Para los archivos y directorios, DAC sigue siendo una muy buena base. Haga que los
permisos sobre archivos y directorios sean lo más estrictos posible. Compruebe el
propietario y la propiedad del grupo y use las listas de control de acceso (ACL) en lugar
de permisos para usuarios no autorizados. Intente evitar usar el bit suid/sgid tanto
como sea posible. ¿Hay usuarios que necesiten cambiar su propia contraseña? ¿No?
A continuación, quite ese bit del comando passwd.
Use la creación de particiones, especialmente para directorios como /tmp, /var, /var/
tmp y /home, y móntelas con las marcas noexec, nodev y nosuid:
• En general, no es buena idea que un usuario pueda ejecutar programas desde
estas ubicaciones. Afortunadamente, si no puede establecer el propietario como
raíz, puede copiar un programa con el bit suid a su propio directorio como
usuario normal.
• Los permisos suid y sgid sobre los archivos de estos directorios son muy peligrosos.
• No permita la creación o la existencia de caracteres o dispositivos especiales en
esta partición.
Para acceder a la VM, use la autenticación basada en claves SSH, no contraseñas. Limite
el acceso a ciertas direcciones IP, mediante ACL o un firewall. Limite a los usuarios y no
permita acceso remoto para la raíz (use el parámetro PermitRootLogin no y AllowUsers
para solo permitir el acceso de una o dos cuentas). Use sudo para ejecutar comandos
como raíz. Tal vez crear usuarios especiales, o grupos de usuarios, para tareas
especiales en la configuración sudo.
No instale demasiado software en una VM, especialmente cuando se trata de servicios
de red, como servidores web y servidores de correo electrónico. Use el comando ss de
vez en cuando para revisar los puertos abiertos y compararlos con las reglas de firewall
o ACL.
Otra sugerencia es no deshabilitar SELinux en su sistema, que es un módulo de
seguridad en el kernel de Linux. No se preocupe por esto ahora, ya que tenemos
una sección dedicada a SELinux.
Mantenga actualizado su sistema; hay una razón por la que los proveedores de
Linux proporcionan actualizaciones. Hágalo manualmente o con una herramienta
de automatización/orquestación. Simplemente, hágalo.
Para los fines de este capítulo, tendrá que implementar RedHat/CentOS 7 y una VM
Ubuntu 18.04. Otra opción es usar SUSE SLE 12 u openSUSE LEAP en lugar de las VM
CentOS y Ubuntu. SUSE es compatible con todas las opciones que se describen en
este capítulo.
DAC
DAC también se conoce como control de acceso dictado por el usuario. Es posible que
ya esté familiarizado con los permisos clásicos en Linux y las ACL. Estos se combinan
para formar DAC. Los permisos clásicos comprueban el ID del usuario (UID) y el ID del
grupo (GID) del proceso actual. Los permisos clásicos hacen coincidir el UID y GID del
usuario que intenta acceder al archivo con el UID y el GID establecidos en el archivo.
Veamos cómo se introdujo DAC y qué nivel de permiso se tiene en Linux. Sin embargo,
no analizaremos esto en detalle, ya que la intención principal es familiarizarnos con los
permisos en Linux.
Introducción a DAC
La mayoría de los sistemas operativos, como Linux, macOS, variedades de Unix e incluso
Windows, se basan en DAC. MAC y DAC se definieron en los Trusted Computer System
Evaluation Criteria (TCSEC, Criterios de evaluación de los sistemas informáticos de
confianza), también conocidos como Orange Book, publicado por el DoD (Departamento
de Defensa) de los Estados Unidos. En la siguiente sección, analizaremos MAC. Como su
nombre indica, DAC permite a los propietarios o creadores de archivos decidir qué nivel
de acceso deben dar a otros usuarios para el mismo archivo.
Si bien vemos que DAC se implementa en todos los sistemas, también se considera
como débil. Por ejemplo, si concedemos acceso de lectura a un usuario, este será
de naturaleza transitiva. Por lo tanto, no hay nada que impida al usuario copiar el
contenido del archivo de otra persona a un objeto al que el usuario tiene acceso.
En otras palabras, la distribución de la información no se administra en DAC. En la
siguiente sección, veremos rápidamente los permisos de archivo.
Permisos de archivo en Linux

Cada archivo y directorio en Linux se trata como un objeto y tiene tres tipos de
propietarios: usuario, grupo y otro. En términos generales, a partir de ahora nos
referiremos a archivos y directorios como objetos. En primer lugar, entendamos los tres
tipos de propietarios distintos:
• Usuario: el usuario es la persona que crea el objeto. De manera predeterminada,
esta persona se convertirá en el propietario del objeto.
• Grupo: un grupo es una colección de usuarios. Todos los usuarios que forman
parte del mismo grupo tendrán los mismos niveles de acceso con respecto al
objeto. El concepto de un grupo hace que sea más fácil asignar permisos a varios
usuarios al mismo tiempo. Piense en un escenario en el que creará un archivo
y también querrá que los miembros de su equipo accedan al archivo. Si forma
parte de un equipo grande y asigna permisos a cada usuario, esto será caótico.
En lugar de eso, puede agregar los usuarios a un grupo y definir el permiso para
el grupo, lo que significa que todos los usuarios del grupo heredan el acceso.
DAC | 187
• Otro: se refiere a cualquier otro usuario que no sea el propietario (creador) del
objeto o que no forme parte del grupo de usuarios que podría poseer el objeto.
En otras palabras, piense en un conjunto que contiene al creador y a todos los
usuarios del grupo que tiene el permiso; “Otro” se refiere a un usuario que no
forma parte de este conjunto.
Como se indicó anteriormente, cada objeto tiene tres tipos de propietario. Cada propietario
(usuario, grupo, propietario) tendrá tres permisos sobre un objeto. Son los siguientes:
• Lectura: el permiso de lectura le permitirá leer o abrir un archivo. El permiso de
lectura sobre un directorio significa que el usuario podrá enumerar el contenido
del directorio.
• Escritura: si se aplica a un archivo, dará permiso para modificar el contenido
del archivo. Al agregar este permiso a un directorio, se concederá la facultad de
agregar, quitar y renombrar los archivos del directorio.
• Ejecutar: este permiso es obligatorio para ejecutar un programa o script ejecutable.
Por ejemplo, si tiene un script de Bash y tiene permiso de lectura/escritura, esto
significa que podrá leer y modificar el código. Sin embargo, para ejecutar el código,
necesita este permiso.
Aquí hay una representación gráfica de los propietarios y los permisos asociados:
Figura 6:1: Tipos de propietarios y permisos de acceso

Sigamos adelante y veamos cómo podemos averiguar los permisos del terminal de Linux.
Para enumerar el contenido de un directorio, ejecute ls -lah.
La salida será diferente en función del contenido que tenga en el directorio desde el que
se enumera:
Figura 6.2: Enumeración del contenido de un directorio
Si observa la línea data, la primera letra es d, lo que implica que es un directorio. En lo

que respecta a external.png, muestra -, que se refiere a un archivo, y hay l para home,
que se refiere a un vínculo (más como un acceso directo).
Echemos un vistazo más de cerca:
Figura 6.3: Línea de datos de la salida del directorio
En primer lugar, rwx denota que el usuario o propietario tiene permisos de lectura,
escritura y ejecución.
En segundo lugar, r-x indica que el grupo tiene permisos de lectura y ejecución.
Sin embargo, no existe permiso de escritura.
En tercer lugar, r-x indica que todos los demás tienen acceso de lectura y ejecución,
pero no acceso de escritura.
Del mismo modo, puede comprender los permisos asignados a otros objetos.
DAC | 189
Estos ya están escritos en el orden read(r), write(w) y execute. Si falta una letra, significa
que el permiso no existe. Esta es una tabla que explica lo que significan estas letras:
Figura 6.4: Símbolos para los permisos de acceso
Es posible que se pregunte quién es el propietario de este archivo y qué grupo obtiene
acceso. Esto se responde en la salida misma:
Figura 6.5: Detalles del propietario y del grupo
En este caso:
• El usuario tiene permiso de lectura y escritura, pero no tiene permiso de ejecución.
• El grupo tiene solo permiso de lectura y no tiene permiso de escritura ni ejecución.
• Todos los demás solo tienen permiso de lectura.
El siguiente diagrama lo ayudará a entender cómo diferenciar los permisos de

cada propietario:
Figura 6.6: Diferenciación de los permisos de cada propietario

Puede cambiar los permisos de un archivo o carpeta con el comando chmod. La sintaxis
general es:
chmod permissions filename/directory
Sin embargo, aplicar un permiso al directorio no hereda lo mismo a las subcarpetas

y archivos que ahí existen. Si quiere que los permisos se hereden, puede usar el
parámetro -R, que se refiere a recursivo.
Además, este comando no da ninguna salida; es decir, no devuelve ningún resultado,
independientemente de si aplicó o no los permisos. Puede usar el parámetro -v para
obtener una salida detallada.
Hay dos maneras en las que puede pasar permisos al comando chmod:
• Método simbólico
• Método absoluto/modelo numérico
Método simbólico
En el método simbólico, utilizaremos las denotaciones de usuarios y operadores.
La siguiente es una lista de operadores:
Figura 6.7: Operadores en el método simbólico
Y esta es una lista de las denotaciones de usuarios:
Figura 6.8: Denotaciones de usuarios
Ahora examinemos cómo podemos combinar el operador y la denotación para cambiar

el permiso. Usaremos el parámetro -v para entender lo que cambió.
DAC | 191
Recordemos cuáles eran los permisos que teníamos para el archivo external.png:
Figura 6.9: Permisos para el archivo external.png
A partir de ahora, el usuario no tiene permisos de ejecución. Para agregarlos, ejecute el

siguiente comando:
chmod -v u+x external.png
En la salida, puede ver que el valor se modificó de rw-r--r-- a rwxr--r--:
Figura 6.10: Incorporación de permisos de ejecución
Aquí verá algunos números. Analizaremos cuáles son cuando veamos el método absoluto.
A continuación, vamos a intentar escribir y ejecutar los permisos para el grupo
mediante la ejecución del siguiente comando:
chmod -v g+wx external.png
Por lo tanto, agregar wx(write, execute) a g(group) generará una salida similar a la
siguiente. Puede entender claramente el cambio de la salida:
Figura 6.11: Incorporación de permisos de escritura y ejecución a un grupo
Hasta ahora, hemos agregado permisos. Ahora, veamos cómo quitar los permisos de
lectura existentes de otros.
Ejecute lo siguiente:
chmod -v o-r external.png
Esto quitará el permiso de lectura, que es evidente en el siguiente resultado:
Figura 6.12: Eliminación del permiso de lectura

Establezcamos los permisos de lectura, escritura y ejecución para todos (usuario, grupo
y otro).
Ejecute el siguiente comando:
chmod -v a=rwx external.png
La salida muestra que los permisos cambiaron a rwxrwxrwx:
Figura 6.13: Configuración de permisos de lectura, escritura y ejecución para todos
Otro ejemplo implica combinar los permisos para cada propietario y pasarlos de una
sola vez, tal como se muestra aquí:
chmod -v u=rw,g=r,o=x external.png
Aquí, el permiso de usuario está establecido en lectura y escritura, el permiso de grupo

en solo lectura y el permiso de otro en solo ejecución. Del mismo modo, puede separar
los permisos mediante comas y usar los operadores necesarios para conceder permisos.
Nodo absoluto (numérico)

En este método, usaremos un número octal de tres dígitos para establecer el permiso.
A continuación, se muestra una tabla de valores y sus permisos correspondientes:
Figura 6.14: Valores numéricos y sus permisos correspondientes

DAC | 193
Veamos un ejemplo. Compruebe los permisos del archivo new-file, que se encuentra en
el directorio actual. Ejecute ls -lah:
Figura 6.15: Comprobación de permisos de new-file
Ahora, usemos el modo numérico y asignemos permisos. Cambiaremos el permiso

de usuario a rwx, para que 4 + 2 + 1 = 7, y luego cambie el permiso de grupo a rw, para
que 4 + 2 + 0 = 6, y solo ejecución para otros, para que 0 + 0 + 1 = 1.
Al combinar estos tres números, da 761, por lo que ese es el valor que se necesita pasar
a chmod.
Ejecute el siguiente comando:
chmod -v 761 new-file
La salida será la siguiente:
Figura 6.16: Asignaciones de permisos con el código octal de 3 dígitos
Ahora, podemos relacionar los números que obtuvimos en las salidas anteriores cuando
estábamos probando el método simbólico.
Esta es una representación gráfica del valor:
Figura 6.17: Representación gráfica del código octal de 3 dígitos

Es posible que haya notado que hay un dígito adicional antes del permiso que asignamos
(por ejemplo, 0761). Este 0 es para los permisos de archivos avanzados. Si recuerda las
sugerencias, dijimos que “Los permisos suid y sgid sobre los archivos de estos directorios
son muy peligrosos” e “Intente evitar usar el bit suid/sgid tanto como sea posible”. Estos
valores suid/sgid se pasan a través de un dígito adicional. Es mejor no usar esto y regirse
según el permiso básico, ya que estos son muy peligrosos y pueden ser complejos.
Ahora sabemos cómo cambiar el permiso, pero ¿cómo cambiaremos el usuario y el
grupo propietarios? Para esto, usaremos el comando chown. La sintaxis es la siguiente:
chown user:group filename/directory
Esto cambiará el propietario y el grupo del archivo. Si solo quiere cambiar el

propietario, puede usar esto:
chown user filename/directory
Si solo quiere cambiar el grupo, use el comando chgrp:

chgrp group filename/directory
Como se explica en el caso del comando chown, este comando tampoco es recursivo. Si
quiere hacer que el cambio se herede a la subcarpeta y a los archivos de un directorio, use
el parámetro -R (recursivo). También tiene una opción detallada (-v) como vimos en chmod.
Ahora que sabemos sobre la administración de permisos, vamos a la siguiente sección
sobre MAC. DAC se trataba de las comprobaciones de permisos mediante UID y GID.
Por otro lado, MAC es un control de acceso basado en directivas. Echemos un vistazo
más de cerca a MAC.
MAC
En MAC, un sistema limita el acceso a recursos específicos en función de la autorización
y la confidencialidad del recurso específico. Está más basado en directivas y se
implementa con los módulos de seguridad de Linux (LSM).
Las etiquetas de seguridad son la base de MAC. A cada persona se le otorga un nivel de
autorización de seguridad (por ejemplo, secreto o confidencial) y cada objeto de datos
obtiene una clasificación de seguridad. Por ejemplo, se deniega el acceso a un usuario
con un nivel de autorización de seguridad confidencial que intenta recuperar un objeto
de datos con una clasificación de seguridad ultrasecreta, porque su autorización es
menor que la clasificación del objeto.
Por lo tanto, es bastante obvio que puede usar el modelo de MAC principalmente en
aquellos entornos donde la confidencialidad es de suma importancia (instituciones
gubernamentales, etc.).
SELinux y AppArmor son ejemplos de sistemas comerciales basados en MAC.
MAC | 195
LSM
LSM es un marco para proporcionar una interfaz para agregar MAC sobre DAC. Esta
capa de seguridad adicional se puede agregar con SELinux (SUSE y distribuciones
basadas en Red Hat), AppArmor (Ubuntu y SUSE) o el menos conocido Tomoyo (SUSE).
En esta sección, analizaremos SELinux y AppArmor.
DAC es un modelo que proporciona control de acceso basado en usuarios que son
miembros de un grupo y permisos sobre archivos y dispositivos. MAC restringe el
acceso a objetos de recursos como los siguientes:
• Archivos
• Procesos
• Puertos TCP/UDP
• Usuarios y sus roles
MAC, como lo implementa SELinux, funciona asignando una etiqueta de clasificación,

también conocida como etiqueta contextual, a cada objeto de recurso, mientras que
AppArmor se basa en la ruta. En cualquier caso, si un objeto de recurso requiere acceso
a otro objeto, necesita autorización. Por lo tanto, incluso si un hacker entra en su
aplicación web, por ejemplo, los otros recursos siguen protegidos.
SELinux
Como mencionamos anteriormente, SELinux es un módulo de seguridad de Linux
y, como sugerencia de seguridad, se recomienda no deshabilitarlo. SELinux lo desarrolló
la NSA y Red Hat. El lanzamiento inicial se hizo el 22 de diciembre de 2000 y, en el
momento de escribir este libro, la versión estable disponible es 2.9, que se publicó
en 2019. Se puede utilizar en SUSE y en todas las distribuciones basadas en Red Hat.
En este libro se abarcará la implementación en Red Hat. Si quiere usarla en SUSE,
visite la documentación sobre SUSE en https://doc.opensuse.org/documentation/
leap/security/html/book.security/cha-selinux.html para instalar y habilitar SELinux.
Después de eso, los procedimientos son los mismos. En el pasado, se hizo algún
esfuerzo para que funcionara en Ubuntu pero, en este momento, no hay desarrollo
activo y los paquetes se dividen.
Todo el acceso se debe conceder de manera explícita pero, en las distribuciones que
utilizan SELinux, ya hay muchas directivas vigentes. Esto cubre casi todos los objetos de
recursos. Además de la lista ya mencionada en la documentación, abarca lo siguiente:
• La pila de red completa, incluido IPsec
• Funcionalidades de Kernel
• Comunicación entre procesos (IPC)
• Protección de la memoria
• Transferencia y herencia de descriptores de archivos (canales de comunicación)
Para las soluciones de virtualización de contenedores, como Docker, SELinux puede

proteger al host y ofrece protección entre contenedores.
Configuración de SELinux
SELinux se configura mediante el archivo /etc/selinux/config:
# Este archivo controla el estado de SELinux en el sistema.
# SELINUX= puede tomar uno de estos tres valores:
# enforcing: se aplica la directiva de seguridad de SELinux.
# permissive: SELinux imprime advertencias en lugar de aplicar las
directivas.
# disabled: no se carga ninguna directiva de SELinux.
SELINUX=enforcing
El estado debe estar en modo enforcing en un entorno de producción. Las directivas

se aplican y, si el acceso está restringido, se puede hacer una auditoría para poder
solucionar los problemas provocados por SELinux. El modo permissive puede resultar
útil si es empaquetador o desarrollador de software y necesita crear directivas de
SELinux para su software.
Es posible cambiar entre los modos enforcing y permissive con el comando setenforce.
Use setenforce 0 para cambiar al modo permissive y setenforce 1 para volver al modo
enforcing. El comando getenforce está disponible para ver el estado actual:
# SELINUXTYPE= puede tomar uno de estos tres valores:
# targeted: los procesos dirigidos están protegidos.
# minimum: modificación de la directiva dirigida.
# Solo se protegen los procesos seleccionados.
# mls: protección de seguridad de varios niveles.
SELINUXTYPE=targeted
MAC | 197
La directiva predeterminada, targeted, protege todos los recursos y proporciona

protección suficiente para la mayoría de las cargas de trabajo. La seguridad de varios
niveles (MLS) ofrece más seguridad mediante el uso de niveles de autorización
proporcionados por categorías y confidencialidades (como confidencial, secreto
y ultrasecreto) junto con roles y usuarios de SELinux. Esto puede ser muy útil para
los servidores de archivos que ofrecen recursos compartidos de archivos.
Si se selecciona el tipo minimum, solo se protege el mínimo básico; si quiere más
protección, tiene que configurar todo lo demás. Este tipo puede ser útil si hay
dificultades en la protección de una aplicación de varios procesos (por lo general,
aplicaciones muy antiguas) y una directiva generada elimina demasiadas restricciones.
En este escenario, es mejor dejar desprotegida la aplicación específica y proteger
el resto del sistema. En esta sección, solo analizaré SELINUXTYPE=targeted, que es la
opción que se usa más.
Para mostrar el estado de SELinux, puede usar el comando sestatus. El resultado debe
ser similar a la siguiente captura de pantalla:
Figura 6.18: Estado de SELinux
Antes de explorar SELinux, deberá agregar los paquetes necesarios al sistema para
poder auditar SELinux. Ejecute el siguiente comando:
sudo yum install setroubleshoot
Después de esto, deberá reiniciar la VM:

sudo systemctl reboot
Después del reinicio, estamos listos para usar SELinux y solucionar problemas que
puedan surgir:
SELinux context on ports
Comencemos con un ejemplo fácil que implica el servicio SSH. Como se indicó
anteriormente, todos los procesos se etiquetan con una etiqueta contextual. Para que
esta etiqueta sea visible, muchas utilidades, como ls, ps y lsof, tienen el parámetro -Z.
En primer lugar, debe descubrir el ID de proceso principal de este servicio:
systemctl status sshd | grep PID
Con este ID de proceso, podemos pedir la etiqueta contextual:

ps -q <PID> -Z
La etiqueta contextual es system_u, system_r, sshd_t y s0-s0, c0.c1023. Debido a que

usamos el tipo de SELinux dirigido, solo nos ocupamos de la parte del tipo SELinux: sshd_t.
SSH se ejecuta en el puerto 22. Ahora investiguemos la etiqueta en el puerto:
ss -ltn sport eq 22 -Z
Establecerá que la etiqueta contextual es system_u, system_r, sshd_t, s0-s0 y c0.c1023.

En otras palabras, exactamente la misma. No es difícil entender que el proceso sshd
implica, de hecho, tener permiso para ejecutarse en este puerto con la misma etiqueta:
Figura 6.19: Etiqueta contextual para el proceso sshd
No siempre es así de sencillo, pero antes de entrar en un escenario más complejo,

modifiquemos el puerto en el que el servidor SSH escucha al puerto 44. Para hacerlo,
edite el archivo /etc/ssh/sshd_config:
sed -i 's/#Port 22/Port 44/' /etc/ssh/sshd_config
Luego, reinicie el servidor SSH:

Esto generará un error:

Job for sshd.service failed because the control process exited with error
code.
See systemctl status sshd.service and journalctl -xe for details.
Si ejecuta el comando journalctl -xe, verá el siguiente mensaje:
SELinux is preventing /usr/sbin/sshd from name_bind access
on the tcp_socket port 44.
MAC | 199
Hay varios métodos para solucionar problemas de SELinux. Puede usar el archivo de
registro, /var/log/audit/audit.log, directamente o con el comando sealert -a /var/
log/audit/audit.log, o bien puede usar el comando journalctl:
journalctl --identifier setroubleshoot
La entrada de registro también indica lo siguiente:

For complete SELinux messages run: sealert -l <audit id>
Ejecute este comando (y tal vez tenga que redirigir la salida a un archivo o canalizarla
mediante less o more), y no solo le volverá a mostrar el mismo mensaje de SELinux, sino
que también vendrá con una sugerencia sobre cómo solucionarlo:
If you want to allow /usr/sbin/sshd to bind to network port 44
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 44
where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_
port_t.
Antes de pasar a esta solución, SELinux trabaja con varias bases de datos que contienen
el objeto de recurso y la etiqueta contextual, es decir, /, se debe aplicar al objeto de
recurso. La herramienta semanage está disponible para modificar la base de datos y
agregarle entradas; en nuestro escenario, el puerto de la base de datos. La salida del
registro sugiere agregar una etiqueta contextual para el puerto TCP 44 a la base de
datos. Hay tres contextos posibles; todos ellos solucionarán su problema.
Otro aspecto importante es el hecho de que a veces hay otras soluciones posibles.
Hay una clasificación de confianza para simplificarle la elección. Pero incluso así, de
todos modos tiene que leer con cuidado. Especialmente con los archivos, a veces desea
agregar una expresión regular en lugar de hacerlo para cada archivo una y otra vez.
Puede adoptar un enfoque pragmático y decir “No estoy usando vnc ni xserver, así
es que elijo ssh_port_t”, o bien puede usar la utilidad sepolicy, parte del paquete
policycoreutils-devel. Si recibe un mensaje de error, instale policycoreutils-devel
con sudo yum install –y policycoreutils-devel:
sepolicy network -a /usr/sbin/sshd
Busque en la salida el name_bind de TCP, porque el acceso de SELinux impide que /usr/
sbin/sshd tenga acceso de name_bind a tcp_socket port 44.
Ahora que sabe de dónde proviene la sugerencia, investigue la etiqueta actual del
puerto 22:
sepolicy network -p 22
La etiqueta es ssh_port_t.
Nota
Puede usar semanage port -l y grep en el puerto 22.
Realmente tiene sentido usar la misma etiqueta. ¿No está convencido? Generemos
páginas man:
sepolicy manpage -a -p /usr/share/man/man8/
mandb
La página man ssh_selinux le indica en la sección de tipos de puerto que la etiqueta
correcta es ssh_port_t.
Por último, solucionemos el problema:
semanage port -a -t ssh_port_t -p tcp 44
No es necesario que reinicie el servicio sshd; systemd reiniciará automáticamente este

servicio en 42 segundos. Por cierto, el archivo sshd_config ya tiene un comentario que
describe esta corrección. Se indica explícitamente en la línea antes de #Port 22:
If you want to change the port on a SELinux system, you have to tell:
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
Es buena idea deshacer el cambio de configuración y volver a establecerla en el
puerto 22; de lo contrario, es posible que se le bloquee el sistema de prueba.
Contexto de SELinux en archivos

Después de nuestro primer encuentro con SELinux y de investigar las etiquetas
contextuales en los puertos, es momento de investigar las etiquetas contextuales en
los archivos. Como ejemplo, vamos a usar un cliente y servidor FTP (protocolo de
transferencia de archivos). Instale vsftpd y un cliente FTP:
sudo yum install vsftpd ftp
Luego, cree un directorio denominado /srv/ftp/pub:

sudo mkdir -p /srv/ftp/pub
chown -R ftp:ftp /srv/ftp
MAC | 201
Y luego cree un archivo en /srv/ftp:

echo WELCOME > /srv/ftp/README
Edite el archivo de configuración, /etc/vsftpd/vsftpd.conf, y agregue lo siguiente

debajo de la línea local_enable=YES:
anon_root=/srv/ftp
Esto hace que /srv/ftp sea el directorio raíz predeterminado para el servicio vsftpd
para los usuarios anónimos. Ahora está listo para poner en marcha el servicio:
sudo systemctl start vsftpd.service
sudo systemctl status vsftpd.service
Con la utilidad ftp, intente iniciar sesión en el servidor FTP como usuario anonymous,
sin contraseña:
ftp localhost
Trying ::1...
Connected to localhost (::1).
220 (vsFTPd 3.0.2)
Name (localhost:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||57280|).
150 Here comes the directory listing.
-rw-r--r-- 1 14 50 8 Jul 16 09:47 README
drwxr-xr-x 2 14 50 6 Jul 16 09:44 pub
226 Directory send OK.
Try to get the file:
get README
Y funciona. ¿Cómo puede ser posible? Porque ya hay una entrada en la base de datos
para /srv/ftp/README con la etiqueta correcta:
semanage fcontext -l | grep /srv
El comando anterior muestra esta línea:

/srv/([^/]*/)?ftp(/.*)? all files system_u:object_r:public_content_t:s0
Se aplica al crear un nuevo archivo:

stat -c %C /srv/ftp/README
ls -Z /srv/ftp/README
Ambos comandos indican que el tipo es public_content_t. La página man de ftpd_
selinux tiene dos secciones que son importantes aquí: standard file context y sharing
files. La página man indica que el tipo public_content_t solo le permite leer (descargar)
archivos, pero que no tiene permiso para escribir (cargar) archivos con este tipo.
Necesita otro tipo, public_content_rw_t, para poder cargar archivos.
Cree un directorio de carga:
mkdir -m 2770 /srv/ftp/incoming
chown -R ftp:ftp /srv/ftp/incoming

Vea la etiqueta actual y cámbiela:
ls -dZ /srv/ftp/incoming
semanage fcontext -a -t public_content_rw_t "/srv/ftp/incoming(/.*)?"
restorecon -rv /srv/ftp/incoming
ls -dZ /srv/ftp/incoming
En primer lugar, debe agregar la directiva a la base de datos fcontext; después de eso,
puede aplicar la directiva al directorio ya existente.
Nota
Lea la página man de selinux-fcontext. Además de describir todas las opciones,
también hay algunos buenos ejemplos.
MAC | 203
SELinux Boolean
Con una sola cadena, puede cambiar el comportamiento de SELinux. Esta cadena
se denomina SELinux Boolean. Puede obtener una lista de los valores booleanos con
getsebool -a. Con boolean allow_ftpd_anon_write, cambiaremos cómo reacciona
SELinux. Vuelva a conectarse anónimamente al servidor FTP e intente cargar un
archivo otra vez:
ftp> cd /incoming
250 Directory successfully changed.
ftp> put /etc/hosts hosts
local: /etc/hosts remote: hosts
229 Entering Extended Passive Mode (|||12830|).
550 Permission denied.
El comando journalctl --identifier setroubleshoot lo pone muy claro:

SELinux is preventing vsftpd from write access on the directory ftp.
El comando sealert le proporcionará la información necesaria para corregir el problema:

setsebool -P allow_ftpd_anon_write 1
¿Qué está pasando aquí entonces? A veces, las reglas sencillas para un puerto o archivo
no son suficientes, por ejemplo, si un recurso compartido NFS se tiene que exportar
también con Samba. En este escenario, es posible crear su propia directiva de SELinux
compleja o utilizar la base de datos booleana con interruptores de encendido/apagado
fáciles de usar. Para hacerlo, puede usar la utilidad setsebool anterior o semanage:
semanage boolean --list | grep "ftpd_anon_write"
semanage boolean --modify ftpd_anon_write --on
Al usar setsebool sin -P, el cambio se hace, pero no es persistente. La utilidad semanage
no tiene la opción de modificarlo de manera no permanente.
AppArmor
En las distribuciones de Debian, Ubuntu y SUSE, AppArmor está disponible para
implementar MAC. Tenga en cuenta que hay algunas pequeñas diferencias entre las
distribuciones pero, en general, una distribución puede agregar menos o más perfiles
y algunas herramientas adicionales. En esta sección, usamos Ubuntu 18.04 como ejemplo.
Además, debe asegurarse de mantener actualizada la distribución, en especial con
AppArmor; los paquetes en Debian y Ubuntu estaban plagados de errores, lo que
a veces generaba un comportamiento inesperado.
Asegúrese de que están instalados los paquetes necesarios:

sudo apt install apparmor-utils apparmor-easyprof \
apparmor-profiles apparmor-profiles-extra apparmor-easyprof
Hay algunas diferencias fundamentales en comparación con SELinux:
• De forma predeterminada, solo se protege el mínimo básico. Necesita aplicar
seguridad para cada aplicación.
• Puede combinar los modos de aplicación y notificación; puede decidir con
respecto a cada aplicación.
• Cuando comenzó el desarrollo de AppArmor, el alcance era bastante limitado:
procesos y archivos. Actualmente, puede usarlo para el control de acceso basado
en roles (RBAC), MLS, directivas de inicio de sesión y, además, otros aspectos.
En este capítulo, trataremos el ámbito inicial: los procesos que necesitan acceso
a los archivos.
Estado de AppArmor
Lo primero que hay que hacer es comprobar si el servicio de AppArmor está
en funcionamiento:
sudo systemctl status apparmor
También puede ejecutar el siguiente comando:

sudo aa-enabled
Después de eso, vea el estado con mayor detalle con el siguiente comando:
sudo apparmor_status
Esta es una alternativa al comando anterior:

sudo aa-status
MAC | 205
La siguiente captura de pantalla muestra el estado de AppArmor, derivado del uso del
comando apparmor_status:
Figura 6.20: Estado de AppArmor
Generación de perfiles de AppArmor

Cada aplicación que quiere proteger requiere un perfil, proporcionado por los paquetes
apparmor-profiles o apparmor-profiles-extra, por el paquete de aplicación o por usted.
Los perfiles se almacenan en /etc/apparmor.d.
Instalemos el servidor web nginx como ejemplo:
sudo apt install nginx
Si explora el directorio /etc/apparmor.d, verá que no hay perfil para nginx. Cree
uno predeterminado:
sudo aa-autodep nginx
Se crea un perfil: /etc/apparmor.d/usr.sbin.nginx. Este archivo está casi vacío y solo

incluye algunas reglas y variables básicas, llamadas abstracciones, y la siguiente línea:
/usr/sbin/nginx mr,
El valor mr define el modo de acceso: r significa “modo de lectura” y m permite asignar

un archivo a la memoria.
Apliquemos el modo para nginx:
sudo aa-enforce /usr/sbin/nginx
sudo systemctl restart nginx
nginx no se iniciará. La salida del comando anterior es la siguiente:
sudo journalctl --identifier audit
Esto va muy claramente en la dirección de AppArmor:

sudo journalctl -k | grep audit
Para solucionar el problema, establezca el modo de notificación para este perfil. De este
modo, no aplica la directiva pero sí notifica cada infracción de la directiva de seguridad:
sudo aa-complain /usr/sbin/nginx
sudo systemctl start nginx
Haga una solicitud http con un explorador o una utilidad, por ejemplo, curl:
curl http://127.0.0.1
El siguiente paso es examinar logfile y aprovechar o rechazar cada acción:

sudo aa-logprof
MAC | 207
Lea atentamente y seleccione la opción correcta con las teclas de dirección

(si es necesario):
Figura 6.21: Configuración del perfil para nginx
LXC (Linux Containers) es una tecnología de contenedores y solo estamos

configurando el perfil para un servidor web. Algo para corregir con DAC parece ser una
buena opción:
Figura 6.22: Corrección de DAC para nginx
La auditoría sugiere un modo nuevo: w significa “acceso de escritura” al archivo /var/

log/nginx/error.log.
Además, puede bloquear el acceso a los siguientes directorios:

• Acceso de lectura a /etc/ssl/openssl.conf. Es difícil, pero la abstracción para ssl
suena bien.
• Acceso de lectura /etc/nginx/nginx.conf. Al igual que antes, no es un contenedor,
por lo que el propietario del archivo debe estar bien.
• En general, el propietario del archivo es una buena opción.
Ahora, es momento de guardar los cambios y volver a intentarlo:

sudo aa-enforce /usr/sbin/nginx
sudo systemctl restart nginx
curl http://127.0.0.1
Ahora todo parece funcionar, al menos para una solicitud a un sitio web simple. Como
puede ver, todo se basa en gran medida en conjeturas. La alternativa es profundizar en
todas las abstracciones sugeridas.
El archivo creado, /etc/apparmor.d/usr.sbin.nginx, es relativamente fácil de leer.
Comienza con todas las variables ajustables que deben estar disponibles para cada
perfil:
#include <tunables/global>
Al archivo lo siguen otras abstracciones, como la siguiente:

#include <abstractions/nameservice
Para saber lo que hacen, solo tiene que consultar el archivo. Por ejemplo, el archivo /
etc/apparmor.d/abstractions/nameservice indica lo siguiente:
/usr/sbin/nginx flags=(complain) {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/openssl>
#include <abstractions/web-data>
Nota
Muchos programas quieren realizar operaciones como servicio de nombres, como
buscar usuarios por nombre o ID, grupos por nombre o ID y hosts por nombre o
dirección IP. Estas operaciones se pueden hacer a través de archivos wins, hesiod,
LDAP, NIS+, NIS y DNS. Permita aquí todas estas opciones.
firewalld y systemd | 209
La siguiente sección se trata de las funcionalidades de POSIX; consulte man 7

capabilities para obtener más información:
capability dac_override,
La sección final son los permisos; para obtener una lista completa, consulte la sección
Modo de acceso en man 5 apparmor.d:
/var/log/nginx/error.log w,
owner /etc/nginx/modules-enabled/ r,
owner /etc/nginx/nginx.conf r,
owner /run/nginx.pid w,
owner /usr/lib/nginx/modules/ngx_http_geoip_module.so mr,
owner /usr/share/nginx/modules-available/mod-http-geoip.conf r,
owner /usr/share/nginx/modules-available/mod-http-image-filter.conf r,
owner /var/log/nginx/access.log w,
}
aa-logprof, en especial, puede ser un poco abrumador cuando lo empiece a usar.

Pero el perfil no es tan difícil de leer; cada opción está en las dos páginas man y las
abstracciones incluidas se documentan mediante comentarios.
firewalld y systemd
En el Capítulo 5, Administración avanzada de Linux, systemd se analizó como un
administrador de sistemas y servicios. En systemd, hay varias opciones para agregar
una capa adicional de protección a sus demonios y sistema de archivos.
Sinceramente, en nuestra opinión tiene sentido usar Azure Firewall en los grupos de
seguridad de red de Azure. Es fácil de configurar, proporciona administración central
y prácticamente no requiere mantenimiento. Proporciona seguridad entre VM, redes
virtuales e incluso distintas suscripciones de Azure.
Nota
Hay un costo adicional si quiere usar este firewall. Sin embargo, un firewall de
Linux no incurre en ningún cargo, ya que es una medida de seguridad instalada en
su máquina.
La elección entre Azure firewall y un Firewall de Linux depende de muchas cosas:

• Costo
• El desarrollo y la orquestación de sus VM y aplicaciones
• Roles distintos: ¿hay un administrador para todo?
Espero que después de cubrir una de las implementaciones de firewall de Linux quede
claro que un firewall de Linux no es de ninguna manera un reemplazo completo para
Azure Firewall. Solo puede proporcionar seguridad para el tráfico entrante a la VM y sí,
es posible configurar este firewall para bloquear también el tráfico saliente, pero eso es
bastante complejo. Por otro lado, si está configurado en los grupos de seguridad de red
de Azure, en muchos casos, eso es más que suficiente.
Existen distintos tipos de soluciones de firewall disponibles para Linux, como firewalld
e iptables, entre otras. En este libro, vamos a seguir a firewalld debido a las opciones
de configuración disponibles y su popularidad. Asegúrese de que el software firewalld
esté instalado y de quitar otro software de firewall del sistema para evitar conflictos.
En las distribuciones basadas en RHEL/CentOS, este ya es el caso. En Ubuntu, use los
siguientes comandos:
sudo apt remove ufw
sudo apt install firewalld
En las distribuciones basadas en SUSE, use los siguientes comandos:
sudo zypper install susefirewall2-to-firewalld
sudo susefirewall2-to-firewalld -c
Hay varias implementaciones de firewall para Linux; algunas de ellos incluso
desarrolladas para una distribución específica, como SuSEfirewall2. En este capítulo,
hablaremos de firewalld, que está disponible en cada distribución.
Firewalld consta de un demonio que administra todos los componentes del firewall:
• Zonas
• Interfaces
• Orígenes
• Reglas directas para iptables y ebtables (no aparecen en este libro)
firewalld utiliza módulos de kernel: tablas IP6/iptables para tráfico de IPv4 e IPv6
y ebtables para el filtrado del tráfico de red que pasa a través de un puente en Linux.
En las distribuciones más recientes, como RHEL 8, se usa el módulo nftables.
Para configurar las reglas de firewalld, hay disponible una utilidad de línea de
comandos: firewall-cmd. Las reglas pueden ser persistentes o solo en tiempo de
ejecución. Hay dos razones importantes para este comportamiento: de esta manera,
no es necesario volver a cargar todas las reglas, lo que implica un riesgo de seguridad
temporal. Puede agregar y quitar reglas de manera dinámica. Si se equivoca y no puede
volver a iniciar sesión por eso, una solución rápida y sencilla es reiniciar. También
podemos usar el comando systemd-run --oncalendar para crear una tarea programada
que ejecute firewall-cmd --reload, lo que es incluso una mejor solución:
sudo systemd-run --on-calendar='2018-08-20 13:00:00' \
firewall-cmd --reload
sudo systemctl list-timers
No olvide detener y deshabilitar el temporizador si las reglas del firewall eran correctas
(y no se bloqueó su acceso).
También puede configurar el demonio con herramientas de orquestación que se
comuniquen con el demonio o insertar archivos XML en el host.
Nota
Los puertos solo están abiertos para las VM conectadas a la red de la máquina
virtual, a menos que abra los puertos en el grupo de seguridad de red.
Es importante saber que Azure Service Fabric (la infraestructura) agregará, si es

necesario, reglas adicionales a la configuración del firewall. Se recomienda no quitar
estas reglas, ya que son importantes, dado que las usa la plataforma Azure. Puede ver
esto si busca en la base de datos de registro con el comando journalctl:
sudo journalctl | grep "Azure fabric firewall"
Use el comando iptables-save para ver todas las reglas activas del firewall o si la
distribución usa nftables:
sudo nft list ruleset
Zonas de firewalld
Uno de los conceptos más importantes de firewalld es la zona. Una zona consta de una
regla predeterminada, llamada destino, una interfaz de red o un origen de red, además
de servicios, puertos, protocolos y reglas enriquecidas adicionales.
Una zona solo está activa si una interfaz de red está conectada a la interfaz o a un
origen de red.
Para enumerar las zonas disponibles, use el comando siguiente:
sudo firewall-cmd --get-zones
Estas zonas se configuran en /usr/lib/firewalld/zones. No debe hacer cambios en

estos archivos. Las zonas nuevas o los cambios de una zona se escriben en el directorio
/etc/firewalld/zones.
La zona predeterminada es la zona pública:
sudo firewall-cmd --get-default-zone
Para enumerar la configuración de zona de la zona pública, use el comando siguiente:

sudo firewall-cmd --zone public --list-all
La configuración de la zona será como se muestra aquí:

public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
La zona pública tiene la directiva de destino default, lo que significa que todo
el tráfico entrante se bloquea de manera predeterminada, excepto los servicios,
puertos y protocolos configurados.
El archivo /usr/lib/firewalld/zones/public.xml correspondiente a esta zona es
el siguiente:
<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers
on networks to not harm your computer. Only selected incoming connections
are accepted.</description>
<service name="ssh"/>
<service name="dhcpv6-client"/>
</zone>
También hay opciones para configurar el enmascaramiento y el enrutamiento de

puerto. Las reglas enriquecidas son reglas de firewall avanzadas, tal como se describe
en la página man firewalld.richlanguage.
Ejecute man firewalld.richlanguages, tal como se muestra en la siguiente captura
de pantalla:
Figura 6.23: Salida del comando man firewalld.richlanguages

Según la distribución que esté utilizando, es posible que tenga nombres de servicio
adicionales. Por ejemplo, si usa RHEL 8, es posible que cockpit aparezca como servicio.
cockpit es una interfaz web que se usa para administrar máquinas RHEL.
Puede que haya notado que, en la zona pública, dice target: default. El destino es el
comportamiento predeterminado. Los posibles valores son los siguientes:
• default: no haga nada, acepte cada paquete de ICMP y rechace todo lo demás.
• %%REJECT%%: esto envía una respuesta de rechazo al cliente a través del
protocolo ICMP.
• DROP: esto envía un SYN/ACK de TCP, como en un puerto abierto, pero se descarta
todo el resto del tráfico. No hay ningún mensaje de ICMP para informar al cliente.
• ACCEPT: acepte todo.
De manera predeterminada, en Ubuntu no hay ninguna interfaz de red adjunta. No

reinicie la VM antes de que se adjunte una interfaz. Ejecute el siguiente comando:
sudo firewall-cmd --add-interface=eth0 --zone=public
sudo firewall-cmd --add-interface=eth0 --zone=public --permanent
sudo firewall-cmd --zone=public --list-all

Si modifica una zona, el archivo se copia de /usr/lib/firewalld/zones a /etc/firewalld/
zones. La siguiente modificación creará una copia de seguridad de la zona con la
extensión de archivo .old y creará un archivo que contenga las modificaciones.
Servicios de firewalld
Un servicio es una configuración centrada en la aplicación para permitir uno o más
puertos. Para recibir una lista de los servicios disponibles, use el siguiente comando:
sudo firewall-cmd --get-services
Si quiere agregar un servicio, por ejemplo, MySQL, ejecute los siguientes comandos:
sudo firewall-cmd --add-service=mysql --zone=public
sudo firewall-cmd --add-service=mysql --zone=public \

--permanent
Si quiere quitar un servicio de una zona, use el parámetro --remove-service.

Los servicios se configuran en el directorio /usr/lib/firewalld/services. Como ya
mencionamos, no debe modificar estos archivos. Si quiere cambiarlos o crear archivos
propios, cópielos en el directorio /etc/firewalld/services.
También es posible agregar puertos individuales pero, en general, no es buena idea:
¿todavía puede recordar después de un tiempo qué puertos usa qué aplicación? En su
lugar, si el servicio aún no está definido, cree su propio servicio.
Ahora crearemos un archivo de servicio para el protocolo de firewall PPTP de Microsoft,
/etc/firewalld/services/pptp.xml:
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>PPtP</short>
<description>Microsoft VPN</description>
<port protocol="tcp" port="1723"/>
</service>
En el archivo anterior, puede ver que se permite el puerto TCP 1723. Puede agregar
tantas reglas de puerto como quiera. Por ejemplo, si quiere agregar el puerto TCP 1724,
el elemento de línea será el siguiente:
<port protocol="tcp" port="1724" />
Después de recargar el firewall con firewalld-cmd --reload, el servicio está disponible.

Esto no es suficiente: no se permite el protocolo GRE (encapsulación de enrutamiento
genérico). Para permitir este protocolo, use los siguientes comandos:
sudo firewall-cmd --service=pptp --add-protocol=gre \
--permanent
sudo firewall-cmd --reload
Esto agregará la siguiente línea al archivo de servicio:

<protocol value="gre"/>
Puede quitar el protocolo con el parámetro --remove-protocol.

Orígenes de red de firewalld

Una zona solo está activa cuando una interfaz de red está conectada a ella o a un
origen de red. No tiene sentido agregar una interfaz de red al área de colocación. El
área de colocación es donde se abandonan todos los paquetes entrantes que no tienen
respuesta; sin embargo, sí se permiten las conexiones salientes. Entonces, como ya
mencioné, si agrega la interfaz de red al área de colocación, firewalld abandonará todos
los paquetes entrantes, lo que no tiene ningún sentido.
Sin embargo, sí tiene sentido agregar un origen de red. Un origen consta de una o más
entradas: una dirección de control de acceso de medios, direcciones IP o intervalos IP.
Por ejemplo, por cualquier motivo, supongamos que quiere bloquear todo el tráfico
de las Bermudas. El sitio web http://ipdeny.com puede proporcionarle una lista de
direcciones IP:
cd /tmp
wget http://www.ipdeny.com/ipblocks/data/countries/bm.zone
Existen varios tipos de ipset. Para ver la lista de tipos ipset compatibles, ejecute el
siguiente comando:
sudo firewall-cmd --get-ipset-types
En nuestro escenario, queremos el tipo para los intervalos IP hash:net:

sudo firewall-cmd --new-ipset=block_bermuda --type=hash:net --permanent
Ahora podemos agregar entradas a ipset con el archivo descargado:
sudo firewall-cmd --ipset=block_bermuda --add-entries-from-file=/tmp/bm.zone
sudo firewall-cmd --ipset=block_bermuda --add-entries-from-file=/tmp/bm.zone \
--permanent
El paso final consiste en agregar ipset como origen a la zona:

sudo firewall-cmd --zone=drop --add-source=ipset:block_bermuda
sudo firewall-cmd --zone=drop --add-source=ipset:block_bermuda --permanent
El propósito del área de colocación es abandonar todo el tráfico sin dejar que el cliente
sepa que el tráfico se descarta. Agregar ipset a esta zona hace que esté activa y se
abandonará todo el tráfico proveniente desde las Bermudas.
sudo firewall-cmd --get-active-zones
drop
sources: ipset:block_bermuda
public
interfaces: eth0
Ahora que sabemos cómo funciona firewalld y cómo podemos proteger nuestra
máquina mediante el uso de las zonas, pasemos a la siguiente sección.
Seguridad de systemd
Tal como se mencionó en el capítulo anterior, systemd es responsable de iniciar todos
los procesos en paralelo durante el proceso de arranque, excepto los procesos que
crea el kernel. Después de eso, es cuestión de activar los servicios, entre otras cosas,
a petición. Las unidades systemd también pueden proporcionar una capa adicional de
seguridad. Puede agregar varias opciones al archivo de unidad para que su unidad sea
más segura.
Simplemente edite el archivo de unidad con systemctl edit y agregue las medidas de
seguridad. Por ejemplo, ejecute el siguiente comando:
sudo systemctl edit sshd
Luego, agregue las siguientes líneas:

[Service]
ProtectHome=read-only
Guarde el archivo, vuelva a leer la configuración systemctl y reinicie sshd:
sudo systemctl daemon-reload
Ahora, vuelva a iniciar sesión con su cliente SSH e intente guardar un archivo en
el directorio principal. Esto generará un error, porque es un sistema de archivo de
solo lectura:
Figura 6.24: Error al iniciar sesión porque el archivo de unidad cambió a de solo lectura
Restricción del acceso al sistema de archivos

El parámetro ProtectHome es muy interesante. Están disponibles los siguientes valores:
• true: la unidad no puede acceder a los directorios /home, /root y /run/user y se ven
vacíos para los procesos que empiezan dentro de la unidad.
• read-only: estos directorios son de solo lectura.
Otro parámetro muy similar es ProtectSystem:

• true: /usr y /boot se montan como de solo lectura.
• full: /etc se monta como de solo lectura junto con /usr y /boot.
• strict: todo el sistema de archivos es de solo lectura, excepto /proc, /dev y /sys.
En lugar de ProtectHome y ProtectSystem, además, puede usar estos parámetros:

ReadWritePaths para agregar directorios a la lista blanca, ReadOnlyPaths e InaccessiblePaths.
Algunos demonios usan el directorio /tmp para el almacenamiento temporal. El
problema con este directorio es que lo pueden leer todos. El parámetro PrivateTmp=true
configura un nuevo sistema de archivos temporal para el proceso, al que solo puede
acceder el proceso.
También hay parámetros relacionados con el kernel: el parámetro
ProtectKernelModules=true hace que sea imposible cargar módulos y el parámetro
ProtectKernelTunables=true hace que sea imposible cambiar los parámetros de kernel
con el comando sysctl o manera manual en la estructura de directorio /proc y /sys.
Por último, pero no menos importante, los parámetros SELinuxContext
y AppArmorProfile imponen el contexto para la unidad.
Restricción del acceso a la red

systemd también se puede utilizar para restringir el acceso a la red, ya que puede
enumerar las direcciones IP que se pueden permitir o denegar. Las versiones más
recientes de systemd, después de la versión 235, como las que usan Ubuntu 18.04,
SLE 15 SP1 y RHEL 8, también admiten las listas de acceso y contabilidad de direcciones
IP para restringir el acceso a la red.
IPAccounting=yes permite que una unidad recopile y analice los datos de la red. Para ver
los resultados, puede usar el comando systemctl:
systemctl show <service name> -p IPIngressBytes \
-p IPIngressPackets \
-p IPEgressBytes -p IPEgressPackets
Al igual que lo que ocurre con cada parámetro, puede usar esto también con systemd-run:
Figura 6.25: Uso de systemd-run y systemctl para recopilar y analizar los datos de red
Puede usar IPAddressDeny para denegar una dirección IP o un intervalo IP. Se puede
hacer una excepción con IPAddressAllow. Incluso es posible denegar todo en el sistema
y agregar cada servicio a una lista blanca:
sudo systemctl set-property sshd.service IPAddressAllow=any
sudo systemctl set-property waagent.service IPAddressAllow=10.0.0.1
Nota
Si usa Ubuntu, el nombre de servicio es walinuxagent.
sudo systemctl set-property system.slice IPAddressAllow=localhost

sudo systemctl set-property system.slice IPAddressAllow=10.0.0.1
sudo systemctl set-property system.slice IPAddressDeny=any
Los cambios se guardan en la estructura de directorio /etc/systemd/system.control:
Figura 6.26: Cómo guardar los cambios en el directorio system.control
Algunos comentarios:
• Por supuesto, tiene que cambiar el intervalo IP a la subred virtual y debe permitir
el acceso a la primera dirección IP de la subred para el servicio de red y el agente
de Azure, como DHCP (Protocolo de configuración dinámica de host).
• También es muy buena idea restringir el acceso SSH a la dirección IP de su
propia red.
• Consulte cuidadosamente el diario de systemd para saber si necesita abrir
más puertos.
La característica de lista de acceso de systemd quizás no sea tan avanzada como

firewalld, pero es una muy buena alternativa para las restricciones en el nivel
de aplicación (los hosts permiten directivas en los archivos de configuración del
demonio o /etc/hosts.allow y /etc/hosts.deny para aplicaciones que se compilan con
compatibilidad con libwrap). Y en Azure, en nuestra opinión, no necesita más que esto.
Si solo todas las distribuciones tuvieran una versión reciente de systemd.
Nota
En este libro no se habla de libwrap, porque cada vez son más las aplicaciones
que ya no usan esta opción y algunos proveedores, como SUSE, están ocupados
quitando el soporte completo para esta biblioteca.
Administración de identidades y acceso en Azure: IAM | 221
Administración de identidades y acceso en Azure: IAM

Hasta ahora, hemos analizado cómo administrar la seguridad en Linux. Como estamos
haciendo la implementación en Azure, Azure también proporciona cierta seguridad
agregada a nuestras VM Linux. Por ejemplo, anteriormente, analizamos Azure Firewall
y los grupos de seguridad de red, que ayudan a controlar el tráfico, limitar el acceso
a puertos no deseados y filtrar el tráfico procedente de ubicaciones desconocidas.
Además de esto, hay otros servicios en Azure, como Azure AD Domain Services, que le
permiten unir una VM Linux a un dominio. Recientemente, Microsoft lanzó una opción
por la cual los usuarios de Azure AD pueden iniciar sesión en la VM Linux. La ventaja
de esto es que no tiene que usar otros nombres de usuario; en su lugar, puede usar las
credenciales de Azure AD. Examinemos más de cerca estos servicios y entendamos
cómo podemos usarlos para aumentar la seguridad de nuestras VM Linux.
Azure AD Domain Services

Hasta ahora, hemos analizado lo que se puede hacer dentro de la VM Linux. Dado
que estamos en Azure, debemos aprovechar Azure AD Domain Services, con lo que
puede unir sus máquinas Linux a un dominio y aplicar las directivas de su organización.
Azure AD Domain Services es un controlador de dominio como servicio que
proporciona un servicio DNS y administración de identidades. La administración central
de identidades siempre es parte importante de las soluciones de seguridad. Permite
que el usuario acceda a los recursos. Además, puede aplicar directivas y habilitar la
autenticación multifactor.
En esta sección, nos centraremos en cómo configurar un servicio y cómo unirse
a un dominio.
Configuración de Azure AD Domain Services

La forma más sencilla de configurar Azure AD Domain Services es a través de Azure
Portal. En la barra de la izquierda, seleccione Crear un recurso y busque Servicios de
dominio. Seleccione Azure AD Domain Services y haga clic en el botón Crear.
En el asistente, se le pedirán algunas configuraciones:
• Nombre de dominio: puede usar un nombre de dominio propio o uno integrado
que termine con .onmicrosoft.com. Eso basta para los fines de este libro.
• Red virtual: se recomienda crear una red virtual y una subred. No importa
el etiquetado.
• Administradores: se creará un grupo denominado Administradores de AAD DC.
Para unirse a un dominio con un usuario, el usuario debe ser miembro de este
grupo, usando la sección Active Directory que se encuentra en la barra de la
izquierda de Azure Portal.
Ahora está listo para implementar el servicio. Esto tardará un poco; en mi experiencia
personal, puede tardar de 20 a 30 minutos.
Cuando termine, vaya a la sección Redes virtuales que se encuentra en la barra de la
izquierda y escriba la red virtual que recién se creó. Encontrará dos interfaces de red
recién creadas y sus direcciones IP. Anote esta información, porque la va a necesitar.
Se recomienda crear una subred en esta red virtual, pero no es necesario.
Configuración de Linux
Tiene que implementar la VM Linux en la misma red virtual o en una red emparejada
donde esté implementado Azure AD Directory Services. Como ya se indicó,
se recomienda conectarla a otra subred. Aquí, no seguimos el LDAP seguro.
Nombre de host
Cambie el nombre de host con la utilidad hostnamectl al fqdn correcto:
sudo hostnamectl set-hostname ubuntu01.frederikvoslinvirt.onmicrosoft.com
Luego, edite el archivo /etc/hosts. Agregue una entrada como la siguiente:

127.0.0.1 ubuntu01.frederikvoslinvirt.onmicrosoft.com ubuntu01
Servidores DNS
En la barra de la izquierda de Azure Portal, vaya a Redes virtuales y navegue a la subred
donde se encuentran las interfaces de red de Azure AD Domain Services. Seleccione
Servicios DNS y use las opciones personalizadas para establecer las direcciones IP de
las interfaces de red de Azure AD Domain Services. Al hacerlo, siempre que se requiera
la resolución DNS del nombre de host, apuntará a Azure AD Domain Services.
Como alternativa, si su instancia de Azure AD Domain Services es una implementación
nueva en el panel Información general de Azure Portal, se le pedirá cambiar los
servidores DNS. Simplemente haga clic en el botón Configurar si quiere cambiar los
servidores DNS de la red virtual para que apunten a Azure AD Domain Services.
Por lo general, reiniciar la red de la VM debería bastar, pero es mejor reiniciar ahora.
De vez en cuando, sobreviven tanto la configuración nueva como la antigua.
En RHEL, Ubuntu y SUSE, vea el contenido del archivo /etc/resolv.conf para
comprobar el resultado. Luego, observe la configuración de eth0.
Instalación de dependencias
Hay algunos componentes y dependencias importantes que se requieren para poder
usar Azure AD Domain Services:
• Un cliente Kerberos, para la autorización
• SSSD, un back-end que es responsable de la configuración y utilización de
características como el uso y el almacenamiento en caché de credenciales
• Bibliotecas de Samba, para admitir las opciones o características de Windows
• Algunas utilidades para unirse al dominio y administrarlo, como realm, adcli
y el comando net
Instale el software necesario para poder unirse al dominio.

Para distribuciones basadas en RHEL/CentOS, ejecute el siguiente comando:
sudo yum install realmd sssd krb5-workstation krb5-libs samba-common-tools
En Ubuntu, ejecute el siguiente comando:

sudo apt install krb5-user samba sssd sssd-tools libnss-sss libpam-sss
realmd adcli
En SLE/OpenSUSE LEAP, YaST controlará las dependencias.
Unión al dominio: Ubuntu y RHEL/CentOS

En las distribuciones basadas en Ubuntu y en RHEL/CentOS, la utilidad realm está
disponible para unirse al dominio. En primer lugar, detecte el dominio:
sudo realm discover <your domain>
La salida debería ser similar a esta:
Figura 6.27: Detección del dominio
Ahora está listo para unirse al dominio:

sudo realm join <your domain> -U <username@domain>
Use el nombre de usuario que agregó anteriormente como miembro del grupo de
administradores de Azure AD Domain Services. Si recibe un mensaje que indica
Necessary packages are not installed (Los paquetes necesarios no están instalados),
pero está seguro de que sí están instalados, agregue el parámetro --install=/ al
comando realm.
Para comprobar el resultado, ejecute el siguiente comando:
sudo realm list
La salida debe ser similar a lo siguiente:
Figura 6.28: Unión al dominio
Debería ser capaz de hacer cosas como las siguientes:

id <user>@<domain>
su <user>@<domain>
Inicie sesión de manera remota con ssh con este usuario.
Nota
Si no funciona y la unión se realizó correctamente, reinicie la VM.
Unión al dominio: SUSE

En SUSE SLE y LEAP, la mejor manera de unirse al dominio es mediante YaST.
Inicie la utilidad YaST:
sudo yast
En la ventana principal de YaST, inicie el módulo User Logon Management

(Administración de inicio de sesión del usuario) y haga clic en Change Settings
(Cambiar configuración). Haga clic en Join Domain (Unirse a un dominio) y rellene el
nombre del dominio. Después de eso, podrá inscribirse correctamente en el dominio.
Si es necesario, se instalarán las dependencias.
Aparecerá una nueva ventana para administrar los inicios de sesión de usuario del
dominio. Necesita al menos lo siguiente: Allow Domain User Logon (Permitir inicio de
sesión de usuario del dominio) y Create Home Directory (Crear directorio principal).
Todas las demás opciones todavía no son posibles en Azure AD Domain Services.
YaST le dará una interfaz colorida como una GUI en el shell, cuyo uso significa
que puede unir la máquina al dominio. Una vez que ejecute sudo yast, recibirá una
pantalla como se muestra aquí. En la lista, use las teclas de dirección para seleccionar
Network Services (Servicios de red) y, luego, Windows Domain Membership
(Pertenencia a dominio de Windows):
Figura 6.29: Interfaz de YaST en el shell

La mejor parte es que si faltan dependencias, YaST le pedirá que las instale, así que siga
y complete la instalación de dependencias. Inmediatamente después de la instalación,
puede escribir su nombre de dominio y, una vez que lo guarde, se le pedirá que escriba
el nombre de usuario y la contraseña, tal como se muestra en la siguiente captura
de pantalla:
Figura 6.30: Ingreso de las credenciales para registrar la máquina

Escriba sus credenciales con el formato usuario@dominio y, luego, la contraseña. Una

vez que complete el proceso, la máquina SUSE se comunicará con Azure AD Domain
Services y registrará su máquina. Si la unión se realiza correctamente, recibirá un
mensaje en pantalla tal como se ve aquí:
Figura 6.31: La unión al dominio se realizó correctamente
Para comprobarlo, cambie el usuario actual a su nombre de usuario de AD con el

comando su, tal como se muestra en la siguiente captura de pantalla:
Figura 6.32: Comprobación de la unión al dominio

Por fin terminamos de unir nuestra máquina Linux a Azure AD Domain Services.
Recientemente, Microsoft agregó compatibilidad con el inicio de sesión de Azure AD en
las VM Linux sin necesidad de unir las máquinas al dominio. Se instalará un agente en la
máquina para completar la autorización. Esto se analizará en la siguiente sección.
Inicio de sesión con las credenciales de Azure AD en la VM Linux

Con Azure AD, es posible otra forma de administración de identidades. Este es un
sistema de administración de identidades totalmente distinto, sin LDAP ni Kerberos,
como se analizó en la sección anterior. En Linux, Azure AD le permitirá usar sus
credenciales de Azure para iniciar sesión en su VM, pero no es compatible en el nivel
de aplicación. En el momento de escribir este libro, esta característica sigue en versión
preliminar. Además, esta característica no está disponible en SUSE.
Para poder usar Azure AD, tiene que implementar una extensión de VM, por ejemplo,
mediante la CLI de Azure:
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--vm-name myVM
Después de esto, debe asignar un rol, ya sea el rol Inicio de sesión de administrador
de máquina virtual (con privilegios raíz) o el rol Inicio de sesión de usuario de
máquina virtual (usuario sin privilegios), a su cuenta de Azure AD, con el ámbito
limitado a esta VM:
az role assignment create \
--role "Virtual Machine Administrator Login" \
--assignee <ad user name> \
--scope <your vm>
Aquí, puede establecer el ámbito en el nivel de suscripción, --scope /

subscriptions/<subcription ID>. Al hacerlo, todos los recursos de la
suscripción heredarán el rol.
Si quiere tener acceso pormenorizado solo a una VM determinada, puede ejecutar el

siguiente comando (en PowerShell):
$vm = Get-AzVM –Name <VM Name> -ResourceGroup <resource group>
$vm.Id le dará el alcance de la VM.

En Bash, ejecute el siguiente comando:
az vm show --name<name> --resource-group <resource group> --query id
Este comando consultará el ID de la VM y es el ámbito de la asignación de roles.

Puede iniciar sesión con sus credenciales de AD:
ssh <ad user>@<ad domain>@<ip address>
Por último, podrá ver que inició sesión en la VM Linux con sus credenciales de Azure AD.
Otras soluciones de seguridad en Azure

En este capítulo, analizamos cómo aumentar el nivel de seguridad de Linux e incorporar
ciertos servicios de Azure para mejorar la seguridad. Dicho esto, la lista de los servicios
de Azure que se pueden usar para aumentar la seguridad es muy larga. Aquí destacamos
algunos de ellos:
• Identidad administrada de Azure AD: con esto, puede crear identidades
administradas para máquinas virtuales, que se pueden usar para autenticar
cualquier servicio que admita la autenticación de Azure AD (https://docs.
microsoft.com/es-xl/azure/active-directory/managed-identities-azure-
resources/overview). Anteriormente, este servicio se conocía como Managed
Service Identity (MSI), que ahora se denomina como identidades administradas
para recursos de Azure.
• Key Vault: se puede usar para almacenar las claves de manera segura. Por ejemplo,
en Azure Disk Encryption, la clave se almacenará en un almacén de claves al que
se podrá acceder cuando sea necesario (https://docs.microsoft.com/es-xl/azure/
key-vault/basic-concepts).
• Azure Disk Encryption: el cifrado de discos lo ayudará a cifrar el disco del
sistema operativo, así como el disco datos, para tener más seguridad en los datos
almacenados (https://docs.microsoft.com/es-xl/azure/virtual-machines/linux/
disk-encryption-overview).
Resumen | 231
• RBAC: RBAC en Azure le ofrece la capacidad de asignar permiso pormenorizado

a las máquinas virtuales. Hay muchos roles integrados disponibles en Azure
y puede asignarlos según sus requisitos de seguridad. También puede crear roles
RBAC personalizados para otorgar permisos más pormenorizados (https://docs.
microsoft.com/es-xl/azure/role-based-access-control/overview).
• Azure Security Center (ASC): ASC es un sistema de administración de seguridad
de infraestructura unificada que está diseñado para consolidar la seguridad
(https://docs.microsoft.com/es-xl/azure/security-center/security-center-intro).
• Configuración de invitado de Azure Policy: se puede usar para auditar la
configuración en la VM Linux. Esto se analizó en detalle en el Capítulo 8,
Exploración de la automatización de la configuración continua.
Le recomendamos revisar la documentación de Microsoft relacionada con estos

servicios para tener una mejor información sobre cómo se pueden usar en el entorno
para fortalecer el aspecto general de la seguridad.
Resumen
Actualmente, la seguridad es un tema muy importante. Muchos informes, libros y más
se han escrito sobre este tema. En este capítulo, analizamos varias opciones en Linux
para aumentar los niveles de seguridad. Todas se basan en la seguridad básica que ya
proporciona Azure a través de los grupos de seguridad de red. Son relativamente fáciles
de implementar y harán una gran diferencia.
La administración central de identidades no solo es una forma de facilitar a los usuarios
el acceso a la VM, sino que también es parte de la reducción de los riesgos de seguridad.
Azure AD Domain Services proporciona, a través de LDAP y Kerberos, una solución de
administración de identidades para todos los sistemas operativos y las aplicaciones que
admiten estos protocolos.
En el Capítulo 8, Exploración de la automatización de la configuración continua, se
analizarán la automatización y la orquestación. Tenga en cuenta que todas las medidas
de seguridad que se tratan en este capítulo se pueden organizar fácilmente. La
orquestación hace posible la administración de la configuración central. Una de sus
grandes ventajas es la prevención de errores y configuraciones incontrolables. De esta
manera, incluso la orquestación es parte de su plan de seguridad.
Y sería bueno si va a crear sus propias VM, especialmente si va a compilar sus propias
imágenes. En el próximo capítulo, veremos cómo compilar sus propias imágenes.
Además, consideraremos los aspectos de seguridad que implica insertar estas imágenes
e implementarlas en su entorno.
Preguntas
1. Si va a implementar firewalld, ¿cuáles son los métodos para configurar este firewall?
2. ¿Cuál es la razón para usar el parámetro --permanent de firewall-cmd?
3. ¿Qué otras opciones hay disponibles para restringir el acceso a la red?
4. Explique la diferencia entre DAC y MAC.
5. ¿Por qué es importante utilizar módulos de seguridad de Linux en una VM que se
ejecuta en Azure?
6. ¿Qué sistema MAC está disponible para qué distribución?
7. ¿Cuál es la principal diferencia entre AppArmor y SELinux?
8. ¿Cuáles son los requisitos para poder unirse a Azure AD Domain Services en lo que
se refiere a las dependencias y la configuración de Linux?
Lectura adicional
Al igual que en el capítulo anterior, se recomienda consultar el Capítulo 11, Solución de
problemas y supervisión de sus cargas de trabajo, para leer sobre el registro en Linux,
porque muchas veces el comando systemctl status no brinda suficiente información.
También mencioné ya el blog de Lennart Poettering y el sitio web de systemd.
Si quiere saber sobre la seguridad de Linux en términos generales, puede empezar
a leer el libro Mastering Linux Security and Hardening (Dominar la seguridad y el
fortalecimiento de Linux) de Donald A. Tevault. Se explican con gran detalle muchos de
los temas tratados en este capítulo, y muchos otros más.
El demonio firewalld tiene un sitio web del proyecto, https://firewalld.org, con un blog
y una excelente documentación. En el caso de las distribuciones anteriores, la wiki de
Arch Linux es un buen lugar para empezar a aprender más: https://wiki.archlinux.org/
index.php/iptables. Y como firewalld utiliza iptables, es un buen comienzo antes de
sumergirse en la página man de firewalld.richlanguage.‑
Todos los detalles sobre SELinux se describen en las guías que proporciona Red Hat :
https://access.redhat.com/documentation/es-xl/red_hat_enterprise_linux/7/html/
selinux_users_and_administrators_guide/ Y si bien está un poco obsoleto, es buena
idea que vea en YouTube este video de una Cumbre de Red Hat relacionado con
SELinux: https://www.youtube.com/watch?v=MxjenQ31b70.
Sin embargo, es más difícil encontrar buena información sobre AppArmor. Hay
documentación disponible sobre el proyecto en https://gitlab.com/apparmor/
apparmor/wikis/Documentation y la guía de Ubuntu Server es un buen comienzo.
Está disponible en https://help.ubuntu.com/lts/serverguide/apparmor.html.en.
Implementación de
7
sus máquinas virtuales
Es fácil implementar una sola máquina virtual (VM) en Azure, pero apenas desee
implementar más cargas de trabajo de una manera única y reproducible, necesitará
algún tipo de automatización.
En Azure, puede usar Azure Resource Manager (ARM) para implementar VM mediante
archivos de configuración de plantilla junto con la CLI de Azure, PowerShell, Ruby y C#.
Otras herramientas de terceros que se usan para crear imágenes para VM, como Packer
y Vagrant, se analizan más adelante en este capítulo.
Todos estos métodos de implementación o métodos de creación de imágenes usan
imágenes de Azure, pero también puede crear sus propias VM personalizadas con
imágenes personalizadas.
234 | Implementación de sus máquinas virtuales
Antes de analizar la configuración de todas las opciones posibles, es importante conocer

las diferentes alternativas de implementación y por qué debe o no debe usarlas. Primero,
debe hacerse varias preguntas:
• ¿Cuándo implementará la aplicación?
• ¿Qué partes de la carga de trabajo deben ser reproducibles?
• ¿Qué partes de la configuración de la carga de trabajo se deben realizar durante
la implementación?
Tendrá la respuesta a todas estas preguntas al final de este capítulo. Estos son los
aportes clave de este capítulo:
• Analizaremos las opciones de implementación automatizadas en Azure.
• Veremos cómo se puede automatizar la implementación mediante la CLI de Azure
y PowerShell.
• Cubriremos las plantillas de Azure ARM para la implementación y cómo se pueden
reutilizar para nuevas implementaciones.
• Se analizarán las herramientas de creación de imágenes de VM como Packer
y Vagrant.
• Por último, explicaremos cómo usar imágenes personalizadas y usar nuestros
propios VHD (discos duros virtuales) a Azure.
Escenarios de implementación
Las tres preguntas mencionadas en la introducción son muy importantes. Pueden
diferir por empresa, por aplicación y durante la etapa de desarrollo. Estos son algunos
ejemplos de escenarios de implementación:
• Las aplicaciones se desarrollan de forma interna, tal vez incluso en su equipo local.
Una vez terminadas, se implementan en Azure. Las actualizaciones se aplicarán
a la carga de trabajo en ejecución.
• Este es el mismo escenario, pero ahora las actualizaciones se realizarán mediante
la implementación de una nueva VM.
• Otro proveedor entrega las aplicaciones.
Estos tres ejemplos son muy comunes y pueden afectar la forma en que desea
implementar la carga de trabajo.
Escenarios de implementación | 235
¿Qué necesita?
Antes de entrar en la implementación, debe saber lo que necesita o, en otras palabras,
qué recursos se necesitan para que su aplicación funcione correctamente. Además,
todo en Azure tiene un límite y una cuota. Algunos límites son complejos y otros
pueden incrementarse mediante el Soporte técnico de Microsoft. Para ver la lista
completa de límites y cuotas de Azure, visite https://docs.microsoft.com/es-xl/azure/
azure-subscription-service-limits.
Antes de la implementación, tenemos que planificar y asegurarnos de que nuestros límites
de suscripción no bloqueen nuestro proyecto. Si hay una restricción o limitación, póngase
en contacto con el Soporte técnico de Microsoft y aumente la cuota. Sin embargo, si usa
en una prueba gratuita, las solicitudes de cuota no se aprobarán. Es posible que tenga
que migrar la implementación a una región donde tenga suficiente cuota para realizar
la implementación. Estos son los recursos clave que implementaremos:
• Un grupo de recursos
• Una cuenta de almacenamiento (no administrada) o un disco administrado
• Un grupo de seguridad de red
• Una red virtual
• Una subred para la red virtual
• Una interfaz de red conectada a la VM
En relación con la VM, debe especificar y pensar en lo siguiente:

• Tamaño de la VM
• Almacenamiento
• Extensiones de VM
• Sistema operativo
• Configuración inicial
• La implementación de la aplicación
Si echa un vistazo a estas listas, puede que se pregunte si es necesario o se requiere

realizar una implementación automatizada o contar con automatización. No es fácil
encontrar una respuesta. Echemos un vistazo a los escenarios nuevamente para
intentar hallar la respuesta. Podríamos hacer lo siguiente:
1. Crear un script en PowerShell o Bash para preparar el entorno de Azure para la
carga de trabajo
2. Crear un segundo script para implementar la VM en función de una oferta en
Azure y usar una extensión de VM de Azure para establecer la configuración inicial
3. Implementar la aplicación con un administrador de software, como Yum
No hay nada de malo en decidir hacer esto; podría ser la mejor solución para usted. Sin
embargo, de todas formas, hay dependencias:
• Implementa su sistema operativo en función de una imagen. Un publicador ha
puesto a disposición esta imagen. ¿Qué sucede si la imagen se actualiza a una
versión que no es compatible con su aplicación?
• ¿Cuánta configuración inicial ya se ha hecho en esta imagen? ¿Cuánto se necesita
y quién controla la imagen?
• ¿Esta imagen cumple con sus directivas de seguridad?
• Si desea dejar Azure por cualquier motivo, ¿puede trasladar su aplicación a otro lugar?
Opciones de implementación automatizada en Azure

Después de esta larga introducción, es momento de ver las opciones de características
que hacen posible automatizar la implementación de su carga de trabajo:
• Azure Resource Manager
• Ansible
• Terraform
Hablaremos de Ansible y Terraform en el Capítulo 8: Exploración de la automatización

de la configuración continua.
Opciones de implementación automatizada en Azure | 237
Creación de scripts
La automatización se puede llevar a cabo con scripts. En Azure, Microsoft cuenta con
muchas opciones compatibles:
• Bash con la CLI de Azure
• PowerShell con el módulo Az
• Python, con el SDK completo disponible en https://docs.microsoft.com/es-xl/
azure/python/python-sdk-azure-install
• Ruby, con un SDK de vista previa disponible en https://azure.microsoft.com/
es-xl/develop/ruby
• Go, con un SDK completo disponible en https://github.com/Azure/azure-sdk-for-go
• Además, hay bibliotecas disponibles para Node.js
Además, puede usar lenguajes de programación, como Java y C#. También hay
proyectos comunitarios; por ejemplo, https://github.com/capside/azure-sdk-perl
es un intento de crear un SDK completo de Azure para Perl.
Todos los lenguajes son opciones válidas; elija un lenguaje con el que ya esté familiarizado.
Tenga en cuenta que el SDK de Ruby estaba en versión preliminar en el momento en que
se escribió este libro. Durante el estado de vista previa, la sintaxis puede cambiar.
La creación de scripts es especialmente buena para preparar un entorno de Azure.
También puede usar la creación de scripts para implementar las VM e incluso puede
incluir la configuración inicial mediante extensiones de VM. La pregunta de si es una
buena idea depende de sus capacidades para la creación de scripts, la imagen base del
sistema operativo y las versiones de software instaladas en él.
El argumento más grande contra el uso de scripts es que tarda mucho tiempo escribirlos.
Estos son algunos consejos que pueden ayudarlo a escribir scripts de manera eficiente:
• Use tantas variables como sea posible. De esta manera, si tiene que hacer cambios
en el script, todo lo que tiene que hacer es cambiar los valores de las variables.
• Use nombres de variables reconocibles en bucles, no algo como for i in.
• En especial, para scripts más grandes, declare las funciones que puede reutilizar.
• A veces, tiene sentido colocar las variables (como la que proporciona
autenticación) y las funciones en archivos independientes. Suele ser una buena
idea colocar una tarea por script.
• Incluya la marca de tiempo de la modificación en su código o, incluso mejor, use
un sistema de control de versiones como, Git.
• Incluya pruebas. Por ejemplo, solo cree este recurso si aún no existe. Use códigos
de salida legibles para personas. Si el script no pudo implementar un recurso, use
algo como not able to create $resource, para que quienquiera que ejecute el script
entienda que el script no pudo crear el recurso.
• Incluya comentarios suficientes. Si necesita depurar o reutilizar el script después
de algún tiempo, aún sabrá lo que hace. No olvide incluir también una descripción
en el encabezado.
• Dedique un tiempo al diseño; use la sangría para mantener el código legible. Use
dos espacios para la sangría, no tabuladores.
Ahora es momento de ver un breve ejemplo. Este ejemplo le dará una idea de cómo crear
scripts para proporcionar las cosas necesarias en Azure antes de implementar una VM.
En primer lugar, declare las variables. También puede agregar las variables a un archivo
y hacer que PowerShell las cargue. Se recomienda almacenarlas en el mismo script para
que siempre pueda volver y actualizarlas cuando sea necesario:
#Declare Variables
$myResourceGroup = "LinuxOnAzure"
$myLocation = "West Europe"
$myNSG = "NSG_LinuxOnAzure"
$mySubnet = "10.0.0.0/24"
$myVnet= "VNET_LinuxOnAzure"
A continuación, escriba un script para crear un grupo de recursos. Si el recurso ya

existe, el script omitirá la parte de creación. Como se mencionó anteriormente, agregar
comentarios es el procedimiento recomendado para que el script sea legible, así que
use comentarios marcados con # para que entienda lo que hace el bloque de código:
# Test if the Resource Group already exists, if not: create it.
Get-AzResourceGroup -Name $myResourceGroup -ErrorVariable notPresent
-ErrorAction SilentlyContinue | out-null
if ($notPresent)
{
# ResourceGroup doesn't exist, create it:
New-AzResourceGroup -Name $myResourceGroup -Location $myLocation
Write-Host "The Resource Group $myResourceGroup is created in the
location $myLocation"
}
else
{
Write-Host "The Resource Group $myResourceGroup already exists in the
location $myLocation"
}
Cree la red virtual y configure la subred:

#Test if the vnet name not already exists:
Get-AzVirtualNetwork -Name $myVnet -ResourceGroupName $myResourceGroup
-ErrorVariable notPresent -ErrorAction SilentlyContinue | out-null
if ($notPresent)
{
# vnet doesn't exist, create the vnet

$virtualNetwork = New-AzVirtualNetwork -ResourceGroupName
$myResourceGroup -Location $myLocation -Name $myVnet -AddressPrefix
10.0.0.0/16
# add subnet configuration

$subnetConfig = Add-AzVirtualNetworkSubnetConfig -Name default
-AddressPrefix $mySubnet -VirtualNetwork $virtualNetwork
# Associate the subnet to the virtual network
$virtualNetwork | Set-AzVirtualNetwork
Write-Host "The virtual network $myVnet with $mySubnet configured is
created in the location $myLocation"
}
else
{
Write-Host "The Resource Group $myVnet already exists in the location
$myLocation"
}
Este es un ejemplo de creación de un grupo de seguridad de red:

# Create NSG
# Test if the Network Security Group does not already exist:
Get-AzNetworkSecurityGroup -ResourceGroupName $myResourceGroup -Name $myNSG

-ErrorVariable notPresent -ErrorAction SilentlyContinue | out-null
if ($notPresent)
{
# create the NSG
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $myResourceGroup
-Location $myLocation -Name $myNSG
# create the rules for SSH and HTTP
$nsg | Add-AzNetworkSecurityRuleConfig -Name "allow_http" -Description "Allow
HTTP" -Access Allow '
-Protocol "TCP" -Direction Inbound -Priority 1002 -SourceAddressPrefix
"*" -SourcePortRange * '
-DestinationAddressPrefix * -DestinationPortRange 80
$nsg | Add-AzNetworkSecurityRuleConfig -Name "allow_ssh" -Description "Allow

SSH" -Access Allow '
-Protocol "TCP" -Direction Inbound -Priority 1001 -SourceAddressPrefix
"*" -SourcePortRange * '
-DestinationAddressPrefix * -DestinationPortRange 22
# Update the NSG.
$nsg | Set-AzNetworkSecurityGroup
Write-Host "The NSG: $myNSG is configured is created with rules for SSH and
HTTP in the resource group $myResourceGroup"
}
else
{
Write-Host "The NSG $myNSG already existed in the resource group
$myResourceGroup"
}
Ahora, debería tener una idea bastante clara de cómo puede crear un script y una red
virtual. Como se mencionó al principio de esta sección, la creación de scripts no es el
único recurso para automatizar una implementación; hay otros métodos. En la siguiente
sección, analizaremos cómo usar las plantillas de Azure Resource Manager para
automatizar la implementación.
Implementación automatizada con Azure Resource Manager

En el Capítulo 2, Introducción a la nube de Azure, definimos Azure Resource Manager
(ARM) de la siguiente manera:
“Básicamente, Azure Resource Manager le permite trabajar con recursos, como el
almacenamiento y las VM. Para ello, tiene que crear uno o más grupos de recursos para
que pueda ejecutar operaciones del ciclo de vida, como implementar, actualizar y eliminar
todos los recursos de un grupo de recursos, en una sola operación”.
Desde Azure Portal o con la creación de scripts, puede hacer todo lo indicado. Pero
eso es solo una pequeña parte. Puede implementar recursos de Azure a través de ARM
con plantillas. Microsoft ofrece cientos de plantillas de inicio rápido disponibles en
https://azure.microsoft.com/es-xl/resources/templates
Cuando crea una VM a través de Azure Portal, puede descargar esa VM como una
plantilla incluso antes de crearla. Si hace referencia a la siguiente captura de pantalla,
puede ver que incluso antes de crear la VM, tenemos una opción para descargar la
plantilla para la automatización:
Figura 7.1: Descarga de VM como plantilla

Si hace clic en Descargar una plantilla para la automatización, verá la siguiente pantalla:
Figura 7.2: Panel de plantillas de VM
Como ve, puede agregar el script a su biblioteca en Azure o puede descargar este
archivo en su equipo local. También verá la opción Implementar, con la que puede
cambiar los parámetros e implementarlos directamente en Azure.
En el panel Scripts, Azure le ofrece vínculos sobre cómo realizar la implementación
mediante PowerShell y la CLI.
Puede cambiar fácilmente los parámetros e implementar una nueva VM o volver
a implementar exactamente la misma VM. No es tan distinto de usar sus propios
scripts, pero consume menos tiempo en términos de desarrollo.
Esto no es lo único que se puede hacer con ARM; puede configurar todos los aspectos
de los recursos de Azure. Por ejemplo, si va a implementar un Grupo de seguridad
de red a través de una plantilla de ARM, defina todo, como la regla, el intervalo de
puertos y la prioridad de la regla, de la misma manera que lo crearía desde Azure Portal
o a través de la CLI. No es tan difícil crear su propia plantilla de ARM. Necesitará la guía
de referencia de ARM, que puede encontrar en https://docs.microsoft.com/es-xl/
azure/templates. Junto con estos ejemplos, es un gran recurso para comenzar.
Otra forma de empezar es mediante el uso de Visual Studio Code Editor, que está
disponible para Windows, Linux y macOS en https://code.visualstudio.com. La
extensión de Herramientas de Azure Resource Manager es imprescindible si va
a iniciar el uso de ARM, junto con algunas otras extensiones, como Azure Account and
Sign-In, Azure Resource Manager snippets y Azure CLI Tools. Puede empezar a usar
las plantillas existentes e incluso cargarlas en Cloud Shell, ejecutarlas y depurarlas.
Para instalar la extensión de Herramientas de Azure Resource Manager, siga estos pasos:
1. Abra Visual Studio Code.
2. Seleccione Extensions (Extensiones) en el menú de la izquierda. O bien, en el menú
View (Ver), seleccione Extensions (Extensiones) para abrir el panel Extensions.
3. Busque Resource Manager (Administrador de recursos).
4. Seleccione Install (Instalar) en Herramientas de Azure Resource Manager.
Esta es la pantalla donde encontrará la opción Install (Instalar):
Figura 7.3: Instalación de Herramientas de Azure Resource Manager

Otra buena característica de Azure es el Visualizador de ARM, que puede encontrar

en http://armviz.io. Todavía está en las primeras etapas de desarrollo. Esta es una
herramienta que puede ayudarlo a obtener una visión rápida del propósito de la plantilla
de ARM que descargó del sitio web de Plantillas de inicio rápido.
En lugar de descargar plantillas, también es posible guardarlas en una biblioteca:
Figura 7.4: Cómo guardar plantillas en la biblioteca

Como se ve en este panel, puede navegar fácilmente en Azure Portal mediante Todos
los recursos en la barra de navegación izquierda y buscar plantillas:
Figura 7.5: Navegación a las plantillas en Azure Portal
Aquí todavía puede editar su plantilla. Otra característica interesante es que puede
compartir su plantilla con otros usuarios de su inquilino. Esto puede ser muy útil, ya que
puede crear un usuario al que solo se le permite usar esta plantilla para la implementación.
Ahora que sabemos cómo implementar una plantilla desde Azure Portal, veamos cómo
podemos implementar plantillas de ARM mediante PowerShell y Bash.
Implementación de plantillas de ARM con PowerShell

En primer lugar, para validar si el formato de la plantilla es correcto, ejecute el
siguiente comando:
Test-AzResourceGroupDeployment -ResourceGroupName ExampleResourceGroup'
-TemplateFile c:\MyTemplates\azuredeploy.json '
-TemplateParameterFile c:\MyTemplates\storage.parameters.json
A continuación, continúe con la implementación:
New-AzResourceGroupDeployment -Name <deployment name> -ResourceGroupName
<resource group name> -TemplateFile c:\MyTemplates\azuredeploy.json
-TemplateParameterFile c:\MyTemplates\storage.parameters.json
Implementación de plantillas de ARM con Bash

También puede validar la plantilla y el archivo de parámetros antes de la
implementación para evitar errores inesperados:
az group deployment validate \
--resource-group ResourceGroupName \
--template-file template.json \
--parameters parameters.json
Para realizar la implementación, ejecute el siguiente comando:

az group deployment create \
--name DeploymentName \
--resource-group ResourceGroupName \
--template-file template.json \
--parameters parameters.json
Ahora que hemos implementado una nueva VM, podemos mantener templates.json
y parameters.json, que se pueden reutilizar al cambiar los valores de las variables.
Supongamos que eliminó la VM y desea que se vuelva a implementar. Todo lo que

necesita son los archivos JSON. Como se explicó anteriormente, si almacenó la plantilla
en Azure, puede encontrar una opción para volver a implementarla allí:
Figura 7.6: Cómo volver a implementar la VM con los archivos JSON
Si prefiere realizar la misma tarea a través de la CLI de Azure o PowerShell, ejecute los
comandos que usamos anteriormente y la VM estará lista con la misma configuración
que se mencionó en la plantilla de ARM.
Configuración inicial
Después de la implementación de la carga de trabajo, se necesita una configuración
posterior a la implementación. Si desea hacer esto como parte de su solución de
automatización, tiene dos opciones:
• La extensión de script personalizado, que se puede usar en cualquier momento
después de la implementación.
• cloud-init está disponible durante el arranque.
Configuración inicial con la extensión de script personalizado

Después de la implementación de la VM, es posible ejecutar scripts posteriores
a la implementación mediante la extensión de script personalizado. En el ejemplo
anterior, implementábamos una VM con plantillas de ARM. ¿Qué pasa si desea ejecutar
un script después de la implementación? Este es el rol de la extensión de script
personalizado. Por ejemplo, supongamos que desea implementar una VM y, después
de la implementación, desea instalar Apache en la VM sin iniciar sesión en ella. En este
caso, escribiremos un script para instalar Apache, el que se instalará después de la
implementación mediante la extensión de script personalizado.
Configuración inicial | 249
Esta extensión funcionará en todos los sistemas operativos Linux respaldados por
Microsoft, excepto CoreOS y OpenSUSE LEAP. Cambie el comando apt-get en el script
por el administrador de software compatible con su distribución si no es Debian o Ubuntu.
Puede usar PowerShell para configurar la extensión:
$myResourceGroup = "<resource group name>"
$myLocation = "<location>"
$myVM = "<vm name>"
$Settings = @{ "commandToExecute" = "apt-get -y install nginx";};
Set-AzVMExtension -VMName $myVM '

-ResourceGroupName $myResourceGroup'
-Name "CustomscriptLinux" -ExtensionType "CustomScript" '
-Publisher "Microsoft.Azure.Extensions" '
-typeHandlerVersion "2.0" -InformationAction SilentlyContinue '
-Verbose -Settings $Settings
La salida de PowerShell le dará el estado después de la configuración, es decir, si estaba

bien o si algo salió mal. Después de ejecutar el script, puede comprobar si la instalación
se realizó correctamente en los registros de la VM. Dado que estamos siguiendo esto en
una VM de Ubuntu, puede revisar el archivo /var/log/apt/history.log para comprobar
la instalación de nginx. La salida confirma que se han instalado nginx y todas las
demás dependencias:
Figura 7.7: Revisión de registros para comprobar la instalación de nginx

En lugar de un comando, también puede proporcionar un script.

Vamos a crear un script muy simple:
#!/bin/sh
apt-get install -y nginx firewalld
firewall-cmd --add-service=http
firewall-cmd --add-service=http --permanent
Ahora, el script debe codificarse mediante el comando base64. Puede hacerlo en

cualquier VM de Linux que tenga o usar WSL (Subsistema de Windows para Linux)
para crear la cadena base64:
cat nginx.sh| base64
Nota
En algunas versiones de base64, tiene que agregar el parámetro -w0 para
deshabilitar el ajuste de palabras. Solo asegúrese de que sea una línea.
La variable $Settings será la siguiente:

$Settings = @{"script" = "<base64 string>";};
Como ya hemos instalado nginx con el primer script, puede eliminar ngnix mediante apt
purge nginx o puede crear una nueva VM por completo. Como hicimos antes, podemos
revisar el registro del historial:
Figura 7.8: Revisión del registro del historial

La entrada de registro muestra claramente que apt install –y nginx firewalld se ejecutó.
Dado que estamos observando el historial de apt, no podremos confirmar si se agregó la
regla firewalld HTTP. Para confirmarlo, puede ejecutar firewall-cmd –list-services:
Figura 7.9: Revisión para saber si se agregó la regla firewalld HTTP
Los scripts se pueden comprimir o cargar en un blob de almacenamiento si lo desea.

Por supuesto que puede usar la CLI de Azure para realizar la configuración inicial.
En ese escenario, tiene que proporcionar un archivo JSON similar a este:
{
"autoUpgradeMinorVersion": true,
"location": "<location>",
"name": "CustomscriptLinux",
"protectedSettings": {},
"provisioningState": "Failed",
"publisher": "Microsoft.Azure.Extensions",
"resourceGroup": "<resource group name>",
"settings": {
"script": "<base64 string"
},
"tags": {},
"type": "Microsoft.Compute/virtualMachines/extensions",
"typeHandlerVersion": "2.0",
"virtualMachineExtensionType": "CustomScript"
}
Luego, ejecute el siguiente comando az:

az vm extension set --resource-group <resource group> \
--vm-name <vm name> \
--name customScript --publisher Microsoft.Azure.Extensions \
--settings ./nginx.json
Nota
El archivo JSON se puede incluir en una plantilla de ARM.
Si usa PowerShell o la CLI de Azure para fines de depuración, el directorio /var/log/

azure/custom-script contiene el registro de sus acciones.
Configuración inicial con cloud-init

Un problema con la extensión de VM personalizada es que los scripts pueden ser
muy específicos de la distribución. Ya se puede ver en los ejemplos utilizados. Si usa
diferentes distribuciones, necesitará varios scripts o tendrá que incluir comprobaciones
de distribución.
Otra forma de realizar una configuración inicial después de la implementación de la VM
es mediante el uso de cloud-init.
cloud-init es un proyecto de Canonical que se creó para proporcionar una solución en
la nube y un enfoque independiente de la distribución de Linux para personalizar las
imágenes en la nube. En Azure, se puede usar con imágenes para preparar el sistema
operativo durante el primer arranque o al crear la VM.
No se admiten todas las distribuciones de Linux respaldadas por Microsoft; Debian
y SUSE no son compatibles en absoluto, y siempre toma un poco de tiempo antes de
que se pueda usar la versión más reciente de una distribución.
cloud-init se puede usar para ejecutar comandos de Linux y crear archivos. Hay
módulos disponibles en cloud-init para configurar el sistema, por ejemplo, para
instalar software o hacer alguna administración de usuarios y grupos. Si un módulo
está disponible, entonces es la mejor manera de hacerlo. No solo es más fácil (no tiene
que hacer el trabajo duro), sino que también es independiente de la distribución.
cloud-init usa YAML; tenga en cuenta que la sangría es importante. El objetivo del script
es instalar los paquetes npm, nodejs y nginx packages, luego configurar nginx y, finalmente,
mostrar un mensaje, Hello World from host $hostname, donde $hostname es el nombre de
la VM. Para partir, crearemos un archivo YAML con el siguiente contenido y el nombre
cloudinit.yml:
#cloud-config
groups: users
users:
- default
- name: azureuser
- groups: users
- shell: /bin/bash
package_upgrade: true
packages:
- nginx
- nodejs
- npm
write_files:
- owner: www-data:www-data
- path: /etc/nginx/sites-available/default
content: |
server {
listen 80;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
- owner: azureuser:users

- path: /home/azureuser/myapp/index.js
content: |
var express = require('express')
var app = express()
var os = require('os');
app.get('/', function (req, res) {
res.send('Hello World from host ' + os.hostname() + '!')
})
app.listen(3000, function () {
console.log('Hello world app listening on port 3000!')
})
runcmd:
- systemctl restart nginx
- cd "/home/azureuser/myapp"
- npm init
- npm install express -y
- nodejs index.js
Si observa este archivo de configuración, puede usar algunos de los siguientes módulos
en acción:
• users y groups: administración de usuarios
• packages y package_upgrade: administración de software
• write_files: creación de archivos
• runcmd: ejecutar comandos que no son posibles con los módulos
También puede crear una VM:

az vm create --resource-group <resource group> \
--name <vm name> --image UbuntuLTS \
--admin-username linuxadmin \
--generate-ssh-keys --custom-data cloudinit.txt
Vagrant | 255
Después de la implementación, tomará algo de tiempo antes de que todo esté listo.
El registro se realiza en la VM en los archivos /var/log/cloud-init.log y /var/log/
cloud-init-output.log.
Cambie las reglas del grupo de seguridad de red para permitir tráfico en el puerto 80.
Después de eso, abra su navegador en la dirección IP de la VM. Si todo está bien, verá
lo siguiente: Hello World from host ubuntu-web!
Nota
No hay compatibilidad con cloud-init en los cmdlets Az.
Vagrant
Hasta ahora, hemos usado las soluciones de Microsoft; tal vez deberíamos llamarlas
soluciones nativas. Esa no es la única forma de implementar la carga de trabajo en Azure.
Muchos proveedores han creado soluciones para automatizar las implementaciones en
Azure. En esta sección, queremos abarcar una solución de una empresa llamada HashiCorp
(https://www.hashicorp.com). Más adelante en este capítulo, veremos otro producto de
esta empresa: Packer. Hay varias razones por las que hemos elegido estos productos:
• Los productos son muy populares y conocidos.
• Hay una excelente relación entre Microsoft y HashiCorp; trabajan muy duro juntos
para implementar más y más características.
• Y la razón más importante es que HashiCorp tiene diferentes productos que puede
usar para distintos escenarios de implementación. Esto le hará pensar nuevamente
en el método que desea elegir en diferentes casos de uso.
Vagrant es una herramienta que puede utilizar para la implementación si es un

desarrollador. Le ayuda a configurar un entorno de una manera estandarizada que
puede volver a implementar una y otra vez.
Instalación y configuración de Vagrant

Vagrant está disponible para varias distribuciones de Linux, Windows y macOS, y se
puede descargar en https://www.vagrantup.com/downloads.html:
1. Para instalar el software en Ubuntu, use los siguientes comandos:
cd /tmp
wget \ https://releases.hashicorp.com/vagrant/2.1.2/vagrant_2.1.2_x86_64.
deb
sudo dpkg -i vagrant_2.1.2_x86_64.deb
En RHEL/CentOS, use el siguiente comando:
sudo yum install \
https://releases.hashicorp.com/vagrant/2.1.2/ \
vagrant_2.1.2_x86_64.rpm
Si lo implementa en una VM o estación de trabajo independiente, asegúrese de
instalar también la CLI de Azure.
Inicie sesión en Azure:
az login
Cree una cuenta de entidad de servicio que Vagrant pueda usar para autenticar:
az ad sp create-for-rbac --name vagrant
De la salida, necesita el appID, también conocido como ID de cliente, y la
contraseña, que es lo mismo que el Secreto de cliente.
2. Ejecute el siguiente comando para obtener su ID de inquilino y su ID de suscripción:
az account show
En la salida de este comando, puede ver su ID de inquilino y su ID de suscripción.
Vagrant | 257
3. Cree un archivo con el siguiente contenido y guárdelo en ~/.azure/vagrant.sh:

AZURE_TENANT_ID="<tenant id>"
AZURE_SUBSCRIPTION_ID="<account id>"
AZURE_CLIENT_ID="<app id>"
AZURE_CLIENT_SECRET="<password>"
export AZURE_TENANT_ID AZURE_SUBSCRIPTION_ID AZURE_CLIENT_ID\

AZURE_CLIENT_SECRET
4. Estas variables deben exportarse antes de poder utilizar Vagrant. En macOS
y Linux, puede hacerlo mediante la ejecución del siguiente comando:
source <file>
5. Debe estar disponible un par de claves SSH. Si aún no se ha hecho, cree un par de
claves con este comando:
ssh-keygen
6. El último paso implica la instalación del complemento de Azure para Vagrant:
vagrant plugin install vagrant-azure
7. Compruebe la instalación:
vagrant version
Figura 7.10: Comprobación de la instalación de Vagrant
Ahora que hemos confirmado que Vagrant está en funcionamiento, continuemos

e implementemos una VM con Vagrant.
Implementación de una VM con Vagrant

Para implementar una VM con Vagrant, deberá crear un nuevo directorio de trabajo
donde crearemos el Vagrantfile:
Vagrant.configure('2') do |config|
config.vm.box = 'azure'
# use local ssh key to connect to remote vagrant box config.ssh.private_key_
path = '~/.ssh/id_rsa'
config.vm.provider :azure do |azure, override|
azure.tenant_id = ENV['AZURE_TENANT_ID']
azure.client_id = ENV['AZURE_CLIENT_ID']
azure.client_secret = ENV['AZURE_CLIENT_SECRET'] azure.subscription_id =
ENV['AZURE_SUBSCRIPTION_ID']
end
end
El archivo de configuración comienza con una declaración en la que necesitamos el

complemento de Azure para Vagrant que instalamos anteriormente. Después de eso,
se inicia la configuración de la VM. Para poder proporcionar una carga de trabajo con
Vagrant, se necesita una VM ficticia. Es casi un archivo vacío: solo registra a Azure
como proveedor. Para obtener esta VM ficticia, ejecute el siguiente comando:
vagrant box add azure-dummy\
https://github.com/azure/vagrant-azure/raw/v2.0/dummy.box\
--provider azure
Normalmente, muchas de las opciones, por ejemplo, vm_image_urn, se integrarán en un
archivo de cuadro y solo tiene que proporcionar opciones mínimas en el Vagrantfile.
Dado que estamos usando un cuadro ficticio, no hay valores predeterminados
configurados con anterioridad. az.vm_image_urn es la imagen real que ofrece Azure
con la siguiente sintaxis:
<publisher>:<image>:<sku>:<version>
Además de usar imágenes estándares, es posible utilizar archivos de disco duro virtual
(VHD) personalizados con estas directivas:
• vm_vhd_uri
• vm_operating_system
• vm_vhd_storage_account_id
Vagrant | 259
Más adelante en este capítulo, analizaremos estos archivos de VHD personalizados con
más detalle.
Otro valor importante es el nombre de la VM; también se usa como prefijo de DNS.
Debe ser único. De lo contrario, obtendrá este error: DNS record <name>.<location>.
cloudapp.azure.com is already used by another public IP.
Implemente el cuadro de Vagrant, la VM:
vagrant up
Así debería verse la salida:
Figura 7.11: Implementación del cuadro vagrant
Cuando la máquina esté lista para usarse, puede iniciar sesión con este comando:
vagrant ssh
El contenido del directorio de trabajo se copia en /vagrant en la VM. Esta es una manera
muy cómoda de tener sus archivos disponibles en la VM.
Limpie su trabajo con este comando:
vagrant destroy
Nota
También es posible crear cuadros de varias máquinas.
Aprovisionadores de Vagrant
Ofrecer una forma sencilla de implementar una VM no es la característica
más importante de Vagrant. La razón principal para usar Vagrant es tener un
entorno completo en funcionamiento. Después de implementarse, las VM deben
configurarse. Hay aprovisionadores para hacer el trabajo posterior. El propósito de
los aprovisionadores es hacer cambios en la configuración, instalar automáticamente
paquetes y mucho más. Puede utilizar el aprovisionador de shell, que ayuda a cargar
y ejecutar scripts en la VM invitada, y el aprovisionador de archivo para ejecutar
comandos y copiar archivos en la VM.
Otra posibilidad es usar aprovisionadores de Vagrant para las herramientas de
orquestación, como Ansible y Salt. Analizaremos estas herramientas en el capítulo
siguiente. En este capítulo, junto con la documentación de los aprovisionadores en el
sitio web de Vagrant (https://www.vagrantup.com/docs/provisioning/), configuraremos
los aprovisionadores de shell y el aprovisionador de archivos. Sigamos configurando los
aprovisionadores al agregar el siguiente bloque de código al Vagrantfile.
Agréguelo al final del Vagrantfile:
# Configure the Shell Provisioner
config.vm.provision "shell", path: "provision.sh"
end # Vagrant.config
Hemos hecho referencia a un archivo, provision.sh, en el aprovisionador de shell. Así
que vamos a crear un breve script de provision.sh con algunos comandos simples:
#!/bin/sh
touch /tmp/done
touch /var/lib/cloud/instance/locale-check.skip
Implemente la VM de nuevo, y verá que Vagrant ha tomado la clave SSH que creamos
y ha comenzado el aprovisionamiento:
Figura 7.12: Vagrant comenzó el aprovisionamiento
Ejecute este código para comprobar si el directorio /tmp/done se creó en la VM tal como
se indicó en el archivo provision.sh:
vagrant ssh -c "ls -al /tmp/done"
Packer | 261
Packer
Para un desarrollador, especialmente si hay muchas personas que trabajan en la
misma aplicación, es importante tener un entorno estandarizado. Si no está usando la
tecnología de contenedores (consulte el Capítulo 9, Virtualización de contenedores en
Azure y el Capítulo 10, Cómo trabajar con Azure Kubernetes Service, para obtener más
información sobre esta tecnología), Vagrant es una herramienta excelente que ayuda
a los desarrolladores con esta tarea y administra el ciclo de vida de una VM para que
todo se ejecute rápidamente de una manera reproducible. Aprovisiona la configuración
en función de las ofertas de imágenes o de un VHD personalizado. Es todo lo que
necesita si desea desarrollar su aplicación en la nube.
Pero si desea entornos más complejos, crear sus propias imágenes, implementar varias
máquinas, entornos en diferentes nubes y mucho más, no es imposible del todo, pero tan
pronto como lo haya intentado, notará que Vagrant no está hecho para esos escenarios.
Aquí es donde otro producto de HashiCorp es útil: Packer. En esta sección, vamos a usar
Packer con una configuración muy similar a la que usamos antes con Vagrant.
Instalación y configuración de Packer

Packer está disponible para macOS, Windows, varias distribuciones de Linux y FreeBSD.
Los paquetes están disponibles para descargar en https://www.packer.io/downloads.html.
Descargue un paquete, descomprímalo y ya está listo para continuar. En Linux, es bueno
crear un directorio ~/.bin y descomprimirlo allí:
mkdir ~/bin
cd /tmp
wget wget https://releases.hashicorp.com/packer/1.2.5/\
packer_1.2.5_linux_amd64.zip
unzip /tmp/packer*zip
cp packer ~/bin
Cierre la sesión y vuelva a iniciarla. Casi todas las distribuciones agregan el directorio
~/bin a la variable PATH tan pronto como está disponible, pero debe cerrar la sesión
y volver a iniciarla.
Compruebe la variable PATH mediante la ejecución de $PATH. Si no puede ver la carpeta
bin en el directorio principal agregado a la ruta de acceso, ejecute lo siguiente:
export PATH=~/bin:$PATH
Compruebe la instalación:
packer version
Si la instalación se realizó correctamente, el comando mostrará la versión de Packer,

como puede ver en esta captura de pantalla:
Figura 7.13: Comprobación de la instalación de packer a través de la versión de Packer
Para la configuración de Packer, necesitaremos la misma información que para Vagrant:

• ID de inquilino de Azure (az account show)
• ID de suscripción de Azure (az account show)
• El ID de la cuenta de la entidad de servicio (si desea utilizar el mismo que en
Vagrant, utilice el comando az app list --display-name vagrant)
• La clave secreta para esta cuenta (si es necesario, puede usar el comando az ad sp
reset-credentials para generar una nueva)
• El grupo de recursos existente en la ubicación correcta; en este ejemplo, estamos
usando LinuxOnAzure como el nombre del grupo de recursos y West Europe como
la ubicación (creada con el comando az group create --location "West Europe"
--name "LinuxOnAzure")
Packer | 263
Cree un archivo (por ejemplo, /packer/ubuntu.json) con el siguiente contenido:

{
"builders": [{
"type": "azure-arm",
"client_id": "<appId>",
"client_secret": "<appPassword>",
"tenant_id": "<tenantId>",
"subscription_id": "<subscriptionID>",
"managed_image_resource_group_name": "LinuxOnAzure",
"managed_image_name": "myPackerImage",
"os_type": "Linux",
"image_publisher": "Canonical",
"image_offer": "UbuntuServer",
"image_sku": "18.04-LTS",
"location": "West Europe",
"vm_size": "Standard_B1s"
}],
"provisioners": [{
"type": "shell",
"inline": [
"touch /tmp/done",
"sudo touch /var/lib/cloud/instance/locale-check.skip"
]
}]
}
Valide la sintaxis:
packer validate ubuntu.json
Luego, compile la imagen de la siguiente manera:

packer build ubuntu.json
Figura 7.14: Compilación de la imagen mediante el comando Packer build

Packer | 265
Packer tarda unos minutos en compilar la VM, ejecutar los aprovisionadores y limpiar
la implementación.
Una vez completada la compilación, Packer le dará un resumen de lo que se creó,
como el grupo de recursos, el lugar donde se implementó la VM, el nombre de la
imagen y la ubicación:
Figura 7.15: Resumen de la imagen
La compilación creará una imagen, pero no una VM en ejecución. Desde la imagen que
creó Packer, puede implementar una máquina con este comando:
az vm create \
--resource-group LinuxOnAzure \
--name mypackerVM \
--image myPackerImage \
--admin-username azureuser \
--generate-ssh-keys
Para limpiar el entorno y eliminar la imagen que creó Packer, ejecute el siguiente
comando:
az resource delete --resource-group LinuxOnAzure --resource-type images \
--namespace Microsoft.Compute --name myPackerImage
El archivo JSON que proporcioné anteriormente en este capítulo es suficiente para
crear una imagen. Es muy similar a lo que hicimos con Vagrant, pero para convertirlo en
una imagen que pueda implementarse, tenemos que generalizar la VM, lo que significa
permitir que se use la imagen para varias implementaciones. Agregar /usr/sbin/waagent
-force -deprovision+user & export HISTSIZE=0 && sync al código generalizará la VM.
No se preocupe por este código: lo volverá a ver cuando generalicemos la VM a través
de la CLI de Azure en la siguiente sección.
Ubique el siguiente código:

"provisioners": [{
"type": "shell",
"inline": [
"touch /tmp/done",
"sudo touch /var/lib/cloud/instance/locale-check.skip"
]
Debe reemplazarse con el siguiente código:

"provisioners": [{
"type": "shell",
"execute_command": "echo '{{user 'ssh_pass'}}' | {{ .Vars }} sudo -S -E
sh '{{ .Path }}'",
"inline": [
"touch /tmp/done",
"touch /var/lib/cloud/instance/locale-check.skip",
"/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 &&
sync"
]
}]
}
execute_command es un comando que se usa para ejecutar el script como el usuario correcto.
Valide la plantilla con el comando packer validate, como lo hicimos antes, para evitar
errores y volver a compilar la imagen.
Hasta ahora, hemos creado la imagen con Packer, pero esto también se puede hacer con
la CLI de Azure y PowerShell. De esto se trata la siguiente sección.
VHD y máquinas virtuales personalizadas | 267
VHD y máquinas virtuales personalizadas

En la sección anterior, usamos ofertas de VM estándar en Azure y dos métodos
diferentes para realizar cierto trabajo de configuración después. Sin embargo, como
se indicó antes, hay razones por las que una imagen predeterminada podría no ser la
solución para su caso. Vamos a resumir las razones una vez más.
Las ofertas de imágenes nativas de Azure son un buen punto de partida para
implementar VM. Algunas ventajas de usar imágenes nativas son las siguientes:
• Las crean y admiten proveedores de distribución de Linux o un socio de confianza
• Rápidas de implementar, de forma manual y orquestada, y, por supuesto, puede
personalizarlas después
• Funcionalidad y opciones fáciles de extender con extensiones de Azure
Si va a usar las ofertas nativas, hay algunas desventajas o, en otras palabras,

algunos inconvenientes:
• Si desea más protección que con la imagen estándar, entonces tiene que depender
de versiones de imagen fortalecidas de Marketplace, lo que es costoso para algunos.
• La imagen estándar no cumple, por ejemplo, con las normas empresariales,
especialmente cuando se trata de la creación de particiones.
• La imagen estándar no está optimizada para una determinada aplicación.
• Algunas distribuciones de Linux no son compatibles, como Alpine y ArchLinux.
• Preguntas sobre entornos reproducibles: ¿por cuánto tiempo está disponible una
versión específica de la imagen?
Por lo tanto, necesitamos imágenes personalizadas con las que podemos personalizar
la imagen y mitigar los problemas o inconvenientes. No estamos sugiriendo que las
ofertas nativas no sean seguras o no puedan cumplir el objetivo, pero en un entorno
empresarial, hay escenarios como “Traiga su propia suscripción” para VM de RHEL/
SLES y software de terceros de fabricantes de software independientes (ISV)
empaquetado como imágenes con las que debe usar las imágenes personalizadas.
Continuemos para ver cómo puede usar imágenes personalizadas en Azure.
Creación de una imagen administrada

En la sección anterior, investigamos Packer. Se creó una VM y, después de eso, se
transformó en una imagen. Esta imagen se puede usar para implementar una nueva VM.
Esta técnica también se denomina captura de una imagen de VM.
Averigüemos si podemos seguir paso a paso la forma manual con la CLI de Azure:
1. Cree un grupo de recursos:
myRG=capture
myLocation=westus
az group create --name $myRG --location $myLocation

2. Cree una VM:
myVM=ubuntudevel
AZImage=UbuntuLTS
Admin=linvirt
az vm create --resource-group $myRG --name $myVM \

--image $AZImage \
--admin-username linvirt --generate-ssh-keys
3. Inicie sesión en la VM y desaprovisiónela con el agente de la VM de Azure.
Generaliza la VM mediante la eliminación de datos específicos del usuario:
sudo waagent -deprovision+user
Una vez que ejecute el comando, la salida mostrará advertencias sobre los datos
que se van a eliminar. Puede continuar si ingresa y, como se muestra aquí:
Figura 7.16: Desaprovisionamiento de la VM
Escriba exit para salir de la sesión de SSH.

4. Desasigne la VM:
az vm deallocate --resource-group $myRG --name $myVM
5. Márquela como generalizada. Esto significa permitir que se cree una imagen para
varias implementaciones:
az vm generalize --resource-group $myRG --name $myVM
6. Cree una imagen a partir de la VM en este grupo de recursos:
destIMG=customUbuntu
az image create --resource-group $myRG --name $destIMG --source $myVM

7. Compruebe el resultado:
az image list -o table
La salida mostrará la lista de imágenes en un formato de tabla:
Figura 7.17: Lista de imágenes de Azure
8. Puede implementar una nueva VM con esta imagen:

--name <vm name> \
--image $destIMG \
--admin-username <username> \
--generate-ssh-key
Si está en PowerShell, esto también es posible. Veamos rápido el primer paso.

El proceso es muy similar; la única diferencia es que estamos usando cmdlets
de PowerShell:
$myRG="myNewRG"
$myLocation="westus"
$myVM="ubuntu-custom"
$AZImage="UbuntuLTS"
#Create resource group

New-AzResourceGroup -Name $myRG -Location $myLocation
#Create VM
New-AzVm '
-Name $myVM '
-ImageName $AZimage '
-VirtualNetworkName "$myVM-Vnet" '
-SubnetName "$myVM-Subnet" '
-SecurityGroupName "$myVM-NSG" '
-PublicIpAddressName "$myVM-pip"
PowerShell puede solicitarle que escriba las credenciales. Ingrese las credenciales para
acceder a la VM. Después, procederemos a la desasignación de la VM:
Stop-AzureRmVM -ResourceGroupName <resource group>'
-Name <vm name>
Como hicimos antes, ahora tenemos que marcar la VM como generalizada:
Set-AzVm -ResourceGroupName <resource group> -Name <vm name> '
-Generalized
Vamos a capturar la información de la VM y guardarla en una variable porque la
necesitaremos para crear la configuración de la imagen:
$vm = Get-AzVM –Name <vm name> -ResourceGroupName <resource group name>
Ahora creemos la configuración de la imagen:

$image = New-AzImageConfig -Location<location> -SourceVirtualMachineId $vm.Id
Dado que tenemos la configuración almacenada en $image, úsela para crear la imagen:
New-AzImage -Image $image -ImageName <image name> '
-ResourceGroupName <resource group name>
Compruebe que se haya creado la imagen:
Get-AzImage –ImageName <Image Name>
Ejecutar el comando anterior le dará una salida similar al siguiente, con los detalles de
la imagen que creó:
Figura 7.18: Recuperación de los detalles de la imagen
Si desea crear una VM con la imagen que acabamos de generar, ejecute el siguiente comando:
New-AzVm '
-ResourceGroupName "<resource group name>" '
-Name "<VM Name>" '
-ImageName "<Image Name>" '
-Location "<location>" '
-VirtualNetworkName "<vnet name>" '
-SubnetName "<subnet name>" '
-SecurityGroupName "<nsg name>" '
-PublicIpAddressName "<public IP name>"
Para resumir lo que hicimos, creamos una VM, la generalizamos y creamos una
imagen que se puede utilizar aún más para implementar varias VM. También hay un
método alternativo para crear varias VM a partir de una imagen de referencia, que
usa “instantáneas”. Esto se tratará en la siguiente sección.
Un método alternativo que usa instantáneas

Si desea conservar la VM original, puede crear una imagen de la VM a partir de una
instantánea. Una instantánea en Azure es, en realidad, una VM completa.
Mediante PowerShell
1. Declare una variable, $vm, que almacenará la información sobre la VM de la que
vamos a tomar una instantánea:
$vm = Get-AzVm -ResourceGroupName <resource group> '
-Name $vmName
$snapshot = New-AzSnapshotConfig '

-SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id '
-Location <location> -CreateOption copy
New-AzSnapshot '
-Snapshot $snapshot -SnapshotName <snapshot name> '
-ResourceGroupName <resource group>
2. A medida que necesitemos el ID de la instantánea para un paso posterior,
reinicializaremos la variable de la instantánea:
$snapshot = Get-AzSnapshot –SnapshotName <Snapshot Name>
3. El siguiente paso consiste en crear la configuración de la imagen a partir de
la instantánea.
$imageConfig = New-AzImageConfig -Location <location>
$imageConfig = Set-AzImageOsDisk -Image $imageConfig '

-OsState Generalized -OsType Linux -SnapshotId $snapshot.Id
4. Finalmente, cree la imagen:
New-AzImage -ImageName <image name> '
-ResourceGroupName <resource group> -Image $imageConfig
Uso de la CLI de Azure

En la CLI de Azure, las cosas son más fáciles; simplemente obtenga el ID de la
instantánea y conviértala en un disco:
1. Con la CLI de Azure, cree una instantánea:
disk=$(az vm show --resource-group <resource group>\
--name <vm name> --query "storageProfile.osDisk.name" -o tsv)
az snapshot create --resource-group <resource group>\

--name <snapshot name> --source $disk
2. Cree la imagen:
snapshotId=$(az snapshot show --name <snapshot name>\
--resource-group <resource group> --query "id" -o tsv)
az image create --resource-group <resource group> --name myImage \

--source $snapshotID --os-type Linux
No olvide generalizar la VM antes de obtener la instantánea. Si no desea hacerlo,
cree un disco a partir de la instantánea y utilícelo como un parámetro de disco con
el comando --attach-os-disk en la CLI de Azure o Set-AzVMOSDisk en PowerShell.
VHD personalizados
Puede crear completamente su propia imagen desde cero. En este escenario, tiene que
compilar su propio archivo VHD. Existen varias maneras de hacerlo:
• Cree una VM en Hyper-V o en VirtualBox, que es un hipervisor gratuito disponible
para Windows, Linux y macOS. Ambos productos admiten VHD de forma nativa.
• Cree su VM en VMware Workstation o KVM, y úselo en Linux qemu-img para
convertir la imagen. Para Windows, Microsoft Virtual Machine Converter está
disponible en https://www.microsoft.com/es-xl/download/details.aspx?id=42497.
Esto incluye un cmdlet de PowerShell, ConvertTo-MvmcVirtualHardDisk, para
realizar la conversión.
Nota
Azure solo admite archivos VHD Tipo 1 y debe tener un tamaño virtual
alineado a 1 MB. En el momento de escribir este libro, el Tipo estaba disponible
en versión preliminar (https://docs.microsoft.com/es-xl/azure/virtual-machines/
windows/generation-2).
Azure se ejecuta en Hyper-V. Linux requiere que ciertos módulos del kernel se ejecuten
en Azure. Si la VM se creó fuera de Hyper-V, es posible que los instaladores de Linux no
incluyan los controladores para Hyper-V en el disco RAM inicial (initrd o initramfs),
a menos que la VM detecte que se está ejecutando en un entorno de Hyper-V.
Cuando se usa un sistema de virtualización diferente (como VirtualBox o KVM) para
preparar la imagen de Linux, es posible que deba volver a compilar la imagen de initrd
para que, al menos, los módulos de kernel hv_vmbus y hv_storvsc estén disponibles
en el disco RAM inicial. Este problema conocido es para los sistemas basados en la
distribución de Red Hat ascendente y, posiblemente, para otros.
El mecanismo para volver a compilar la imagen de initrd o initramfs puede
variar según la distribución. Consulte la documentación o el soporte técnico de
su distribución para conocer el procedimiento adecuado. Este es un ejemplo de
recompilación de initrd mediante el uso de la utilidad mkinitrd:
1. Realice una copia de seguridad de la imagen existente de initrd:
cd /boot
sudo cp initrd-'uname -r'.img initrd-'uname -r'.img.bak
2. Recompile initrd con los módulos de kernel hv_vmbus y hv_storvsc kernel:
sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-'uname
-r'.img 'uname -r'
Es casi imposible describir todas las opciones disponibles para cada distribución
de Linux y cada hipervisor. En general, lo que debe hacer se enumera aquí. Es
muy importante que sigamos los pasos con precisión, de lo contrario, esta tarea
no se puede cumplir. Recomendamos seguir la documentación de Microsoft para
esto (https://docs.microsoft.com/es-xl/azure/virtual-machines/linux/create-
upload-generic).
3. Modifique la línea de arranque del kernel en GRUB o GRUB2 para incluir los
siguientes parámetros, de modo que todos los mensajes de la consola se envíen
al primer puerto serie. Estos mensajes pueden ayudar al Soporte técnico de Azure
para depurar cualquier problema:
console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
4. Microsoft también recomienda eliminar los siguientes parámetros, si existen:
rhgb quiet crashkernel=auto
5. Instale el agente para Linux de Azure porque es necesario para aprovisionar
imágenes de Linux en Azure. Puede instalarlo con el archivo rpm o deb, o puede
instalarlo manualmente mediante los pasos disponibles en la Guía del agente para Linux
(https://docs.microsoft.com/es-xl/azure/virtual-machines/extensions/agent-linux).
6. Asegúrese de que el servidor OpenSSH esté instalado y se inicie automáticamente

durante el arranque.
7. No cree intercambio. Puede habilitarlo más adelante si es necesario, como
analizamos en el capítulo anterior.
8. Desaprovisione la VM como se indica en la sección Creación de una
imagen administrada.
9. Apague la VM, y el VHD estará listo para cargarse en la VM.
Para simplificar, vamos a omitir los pasos anteriores y descargar la imagen oficial del
repositorio de imágenes en la nube de Ubuntu porque lo más importante es la carga
de la imagen en Azure. Descargue la imagen de la nube desde https://cloud-images.
ubuntu.com/bionic/. Esta página web contiene todas las versiones de Bionic, y puede
navegar por los directorios y descargar el archivo tar.gz para Azure. El nombre del
archivo será similar a bionic-server-cloudimg-amd64-azure.vhd.tar.gz; sin embargo,
este nombre puede variar un poco según la versión que esté usando.
Ahora tenemos que cargar el VHD en Azure:
1. Para empezar, es bueno tener una cuenta de almacenamiento independiente para
las imágenes, así que vamos a crear una nueva cuenta de almacenamiento. Aquí
usaremos Premium_LRS, pero si lo desea, puede usar Standard_LRS también para
ahorrar algunos costos:
az storage account create --location <location> \
--resource-group <resource group> --sku Premium_LRS \
--name <account name> --access-tier Cool --kind StorageV2
2. Guarde la salida para su uso posterior. Enumere las claves de acceso:
az storage account keys list --account-name <storage account name>\
--resource-group <resource group>
3. Vuelva a guardar la salida. Lo siguiente que necesitamos es un contenedor para
almacenar los archivos:
az storage container create \
--account-name <storage account>\
--account-key <storage account key 1>
--name <container name>
4. Ahora puede cargar el VHD:

az storage blob upload --account-name <storage account>\
--account-key <storage account key> \
--container-name <container name> \
--type page --file ./bionic-server-cloudimg-amd64.vhd \
--name bionic.vhd
Nota
También puede cargar el archivo con Azure Portal o PowerShell. Otros métodos
son el Explorador de Azure Storage (https://azure.microsoft.com/es-xl/features/
storage-explorer/) o utilidades de Azure VHD (https://github.com/Microsoft/azure-
vhd-utils). El último método es increíblemente rápido.
5. Reciba la URL del blob:

az storage blob url --account-name <storage account> \
--account-key <storage account key> \
--container-name <container name> \
--name bionic.vhd
6. Ahora es posible crear un disco a partir de la carga:
az disk create --resource-group <resoure group> \
--name bionic --source <blob url> --Location <location>
7. Cree una imagen de la VM con este disco:
az image create --resource-group <resource group> \
--name bionic --source <blob url> --os-type linux
--location <location>
Resumen | 277
8. Por último, cree una VM basada en esta imagen:

--name <vm name> \
--image bionic \
--admin-username <username> \
--generate-ssh-key \
--location <location>
Nota
Puede hacer que las imágenes de VHD sean públicas; un buen ejemplo de esto
es una distribución de Linux menos conocida llamada NixOS. En su sitio web,
https://nixos.org/nixos/download.html, describen una forma de implementar
su sistema operativo en Azure.
Concluyamos lo que hemos hecho. Aquí aplicamos dos enfoques. Creamos y cargamos
un VHD de Linux desde una VM existente y, luego, descargamos manualmente un
VHD de Ubuntu y lo usamos. De cualquier manera, lo subiremos a una cuenta de
almacenamiento y crearemos una imagen usándolo. Esta imagen es reutilizable
y puede implementar todas las VM que desee.
El proceso de automatización y las herramientas disponibles son muchísimas. En el
siguiente capítulo, continuaremos con el proceso de automatización y analizaremos
las herramientas más utilizadas, que son Ansible y Terraform.
Resumen
Al principio de este capítulo, preguntamos por qué y cuándo debemos usar la
automatización en Azure. Más adelante, agregamos preguntas sobre el uso de las
imágenes que ofrece Azure.
Con estas preguntas en mente, exploramos las opciones para automatizar nuestras
implementaciones:
• Plantillas de ARM
• Vagrant
• Packer
• Creación y uso de sus propias imágenes
Vagrant y Packer son ejemplos de soluciones de terceros que son herramientas muy
populares para crear y recrear fácilmente los entornos como una parte importante de
su proceso de desarrollo.
Es importante saber que todas las técnicas descritas en este capítulo se pueden
combinar en una solución completa. Por ejemplo, puede usar cloud-init junto con ARM,
pero también con Vagrant.
La orquestación y automatización están muy relacionadas. En este capítulo, vimos
la automatización, especialmente como parte de los entornos de desarrollo, para
automatizar la implementación de VM. La automatización suele ser una solución difícil
para mantener su carga de trabajo después del desarrollo y la implementación. Aquí es
donde entra la orquestación, como se abarca en el siguiente capítulo.
Preguntas
1. ¿Cuáles son las principales razones para usar las implementaciones automatizadas
en Azure?
2. ¿Cuál es el objetivo de la automatización en los entornos de desarrollo?
3. ¿Puede describir las diferencias entre creación de scripts y automatización?
4. ¿Puede nombrar algunas de las opciones de implementación automatizadas
disponibles en Azure?
5. ¿Cuál es la diferencia entre Vagrant y Packer?
6. ¿Por qué debería usar su propia imagen en lugar de una imagen de Azure?
7. ¿Qué opciones hay disponibles para crear su propia imagen?
Tal vez pueda hallar tiempo para terminar el script de ejemplo de la sección Creación de
scripts, en el lenguaje de su elección.
Lectura adicional
Especialmente con respecto a la CLI de Azure, PowerShell y ARM, la documentación
de Azure contiene una gran cantidad de información valiosa, con muchos ejemplos.
Además, todo lo que escribimos en la sección Lectura adicional del Capítulo 2,
Introducción a la nube de Azure, también es importante para este capítulo.
Otro recurso que ofrece Microsoft son sus blogs. Si visita https://blogs.msdn.microsoft.
com/wriju/category/azure/, encontrará muchas publicaciones interesantes sobre la
automatización, incluidos ejemplos más detallados.
En su blog en https://michaelcollier.wordpress.com, Michael S. Collier proporciona
mucha información con respecto a Azure. Casi todas las publicaciones incluyen
posibilidades de creación de scripts y automatización.
No existen muchos libros recientes sobre Vagrant. Estamos seguros de que realmente
disfrutará Infrastructure as Code (IAC) Cookbook de Stephane Jourdan y Pierre Pomes,
publicado hace un año. Este libro no solo se refiere a Vagrant; también abarca otras
soluciones, como cloud-init y Terraform. Los autores crearon un libro que no solo
es una gran introducción, sino que también lograron que se pueda usar como guía
de referencia.
¿Le podemos sugerir un libro que se publicó hace poco? Hands-On DevOps with
Vagrant: Implement End-to-End DevOps and Infrastructure Management Using Vagrant,
de Alex Braunton. También vale la pena ver sus publicaciones en YouTube con respecto
a este tema.
Exploración de la
8
automatización de la
configuración continua
Hasta ahora, hemos trabajado con máquinas virtuales únicas, que implementamos
y configuramos de forma manual. Esto es bueno para los laboratorios y entornos muy
pequeños, pero si tiene que administrar entornos más grandes, es un trabajo que lleva
mucho tiempo e incluso es aburrido. También es muy fácil cometer errores y olvidar
cosas, como las leves diferencias entre las VM, por no mencionar los riesgos para la
estabilidad y seguridad asociados. Por ejemplo, elegir la versión incorrecta durante
la implementación dará lugar a problemas de coherencia y realizar una actualización
después es un proceso tedioso.
282 | Exploración de la automatización de la configuración continua
La automatización de la implementación y la administración de la configuración es la

forma ideal de mitigar esta aburrida tarea. Sin embargo, después de un tiempo, puede
que tenga algunos problemas con ese enfoque. Hay muchas razones por las que hay
problemas. Estas son algunos de los motivos por los que se producen errores:
• El script falla porque algo cambió, debido a, por ejemplo, una actualización
de software.
• Hay una versión más reciente de una imagen base que es ligeramente diferente.
• Los scripts pueden ser difíciles de leer y de mantener.
• Los scripts dependen de otros componentes; por ejemplo, el sistema operativo,
el lenguaje del script y los comandos internos y externos disponibles.
• Y siempre hay un colega con problemas: el script funciona, pero, por alguna razón,
siempre falla cuando un colega lo ejecuta.
Por supuesto que las cosas han mejorado con el tiempo:

• Muchos lenguajes de script ahora son multiplataforma, como Bash, Python
y PowerShell. Están disponibles en Windows, macOS y Linux.
• En systemd, la utilidad systemctl con el parámetro -H puede ejecutar comandos de
forma remota y funciona incluso si el host remoto es otra distribución de Linux.
La versión más reciente de systemd tiene más características.
• firewalld y systemd trabajan con invalidaciones y archivos de configuración fáciles
de implementar.
Es muy probable que la automatización no sea la respuesta a su búsqueda por implementar,

instalar, configurar y administrar su carga de trabajo. Afortunadamente, hay otra forma:
la orquestación.
En términos musicales, la orquestación es el estudio de cómo escribir música para una
orquesta. Debe entender todos los instrumentos y saber qué sonidos pueden hacer.
Luego, puede escribir la música; para ello, tiene que entender cómo suenan juntos
los instrumentos. La mayoría de las veces, se empieza con un solo instrumento, como
un piano. Después, puede escalar verticalmente para incluir los demás instrumentos.
Con suerte, el resultado será una obra maestra y los miembros de la orquesta podrán
empezar a tocar la música. No es tan importante cómo comiencen, pero al final,
el director se asegura de que los resultados sean positivos.
| 283
La orquestación en la informática es muy similar. Antes de que pueda comenzar, tiene

que entender cómo funcionan todos los componentes, cómo se vinculan y qué hacen
para que pueda hacer su trabajo. Después de eso, puede escribir el código para lograr
el objetivo final: un entorno administrable.
Una de las mayores ventajas de un entorno de nube es que en realidad todos los
componentes del entorno están escritos en software. Sí, sabemos que al final hay un
centro de datos con muchos componentes de hardware, pero como usuario en la nube, eso
no le importa. Todo lo que necesita está escrito en software y tiene API con las que hablar.
Por lo tanto, no solo es posible automatizar la implementación de sus cargas de trabajo
de Linux, sino que puede automatizar y orquestar la configuración del sistema operativo
de Linux y la instalación y configuración de las aplicaciones, además de mantener todo
actualizado. También puede usar herramientas de orquestación para configurar los
recursos de Azure, e incluso es posible crear VM de Linux con estas herramientas.
En la orquestación, hay dos enfoques diferentes:
• Imperativo: le dice a la herramienta de orquestación qué hacer para alcanzar
este objetivo
• Declarativo: le dice a la herramienta de orquestación cuál es el objetivo que
desea lograr
Algunas herramientas de orquestación pueden hacer ambas cosas, pero, en general,

el enfoque declarativo es el mejor enfoque en un entorno de nube, donde tiene muchas
opciones para configurar y puede declarar cada opción para lograr el objetivo exacto.
La buena noticia es que si se torna demasiado complejo usar este método, por ejemplo,
cuando la herramienta de orquestación no es capaz de entender el objetivo, siempre
puede extenderlo con un poco del método imperativo mediante scripts.
Gran parte de este capítulo se trata de Ansible, pero también trataremos la Configuración
de estado deseado (DSC) de PowerShell y Terraform como ejemplos de implementaciones
declarativas. En este capítulo, el enfoque es comprender la orquestación y saber lo
suficiente para empezar. Y, por supuesto, analizaremos la integración con Azure.
Los aportes clave de este capítulo son los siguientes:
• Comprender las herramientas de automatización de terceros, como Ansible
y Terraform, y cómo se pueden usar en Azure
• Usar la automatización nativa de Azure y DSC de PowerShell para lograr el estado
deseado de la máquina
• Cómo implementar la configuración de invitado de Azure Policy y auditar la
configuración en sus VM de Linux
• Una visión general de otras soluciones disponibles en el mercado para automatizar
las implementaciones y la configuración
En la práctica, necesitará al menos una VM como máquina de control, o puede usar su
estación de trabajo que ejecuta Linux o Subsistema de Windows para Linux ((WSL).
Junto con esto, necesitamos un nodo, que debe ser una VM de Azure. Sin embargo, para
ofrecer una mejor explicación, hemos implementado tres nodos. Si tiene restricciones
presupuestarias para su suscripción de Azure, no dude en continuar con un nodo. No
importa qué distribución de Linux esté usando. Los ejemplos de esta sección para orquestar
el nodo son para un nodo Ubuntu, pero es fácil traspasarlos a otras distribuciones.
En este capítulo, se exploran varias herramientas de orquestación. Para cada
herramienta, necesitará un entorno limpio. Por lo tanto, cuando haya terminado con la
sección de Ansible en este capítulo, elimine las VM e implemente otras nuevas antes de
empezar con Terraform.
Definición de la administración de la configuración

En la introducción de este capítulo, es posible que haya leído el término administración
de configuración. Veamos esto en más detalle. La administración de configuración
se refiere a cómo desea que se configure la VM. Por ejemplo, desea que un servidor
web de Apache hospede un sitio web en una VM de Linux. Por lo tanto, la parte de la
configuración de la VM implica lo siguiente:
• Instalación de paquetes y dependencias de Apache
• Abrir puertos de firewall para tráfico HTTP o tráfico HTTPS si está usando
certificados SSL (Capa de sockets seguros)
• Habilitar el servicio y arrancarlo para que el servicio de Apache se inicie en el arranque
Este ejemplo es para un servidor web muy simple. Piense en un escenario complejo donde
tiene un servidor web de front-end y bases de datos backend, por lo que la configuración
involucrada es muy alta. Hasta ahora, hemos hablado de una sola VM. ¿Qué pasa si desea
varias VM con la misma configuración? Volvemos al principio, donde hay que repetir la
configuración varias veces, una tarea lenta y aburrida. Aquí entra el rol de la orquestación,
como analizamos en la introducción. Podemos hacer uso de herramientas de orquestación
para implementar la VM con el estado que queramos. Las herramientas se ocuparán de la
configuración. Además, en Azure tenemos la configuración de invitado de Azure Policy,
que se puede usar para auditar la configuración. Con esta directiva, podemos definir una
condición que deba cumplir la VM. Si se produce un error en la evaluación o no se cumple
la condición, Azure marcará esta máquina como no compatible.
Gran parte de este capítulo se trata de Ansible, pero también trataremos la DSC de
PowerShell y Terraform como ejemplos de implementaciones declarativas. En este
capítulo, el enfoque es comprender la orquestación y aprender lo suficiente para
empezar. Y, por supuesto, analizaremos la integración con Azure.
Uso de Ansible | 285
Uso de Ansible
Ansible tiene una naturaleza mínima, casi no tiene dependencias y no implementa
agentes en los nodos. Solo se requieren OpenSSH y Python para ansible. También
es muy confiable: los cambios se pueden aplicar varias veces sin cambiar el resultado
más allá de la aplicación inicial y no debería haber efectos secundarios en el resto del
sistema (a menos que escriba código realmente incorrecto). Hay un gran enfoque en la
reutilización del código, lo que hace que sea aún más confiable.
Ansible no tiene una curva de aprendizaje muy pronunciada. Puede empezar con
solo unas líneas de código y escalar verticalmente después sin provocar problemas.
En nuestra opinión, si desea probar una herramienta de orquestación, empiece con
Ansible y, si desea probar otra, la curva de aprendizaje será mucho menos pronunciada.
Instalación de Ansible
En Azure Marketplace, hay una VM lista para usar disponible para Ansible. Actualmente,
hay tres versiones de Ansible disponibles en Azure Marketplace: Ansible Instance,
Ansible Tower y AWX, que es una edición comunitaria de Ansible Tower. En este libro,
nos centraremos en el proyecto comunitario que está disponible gratis; es más que
suficiente para aprender y comenzar a usar Ansible. Después de eso, puede ir al sitio
web de Ansible para explorar las diferencias, descargar la versión de prueba de la
edición empresarial de Ansible y decidir si la necesita.
Existen varias maneras de instalar Ansible:
• Usar el repositorio de su distribución
• Usar la versión más reciente disponible en https://releases.ansible.com/ansible
• Usar GitHub: https://github.com/ansible
• Usar el instalador de Python, el método preferido, que funciona en todos los
sistemas operativos:
pip install ansible[azure]
En los repositorios estándar de Red Hat y CentOS, pip de Python no está disponible
para la instalación. Tiene que usar el repositorio adicional de EPEL:
sudo yum install epel-release
sudo yum install python-pip
Después de instalar Ansible, compruebe la versión:
ansible --version
No tiene que instalar Ansible si no lo desea: Ansible está preinstalado en Azure Cloud
Shell. En el momento de escribir este libro, Cloud Shell es compatible con la versión
2.9.0 de Ansible. Sin embargo, para que tenga un tutorial de la instalación, vamos a ver
la instalación local de Ansible en la VM. Para la integración con Azure, también debe
instalar la CLI de Azure para obtener la información que deberá proporcionar a Ansible.
Configuración de SSH
La máquina en la que instaló Ansible ahora se denomina Ansible maestra o, en
otras palabras, es solo una VM con Ansible, el archivo de configuración de Ansible
y las instrucciones para la orquestación. La comunicación con los nodos se realiza
mediante protocolos de comunicación. Para Linux, se usa SSH como un protocolo de
comunicación. Para que Ansible pueda comunicarse de forma segura con los nodos,
use la autenticación basada en claves. Si no lo ha hecho, genere un par de claves SSH
y copie la clave en la VM que desea orquestar.
Para generar la clave SSH, use este comando:
ssh-keygen
Una vez que genere la clave, se guarda en el directorio de inicio del usuario en el
directorio .ssh de forma predeterminada. Para mostrar la clave, use este comando:
cat ~/.ssh/id_rsa.pub
Una vez que tenemos la clave, tenemos que copiar este valor en el servidor del nodo.
Siga estos pasos para copiar la clave:
1. Copie el contenido del archivo id_rsa.pub.
2. SSH al servidor del nodo.
3. Cambie a superusuario con el comando sudo.
4. Edite el archivo authorized_keys en ~/.ssh/.
5. Pegue la clave que copiamos del servidor de Ansible.
6. Guarde y cierre el archivo.
Para comprobar si el proceso se realizó correctamente, vuelva a la máquina donde está

instalado Ansible (de aquí en adelante, la llamaremos Ansible maestra) y ssh al nodo. Le
preguntará la frase de contraseña si usó una mientras generaba la clave. Otro método
para automatizar todo el proceso de copia de claves es usar el comando ssh-copy-id.
Configuración mínima indispensable

Para configurar Ansible, necesitará un archivo ansible.cfg. Hay diferentes ubicaciones
donde se puede almacenar este archivo de configuración. Ansible busca en el
siguiente orden:
ANSIBLE_CONFIG (variable de entorno si se establece)
ansible.cfg (en el directorio actual)
~/.ansible.cfg (en el directorio inicial)
/etc/ansible/ansible.cfg
Ansible procesará la lista anterior y usará el primer archivo que encuentre; todos los
demás se omitirán.
Cree el directorio ansible en /etc si no está disponible y agregue un archivo llamado
ansible.cfg. Aquí es donde vamos a guardar nuestra configuración:
[defaults]
inventory = /etc/ansible/hosts
Probemos lo siguiente:
ansible all -a "systemctl status sshd"
Este comando, denominado comando ad hoc, ejecuta systemctl status sshd en todos
los hosts definidos en /etc/ansiblehosts. Si tiene varios nombres de usuario para cada
host, también puede especificar el nombre de usuario para estos nodos en el formato
que se muestra en el siguiente archivo de hosts de Ansible:
<ip address> ansible_ssh_user='<ansible user>'
Por lo tanto, puede agregar el usuario a los elementos de línea del archivo de inventario
como se muestra en la siguiente captura de pantalla, si es necesario. El archivo se verá
así para tres nodos:
Figura 8.1: Adición del usuario a los elementos de línea de archivo de inventario
Vuelva a intentarlo. En lugar de su nombre de usuario local, se usa el usuario remoto.

Ahora puede iniciar sesión y ejecutar el comando.
Archivo de inventario
El archivo de inventario de Ansible define los hosts y grupos de hosts. En función de
esto, puede llamar al host o al grupo (grupo de hosts) y ejecutar un manual específico
o ejecutar un comando.
Aquí, vamos a llamar a nuestro grupo nodepool y agregaremos direcciones IP de
nuestros nodos. Dado que todas nuestras VM están en la misma red virtual de Azure,
estamos usando la IP privada. Si están en diferentes redes, puede agregar la IP pública.
Aquí estamos usando tres VM para explicar. Si solo tiene un nodo, solo ingrese uno.
Además, puede usar el nombre de DNS de las VM, pero deben agregarse a su archivo
/etc/hosts para su resolución:
[nodepool]
10.0.0.5
10.0.0.6
10.0.0.7
Otro parámetro que será útil es ansible_ssh_user. Puede usarlo para especificar el
nombre de usuario que se utiliza para iniciar sesión en el nodo. Este escenario entra
en juego si usa varios nombres de usuario en sus VM.
En lugar de usar all en nuestro ejemplo, puede usar un nombre de grupo que sea
ansible-nodes. También es posible usar variables genéricas que sean válidas para
cada host y reemplazarlas por servidor; por ejemplo:
[all:vars]
ansible_ssh_user='student'
[nodepool]
<ip address> ansible_ssh_user='other user'
A veces, necesitará privilegios para ejecutar un comando:
ansible nodepool-a "systemctl restart sshd"
Esto muestra el siguiente mensaje de error:

Failed to restart sshd.service: Interactive authentication required.
See system logs and 'systemctl status sshd.service' for details.non-zero
return code.
Para los comandos ad hoc, simplemente agregue la opción -b como un parámetro

de Ansible para habilitar el escalado de privilegios. Usará el método sudo de forma
predeterminada. En las imágenes de Azure, no es necesario dar su contraseña raíz
si está usando sudo. Esta es la razón por la que la opción -b funciona sin problemas.
Si configuró sudo para solicitar una contraseña, use -K.
Sugerimos ejecutar otros comandos, como netstat y ping, para entender cómo se
ejecutan los comandos en estas máquinas. Ejecutar netstat y la herramienta grep
para sshd dará una salida similar a esta:
Figura 8.2: Ejecución de netstat y herramienta grep para sshd
Nota
Es posible que reciba advertencias de obsolescencia al ejecutar el comando
ansible all. Para eliminar esto, use deprecation_warnings=False en ansible.cfg.
Manuales y módulos de Ansible

El uso de comandos ad hoc es un método imperativo y es igual de eficaz que
simplemente usar el cliente SSH para ejecutar comandos de forma remota.
Hay dos componentes que necesita para convertirlo en una orquestación real
e imperativa: un manual y un módulo. El manual es la base para la implementación,
la configuración y el mantenimiento de su sistema. Puede orquestar todo, incluso entre
hosts. El objetivo del manual es describir el estado al que desea llegar. Los manuales
están escritos en YAML y se pueden ejecutar con el comando ansible-playbook:
ansible-playbook <filename>
El segundo componente es el módulo. La mejor manera de describir un módulo es:

la tarea que se ejecutará para alcanzar el estado deseado. También se conocen como
complementos de tareas o complementos de biblioteca.
Todos los módulos disponibles están documentados; puede consultar la documentación
en línea y en su sistema.
Para enumerar toda la documentación disponible del complemento, ejecute el
siguiente comando:
ansible-doc -l
Esto tardará. Le sugerimos que redirija el resultado a un archivo. De esta manera,

se tarda menos tiempo y es más fácil buscar un módulo.
Como ejemplo, intentemos crear un manual que creará un usuario con el módulo de
user si el usuario todavía no existe. En otras palabras, el estado deseado es que existe
un usuario específico.
Comience por leer la documentación:
ansible-doc user
Cree un archivo en el directorio de Ansible, como por ejemplo, playbook1.yaml, con el

siguiente contenido. Compruebe los parámetros en la documentación del usuario:
---
- hosts: all
tasks:
- name: Add user Jane Roe

become: yes
become_method: sudo
user:
state: present
name: jane
create_home: yes
comment: Jane Roe
generate_ssh_key: yes
group: users
groups:
- sudo
- adm
shell: /bin/bash
skeleton: /etc/skel
En la salida, puede ver que todos los hosts están OK y se creó el usuario:
Figura 8.3: Ejecución del manual de Ansible
Solo para asegurarse de que el usuario esté creado, revisaremos el archivo /etc/passwd
en todos los hosts. En la salida, podemos ver que se ha creado el usuario:
Figura 8.4: Comprobación de la creación de usuarios con /etc/passwd

Asegúrese de que la sangría sea correcta porque YAML es un lenguaje muy estricto
cuando se trata de la sangría y el espacio en blanco. El uso de un editor, como vi,
Emacs o Visual Studio Code, con compatibilidad de YAML realmente ayuda.
Si está obligado a ejecutar una escalada de privilegios de comandos, puede usar become
y become_method o –b.
Para comprobar la sintaxis de Ansible, use el siguiente comando:
ansible-playbook --syntax-check Ansible/example1.yaml
Sigamos y veamos cómo podemos autenticar en Azure e iniciar su implementación allí.
Autenticación en Microsoft Azure

Para integrar Ansible con Microsoft Azure, debe crear un archivo de configuración que
proporcione las credenciales de Azure a Ansible.
Las credenciales deben almacenarse en el directorio de inicio en el archivo ~/.azure/
credentials. En primer lugar, tenemos que recopilar la información necesaria con la CLI
de Azure. Autentique en Azure de la siguiente forma:
az login
Si ha iniciado sesión correctamente, recibirá una salida similar a esta:
Figura 8.5: Inicio de sesión en Azure con el comando az login

Esto ya es parte de la información que necesitará. Si ya inició sesión, ejecute el

siguiente comando:
az account list
Cree una entidad de servicio:

az ad sp create-for-rbac --name <principal> --password <password>
El ID de la aplicación es su client_id y la contraseña es su secret, al que se hará

referencia en el archivo de credenciales que vamos a crear.
Cree el archivo ~/.azure/credentials con el siguiente contenido:
[default]
subscription_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_id=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
secret=xxxxxxxxxxxxxxxxx
tenant=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Use ansible-doc -l | grep Azure para averiguar qué módulos de Ansible están
disponibles para Azure. Redirija el contenido a un archivo para referencia.
Grupo de recursos
Vamos a comprobar que todo funciona según lo esperado. Cree un nuevo manual
llamado resourcegroup.yaml con el siguiente contenido:
---
- hosts: localhost
tasks:
- name: Create a resource group

azure_rm_resourcegroup:
name: Ansible-Group
location: westus
Tenga en cuenta que la directiva para hosts es localhost. Ejecute el manual y compruebe
si se creó el grupo de recursos:
az group show --name Ansible-Group
La salida debe ser muy similar a lo siguiente:

{
"id": "/subscriptions/xxxx/resourceGroups/Ansible-Group",
"location": "westus",
"managedBy": null,
"name": "Ansible-Group",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
Máquina virtual
Vamos a crear una VM en Azure con Ansible. Para ello, cree un archivo virtualmachine.
yaml con el siguiente contenido. Examine el campo name de cada bloque para entender
lo que hace el código:
- hosts: localhost
tasks:
- name: Create Storage Account
azure_rm_storageaccount:
resource_group: Ansible-Group
name: ansiblegroupsa
account_type: Standard_LRS
.
.
.
- name: Create a CentOS VM
azure_rm_virtualmachine:
resource_group: Ansible-Group
name: ansible-vm
vm_size: Standard_DS1_v2
admin_username: student
admin_password:welk0mITG!
image:
offer: CentOS
publisher: OpenLogic
sku: '7.5'
version: latest
Debido a la longitud del código, solo mostramos algunas líneas aquí. Puede descargar
todo el archivo virtualmachine.yaml desde la carpeta chapter 8 en el repositorio de
GitHub de este libro.
En la siguiente captura de pantalla, puede ver que Ansible crea todos los recursos
necesarios para la VM:
Figura 8.6: Creación de todos los recursos necesarios para la VM con Ansible
Puede ver un ejemplo completo para la implementación de VM de Azure con Ansible

en la guía de Microsoft Azure de Ansible (https://docs.ansible.com/ansible/latest/
scenario_guides/guide_azure.html).
Administración de inventario de Azure en Ansible

Hemos aprendido dos formas de usar Ansible en Azure:
• Usar Ansible en un archivo de inventario para conectarse a máquinas Linux.
De hecho, no importa si se ejecuta en Azure o en otro lugar.
• Usar Ansible para administrar recursos de Azure.
En esta sección, vamos un paso más allá. En lugar de usar un inventario estático,
le preguntamos a Azure qué se está ejecutando en su entorno mediante scripts de
inventario dinámicos.
El primer paso es descargar el script de inventario dinámico para Azure. Ejecútelo con
sudo si no es un usuario raíz:
cd /etc/ansible
wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/
inventory/azure_rm.py
chmod +x /etc/ansible/azure_rm.py
Edite el archivo /etc/ansible/ansible.cfg y elimine la línea inventory=/etc/ansible/hosts.

Vamos a llevar a cabo el primer paso:
ansible -i /etc/ansible/azure_rm.py azure -m ping
Probablemente, mostrará un error por los problemas de autenticación:
Figura 8.7: Error de conexión del host debido a problemas de autenticación

Si tiene un inicio de sesión diferente para diferentes VM, siempre puede usar la
directiva de usuario por tarea. Aquí estamos usando azure, que significa todas las VM.
Siempre puede consultar una máquina con el nombre de la VM. Por ejemplo, puede
hacer ping a la VM ansible-node3 con una credencial de usuario:
Figura 8.8: Realización de consultas para la VM ansible-node3
Idealmente, Ansible espera que use claves SSH en lugar de contraseñas. Si desea usar
una contraseña, puede usar –extra-vars y pasar la contraseña. Tenga en cuenta que
para esto es necesario instalar una aplicación llamada sshpass. Para hacer ping a una
VM en Azure que use una contraseña a través de Ansible, ejecute el siguiente comando:
ansible -i azure_rm.py ansible-vm -m ping \
--extra-vars "ansible_user=<username> ansible_password=<password>"
Tomemos la instancia de la VM que creamos con Ansible en el ejemplo anterior, donde
el nombre de usuario era student y la contraseña era welk0mITG.. En la captura de
pantalla, puede ver que el ping tiene éxito. Es posible que vea algunas advertencias,
pero pueden omitirse de forma segura. Sin embargo, se necesita una investigación
más detallada si se produce un error con el ping:
Figura 8.9: Envío de un ping para el nombre de usuario student

Al crear un archivo azure_rm.ini en el mismo directorio que el directorio azure_rm.py,

puede modificar el comportamiento del script del inventario. Aquí puede ver un ejemplo
de archivo ini:
[azure]
include_powerstate=yes
group_by_resource_group=yes
group_by_location=yes
group_by_security_group=yes
group_by_tag=yes
Funciona de manera muy similar al archivo hosts. La sección [azure] significa todas las
VM. También puede proporcionar secciones para lo siguiente:
• Nombre de la ubicación
• Nombre del grupo de recursos
• Nombre del grupo de seguridad
• Clave de la etiqueta
• Valor de la clave de la etiqueta
Otro método para seleccionar una o más VM es usar etiquetas. Para poder etiquetar una
VM, necesitará el ID:
az vm list --output tsv
Ahora puede etiquetar la VM:

az resource tag --resource-group <resource group> \
--tags webserver --id </subscriptions/...>
También puede etiquetar la VM en Azure Portal:
Figura 8.10: Etiquetado de la VM en Azure Portal
Haga clic en cambiar y agregue una etiqueta, con o sin un valor (puede usar el valor
para filtrar el valor también). Para comprobar, use el host del nombre de la etiqueta:
ansible -i /etc/ansible/azure_rm.py webserver -m ping
Solo se realiza ping en la VM etiquetada. Vamos a crear un manual para esta VM

etiquetada, por ejemplo, /etc/ansible/example9.yaml. La etiqueta se usa, una vez más,
en la directiva hosts:
---
- hosts: webserver
tasks:
- name: Install Apache Web Server

become: yes
become_method: sudo
apt:
name: apache2
install_recommends: yes
state: present
update-cache: yes
when:
- ansible_distribution == "Ubuntu"
- ansible_distribution_version == "18.04"
Ejecute el manual:
ansible-playbook -i /etc/ansible/azure_rm.py /etc/ansible/example9.yaml
Una vez que se ha ejecutado el manual, si revisa la VM, puede ver que Apache
está instalado.
Como se mencionó anteriormente, Ansible no es la única herramienta. Existe
otra herramienta popular llamada Terraform. En la próxima sección, analizaremos
Terraform en Azure.
Uso de Terraform | 301
Uso de Terraform
Terraform es otra herramienta de Infraestructura como código (IaC) que desarrolló
HashiCorp. Es posible que se pregunte por qué se llama herramienta de IaC. La razón
es que puede definir cómo su infraestructura debe usar el código, y Terraform lo
ayuda a implementarlo. Terraform usa el Lenguaje de Configuración HashiCorp (HCl);
sin embargo, también puede usar JSON. Terraform es compatible con macOS,
Linux y Windows.
Terraform es compatible con una amplia gama de recursos de Azure, como redes,
subredes, almacenamiento, etiquetas y VM. Si recuerda, analizamos las formas
imperativas y declarativas para escribir código. Terraform es declarativa por naturaleza,
y puede mantener el estado de la infraestructura. Una vez implementada, Terraform
recuerda el estado actual de la infraestructura.
Como en todas las secciones, la primera parte del proceso implica la instalación de
Terraform. Procedamos con la instalación en Linux de Terraform.
Instalación
El archivo ejecutable principal de Terraform se puede descargar en https://www.terraform.
io/downloads.html y puede copiarse en uno de los directorios agregados a su variable
$PATH. También puede usar el comando wget para descargar el archivo ejecutable principal.
Para ello, primero debe descubrir la versión más reciente de Terraform en el vínculo
mencionado anteriormente. En el momento de la escritura, la última versión disponible
era 0.12.16.
Ahora que tenemos la versión, descargaremos el archivo ejecutable mediante wget con
el siguiente comando:
wget https://releases.hashicorp.com/terraform/0.12.17/terraform_0.12.17_
linux_amd64.zip
El archivo ZIP se descargará en el directorio de trabajo actual. Ahora usaremos la

herramienta para descomprimir a fin de extraer el archivo ejecutable:
unzip terraform_0.12.16_linux_amd64.zip
Nota
Es posible que unzip no esté instalado de forma predeterminada. Si se produce un
error, instale unzip con apt o yum según la distribución que esté utilizando.
El proceso de extracción le permitirá obtener el archivo ejecutable de Terraform,

y podrá copiarlo en cualquier ubicación de su $PATH.
Para comprobar si la instalación se realizó correctamente, puede ejecutar lo siguiente:
terraform --version
Ahora que hemos confirmado que se instaló Terraform, sigamos y configuremos la

autenticación en Azure.
Autenticación en Azure
Existen varias formas en las que puede autenticar en Azure. Puede usar la CLI de
Azure, la entidad de servicio con un certificado de cliente, la entidad de servicio y el
secreto de cliente, y muchos más métodos. Para fines de prueba, la CLI de Azure que
usa el comando de inicio de sesión az es la opción correcta. Sin embargo, si queremos
automatizar la implementación, este no es el método ideal. Deberíamos ir a la entidad
de servicio y el secreto de cliente, lo mismo que hicimos en Ansible.
Comencemos por crear una entidad de servicio para Terraform. Si ya tiene una entidad
de servicio creada para la sección anterior, úsela. Para crear una entidad de servicio
nueva en la CLI de Azure, use este comando:
az ad sp create-for-rbac -n terraform
En este punto, es posible que ya esté familiarizado con la salida, que contiene el appID,
la contraseña y el ID de inquilino.
Anote los valores en la salida. Crearemos variables para almacenar este valor:
export ARM_CLIENT_ID="<appID>"
export ARM_CLIENT_SECRET="<password>"
export ARM_SUBSCRIPTION_ID="<subscription ID>"
export ARM_TENANT_ID="<tenant ID>"
Por lo tanto, hemos almacenado todos los valores en variables que Terraform usará para
la autenticación. Dado que hemos tratado la autenticación, escribamos código en HCL
con el que podemos implementar recursos en Azure.
Implementación en Azure
Puede usar cualquier editor de código para este propósito. Dado que ya estamos
en una máquina Linux, puede usar vi o nano. Si lo desea, también puede usar Visual
Studio Code, que tiene extensiones para Terraform y Azure, lo que le proporcionará
IntelliSense y resaltado de sintaxis.
Crearemos un directorio terraform para almacenar todo nuestro código y, en el
directorio terraform, crearemos más directorios según lo que vamos a implementar.
En nuestro primer ejemplo, vamos a usar Terraform para crear un grupo de recursos en
Azure. Más adelante, analizaremos cómo implementar una VM en este grupo de recursos.
Por lo tanto, para crear un directorio terraform y una subcarpeta resource-group dentro
de este directorio, ejecute el siguiente comando:
mkdir terraform
cd terraform && mkdir resource-group
cd resource-group
A continuación, cree un archivo main.tf con el siguiente contenido:
provider "azurerm" {
version = "~>1.33"
}
resource "azurerm_resource_group" "rg" {

name = "TerraformOnAzure"
location = "eastus"
}
El código es muy sencillo. Observaremos detalladamente cada uno de estos elementos.
La directiva de proveedor muestra que nos gustaría usar la versión 1.33 del proveedor
azurerm. En otras palabras, estamos indicando que vamos a usar la versión 1.33 del
proveedor de Azure Resource Manager de Terraform, que es uno de los complementos
disponibles para Terraform.
La directiva resource indica que vamos a implementar un recurso de Azure del tipo
azurerm_resource_group con dos parámetros, name y location.
rg significa configuración del recurso. Los nombres de recursos deben ser únicos por
tipo en cada módulo. Por ejemplo, si desea crear otro grupo de recursos en la misma
plantilla, no puede volver a usar rg porque ya lo usó. En su lugar, puede usar cualquier
otro que no sea rg, como rg2.
Antes de iniciar la implementación con la plantilla, primero tenemos que inicializar
el directorio de proyecto, que es nuestra carpeta resource-group. Para inicializar
Terraform, ejecute lo siguiente:
terraform init
Durante la inicialización, Terraform descargará el proveedor azurerm desde su

repositorio y mostrará una salida como esta:
Figura 8.11: Inicialización de Terraform para descargar el proveedor azurerm
Como ya exportamos los detalles de la entidad de servicio a las variables, podemos

realizar la implementación con este comando:
terraform apply
Este comando conectará Terraform con su suscripción de Azure y comprobará si el

recurso existe. Si Terraform se da cuenta de que el recurso no existe, creará un plan
de ejecución para la implementación. Obtendrá la salida que se muestra en la siguiente
captura de pantalla. Para continuar con la implementación, escriba yes:
Figura 8.12: Conexión de Terraform con la suscripción de Azure
Una vez que haya ingresado los datos, Terraform iniciará la creación de recursos.
Después de la creación, Terraform le mostrará un resumen de todo lo que se creó
y cuántos recursos se agregaron y destruyeron, como se muestra aquí:
Figura 8.13: Resumen de los recursos creados

Se generará un archivo de estado llamado terraform.tfstate en el directorio de

proyecto desde donde inicializamos Terraform. Este archivo tendrá la información
de estado y también la lista de recursos que implementamos en Azure.
Creamos correctamente el grupo de recursos. En la siguiente sección, analizaremos
cómo crear una VM de Linux con Terraform.
Implementación de una máquina virtual

En el ejemplo anterior, donde creamos el grupo de recursos, usamos azurerm_resource_
group como el recurso para crear. Para cada recurso habrá una directiva. Por ejemplo,
para una VM, será azurerm_virtual_machine.
También creamos el grupo de recursos con el comando terraform apply. Sin embargo,
Terraform también ofrece una forma de trabajar con un plan de ejecución. Entonces,
en lugar de implementarlo de inmediato, podemos crear un plan y ver qué cambios se
realizarán para luego implementarlos.
Para empezar, puede volver al directorio terraform y crear un nuevo directorio llamado
vm. Siempre es recomendable tener directorios independientes para diferentes proyectos:
mkdir ../vm
cd ../vm
Una vez que esté en el directorio, puede crear un nuevo archivo main.tf con el contenido
que se muestra en el siguiente bloque de código. Use los comentarios agregados para ver
el propósito de cada bloque. Dada la longitud del código, mostramos la versión truncada
del bloque de código. Puede ver e archivo de código main.tf en la carpeta chapter 8 del
repositorio de GitHub de este libro:
provider "azurerm" {
version = "~>1.33"
}
#Create resource group
resource "azurerm_resource_group" "rg" {
name = "TFonAzure"
location = "eastus"
}
.
.
.
#Create virtual machine, combining all the components we created so far
resource "azurerm_virtual_machine" "myterraformvm" {
name = "tf-VM"
location = "eastus"
resource_group_name = azurerm_resource_group.rg.name
network_interface_ids = [azurerm_network_interface.nic.id]
vm_size = "Standard_DS1_v2"
storage_os_disk {
name = "tfOsDisk"
caching = "ReadWrite"
create_option = "FromImage"
managed_disk_type = "Standard_LRS"
}
storage_image_reference {
publisher = "Canonical"
offer = "UbuntuServer"
sku = "16.04.0-LTS"
version = "latest"
}
os_profile {
computer_name = "tfvm"
admin_username = "adminuser"
admin_password = "Pa55w0rD!@1234"
}

os_profile_linux_config {
disable_password_authentication = false
}
}
Si observa la sección de azurerm_virtual_network, puede ver que, en lugar de escribir el

nombre del recurso, dimos una referencia con el formato type.resource_configuration.
parameter. En este caso, en lugar de anotar el nombre del grupo de recursos, la referencia
se determinó como azurerm_resource_group.rg.name. Del mismo modo, en todo el código,
hemos tomado referencias para facilitar la implementación.
Antes de iniciar la planificación de la implementación, tenemos que inicializar el
proyecto con lo siguiente:
terraform init
Como se mencionó anteriormente, usaremos el plan de ejecución. Para crear un plan de

ejecución y guardarlo en un archivo vm-plan.plan, ejecute lo siguiente:
terraform plan -out vm-plan.plan
Recibirá muchas advertencias, pero pueden omitirse de forma segura. Asegúrese de

que el código no muestre ningún error. Si el plan de ejecución se crea correctamente,
mostrará el siguiente paso que se debe tomar para ejecutar el plan, como aparece aquí:
Figura 8.14: Visualización del plan de ejecución

Como se sugiere en la salida, ejecutaremos esto:

terraform apply "vm-plan.plan"
Ahora empezará la implementación y mostrará qué recurso está implementando,

cuánto tiempo ha transcurrido y así sucesivamente, como se muestra en la salida:
Figura 8.15: Detalles de la implementación de recursos
Al final, Terraform brinda un resumen del número de recursos implementados:
Figura 8.16: Resumen del número de recursos implementados

También hay otro comando: el comando show. Esto mostrará el estado completo de la
implementación, como se muestra en la siguiente captura de pantalla:
Figura 8.17: Visualización del estado completo de la implementación
Hemos escrito un pequeño fragmento de código que puede implementar una VM

en Azure. Sin embargo, hay muchos argumentos que se pueden agregar al código
mediante los cuales se puede realizar una configuración avanzada del estado. La
lista completa de argumentos está disponible en la documentación de Terraform
(https://www.terraform.io/docs/providers/azurerm/r/virtual_machine.html) y en
la documentación de Microsoft (https://docs.microsoft.com/es-xl/azure/virtual-
machines/linux/terraform-create-complete-vm).
Como estas plantillas son un poco avanzadas, usarán variables en lugar de los valores
que se repiten. Sin embargo, una vez que se acostumbre, entenderá lo eficaz que
es Terraform.
Por último, puede destruir toda la implementación o el proyecto mediante la ejecución
de lo siguiente:
terraform destroy
Esto eliminará todos los recursos que mencionamos en el archivo main.tf del proyecto.
Si tiene varios proyectos, debe navegar al directorio del proyecto y ejecutar el comando
destroy. Al ejecutar este comando, se le pedirá que confirme la eliminación; una vez que
diga yes, los recursos se eliminarán:
Figura 8.18: Eliminación de todos los recursos con el comando destroy de Terraform
Finalmente, recibirá un resumen, como se muestra aquí:
Figura 8.19: Resumen de los recursos eliminados
Ahora estamos familiarizados con el uso de Terraform en Azure y la implementación

de una VM simple. Actualmente, Terraform está ganando mucha popularidad debido
a su facilidad de uso y la adopción de DevOps. Terraform ha logrado que el proceso de
evaluación de la infraestructura y su reconstrucción esté libre de complicaciones.
Uso de DSC de PowerShell

Al igual que Bash, PowerShell es un shell con posibilidades sólidas de creación de
scripts. Podríamos pensar que PowerShell es más bien un lenguaje de creación de
scripts y que se puede usar para realizar operaciones simples o para crear recursos,
como lo hemos hecho hasta ahora. Sin embargo, las capacidades de PowerShell van
más allá y se extienden hasta la automatización y la configuración.
DSC es una parte importante, pero poco conocida de PowerShell que, en lugar de
automatizar los scripts en el lenguaje de PowerShell, proporciona una orquestación
declarativa en PowerShell.
Si lo compara con Ansible, el soporte para Linux es muy limitado. Pero es muy útil
para las tareas de administración comunes, y las características que no incluye se
pueden compensar con los scripts de PowerShell. Microsoft está muy enfocado en
conseguir que esté a la par con Windows Server. Cuando eso suceda, se reemplazará
por PowerShell DSC Core, una acción muy similar a lo que se hizo antes con PowerShell
| PowerShell Core. Esto estará listo a fines de 2019.
Uso de DSC de PowerShell | 313
Otra nota importante es que, por alguna razón, los scripts de Python que vienen
con DSC no funcionan. De vez en cuando, obtendrá un error 401 o incluso un error
indefinido. En primer lugar, asegúrese de tener la versión más reciente del servidor
OMI y DSC, e inténtelo de nuevo. A veces, hay que intentarlo dos o tres veces.
DSC de Azure Automation

Una forma de usar DSC es usar DSC de Azure Automation. De esta manera, no tiene que
usar una máquina independiente como nodo del controlador. Para poder usar DSC de
Azure Automation, necesitará una cuenta de Azure Automation.
Cuenta de Automation
En Azure Portal, seleccione Todos los servicios en la barra de la izquierda. Vaya hasta
Administración y gobernanza y elija Cuentas de Automation. Cree una cuenta de
automatización y asegúrese de elegir Ejecutar como cuenta.
Navegue de nuevo a Todos los servicios, Herramientas de administración
y, a continuación, seleccione la cuenta recién creada:
Figura 8.20: Creación de una cuenta de automatización en Azure Portal

Aquí puede administrar sus nodos, configuraciones y mucho más.

Tenga en cuenta que este servicio no es exactamente gratuito. La automatización
de procesos tiene un precio por minuto de ejecución de trabajo, mientras que la
administración de configuración tiene un precio por nodo administrado.
Para poder usar esta cuenta, necesitará la URL de registro y la clave correspondiente de
su Cuenta de ejecución. Ambos valores están disponibles en Cuenta y Configuración de
la clave.
O bien, ejecute el siguiente comando en PowerShell:
Get-AzAutomationRegistrationInfo '
-ResourceGroup <resource group> '
-AutomationAccountName <automation account name>
Hay una extensión de VM disponible para Linux; de esta manera, puede implementar
VM, incluida su configuración, completamente orquestadas.
Para obtener más información, visite https://github.com/Azure/azure-linux-
extensions/tree/master/DSC y https://docs.microsoft.com/es-xl/azure/virtual-
machines/extensions/dsc-linux.
Debido a que vamos a usar con Linux y DSC, necesitaremos un módulo de DSC llamado
nx. Este módulo contiene recursos de DSC para Linux. En la configuración de su
cuenta de automatización, seleccione Recursos y módulos compartidos. En la pestaña
Explorar galería, busque nx e importe el módulo.
Instalación de DSC de PowerShell en Linux

Para poder usar DSC de PowerShell en Linux, necesitará Open Management Infrastructure
Service. Las versiones compatibles de las distribuciones de Linux son las siguientes:
• Ubuntu 12.04 LTS, 14.04 LTS y 16.04 LTS. Ubuntu 18.04 no es compatible por ahora.
• RHEL/CentOS 6.5 y posteriores.
• openSUSE 13.1 y posteriores.
• SUSE Linux Enterprise Server 11 SP3 y posteriores.
Se puede descargar el software en https://github.com/Microsoft/omi.

La instalación en las distribuciones basadas en Red Hat es la siguiente:
sudo yum install \
https://github.com/Microsoft/omi/releases/download/\
v1.4.2-3/omi-1.4.2-3.ssl_100.ulinux.x64.rpm
Para Ubuntu, puede descargar el archivo deb desde el repositorio de GitHub mediante
wget e instalarlo con dpkg:
dpkg –i ./omi-1.6.0-0.ssl_110.ulinux.x64.deb
Nota
Asegúrese de descargar el archivo que coincide con su versión de SSL. La versión
de SSL se puede comprobar mediante el comando openssl version.
Después de la instalación, el servicio se inicia automáticamente. Compruebe el estado

del servicio con el siguiente comando:
sudo systemctl status omid.service
Para mostrar la información del producto y la versión, incluidos los directorios de

configuración utilizados, use el siguiente comando:
/opt/omi/bin/omicli id
Figura 8.21: Visualización de la información del producto y la versión

Creación de estado deseado

DSC de PowerShell no es solo un script o un código con parámetros, como en Ansible.
Para empezar con DSC de PowerShell, necesitará un archivo de configuración que debe
compilar en un archivo de Management Object Format (MOF).
Pero empecemos por el principio. Vamos a crear un archivo, example1.ps1, con el
siguiente contenido:
Configuration webserver {
Import-DscResource -ModuleName PSDesiredStateConfiguration,nx
Node "ubuntu01"{
nxPackage apache2
{
Name = "apache2"
Ensure = "Present"
PackageManager = "apt"
}
}
}
webserver
Investiguemos esta configuración. Como se indicó, es muy similar a una declaración
de función. La configuración obtiene una etiqueta y se ejecuta al final del script.
Se importan los módulos necesarios, se declara el nombre de host de la VM y se inicia
la configuración.
Recursos de DSC de PowerShell

En este archivo de configuración, se usa un recurso llamado nxPackage. Hay varios
recursos incorporados:
• nxArchive: proporciona un mecanismo para desempaquetar archivos (.tar, .zip)
en una ruta específica.
• nxEnvironment: administra las variables del entorno.
• nxFile: administra archivos y directorios.
• nxFileLine: administra líneas en un archivo de Linux.
• nxGroup: administra grupos de Linux locales.
• nxPackage: administra paquetes en nodos de Linux.
• nxScript: ejecuta scripts. La mayoría de las veces, se usa para cambiar
temporalmente a un enfoque de orquestación más imperativo.
• nxService: administra los servicios de Linux (daemons).
• nxUser: administra a los usuarios de Linux.
También puede escribir sus propios recursos en el lenguaje MOF, C#, Python o C/C++.
Puede usar la documentación oficial que se encuentra en https://docs.microsoft.com/
es-xl/powershell/dsc/lnxbuiltinresources.
Guarde el script y ejecútelo de la siguiente manera:
pwsh -file example1.ps
Como resultado del script, se crea un directorio con el mismo nombre que el nombre
de la configuración. En él, hay un archivo localhost en formato MOF. Este es el lenguaje
que se usa para describir las clases de CIM (CIM significa Common Information Model
o Modelo de información común). CIM es un estándar abierto para la administración de
un entorno completo, incluido el hardware.
Creemos que esta descripción por sí sola es suficiente para entender por qué Microsoft
elige este modelo y el archivo de idioma correspondiente para la orquestación.
También puede cargar el archivo de configuración en Azure, en Configuraciones de DSC.
Presione el botón Compilar para generar el archivo MOF en Azure.
Aplicación de recursos en Azure

Si lo desea, puede aplicar el estado deseado localmente, mediante los scripts en
/opt/microsoft/dsc/Scripts, que, en nuestra opinión, no es tan fácil como debería ser.
Además, debido a que este capítulo se trata de la orquestación en Azure, simplemente
avanzaremos directo a Azure.
Registre la VM:
sudo /opt/microsoft/dsc/Scripts/Register.py \
--RegistrationKey <automation account key> \
--ConfigurationMode ApplyOnly \
--RefreshMode Push --ServerURL <automation account url>
Compruebe la configuración de nuevo:

sudo /opt/microsoft/dsc/Scripts/GetDscLocalConfigurationManager.py
El nodo ahora se ve en el panel de Nodos de DSC en la configuración de su Cuenta de
Automation. Ahora puede vincular la configuración de DSC cargada y compilada. Se
aplica la configuración.
Otra forma es usar la opción Agregar nodo y luego seleccionar la configuración de DSC.
Para concluir, el escenario de caso práctico principal de DSC de PowerShell es escribir,
administrar y compilar configuraciones de DSC, así como importar y asignar estas
configuraciones a los nodos de destino en la nube. Antes de usar cualquier herramienta,
debe comprender los escenarios de casos prácticos y cómo se adaptan a su entorno
para lograr el objetivo. Hasta ahora, hemos configurado VM. La siguiente sección
se trata de cómo auditar la configuración dentro de la VM de Linux mediante la
configuración de invitado de Azure Policy.
Configuración de invitado de Azure Policy

Las directivas se usan principalmente para la gobernanza de los recursos. Azure Policy
es un servicio de Azure con el que puede crear, administrar y asignar las directivas en
Azure. Estas directivas se pueden usar para la auditoría y el cumplimiento. Por ejemplo,
si hospeda una aplicación protegida en la ubicación Este de EE. UU. y desea limitar las
implementaciones solo a esa zona, se puede usar Azure Policy para lograrlo.
Supongamos que no desea implementar servidores SQL en una suscripción. En Azure
Policy, puede crear una directiva y especificar los servicios permitidos, y solo se
pueden implementar esos servicios en esa suscripción. Tenga en cuenta que, si asigna
una directiva a una suscripción que ya tiene recursos, Azure Policy solo puede actuar
sobre los recursos que se crean después de la asignación. Sin embargo, si alguno de los
recursos existentes antes de la asignación no cumple con la directiva, se marcará como
“no conforme”, por lo que un administrador puede rectificarlos si es necesario. Además,
Azure Policy solo actúa durante la etapa de validación de la implementación.
Configuración de invitado de Azure Policy | 319
Algunas de las directivas incorporadas son las siguientes:

• Ubicaciones permitidas: con esto, puede exigir el cumplimiento geográfico.
• SKU de máquinas virtuales permitidos: define un conjunto de SKU de
máquinas virtuales.
• Agregar una etiqueta a los recursos: agrega una etiqueta al recurso. Si no se
entrega ningún valor, tomará el valor predeterminado de la etiqueta.
• Aplicar una etiqueta y su valor: se usa para aplicar una etiqueta obligatoria
y su valor al recurso.
• Tipos de recursos no permitidos: impide la implementación de recursos
seleccionados.
• SKU de la cuenta de almacenamiento permitidos: analizamos diferentes SKU que
están disponibles para las cuentas de almacenamiento en el capítulo anterior,
como LRS, GRS, ZRS y RA-GRS. Puede especificar las SKU permitidas y al resto
se les niega la implementación.
• Tipo de recurso permitido: como mencionamos en el ejemplo, puede especificar
qué recursos se permiten en la suscripción. Por ejemplo, si solo desea VM y redes,
puede aceptar los proveedores de recursos Microsoft.Compute y Microsoft.
Network; a todos los demás proveedores se les niega la implementación.
Hasta ahora, hemos analizado cómo se puede usar Azure Policy para auditar los
recursos de Azure, pero también se puede usar para auditar la configuración dentro
de una VM. Azure Policy logra esta tarea con el cliente y la extensión de configuración
de invitado. La extensión y el cliente trabajan mano a mano para confirmar la
configuración del SO invitado, la presencia de una aplicación, su estado y también la
configuración del entorno del SO invitado.
La configuración de invitado de Azure Policy solo puede ayudarlo a auditar la VM
invitada. Por ahora, no está disponible la aplicación de configuraciones.
Extensión de configuración de invitado para Linux

La configuración de la directiva de invitado la realiza la extensión y el agente de
configuración de invitado. El agente de configuración de invitado en las VM se configura
mediante la extensión de configuración de invitado para Linux. Como se analizó
anteriormente, trabajan de la mano, lo que permite al usuario ejecutar la directiva en
el invitado en las VM, lo que a su vez, ayuda al usuario a auditar las directivas en la VM.
Chef InSpec (https://www.inspec.io/docs/) es la directiva en el invitado para Linux.
Veamos cómo implementar la extensión en una VM y usar los comandos compatibles
con la extensión.
Implementación en una máquina virtual

Para ello, debe tener una VM de Linux. Implementaremos la extensión de la
configuración de invitado en la VM al ejecutar lo siguiente:
az vm extension set --resource-group <resource-group> \
--vm-name <vm-name> \
--name ConfigurationForLinux \
--publisher Microsoft.GuestConfiguration \
--version 1.9.0
Obtendrá una salida similar a esta:
Figura 8.22: Implementación de la extensión de configuración de invitado en la VM
Comandos
La extensión de configuración de invitado es compatible con los comandos install,
uninstall, enable, disable y update. Para ejecutar estos comandos, debe cambiar
el directorio de trabajo actual a /var/lib/waagent/Microsoft.GuestConfiguration.
ConfigurationForLinux-1.9.0/bin. Después de eso, puede encadenar los comandos
disponibles con el script guest-configuration-shim.
Nota
Compruebe si la ejecución está habilitada para el archivo. Si no es así, use chmod
+x guest-configuration-shim para establecer el permiso de ejecución.
La sintaxis general para ejecutar cualquier comando es ./guest-configuration-shim

<command name>.
Configuración de invitado de Azure Policy | 321
Por ejemplo, si desea instalar la extensión de configuración de invitado, puede usar

el comando install. Cuando la extensión ya está instalada, se llamará a enable, que
extraerá el paquete Agent, que instala y habilita al agente.
Del mismo modo, update actualizará el Servicio de agente al nuevo agente, disable
inhabilitará el agente y, por último, uninstall desinstalará el agente.
El agente se descarga en una ruta como /var/lib/waagent/Microsoft.
GuestConfiguration.ConfigurationForLinux-<version>/GCAgent/DSC, y la salida de
agent se guarda en los archivos stdout y stderr en este directorio. Si se produce
algún problema, compruebe el contenido de estos archivos. Intente comprender
el error y, a continuación, solucionar el problema.
Los registros se guardan en /var/log/azure/Microsoft.GuestConfiguration.
ConfigurationForLinux. Puede usarlos para depurar los problemas.
Actualmente, estas son las versiones compatibles de SO para la configuración de
invitado de Azure Policy:
Publicador Nombre Versiones

Canonical Ubuntu Server 14.04, 16.04, 18.04
Credativ Debian 8, 9
OpenLogic CentOS 7.3, 7.4, 7.5
Red Hat Red Hat Enterprise Linux 7.4, 7.5
Suse SLES 12 SP3
Figura 8.23: Versiones de SO compatibles con la configuración de invitado de Azure Policy
Azure Policy se escribe como un manifiesto JSON. Como las directivas de redacción
no forman parte de este libro, puede consultar la directiva de ejemplo compartida
por Microsoft (https://github.com/Azure/azurepolicy/tree/master/samples/
GuestConfiguration/installed-application-linux). Este ejemplo es para auditar si se
instalan aplicaciones específicas dentro de las VM de Linux.
Si investiga el ejemplo, aprenderá cuáles son los componentes y cómo puede usar los
parámetros en su contexto.
Otras soluciones
Otra gran opción en el mercado de la orquestación es Puppet. Hasta hace muy poco,
el soporte para Azure en Puppet era muy limitado, pero eso está cambiando muy
rápido. El módulo de Puppet, puppetlabs/azure_arm, aún está en sus primeras etapas,
pero puppetlabs/azure le ofrece todo lo que necesita. Ambos módulos necesitan que
la CLI de Azure funcione. La integración de la CLI de Azure en el producto comercial
de Puppet Enterprise es increíblemente buena. Azure tiene una extensión de VM
disponible para las VM que se convierten en nodos de Puppet.
Puede obtener más información en https://puppet.com/products/managed-
technology/microsoft-windows-azure.
También puede usar el software Chef, que proporciona una plataforma de
automatización y orquestación que ha existido durante mucho tiempo. Su desarrollo
comenzó en 2009. El usuario escribe “recetas” que describen cómo Chef administra la
“cocina” con herramientas, como un cuchillo. En Chef, gran parte de su terminología
proviene de la cocina. Chef se integra muy bien con Azure, especialmente si usa Chef
Automate de Azure Marketplace. También hay una extensión de VM disponible. Chef
está diseñado para entornos grandes y tiene una curva de aprendizaje relativamente
pronunciada, pero vale la pena, al menos, intentarlo.
Puede obtener más información en https://www.chef.io/partners/azure/.
Resumen
Comenzamos este capítulo con una breve introducción a la orquestación, las razones
para usarla y los diferentes enfoques: imperativo en comparación a declarativo.
Después de eso, abarcamos las plataformas de Ansible, Terraform y DSC de PowerShell.
Se cubrieron muchos detalles sobre lo siguiente:
• Cómo instalar las plataformas
• Trabajar con recursos en el nivel de SO
• Integración con Azure
Preguntas | 323
Ansible es, por lejos, la solución más completa y, tal vez, la que tiene la curva de
aprendizaje menos pronunciada. Sin embargo, todas las soluciones son muy eficaces
y siempre hay formas de solucionar sus limitaciones. Y para todas las plataformas de
orquestación, el futuro es prometedor en términos de que existan más características
y capacidades.
La creación de VM de Linux no es la única forma de crear una carga de trabajo en
Azure; también puede usar la virtualización de contenedores para implementar una
plataforma para su aplicación. En el próximo capítulo, abarcaremos las tecnologías
de contenedores.
Preguntas
Para este capítulo, omitamos las preguntas normales. Active algunas VM y elija la
plataforma de orquestación que prefiera. Configure los grupos de seguridad de red
para permitir el tráfico HTTP.
Intente configurar los siguientes recursos con Ansible, Terraform o DSC de PowerShell:
1. Cree un usuario y haga que sea miembro de wheel (distribuciones basadas en RH)
o sudo (Ubuntu) del grupo.
2. Instale un servidor web Apache, entregue contenido de /wwwdata, asegúrelo con
AppArmor (Ubuntu) o SELinux (distribuciones basadas en RHEL) y entregue una
página index.html buena en este servidor web.
3. Restrinja SSH a su dirección IP. Los puertos HTTP deben estar abiertos a todo
el mundo. Puede usar los métodos de systemd al proporcionarles archivos de
reemplazo o FirewallD.
4. Implemente una nueva VM con la distribución y la versión que prefiera.
5. Cree un nuevo archivo /etc/hosts mediante variables. Si usa DSC de PowerShell,
también necesitará PowerShell para esta tarea. Para expertos: use los nombres de
host y las direcciones IP de otras máquinas de su grupo de recursos.
Lectura adicional
Realmente esperamos que haya disfrutado esta introducción a las plataformas de
orquestación. Fue solo una breve introducción para que despertar su curiosidad por
obtener más información. Todos los sitios web de las herramientas de orquestación
mencionadas en este capítulo son excelentes recursos y fáciles de leer.
Algunos recursos adicionales que vale la pena mencionar son:
• Learning PowerShell DSC: segunda edición de James Pogran.
• Ansible: Creemos que Learn Ansible de Russ McKendrick, y otros títulos del mismo
autor sobre Ansible merecen mucho crédito. Si no desea leer el libro, puede
consultar la documentación de Ansible para comenzar. Si desea algunos tutoriales
prácticos, puede usar este repositorio de GitHub: https://github.com/leucos/
ansible-tuto.
• Terraform: Terraform on Microsoft Azure - Part 1: Introduction es una serie de
blogs que escribió Julien Corioland, ingeniero sénior de software de Microsoft.
El blog incluye una serie de temas que analizan Terraform en Azure. Vale la pena
leer y probar las tareas. El blog está disponible en https://blog.jcorioland.io/
archives/2019/09/04/terraform-microsoft-azure-introduction.html.
• Mastering Chef de Mayank Joshi
• Learning Puppet de Jussi Heinonen
Virtualización de
9
contenedores en Azure
En el Capítulo 2, Introducción a la nube de Azure, iniciamos nuestro viaje en Azure con
la creación de nuestra primera carga de trabajo en Azure: la implementación de una VM
de Linux. Después de eso, cubrimos muchos aspectos del sistema operativo Linux.
En el Capítulo 7, Implementación de sus máquinas virtuales, exploramos varias opciones
para implementar sus VM, y en el Capítulo 8, Exploración de la automatización de la
configuración continua, se trató de qué hacer después en términos de administración
de la configuración mediante herramientas de orquestación.
La orquestación es una parte cada vez más importante de un movimiento llamado
DevOps. DevOps se trata de eliminar los silos clásicos de las organizaciones. Los
diferentes equipos involucrados en el desarrollo, la prueba y la implementación de
productos deben comunicarse y trabajar en conjunto. DevOps es una combinación
de filosofías, prácticas y herramientas culturales. Además, es una forma de hacer que
las implementaciones sean eventos graduales, frecuentes y rutinarios, a la vez que
restringe el impacto de los errores.
326 | Virtualización de contenedores en Azure
Las VM no son la única forma de implementar cargas de trabajo: también puede

implementar su carga de trabajo en contenedores. Esto hace que sea posible, junto
con la orquestación, cumplir con los requisitos de DevOps.
Entonces, antes de conocer e implementar contenedores en Azure, echemos un vistazo
rápido a lo que este capítulo nos ofrece. Al final de este capítulo:
• Comprenderá la historia de los contenedores y conocerá las primeras adopciones
de la contenedorización.
• Estará familiarizado con herramientas de contenedor, como systemd-nspawn y Docker.
• Será capaz de trabajar con Docker Machine y Docker Compose.
• Podrá usar Azure Container Instances y Azure Container Registry.
• Conocerá las herramientas de contenedores de nueva generación, como Buildah,
Podman y Skopeo.
Ahora, primero entenderemos qué es un contenedor y cómo ha evolucionado.
Introducción a la tecnología de contenedores

En el Capítulo 1, Explorar la nube de Azure, presentamos una breve introducción
a los contenedores. Por lo tanto, vamos a seguir adelante y a abarcar los contenedores
con más detalle. Sabemos que las VM se ejecutan en un hipervisor y, para cada
propósito, en la mayoría de los casos tiene que crear una VM independiente para aislar
los entornos. Las VM tendrán un sistema operativo invitado, como Linux, y, además,
instalaremos el software necesario. Habrá escenarios en los que tendrá que implementar
un gran número de VM para realizar pruebas. Si está usando una infraestructura local
que ejecuta Hyper-V, tiene que pensar en el uso de recursos, es decir, cuánta memoria,
CPU y lo demás que usará para cada VM. Si está implementando en Azure, también tiene
que pensar en el costo. Es posible que necesite algunas VM solo por un par de horas
para probar algo, pero las huellas de estas VM son grandes; son equipos completos que
se ejecutan virtualmente. Otro tema son los problemas de compatibilidad. Supongamos
que tiene una aplicación que requiere un paquete de dependencia, como Python 2.2.
Ahora piense en otra aplicación que se ejecuta en la misma VM que tiene problemas
de compatibilidad con Python 2.2 y solo puede funcionar con Python 2.1. Terminaría
creando una nueva VM para la segunda aplicación con Python 2.1. Para solucionar este
problema, se crearon los contenedores. Esta es una representación gráfica de cómo los
contenedores se diferencian de las VM:
Introducción a la tecnología de contenedores | 327
Aplicación Aplicación Aplicación Aplicación Aplicación Aplicación

Bin/Libs Bin/Libs Bin/Libs
SO invitado SO invitado SO invitado Bin/Libs Bin/Libs Bin/Libs
Hipervisor Tiempo de ejecución de contenedor
SO host SO host
Infraestructura Infraestructura
Máquina virtual Contenedores

Figura 9.1: Representación de VM y contenedores
Al igual que las VM, los contenedores le permiten empaquetar su aplicación junto
con todas las dependencias y bibliotecas. Son entornos aislados, como las VM, y se
pueden usar para probar y ejecutar aplicaciones sin necesidad de crear varias VM.
Los contenedores también son ligeros.
En lugar de virtualizar cada componente de hardware, como con las VM, los
contenedores virtualizan en el nivel de SO. Esto significa que los contenedores tienen
una huella más pequeña que las VM. Por ejemplo, una imagen ISO de Ubuntu tendrá
un tamaño cercano a 2,4 GB; por otro lado, una imagen de contenedor de Ubuntu pesa
menos de 200 MB. Consideremos el ejemplo anterior, donde tuvimos problemas de
dependencia con Python 2.2 y terminamos creando dos VM. Con los contenedores,
podemos tener dos contenedores con una huella mucho más pequeña que dos VM.
Además, el costo y el uso de recursos del SO host es mucho menor que el de dos VM.
Los contenedores se implementan mediante un tiempo de ejecución de contenedor,
y existen diferentes tiempos de ejecución disponibles. En este capítulo, observaremos
los tiempos de ejecución de contenedores populares.
Un contenedor no es el Santo Grial. No soluciona todos sus problemas. Sin embargo,

puede considerar los siguientes escenarios y, si alguno de ellos coincide con sus
requisitos, puede crear un contenedor en su aplicación:
• Se necesitan aplicaciones que suelen requerir actualizaciones con nuevas
características, preferentemente sin tiempo de inactividad, impulsadas por las
necesidades empresariales.
• Los ingenieros y desarrolladores de sistemas pueden trabajar juntos para abordar
las necesidades de la empresa y comprender y conocer lo suficiente los dominios
de los demás (sin ser un especialista en ambos), además de tener una cultura de
experimentación y aprendizaje continuos.
• Hay espacio para el error con el fin de que la aplicación sea mejor.
• La aplicación no es un único punto de error.
• La aplicación no es una aplicación crítica en términos de disponibilidad y seguridad.
Otra pequeño detalle: si tiene muchos tipos diferentes de aplicaciones y casi no hay
código compartido entre esas aplicaciones, la tecnología de contenedores sigue siendo
una opción, pero es posible que las VM sean una mejor solución en este escenario.
Cubriremos un poco la historia de la tecnología de contenedores para que pueda
comprender mejor de dónde proviene. Exploraremos algunas de las soluciones
disponibles en la actualidad: systemd-nspawn y Docker. Hay más implementaciones
de virtualización de contenedores disponibles, incluso algunas de las primeras
implementaciones, como LXC. De hecho, no importa qué herramienta de contenedores
use: si entiende las ideas y los conceptos que son la base de los contenedores, es fácil
implementar las mismas ideas y conceptos con otras herramientas. Lo único que cambia
es el comando; los conceptos subyacentes para todas estas herramientas son los mismos.
Historia de los contenedores

Los contenedores son muy populares hoy en día. Pero no son nuevos; no salieron de la
nada. No es fácil nombrar el momento exacto cuando aparecieron. No queremos darle
una lección de historia, pero la historia puede ayudarle a entender la tecnología e incluso
darle una pista sobre por qué o cuándo debe usar contenedores en su organización.
Por lo tanto, en lugar de centrarnos en una línea de tiempo exacta, solo trataremos
los pasos clave: la implementación de tecnologías que son importantes si desea
comprender la tecnología de contenedores tal como es actualmente.
Introducción a la tecnología de contenedores | 329
El entorno chroot
En Linux, hay un sistema de archivos raíz, como se explica en el Capítulo 5, Administración
avanzada de Linux, y todo se monta en ese sistema de archivos, que será visible para los
procesos en ejecución y sus hijos.
Un proceso que se ejecuta en chroot tiene su propio sistema de archivos raíz,
completamente separado de la raíz del sistema completo, conocida como chroot jail.
En chroot jail, hay un sistema de archivos llamado fs.chroot. A menudo se usa en
desarrollo, ya que el programa que se ejecuta en chroot no puede acceder a archivos
o comandos fuera de su sistema de archivos raíz. Para poner en marcha un chroot jail
desde un directorio, ejecute lo siguiente:
chroot /<directory>
En 1979, se introdujo la llamada al sistema de chroot en la versión 7 de Unix, y en 1982,

se introdujo en BSD Unix. Linux ha implementado esta llamada al sistema desde los
primeros días de su existencia.
OpenVZ
En 2005, casi al mismo tiempo que Solaris comenzó su tecnología de contenedores, una
empresa llamada Virtuozzo inició el proyecto OpenVZ.
Tomaron el principio del entorno de chroot y lo aplicaron a otros recursos. Un proceso
de chroot tendrá lo siguiente:
• Un sistema de archivos raíz
• Usuarios y grupos
• Dispositivos
• Un árbol de procesos
• Una red
• Objetos de comunicación entre procesos
En ese momento, OpenVZ se consideró como una alternativa ligera a la virtualización

basada en un hipervisor y también como una plataforma sólida para los desarrolladores.
Todavía existe, y puede usarlo sobre cada sistema operativo Linux, ejecutándose en la
nube o no.
El uso de OpenVZ es similar al uso de una VM: se crea una imagen con una instalación
base de su distribución favorita y, si lo desea, después se puede usar la orquestación
para instalar la aplicación y mantener todo.
LXC
En 2006, los ingenieros de Google empezaron a trabajar en una característica en
el kernel de Linux llamada cgroups (grupos de control) para permitir el control de
recursos en recursos como la CPU, la memoria, E/S de disco y la red de colecciones
de procesos (grupos de recursos).
Una característica relacionada del kernel de Linux es el concepto de aislamiento de
espacios de nombres: la posibilidad de aislar los grupos de recursos para que no puedan
ver los recursos en otros grupos. Entonces, cgroups se convirtió en un espacio de nombre.
En 2008, cgroups se fusionó en el kernel de Linux y se introdujo un nuevo espacio de
nombres, el espacio de nombres usuario. Ambas tecnologías se habilitaron para dar
un nuevo paso para los contenedores: LXC.
Otros espacios de nombres disponibles son pid, mount, network, uts (nuestro nombre
de dominio) e ipc.
Ya no es necesario mantenerse al día con el desarrollo del kernel de Linux: cada componente
que se necesita está disponible, y hay una administración de recursos mucho mejor.
Recientemente, Canonical desarrolló un nuevo administrador de contenedores llamado
LXD, con LXC en su backend y como objetivo busca proporcionar una experiencia de
usuario mejorada para la administración de contenedores. Técnicamente, LXD usa LXC
a través de liblxc y su enlace Go para lograr este objetivo. Algunas de las ventajas de
LXD se indican aquí:
• Seguro
• Altamente escalable
• Simplifica el uso compartido de recursos
systemd-nspawn
systemd incluye una solución de contenedores. Comenzó como un experimento y
luego Lennart Poettering lo consideró listo para la producción. De hecho, es la base
de otra solución, Rkt. En el momento de escribir este libro, el desarrollo de Rkt había
terminado. Sin embargo, aún puede acceder al repositorio de Rkt de GitHub
(https://github.com/rkt/rkt).
systemd-nspawn no es muy conocido, pero es una solución eficaz que está disponible
en todos los sistemas Linux modernos. Se crea sobre los espacios de nombre del kernel
y systemd para la administración. Es una especie de chroot con esteroides.
Si desea obtener más información sobre las tecnologías subyacentes de los
contenedores, systemd-nspawn es un buen punto de partida. Aquí, cada componente
es visible y se puede configurar manualmente, si lo desea. La desventaja de systemd-
nspawn es que tiene que hacer todo por su cuenta, desde crear la imagen y la
orquestación hasta la alta disponibilidad: todo es posible, pero tiene que compilarlo.
systemd-nspawn | 331
Los contenedores también se pueden crear mediante administradores de paquetes,

como yum, y mediante la extracción de imágenes en la nube sin procesar (varias
distribuciones proporcionan esas imágenes, como https://cloud.centos.org/centos/7/
images y https://cloud-images.ubuntu.com/). Incluso puede usar imágenes de Docker.
Como se indica, hay varias formas de crear un contenedor. Como ejemplo, abordaremos
dos de ellas: debootstrap y yum.
Creación de un contenedor con debootstrap

La utilidad debootstrap es una herramienta que instalará un sistema basado en Debian
o Ubuntu en un subdirectorio de otro sistema ya instalado. Está disponible en los
repositorios de SUSE, Debian y Ubuntu; en CentOS u otras distribuciones basadas
en Red Hat, deberá extraerla del repositorio de Paquetes Adicionales para Linux
Empresarial (EPEL).
Como ejemplo, vamos a usar bootstrap con Debian en una máquina de CentOS para
crear una plantilla para nuestros contenedores systemd.
Para cumplir el fin de este capítulo, si se ejecuta en CentOS, debe cambiar la etiqueta
de seguridad de systemd-nspawn:
semanage fcontext -a -t virtd_lxc_exec_t /usr/bin/systemd-nspawn
restorecon -v /usr/bin/systemd-nspawn
En primer lugar, instale debootstrap:
sudo yum install epel-release
sudo yum install debootstrap
Cree un subdirectorio:
sudo mkdir -p /var/lib/machines/releases/stretch
sudo -s
cd /var/lib/machines/releases
Y bootstrap, por ejemplo, desde el espejo de Estados Unidos de Debian:
debootstrap --arch amd64 stretch stretch \
http://ftp.us.debian.org/debian
Creación de un contenedor con yum

La utilidad yum está disponible en todos los repositorios y se puede usar para crear un
contenedor con una distribución basada en Red Hat.
Revisemos los pasos para crear un contenedor de CentOS 7:
1. Cree un directorio para instalar CentOS y que se usará para nuestra plantilla:
sudo mkdir -p /var/lib/machines/releases/centos7
sudo -s
cd /var/lib/machines/releases/centos7
En primer lugar, debe descargar el paquete centos-release rpm en http://mirror.
centos.org/centos-7/7/os/x86_64/Packages/.
2. Inicialice base de datos de rpm e instale este paquete:
rpm --rebuilddb --root=/var/lib/machines/releases/centos7
rpm --root=/var/lib/machines/releases/centos7 \
-ivh --nodeps centos-release*rpm
3. Ahora está listo para instalar, al menos, el mínimo:
yum --installroot=/var/lib/machines/releases/centos7 \
groups install 'Minimal Install'
Después de la instalación de los paquetes, está disponible un sistema de archivos raíz
completo, que ofrece todo lo necesario para arrancar el contenedor. También puede
usar este sistema de archivos raíz como plantilla; en ese caso, debe modificar la plantilla
para asegurarse de que cada contenedor sea único.
systemd-firstboot
systemd-firstboot es una buena forma de configurar algunas cosas si inicia el
contenedor por primera vez. Puede configurar los siguientes parámetros:
• Configuración regional del sistema (--locale=)
• Mapa del teclado del sistema (--keymap=)
• Zona horaria del sistema (--timezone=)
• Nombre de host del sistema (--hostname=)
• ID de máquina del sistema (--machine-id=)
• Contraseña del usuario raíz (--root-password=)
También puede usar el parámetro -prompt para solicitar estos parámetros en el

primer arranque.
En el siguiente ejemplo, modificaremos la unidad systemd-firstboot para pasar a una
configuración que se ejecutará cuando el contenedor se ejecute por primera vez.
Ejecute chroot en el directorio del contenedor. Tomemos como ejemplo nuestra imagen
de CentOS:
chroot /var/lib/containers/releases/centos7
passwd root
Arranque la imagen:
systemd-nspawn --boot -D centos7
Abra la unidad systemd-firstboot, /usr/lib/systemd/system/systemd-firstboot.service

y modifíquela:
[Unit]
Description=First Boot Wizard
Documentation=man:systemd-firstboot(1)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
systemd-remount-fs.service
Before=systemd-sysusers.service sysinit.target shutdown.target
ConditionPathIsReadWrite=/etc
ConditionFirstBoot=yes
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/systemd-firstboot --locale=en_US-utf8 --root-
password=welk0mITG! --timezone=Europe/Amsterdam
StandardOutput=tty
StandardInput=tty
StandardError=tty
Habilite el servicio:
systemctl enable systemd-firstboot
Limpie la configuración:
rm /etc/\
{machine-id,localtime,hostname,shadow,locale.conf,securetty}
Salga del entorno de chroot con Ctrl + D.
Implementación del primer contenedor

Si está usando el directorio de la plantilla del sistema de archivos BTRFS como un
subvolumen, puede usar el parámetro --template de systemd-nspawn. De lo contrario,
creará un nuevo subvolumen:
cd /var/lib/machines/releases
cp -rf centos7/ /var/lib/machines/centos01
Es momento de arrancar nuestro primer contenedor:
systemd-nspawn --boot -D centos01
Intente iniciar sesión y abandonarlo con Ctrl + ]]].

A partir de ahora, puede administrar los contenedores con el comando machinectl:
machinectl start <machine name>
Inicie sesión con los siguientes datos:

machinectl login <machine name>
Hay muchos otros parámetros de machinectl que vale la pena investigar. Si recibe un
mensaje de denegación de permiso, piense en la solución de problemas de SELinux.
Además, journalctl tiene un parámetro -M para ver el inicio de sesión dentro del
contenedor, o use lo siguiente:
journalctl _PID=<pid of container> -a
Si ejecuta hostnamectl en el contenedor, verá algo similar a lo siguiente:
Figura 9.2: Salida del comando hostnamectl
El kernel es uno de los hosts.
Habilitación de un contenedor en el momento del arranque

Para que un contenedor esté disponible en el momento del arranque, habilite el objetivo
machines.target:
sudo systemctl enable machines.target
Ahora cree un archivo nspawn para nuestro contenedor: /etc/systemd/nspawn/centos01.

nspawn. El nombre de archivo debe ser el mismo que el contenedor:
[Exec]
PrivateUsers=pick
[Network]
Zone=web
Port=tcp:80
[Files]
PrivateUsersChown=yes
[Network] también configura el reenvío de puertos desde el puerto TCP 80 en el

contenedor hasta el puerto 80 en el host. Tiene que configurar una dirección IP en la
interfaz de red en el contenedor y en el host en la interfaz de Ethernet virtual en la
subred para que funcione.
Ahora habilite la VM:
sudo machinectl enable centos01
Ahora que sabe cómo trabajar con systemd-nspawn e implementar su contenedor,

continuemos y hablemos de la herramienta de contenedores más popular: Docker.
Es posible que haya oído hablar mucho sobre Docker, así es que empecemos.
Docker
En marzo de 2010, Solomon Hykes comenzó el desarrollo de Docker. Empezó en
Francia como una nube dotCloud interna. Gracias al lanzamiento público en una gran
conferencia de Python en 2013 y al interés de Red Hat, Docker realmente prosperó. En
el último trimestre de ese mismo año, se cambió el nombre de la empresa a Docker Inc.
Docker se creó originalmente sobre LXC, pero después de un tiempo, se reemplazó LXC
con su propia biblioteca libcontainer.
La arquitectura de Docker es bastante compleja: está conformada por un cliente, Docker
y un demonio, dockerd. Otro demonio, containerd, es una capa de abstracción para
el SO y el tipo de tecnología de contenedor que se está utilizando. Puede interactuar
con containerd mediante la utilidad docker- containerd-ctr. El demonio containerd es
responsable de lo siguiente:
• El registro (donde puede almacenar imágenes)
• La imagen (compilación, metadatos, etcétera)
• Las redes
• Los volúmenes (para almacenar datos persistentes)
• Las firmas (confianza en el contenido)
containerd se comunica con RunC, que es responsable de lo siguiente:

• Administración del ciclo de vida
• Información del tiempo de ejecución
• Ejecución de comandos en el contenedor
• Generación de especificaciones (ID de imagen, etiquetas, etcétera)
Docker | 337
Hay dos ediciones de Docker disponibles: Docker Community Edition (CE) y Docker
Enterprise Edition (EE). Docker Inc vendió Docker EE a Mirantis en noviembre de 2019;
sin embargo, Docker Inc todavía administra Docker CE. Docker EE agrega el soporte
técnico de Docker, pero también un marco de seguridad integrado, complementos
certificados, compatibilidad con Docker Swarm (que es una solución de orquestación de
contenedores, como Kubernetes) y compatibilidad con RBAC/AD/LDAP. No obstante,
todo esto tiene un precio. Si cree que su entorno necesita estas ventajas añadidas, vale
la pena pagarlo. Por otro lado, Docker CE es un software de código abierto que está
disponible de forma gratuita.
Instalación de Docker
Existen varias formas de instalar y usar Docker CE en Azure. Puede instalar la distribución
de Linux que prefiera e instalar Docker sobre ella. Hay varias VM disponibles en Azure
Marketplace, como RancherOS, que es una distribución de Linux muy mínima que se
creó especialmente para ejecutar Docker. Por último, pero no menos importante, está la
plantilla Docker para Azure, que Docker proporciona a https://docs.docker.com/docker-
for-azure.
Para alcanzar el objetivo de este capítulo, la VM de Docker en Ubuntu Server no es mala
idea; permite ahorrar mucho trabajo. Pero existen varios motivos por los cuales no usar
esta VM:
• Realmente puede ayudarle a entender mejor las cosas si usted configura todo.
• El software usado es relativamente antiguo.
• La extensión de Docker VM que se usa para crear la VM está obsoleta y ya no está
en desarrollo activo.
La plantilla Docker para Azure también instala y configura Docker Swarm, un sistema de
agrupación en clúster nativo de Docker.
El sitio web de Docker proporciona una excelente documentación sobre cómo instalar
Docker manualmente. Si desea realizar la instalación mediante apt o yum sin seguir el
script, puede seguir la documentación oficial de Docker (https://docs.docker.com/v17.09/
engine/installation/#supported-platforms). Si la sigue, puede omitir el script cloud-init.
Aquí seguiremos la instalación con nuestro script. Tenga en cuenta que este script es
adecuado para entornos de laboratorio, pero no para entornos de producción.
Instala la versión más reciente de Docker desde el canal perimetral, no desde el canal
estable. En teoría, esto podría ser un poco inestable.
Sin embargo, para los fines de este capítulo, es una buena manera de comenzar. Para
poner las cosas en marcha rápido, usemos la técnica de cloud-init que aprendimos en
el Capítulo 7, Implementación de sus máquinas virtuales.
Empiece por crear un nuevo grupo de recursos, por ejemplo, Docker_LOA:

az group create --name Docker_LOA --location westus
Cree un archivo de configuración cloud-init; en mi ejemplo, el archivo se denomina

docker.yml con el siguiente contenido:
#cloud-config
package_upgrade: true
write_files:
- content: |
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
path: /etc/systemd/system/docker.service.d/docker.conf
- content: |
{
"hosts": ["fd://","tcp://127.0.0.1:2375"]
}
path: /etc/docker/daemon.json
runcmd:
- curl -sSL https://get.docker.com/ | sh
- usermod -aG docker <ssh user>
No olvide reemplazar <ssh user> con el nombre de inicio de sesión de la cuenta que
está usando para ejecutar el comando az.
Es posible que haya notado que agregamos ExecStart dos veces en el script. ExecStart
le permite especificar qué comando debe ejecutarse cuando se inicia una unidad. Se
recomienda borrarla con ExecStart= y, a continuación, especificar el comando real en
la segunda línea. La razón es que cuando se instala Docker, tiene inicialmente un valor
ExecStart y cuando suministramos otro valor, se genera un conflicto. Este conflicto
detendrá el inicio del servicio. Sigamos y creemos una VM con Docker instalado con
el archivo cloud-init que creamos:
1. Cree una VM con la distribución que prefiera:
az vm create --name UbuntuDocker --resource-group Docker_LOA \
--image UbuntuLTS --generate-ssh-keys --admin-username <ssh-user> \
--custom-data docker.yml
Docker | 339
2. Cuando la VM esté lista, inicie sesión y ejecute lo siguiente:

sudo systemctl status docker.service
Nota
Si recibe un mensaje que dice “Warning: docker.service changed on disk, run
systemctl daemon-reload to reload docker.service”, sea paciente pues cloud-init
aún está ocupado. Además, si observa que no se encuentra docker.service, espere
un momento para que cloud-init finalice la instalación. Siempre puede comprobar
si Docker CE está instalado mediante la ejecución de dpkg -l | grep docker.
3. Ejecute lo siguiente para recibir aún más información sobre el demonio de Docker:
docker info
4. Es momento de descargar nuestro primer contenedor y ejecutarlo:
docker run hello-world
En la siguiente captura de pantalla, puede ver que el contenedor se ejecutó
correctamente y recibió el mensaje Hello from Docker!:
Figura 9.3: Ejecución correcta de contenedor

Un contenedor de Docker es una imagen ejecutada. Para enumerar las imágenes

disponibles en su sistema, ejecute lo siguiente:
docker image ls
En el ejemplo anterior, ejecutamos docker run hello-world. Por lo tanto, ya se extrajo la

imagen, y puede ver que la imagen de hello-world aparece cuando usamos el comando
docker image ls:
Figura 9.4: Enumeración de la imagen de Docker
Si ejecuta de nuevo docker run hello-world, esta vez la imagen no se descargará. En su

lugar, buscará la imagen que ya se almacenó o descargó durante la ejecución anterior.
Vamos a descargar otra imagen:
docker run ubuntu
Después de eso, enumeraremos todos los contenedores, incluso aquellos que no se

están ejecutando:
docker ps -a
Todos los contenedores tienen el estado exited. Si desea mantener el contenedor en

ejecución, debe agregar los parámetros -dt al comando de ejecución; -d significa que
se ejecutan en modo independiente:
docker run -dt ubuntu bash
Si desea un shell interactivo para el contenedor de Ubuntu (como aplicar SSH a una
VM), puede agregar el parámetro -i:
docker run -it ubuntu
Vea nuevamente la lista de procesos para comprobar que se esté ejecutando:

docker ps
Con el ID o el nombre del contenedor, puede ejecutar un comando en un contenedor

y recibir la salida estándar en su terminal:
docker exec <id/name> <command>
Por ejemplo, puede ejecutar el siguiente comando para ver la versión del sistema
operativo de la imagen del contenedor:
docker exec <id/name> cat /etc/os-release
Docker | 341
Adjúntelo al contenedor para comprobar si el contenido es el esperado:

docker attach <id/name>
Y sepárelo mediante Ctrl + P y Ctrl + Q, lo que significa que saldrá del shell interactivo
y el contenedor comenzará a ejecutarse en segundo plano.
Para concluir, si ha seguido las indicaciones, ya podrá ejecutar contenedores,
ejecutarlos en modo independiente, ejecutar comandos en el contenedor desde la
máquina host y también obtener un shell interactivo en el contenedor. Hasta ahora,
hemos usado imágenes que ya están disponibles en Docker Hub. En la siguiente sección,
aprenderemos a crear nuestras propias imágenes de Docker con configuraciones
personalizadas a partir de una imagen base.
Creación de imágenes de Docker

Una imagen de Docker contiene capas. Para cada comando que ejecuta para agregar un
componente al contenedor, se agrega una capa. Cada contenedor es una imagen con
capas de solo lectura y una capa de escritura sobre ellas. La primera capa es el sistema
de archivos de arranque y la segunda se llama base; contiene el sistema operativo.
Puede extraer imágenes del Registro de Docker (encontrará más información sobre
el registro más adelante) o compilarlas usted mismo.
Si desea compilar una imagen usted, puede hacerlo de manera similar a lo que vimos
anteriormente, con los contenedores systemd-nspawn, por ejemplo, mediante el uso
de debootstrap. La mayoría de los comandos requieren acceso de usuario raíz, por lo
que debe escalar sus privilegios de la siguiente manera:
sudo -i
Tomemos Debian como la imagen base aquí. Esto le ayudará a entender el comando
docker import. Descargue y extraiga Debian Stretch:
debootstrap --arch amd64 stretch stretch \
http://ftp.us.debian.org/debian
Cree un archivo comprimido e impórtelo directamente en Docker:
tar -C stretch -c . | docker import - stretch
Verifíquelo con el siguiente comando:

docker images
Docker también ofrece una imagen base muy mínima llamada scratch.
Una imagen de Docker se crea a partir de un Dockerfile. Vamos a crear un directorio de
trabajo para guardar el Dockerfile:
mkdir ~/my-image && cd ~/my-image
Como la imagen stretch ya está disponible en Docker Hub, es una buena idea etiquetar
la imagen con un nuevo nombre para que Docker no intente extraer la imagen, sino ir
a la imagen local. Para etiquetar la imagen, use el siguiente comando:
docker tag stretch:latest apache_custom:v1
Luego, cree un Dockerfile mediante la ejecución de vi Dockerfile (puede usar cualquier

editor de texto). La primera línea en el archivo agrega la imagen base como una capa:
FROM apache_custom:v1
La segunda capa contiene las actualizaciones de Debian:

RUN apt-get --yes update
La tercera capa contiene la instalación de Apache:

RUN apt-get --yes install apache2
Agregue la capa más reciente y ejecute Apache en esta capa de lectura/escritura. CMD
se usa para especificar los valores predeterminados para la ejecución del contenedor:
CMD /usr/sbin/apachectl -e info -DFOREGROUND
Puerto abierto 80:

EXPOSE 80
Guarde el archivo. Sus entradas del archivo se verán como la siguiente captura de
pantalla. Agregar comentarios es un procedimiento recomendado, pero opcional:
Figura 9.5: Creación de una imagen de Docker

Docker | 343
Compile el contenedor:
docker build -t apache_image .
Si todo salió bien, la salida debería mostrar algo similar a lo siguiente:
Figura 9.6: Imagen de Docker compilada correctamente
Puede probar el contenedor:

docker run -d apache_image
Revise el historial de la compilación:

docker history <ID/name>
Como se muestra en la siguiente captura de pantalla, podrá ver el historial de la

compilación de su contenedor:
Figura 9.7: Revisión del historial del contenedor compilado
Ejecute docker ps para obtener el ID del contenedor y úselo para recopilar información
sobre el contenedor:
docker inspect <ID/name> | grep IPAddress
En la salida, puede hallar la dirección IP del contenedor:
Figura 9.8: Recuperación de la dirección IP desde el contenedor de Docker
Use curl para ver si el servidor web realmente se está ejecutando:

curl <ip address>
Podrá ver la famosa página “It works” en HTML, como se muestra aquí:
Figura 9.9: Uso del comando curl para probar el servidor web
Ahora detendremos el contenedor usando el siguiente comando:

docker stop <ID>
Ahora ejecútelo de nuevo:

docker run -d <ID> -p 8080:80
Esto hace que el sitio web esté disponible en el puerto localhost 8080.
También puede usar acbuild para crear contenedores de Docker.
Docker Machine
Existe otra manera de crear contenedores de Docker: Docker Machine. Es una
herramienta que crea VM que hospedarán Docker. Es algo que debe ejecutar en una
máquina de desarrollo, física o no, y debe ejecutar todo de forma remota.
Tenga en cuenta que Docker Machine se puede instalar en máquinas macOS, Linux
y Windows. Consulte la documentación de Docker Machine (https://docs.docker.com/
machine/install-machine/) para la instalación en macOS y Windows, ya que solo estamos
siguiendo la instalación en Linux.
Vuelva a la máquina Ubuntu donde instalamos Docker. Instale la siguiente dependencia:
sudo apt install sshfs
Docker | 345
A continuación, debe descargar Docker Machine y extraerla en su PATH:

base=https://github.com/docker/machine/releases/download/v0.16.0 \
&& curl -L $base/docker-machine-$(uname -s)-$(uname -m) \
>/tmp/docker-machine && \
sudo mv /tmp/docker-machine /usr/local/bin/docker-machine \
&& chmod +x /usr/local/bin/docker-machine
La finalización automática puede ser muy útil. También asegúrese de que ejecute el
siguiente script como raíz, ya que el script escribirá en el directorio /etc/:
base=https://raw.githubusercontent.com/docker/machine/v0.16.0
for i in docker-machine-prompt.bash docker-machine-wrapper.bash \
docker-machine.bash
do
sudo wget "$base/contrib/completion/bash/${i}" -P \ /etc/bash_completion.d
source /etc/bash_completion.d/$i
done
Cierre la sesión y vuelva a iniciarla. Para comprobar que bash-completion funciona,

puede pulsar el botón de la pestaña para ver los comandos disponibles para
docker-machine, como se muestra en la siguiente captura de pantalla:
Figura 9.10: Comprobación de que bash-completion se realizó correctamente
Compruebe la versión:
docker-machine version
Con Azure como controlador, ahora puede implementar una VM:

docker-machine create -d azure \
--azure-subscription-id <subscription id> \
--azure-ssh-user <username> \
--azure-open-port 80 \
--azure-size <size> <vm name>
Hay otras opciones, como la IP pública y el nombre del grupo de recursos, que se
pueden traspasar durante la implementación. Puede ver la lista completa y los valores
predeterminados para estas opciones en la documentación de Docker (https://docs.
docker.com/machine/drivers/azure/). Si no especificamos un valor para una opción
específica, Docker tomará el valor predeterminado. Otra cosa que debe tener en cuenta
es que el nombre de la VM solo debe incluir caracteres alfanuméricos en minúsculas
o guiones, si es necesario. De lo contrario, recibirá un error.
En la siguiente captura de pantalla, puede ver que la implementación de una VM llamada
docker-machine-2 del tamaño Standard_A2 se realizó correctamente y que Docker se
ejecuta en la máquina. Para simplificar, hemos guardado nuestro ID de suscripción en
una variable, $SUB_ID, para que no tengamos que revisarlo todas las veces. Puede hacer
lo mismo si es necesario. Dado que ya hemos autenticado antes, el controlador no
nos pide iniciar sesión de nuevo. El controlador recuerda sus credenciales por hasta
dos semanas, lo que significa que no tiene que iniciar sesión cada vez que realiza una
implementación. También puede ver qué recursos se implementaron:
Figura 9.11: Implementación de la VM docker-machine-2
Para indicarle a Docker que use el entorno remoto en lugar de ejecutar contenedores
localmente, ejecute lo siguiente:
docker-machine env <vm name>
eval $(docker-machine env <vm name>)
Para comprobar que se está usando el entorno remoto, use el comando info:
docker info
Docker | 347
Entre otra información, la salida muestra que está usando una VM específica que se
ejecuta en Azure:
Figura 9.12: Recuperación de la información de Docker
Y para Docker Machine, ejecute el siguiente comando:

docker-machine ls
Figura 9.13: Enumeración de docker-machine
Vamos a crear un contenedor nginx con el puerto 80 de host asignado al puerto 80 del
contenedor. Esto significa que todo el tráfico que llega al puerto 80 de la VM host se
dirigirá al puerto 80 del contenedor. Esto se debe al parámetro –p. Ejecute el siguiente
comando para crear un contenedor nginx:
docker run -d -p 80:80 --restart=always nginx
Encuentre la dirección IP de la VM:

docker-machine ip <vm name>
Use esa dirección IP en un explorador para comprobar que nginx se esté ejecutando.
Docker Machine también nos permite copiar archivos en la VM con el parámetro scp,
o incluso montar los archivos localmente:
mkdir -m 777 /mnt/test
docker-machine mount <vm name>:/home/<username> /mnt/test
Use docker ps para buscar las instancias en ejecución, detenerlas y eliminarlas, para que
estén listas para la siguiente utilidad.
Docker Compose
Docker Compose es una herramienta para crear una aplicación de varios contenedores,
por ejemplo, una aplicación web que necesita un servidor web y una base de datos.
Puede comprobar la versión más reciente o estable de Docker Compose en
https://github.com/docker/compose/releases e instalarlo, reemplazando el
número de versión en el comando con la última versión:
sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/
docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
Ahora, aplique el permiso ejecutable en el binario que descargamos:

sudo chmod +x /usr/local/bin/docker-compose
Luego, compruebe la instalación:

docker-compose version
Si la instalación se realizó correctamente, podrá ver la versión de Docker

Compose instalada:
Figura 9.14: Comprobación de la instalación de Docker Compose
Nota
Después de la instalación, si se produce un error en el comando anterior,
compruebe la ruta o cree un vínculo simbólico a /usr/bin o a cualquier otro
directorio de la ruta. Para saber qué directorios están en su PATH, ejecute $PATH
en el shell. Para crear un vínculo simbólico, ejecute sudo ln -s /usr/local/bin/
docker-compose /usr/bin/docker-compose.
Docker | 349
Cree un archivo llamado docker-compose.yml con el siguiente contenido:

wordpress:
image: wordpress
links:
- db:mysql
ports:
- 80:80
db:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: <password>
Reemplace <password> con la contraseña de su elección. Mientras sigue conectado
al entorno de Azure, con Docker Machine, ejecute lo siguiente:
docker-compose up -d
Si la compilación se realiza correctamente, se ejecutan dos contenedores, que

puede comprobar al usar docker ps y abrir un navegador con la dirección IP correcta
(docker-machine ip <vm name>). El instalador de WordPress lo espera.
Registro de Docker
Cada vez que ejecutamos docker run o docker pull (solo descarga), las imágenes se
obtienen de Internet. ¿De dónde provienen? Ejecute este comando:
docker info | grep Registry
La salida del comando anterior le otorga la respuesta: https://index.docker.io/. Esta

dirección URL es el Docker Hub oficial. Docker Hub, o Docker Store, también tiene una
buena interfaz web disponible mediante https://hub.docker.com, y es un repositorio en
línea de imágenes de Docker privadas y disponibles públicamente.
El comando docker search puede usarse para buscar este repositorio. Para limitar la
salida de este comando, puede agregar filtros:
docker search --filter "is-official=true" nginx --no-trunc
Aquí está la salida del comando docker search:
Figura 9.15: Salida del comando docker search
Opcionalmente, agregue el parámetro --no-trunc para ver la descripción completa de

la imagen. En la salida, también hay una calificación por estrellas que nos puede ayudar
a seleccionar la mejor imagen disponible.
Si crea su propia cuenta en el sitio web de Docker Hub, puede usar docker push para
cargar sus imágenes en el registro. Es gratis.
Inicie sesión con los siguientes datos:
docker login -u <username> -p <password>
Compile la imagen:
docker build -t <accountname>/<image>:versiontag .
También puede etiquetar la imagen después:

docker tag <tag id> <accountname>/<image>:versiontag
Para el control de versiones, es una buena idea usar una cadena como v1.11.1.2019,
que significa que la primera versión se publicó el 1 de noviembre de 2019. Si no agrega la
versión, se etiqueta como la versión más reciente.
Docker | 351
No puede ver las etiquetas con el comando docker search. Necesitará la interfaz web
o consultar la API de Docker con curl (una herramienta para transferir datos desde
y hacia un servidor) y jq (una herramienta similar a sed, pero específicamente para
los datos JSON):
wget -q https://registry.hub.docker.com/v1/repositories/<image>/tags -O - |
jq
Nota
jq no está instalada de forma predeterminada. Tiene que instalarla con apt
install jq.
Esta salida estará en formato JSON. Puede realizar consultas adicionales con jq y definir
mejor la salida si es necesario. Si no desea usar jq para formatear JSON, puede usar los
comandos nativos sed, try cut para asignar formato a la salida y obtener algo más limpio:
wget -q https://registry.hub.docker.com/v1/repositories/<image name>/tags -O
- | sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' | tr '}' '\n' | cut -d ":"
-f3
Si desea obtener todas las etiquetas de nginx, puede reemplazar <image name> con nginx.
Hemos analizado Docker Hub y cómo comprobar las imágenes disponibles. Del mismo
modo, Azure ofrece Azure Container Registry, donde puede almacenar sus imágenes
privadas y extraerlas cuando lo necesite. Antes de empezar a usar Azure Container
Registry, necesitamos entender Azure Container Instances, con el que puede ejecutar
contenedores sin la molestia de administrar las máquinas host. Sigamos y aprendamos más.
Azure Container Instances

Ahora que podemos ejecutar un contenedor en una VM, podemos ir un paso
más allá: podemos usar el servicio Azure Container Instances para ejecutarlo
sin administrar servidores.
Puede hacerlo en Azure Portal. En la barra de navegación de la izquierda, seleccione
Todos los servicios y busque Instancias de contenedor. Una vez que esté en Instancias
de contenedor, haga clic en Agregar para crear una nueva instancia de contenedor
y el portal lo redirigirá a la siguiente ventana:
Figura 9.16: Creación de una instancia de contenedor Docker

Azure Container Instances | 353
Puede crear un grupo de recursos o usar uno existente. Establezca el nombre del
contenedor en nginx y establezca el Tipo de imagen en Public porque vamos a extraer
una imagen pública. Establezca el nombre de la imagen en nginx:latest, establezca
el Tipo de SO en Linux y elija el requisito de recursos deseado para el contenedor.
Presione Siguiente y en la sección Redes, expondremos el puerto 80 para el tráfico
HTTP, como se muestra en la siguiente captura de pantalla. Además, puede agregar
una etiqueta DNS y optar por una dirección IP pública si es necesario:
Figura 9.17: Adición de detalles de red a la instancia de contenedor
Esto es suficiente para la validación y creación de la instancia. Puede omitir las

siguientes secciones e ir a Revisar y crear. Sin embargo, Azure ofrece opciones
avanzadas en la pestaña Opciones avanzadas. Se pueden usar para agregar variables del
entorno, establecer la opción de directiva de reinicio y usar la invalidación de comandos
para incluir un conjunto de comandos que deben ejecutarse cuando se inicializa el
contenedor. Si lo desea, también puede configurarse.
También puede crear contenedores con la línea de comandos mediante la CLI de Azure:
az container create --resource-group <resource group> --name nginx --image
nginx:latest --dns-name-label nginx-loa --ports 80
También puede usar PowerShell:
New-AzContainerGroup -ResourceGroupName <resource group> '
-Name nginx -Image nginx:latest r -OsType Linux '
-DnsNameLabel nginx-loa2
Tenga en cuenta que la etiqueta DNS debe ser única en su región.

En la salida de los comandos, la dirección IP de la instancia es visible:
Figura 9.18: Creación de contenedores mediante PowerShell

Azure Container Registry | 355
Debe poder acceder al servidor web en un FQDN y una dirección IP. Como se muestra
en la captura de pantalla, puede apuntar su navegador a la etiqueta DNS o a la dirección
IP, y puede ver la página Welcome to nginx!:
Figura 9.19: Salida del servidor web cuando el navegador apunta a la etiqueta DNS
Para obtener la lista de instancias de contenedores, ejecute lo siguiente:

az container list
Como alternativa, ejecute lo siguiente:

Get-AzContainerGroup | Format-List
Hasta ahora, hemos usado el Registro de Docker para guardar, extraer e insertar
imágenes. Azure ofrece un registro de imágenes privadas donde puede almacenar
sus imágenes para que puedan usarse cuando sea necesario. Este servicio se denomina
Azure Container Registry. Veamos de qué se trata.
Azure Container Registry

Como se mencionó, en lugar del Registro de Docker, puede usar Azure Container
Registry privado. Este servicio no es gratuito. El uso de este servicio de Azure tiene
la ventaja de que incluye todas las características de Almacenamiento de blobs
(confiabilidad, disponibilidad, replicación, etcétera) y puede mantener todo el tráfico
dentro de Azure, lo que hace que este registro sea una opción interesante en términos
de características, rendimiento y costo.
Uso de Azure Portal

La forma más sencilla de crear un registro es mediante el uso de Azure Portal. En la
barra de navegación de la izquierda, seleccione Todos los servicios y busque Registros
de contenedor. Haga clic en Agregar y debería obtener la siguiente pantalla. No olvide
habilitar la opción Usuario administrador; al hacerlo, puede iniciar sesión en el registro
de contenedores a través del inicio de sesión de Docker con el nombre de usuario
como el nombre de registro y la contraseña como la clave de acceso:
Figura 9.20: Creación de un registro de contenedores en Azure Portal

Si el registro está listo, habrá una ventana emergente que dice que el trabajo está
terminado y podrá ver el recurso. Si navega a la hoja Claves de acceso, encontrará el
servidor de inicio de sesión y su nombre de usuario, que es el mismo que el nombre
del registro y el conjunto de contraseñas:
Figura 9.21: Panel de la hoja Claves de acceso
Use esta información para iniciar sesión en el repositorio, de la misma manera que lo
hizo con Docker Hub.
Después de insertar una imagen, estará disponible en el repositorio. Desde allí, puede
implementarla en el servicio de Azure Container Instances y ejecutarla.
Uso de la CLI de Azure

Hemos creado una instancia de Azure Container Registry a través de Azure Portal.
También es posible usar la CLI de Azure y PowerShell para realizar la misma tarea.
Vamos a seguir los pasos de la CLI de Azure y lo invitamos a probar este proceso con
PowerShell por su cuenta.
Para empezar, necesitamos una VM de Linux en la que se instalen Docker y la CLI
de Azure.
Comencemos por crear un grupo de recursos, o puede usar el mismo grupo de recursos
que se usó en el ejemplo del portal. Solo para recordar el comando que estudiamos
al principio, en la sección Instalación de Docker, procederemos con un nuevo grupo
de recursos:
az group create --name az-acr-cli --location eastus
Una vez que reciba el mensaje de éxito, siga con la creación del registro de
contenedores mediante lo siguiente:
az acr create --resource-group az-acr-cli --name azacrcliregistry --sku
Basic --admin-enabled true
Aquí estamos creando el registro de contenedores con la SKU básica. Hay otras
SKU disponibles que ofrecen más opciones de almacenamiento y rendimiento. Las
SKU apuntan a diferentes niveles de precios del registro de contenedores. Visite la
página de precios de Microsoft Azure (https://azure.microsoft.com/es-xl/pricing/
details/container-registry/) para ver el precio de cada SKU. Dado que se trata de una
demostración y para mantener el costo al mínimo, usaremos la opción básica.
Después de implementar la instancia de Azure Container Registry, iniciaremos sesión
en el registro. Pero para iniciar sesión, necesitamos la contraseña. Ya sabemos el
nombre de usuario, que es el del registro, así que vamos a ver la contraseña del registro:
az acr credential show --name azacrcliregistry --resource-group az-acr-cli
La salida mostrará el nombre de usuario y la contraseña. Tome nota. Puede usar

la contraseña 1 o la contraseña 2. Ahora que estamos seguros de las credenciales,
iniciaremos sesión en la instancia de Azure Container Registry al ejecutar lo siguiente:
az acr login --name azacrcliregistry --username azacrcliregistry --password
<password>
Si se inicia sesión correctamente, debería ver la salida que se muestra en la siguiente

captura de pantalla:
Figura 9.22: Inicio de sesión de Azure Container Registry correcto
Sigamos e insertemos una imagen en el registro. Para insertar una imagen, primero
necesitamos tener una imagen. Si usa la misma VM que se usó en los ejemplos
anteriores, es posible que tenga algunas imágenes. Si las imágenes no están allí, puede
usar docker pull <image name> para obtener la imagen. Puede comprobar la lista de
imágenes disponibles con el comando docker images. Dado que ya tenemos una imagen
nginx, no la extraeremos de Docker Hub.
Ahora que tenemos la imagen, vamos a etiquetarla. El etiquetado le ayudará a saber

qué imagen está usando. Por ejemplo, si tiene una imagen etiquetada como v1 y realiza
algunos cambios en ella, puede etiquetarla como v2. El etiquetado le ayuda a tener
una organización lógica de sus imágenes en función de la fecha de lanzamiento, el
número de versión o cualquier otro identificador. Necesitamos etiquetar con el formato
<AcrLoginName>/<image name>:<version tag> donde acr-name es el FQDN de la instancia
de Azure Container Registry. Para obtener el FQDN de la instancia de Azure Container
Registry, ejecute lo siguiente:
az acr show -n azacrcliregistry -g az-acr-cli | grep loginServer
Para la imagen nginx, vamos a etiquetarla como nginx:v1:

docker tag nginx azacrcliregistry.azurecr.io/ngnix:v1
Insertemos la imagen etiquetada en Azure Container Registry con el comando docker push:
docker push azacrcliregistry.azurecr.io/ngnix:v1
Deben insertarse todas las capas, como se muestra en la captura de pantalla:
Figura 9.23: Inserción de la imagen etiquetada en el registro de contenedores
Supongamos que ha insertado varias imágenes en Azure Container Registry y desea

obtener una lista de todas las imágenes. A continuación, puede usar el comando az acr
repository list. Para enumerar todas las imágenes de la instancia de Azure Container
Registry que creamos, use este comando:
az acr repository list --name azacrcliregistry -o table
Puede usar el comando docker run para ejecutar el contenedor. Pero siempre asegúrese
de que el nombre de la imagen esté en el formato <AcrLoginName>/<image>. La era de
Docker terminará y, finalmente, se reemplazará con herramientas de última generación
sin demonios.
La siguiente sección se trata de estas herramientas y cómo puede crear una analogía
con Docker para una transición sin problemas.
Buildah, Podman y Skopeo

En la sección anterior, analizamos cómo funciona Docker y cómo se puede usar para
implementar contenedores. Como se indicó anteriormente, Docker usa el demonio
de Docker, que nos ayuda a lograr todo esto. ¿Qué pasa si decimos que las personas
han comenzado a despedirse de Docker? Sí, con la introducción de herramientas de
administración de contenedores de última generación, Docker está desapareciendo.
No estamos diciendo que Docker desapareció completamente del mapa, pero con el
tiempo lo reemplazarán herramientas de contenedor de Linux sin raíz ni demonios.
Leyó bien: no hay ningún demonio en ejecución con estas herramientas, y el enfoque de
usar el demonio del monolito está llegando a su fin. No es de extrañar que las personas
hayan comenzado a llamar a los contenedores implementados con estas herramientas
“contenedores sin Docker”.
Historia
Puede que se pregunte cuándo sucedió todo esto. En 2015, Docker Inc. y CoreOS,
junto con algunas otras organizaciones, tuvieron la idea de crear Open Container
Initiative (OCI). La intención detrás de esto era estandarizar el tiempo de ejecución
del contenedor y las especificaciones de formato de imagen. El formato de imagen
OCI es compatible con la mayoría de los registros de imágenes de contenedores, como
Docker Hub y Azure Container Registry. La mayoría de los tiempos de ejecución de
contenedores que están disponibles ahora son compatibles con OCI o tienen OCI en la
canalización. Esto fue solo el comienzo.
Antes Docker era el único tiempo de ejecución de contenedores disponible para
Kubernetes. Obviamente, otros proveedores querían tener soporte para sus tiempos
de ejecución específicos en Kubernetes. Debido a este dilema y la falta de soporte
para otros proveedores, Kubernetes creó CRI en 2017. CRI significa Container Runtime
Interface. Se pueden usar otros tiempos de ejecución, como CRI-O, containerd o frakti.
Como Kubernetes estaba en auge y debido a su compatibilidad con varios tiempos de
ejecución, el monopolio de Docker comenzó a desmoronarse. En muy poco tiempo,
el estado de monopolio de Docker cambió y se convirtió en uno de los tiempos de
ejecución admitidos en Kubernetes. Las ondas que generó este cambio en realidad
dieron origen a la idea de herramientas sin demonios y a la idea de derribar el enfoque
de usar el demonio del monolito, que requiere acceso de superusuario.
En lugar de usar términos genéricos, intentemos entender los términos populares.
Buildah se usa para la creación de contenedores, Podman se usa para la ejecución
de contenedores y Skopeo le permite realizar varias operaciones en imágenes
y repositorios donde se almacenan las imágenes. Observaremos detalladamente cada
una de estas herramientas. Algunas personas sugieren eliminar Docker antes de usar
estas herramientas, pero recomendamos mantener Docker para que pueda compararlo
constantemente con estas herramientas. Si ha seguido las secciones anteriores sobre
Docker, podrá crear una analogía.
Buildah, Podman y Skopeo | 361
Instalación
Instalar estas herramientas es muy sencillo. Puede usar apt en Ubuntu o yum en RHEL
para instalarlas. Dado que estamos usando la misma VM, vamos a seguir la instalación
de Ubuntu de estos paquetes. Para instalar Buildah, ejecute lo siguiente:
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:projectatomic/ppa
sudo apt update
sudo apt install -y buildah
Dado que ya tenemos el repositorio de PPA agregado durante la instalación de Buildah,
podemos implementar Podman inmediatamente con apt install. Para instalar Podman,
ejecute lo siguiente:
sudo apt -y install podman
Para poder instalar Skopeo, necesitamos que se instale snap en la VM de Ubuntu.

Si está en Ubuntu 16.04 LTS o posterior, snap se instalará de forma predeterminada.
De lo contrario, debe instalarlo manualmente con apt install snapd.
Vamos a instalar Skopeo mediante snap:
sudo snap install skopeo --edge
Nota
Si recibe un mensaje de error que indica revision is not meant production,
puede usar el parámetro –devmode para instalarlo. Así evitará este error
y completará la instalación.
Ahora estamos listos para explorar estas herramientas.

Buildah
En la sección anterior, analizamos Dockerfiles. Aquí está lo interesante: Buildah tiene
soporte completo para Dockerfiles. Todo lo que tiene que hacer es escribir el Dockerfile
y usar el comando bud, que significa “build-using-docker” (crear con docker). Tomemos
el mismo ejemplo que usamos en la sección de Dockerfile. Cree un Dockerfile mediante
la ejecución de vi Dockerfile (puede usar cualquier editor de texto) y agregue las
siguientes líneas:
FROM nginx
RUN apt-get --yes update
RUN apt-get --yes install apache2
CMD /usr/sbin/apachectl -e info -DFOREGROUND
EXPOSE 80
Guarde el archivo.
Antes de compilar, hay algo más que debemos realizar. Buildah busca la lista de
registros en el archivo /etc/containers/registries.conf. Si este archivo no existe,
necesitamos crear uno, agregar el siguiente código y guardar el archivo:
[registries.search]
registries = ['docker.io']
Al hacerlo, estamos dando la instrucción de buscar la imagen en Docker Hub. También
puede agregar su instancia de Azure Container Registry a la lista si es necesario.
Compilemos la imagen. Asegúrese de estar en el directorio donde está el Dockerfile.
Comience el proceso de compilación mediante:
buildah bud -t ngnix-buildah .
Hemos creado una imagen llamada nginx-buildah. Para ver la lista de imágenes, puede
usar el comando buildah images. Sí, sabemos que se ve muy similar a la forma en que se
enumeran las imágenes en Docker. Tenemos que tener en cuenta esta analogía que le
ayudará a aprender.
La salida será similar a esto:
Figura 9.24: Enumeración de las imágenes con el comando buildah

Puede ver que Buildah enumera la imagen que extrajo de Docker Hub y también la
imagen que creamos que se almacena en el repositorio de localhost.
Para crear un contenedor a partir de una imagen, podemos usar lo siguiente:
buildah from <image>
Esto creará un contenedor llamado <image>-working-container. Si desea compilar

un contenedor nginx, ejecute esto:
buildah from nginx
Obtendrá una salida similar a esta:
Figura 9.25: Compilación de un contenedor nginx
Al igual que cuando usa docker ps para enumerar todos los contenedores, ejecutaremos
buildah ps y podremos ver el nginx-working-container que acabamos de crear:
Figura 9.26: Enumeración de los contenedores con el comando buildah ps
Además, podemos ejecutar comandos directamente en el contenedor mediante el

comando buildah run. La sintaxis es la siguiente:
buildah run <container name> <command>
Vamos a intentar imprimir el contenido del archivo /etc/os-release del contenedor

nginx que creamos. Este será el comando:
buildah run nginx-working-container cat /etc/os-release
La salida será similar a esto:
Figura 9.27: Impresión del contenido del contenedor nginx
Al igual que Docker, Buildah tiene soporte para comandos, como push, pull, tag e inspect.
Podman
Las imágenes que compilamos a través de Buildah siguen el cumplimiento de OCI y se
pueden usar con Podman. En Podman, la analogía continúa. Todo lo que tenemos que
hacer es reemplazar todos los comandos de Docker con los comandos de Podman. Uno
de los aspectos clave que tenemos que tener en cuenta es que en Podman, no podemos
hacer el enlace de puertos para un contenedor como usuario no raíz. Si su contenedor
necesita una asignación de puertos, entonces tiene que ejecutar Podman como raíz. Como
ya hablamos de Docker y está familiarizado con sus comandos, intentaremos ejecutar un
contenedor y comprobarlo. Vamos a crear un contenedor nginx con el puerto asignado
a 8080. Dado que necesitamos asignar un puerto, ejecutaremos el comando como sudo:
sudo podman run -d -p 8080:80 --name webserver nginx
Dado que hemos creado el contenedor mediante el comando sudo, será propiedad del
usuario raíz. Si se crea un contenedor con sudo, asegúrese de encadenar sudo para
todas las acciones relacionadas con ese contenedor.
Para enumerar los contenedores, use podman ps. Podemos ver que el contenedor está
escuchando en 0.0.0.0:8080 del host, que se asigna al puerto del contenedor:
Figura 9.28: Enumeración de los contenedores con el comando podman ps command
Hagamos una llamada a curl y confirmemos si el servidor web se está ejecutando en el

puerto 8080 o no:
curl localhost:8080
Si todo está funcionando, verá la página de bienvenida de nginx:
Figura 9.29: Comprobación de la autenticación en el puerto del servidor web
Sí, el contenedor se está ejecutando sin demonios.

No estamos cubriendo todos los comandos de Podman aquí, y una vez que esté
familiarizado con Docker, todo lo que tiene que hacer es reemplazar docker con podman
en la línea de comandos.
Skopeo
Si recuerda, anteriormente intentamos obtener las etiquetas de una imagen mediante
Docker. Con Skopeo, puede inspeccionar un repositorio, copiar imágenes y eliminar
imágenes. Para empezar, usaremos el comando skopeo inspect para obtener las
etiquetas de una imagen en Docker Hub sin extraerla:
skopeo inspect docker://nginx:latest
La ejecución de este comando activará algunas advertencias. Puede omitirlas. Si comprueba

la salida, puede ver que está proporcionando las etiquetas, las capas, el tipo de sistema
operativo y así sucesivamente.
Puede usar el comando skopeo copy para copiar imágenes de contenedor en varios
repositorios de almacenamiento. Además, puede usar Skopeo con Azure Container Registry.
No nos referiremos a todo esto. Sin embargo, puede visitar los repositorios de GitHub
de estas herramientas:
• Buildah: https://github.com/containers/buildah
• Podman: https://github.com/containers/libpod
• Skopeo: https://github.com/containers/skopeo
Contenedores y almacenamiento
Esta sección tiene como objetivo brindarle una idea básica de los contenedores y el
almacenamiento. Cada herramienta de compilación que puede crear imágenes ofrece
la opción de agregar datos a su contenedor.
Debe utilizar esta característica solo para proporcionar archivos de configuración.
Los datos de las aplicaciones deben estar hospedados, tanto como sea posible, fuera
del contenedor. Si desea actualizar/eliminar/reemplazar o escalar rápidamente su
contenedor, es casi imposible si los datos están dentro del contenedor.
Cuando creamos un contenedor, el almacenamiento se conecta al contenedor. Sin
embargo, los contenedores son efímeros, lo que significa que el almacenamiento
también se destruye cuando se destruye el contenedor. Supongamos que creó un
contenedor de Ubuntu para las pruebas y guardó algunos scripts que se probaron en
el contenedor con la esperanza de que los pudiese usar más adelante. Ahora, si eliminó
accidentalmente este contenedor, todos los scripts que probó y guardó para más
adelante habrán desaparecido.
Los datos de la aplicación son importantes y le recomendamos retenerlos incluso después
de que se completa el ciclo de vida del contenedor. Por lo tanto, queremos separar los
datos del ciclo de vida del contenedor. Al hacerlo, sus datos no se destruyen y se pueden
reutilizar si es necesario. En Docker, esto se logra mediante el uso de volúmenes.
Docker admite una amplia gama de opciones para volúmenes persistentes, incluidos
Archivos de Azure. En otras palabras, puede vincular el recurso compartido de su
archivo de Azure a un contenedor de Docker como un volumen persistente. Para
demostrarlo, usaremos el volumen del host, donde se montará una ubicación como
un volumen en el contenedor. El propósito de estos pasos es mostrar cómo se pueden
guardar los datos incluso después de que el contenedor se elimina del host.
La información de volumen se traspasa al comando docker run mediante el parámetro
-v al crear el contenedor. La sintaxis general es la siguiente:
docker run -v /some-directory/on host:/some-directory/in container
Supongamos que tiene una aplicación que creará un archivo en un directorio /var/log
en el contenedor y necesitamos lograr que sea persistente. En el siguiente comando,
asignamos un directorio en el host al directorio /var/log del contenedor.
Contenedores y almacenamiento | 367
Para completar este ejercicio, necesita una VM de Linux con Docker ejecutándose
en ella. Vamos a crear un directorio ~/myfiles en la máquina host que se asignará
al contenedor:
mkdir ~/myfiles
Vamos a crear un contenedor de Ubuntu con un shell interactivo, donde se traspasa

el parámetro -v para montar el volumen:
docker run -it -v ~/myfile:/var/log ubuntu
Si el contenedor se creó correctamente, se abrirá sesión como usuario raíz en el

contenedor:
Figura 9.30: Creación de un contenedor Ubuntu
Iremos al directorio /var/log del contenedor y crearemos 10 archivos vacíos con

este comando:
touch file{1..10}
Enumerar el contenido del directorio mostrará los 10 archivos que acabamos de crear:
Figura 9.31: Enumeración del contenido del directorio /var/log
Salga del shell interactivo con Ctrl + D, y ahora volveremos a la máquina host. Ahora
eliminaremos el contenedor:
docker rm <id/name of the container>
El parámetro id/name se puede obtener de la salida del comando docker ps --all.

Ahora que se eliminó el contenedor, iremos al directorio ~/myfiles de la máquina host
para comprobar el contenido.
En la siguiente captura de pantalla, puede ver que el contenedor se eliminó
correctamente; sin embargo, el directorio ~/myfiles todavía contiene los archivos que
creamos dentro del contenedor:
Figura 9.32: Enumeración de los archivos en el directorio ~/myfiles
Ahora sabemos cómo hacer que nuestro volumen sea persistente. En el caso de Docker,
hay soluciones, como https://github.com/ContainX/docker-volume-netshare.
Si está usando Docker y desea usar Archivos de Azure, puede usar Cloudstor, un
complemento disponible en https://docs.docker.com/docker-for-azure/persistent-
data-volumes.
El uso de Azure File Storage quizás no sea la solución más económica, pero de esta
manera obtendrá todas las opciones de disponibilidad y copia de seguridad que necesita.
Si va a usar Kubernetes, la historia cambia. En el próximo capítulo, trataremos ese tema.
Resumen | 369
Resumen
En este capítulo, se analizó otra forma de implementar la carga de trabajo en Azure.
Después de una introducción a la historia, las ideas y los conceptos de la virtualización de
contenedores, vimos algunas de las opciones disponibles. Junto con las implementaciones
más antiguas, como LXC, analizamos otras implementaciones eficaces y sólidas para
hospedar contenedores: systemd-nspawn y Docker.
No solo vimos cómo ejecutar imágenes existentes extraídas de los repositorios, sino
también cómo crear nuestra propia imagen. Tal vez la mejor noticia es que hay una
herramienta llamada Buildah que es capaz de crear una imagen usando el estándar
OCI de Open Container Initiative y se puede utilizar para Docker.
La mayor parte de este capítulo se trató de Docker. Esta es, por lejos, la solución de
contenedor más implementada en la actualidad. Y, hablando de implementaciones,
hay muchas formas de implementar Docker:
• Impleméntelo manualmente en una VM
• Implemente una VM lista para llevar desde Marketplace
• Docker Machine
• Azure Container Instances
También se analizó el trabajo con Docker Hub y Azure Container Registry.

Por último, analizamos las nuevas tecnologías de contenedores, como Buildah,
Podman y Skopeo.
Terminamos el capítulo con algunas palabras sobre los contenedores y el
almacenamiento. Es posible que se pregunte qué sucederá con el almacenamiento
conectado a un contenedor si el contenedor se destruye o cómo lograr que el
almacenamiento sea persistente. Aprenderá sobre la persistencia en el próximo
capítulo, Capítulo 10, Cómo trabajar con Azure Kubernetes Service. Además,
analizaremos la famosa herramienta de orquestación de contenedores Kubernetes.
Preguntas
1. ¿Cuáles son las razones para usar los contenedores?
2. ¿Cuándo los contenedores no son la solución que necesita?
3. Si necesita algo como un servidor privado virtual, ¿se recomienda una VM o hay
una solución de virtualización de contenedores disponible que puede ser una
buena idea?
4. ¿Por qué no debería ser difícil migrar de una solución, como Docker, a otra, por
ejemplo, Buildah?
5. ¿Para qué se usa una máquina de desarrollo?
6. ¿Por qué usar Buildah es una buena idea, incluso si está bajo un gran desarrollo?
7. ¿Por qué no debería almacenar los datos de la aplicación en un contenedor?
Lectura adicional
Llevar a cabo lecturas adicionales no es muy fácil en el área de la virtualización de
contenedores. Para systemd-nspawn, es relativamente fácil: las páginas principales
son fáciles de leer. Hagamos una sugerencia que sea relevante para systemd-nspawn
e incluso Docker: Red Hat proporciona un documento en su sitio web llamado Guía de
administración de recursos (https://access.redhat.com/documentation/es-xl/red_
hat_enterprise_linux/7/html/resource_management_guide/) con buena información
sobre cgroups.
Aquí se enumeran un par de referencias sobre Docker:
• Orchestrating Docker, de Shrikrishna Holla, donde puede entender cómo
administrar e implementar los servicios de Docker
• Mastering Docker Enterprise: A companion guide for agile container adoption, de
Mark Panthofer, donde puede explorar los servicios complementarios de Docker
EE y cómo se pueden usar
Cómo trabajar
10
con Azure
Kubernetes Service
En el capítulo anterior, exploramos el mundo de la virtualización de contenedores y, en
particular, de los contenedores Docker. Este capítulo se trata sobre la administración de
cargas de trabajo en contenedores con Azure Kubernetes Service (AKS).
Este capítulo es diferente de todos los demás capítulos de este libro. Hasta ahora, cada
capítulo se ha tratado sobre la infraestructura y cómo proporcionar una plataforma:
el administrador de sistema clásico que trabaja en la nube. Incluso el Capítulo 9,
Virtualización de contenedores en Azure, contenía preguntas como “¿Cómo instalamos
Docker?” y “¿Cómo hacemos funcionar el contenedor?”. Las preguntas que
responderemos en este capítulo son las siguientes:
• ¿Cómo implementamos y administramos nuestra carga de trabajo durante la fase
de desarrollo y después de ella?
• ¿Cómo podemos escalar o reducir verticalmente?
• ¿Cuáles son las opciones de disponibilidad?
372 | Cómo trabajar con Azure Kubernetes Service
Kubernetes brinda una respuesta importante a todas estas preguntas. Es una solución
que se utiliza para automatizar las tareas importantes, como la implementación,
la administración, el escalado, las redes y la administración de la disponibilidad de
aplicaciones basadas en contenedores.
Google diseñó originalmente Kubernetes y ahora lo mantiene la fundación Cloud Native
Computing Foundation (https://www.cncf.io). Microsoft es un gran socio de esta
fundación y es un importante colaborador con los proyectos de Kubernetes en términos
de dinero y código. En realidad, uno de los cofundadores de Kubernetes, Brendan
Burns, trabaja para Microsoft y lidera los equipos que se dedican a la orquestación de
contenedores dentro de Microsoft. Además, Microsoft ha iniciado varios proyectos
open source con herramientas adicionales para Kubernetes.
Debido a que Microsoft está muy involucrado en Kubernetes, puede implementar
una versión de Kubernetes en Azure completamente compatible con el nivel superior.
Esto también es importante para los desarrolladores, de modo que puedan usar
una instalación local de Kubernetes para desarrollar software y, una vez que esté
desarrollado, publicarlo en la nube de Azure.
AKS ofrece una solución de contenedores como servicio totalmente administrada para
Kubernetes. Esto significa que no necesita pensar en la configuración, la administración
y la actualización del software de Kubernetes. Es Azure el que administra el plano
de control.
AKS facilita la implementación y administración de Kubernetes en Azure: puede manejar
todo el proceso de mantenimiento, desde el aprovisionamiento hasta la actualización
y el escalado de las aplicaciones según sus necesidades.
Con AKS incluso se puede llevar a cabo el proceso de actualización del clúster de
Kubernetes sin ningún tiempo de inactividad.
Y por último, pero no menos importante, la supervisión está disponible para cada parte
de su clúster de Kubernetes.
• Explicar qué es Kubernetes y AKS.
• Usar AKS para implementar y administrar sus clústeres.
• Mantener el ciclo de vida completo de las aplicaciones en AKS.
Así es que empecemos y veamos cuáles son los requisitos técnicos antes de que
realmente comencemos a usar AKS.
Como se indica en la introducción de este capítulo, este es diferente de todos los demás
capítulos, lo que afecta los requisitos técnicos. Hasta ahora, los requisitos técnicos eran
sencillos: solo necesitaba un montón de máquinas virtuales.
Este capítulo necesita un entorno de DevOps en el que los desarrolladores y operadores
estén en el mismo equipo, trabajando en estrecha colaboración, y donde también haya
alguien que realice las tareas relacionadas con el desarrollo y las operaciones.
Es necesario tomar otra decisión: ¿dónde vamos a llevar a cabo el desarrollo? ¿En el
entorno local o en la nube de Azure? Ambas opciones son posibles y no debería haber
ninguna diferencia. En cuanto a los costos, puede que sea mejor hacerlo en una estación
de trabajo. En este capítulo, se supone que lo está haciendo en el entorno local. Por lo
tanto, necesitará una estación de trabajo (o máquina virtual). Necesitamos lo siguiente:
• La CLI de Azure.
• Herramientas de compilación y Docker.
• Kubernetes.
• Algunas herramientas esenciales para desarrolladores, como Git.
• Algunas otras herramientas, como Helm, se analizarán más adelante.
• Un entorno de desarrollo integrado (IDE) adecuado. Preferimos Microsoft
Visual Studio (VS) Code con las extensiones de Microsoft para Docker y Kubernetes
(solo si hay disponible una interfaz gráfica. De lo contrario, use el editor Nano).
• Opcionalmente, una herramienta de orquestación como Ansible. Consulte los
módulos azure_rm_aks y 8ks_raw de Ansible.
Uso de WSL y VS Code

Puede usar Subsistema de Windows para Linux (WSL) y VS Code junto con la
extensión WSL remota de VS Code para obtener un entorno de desarrollo de Linux
en el equipo de escritorio o portátil con Windows sin la sobrecarga que implica
tener una máquina virtual. Esto le permitirá acceder a sus archivos de Linux desde
PowerShell o CMD y a sus archivos de Windows desde Bash. VS Code es un editor de
código fuente que se puede ejecutar en varias plataformas y es compatible con muchos
lenguajes. Puede desarrollar, ejecutar y depurar aplicaciones basadas en Linux desde
su plataforma favorita de Windows con WSL y VS Code. Las características de WSL
se pueden habilitar mediante PowerShell y la instalación de Linux desde Microsoft
Store. VS Code está disponible para Windows y Linux y se puede descargar en
https://code.visualstudio.com/. Dado que las opciones de configuración de VS Code
se conservan en las plataformas Windows y Linux, puede cambiar fácilmente de
Windows a Linux y Linux a Windows.
Puede buscar el tutorial paso a paso de WSL en https://docs.microsoft.com/es-xl/
learn/modules/get-started-with-windows-subsystem-for-linux/ y una guía de
instalación detallada en https://docs.microsoft.com/es-xl/windows/wsl/install-win10.
Puede configurar shells predeterminados y elegir entre PowerShell y WSL al ejecutarse
en Windows y puede elegir Zsh o Bash en Linux.
Instalación de dependencias
Usaremos Ubuntu 18.04 LTS Desktop Edition, pero también puede usar un servidor
Ubuntu 18.04 LTS en una máquina virtual de Azure. Con todo el conocimiento que
adquirió en los otros capítulos, le resultará fácil trasladar lo que haremos a otras
distribuciones de Linux, macOS e incluso Windows:
1. En primer lugar, actualice Ubuntu:
sudo apt update &&sudo apt upgrade
2. Instale las herramientas para desarrolladores, incluidas algunas otras
dependencias y openssh:
sudo apt install build-essential git curl openssh-server \
ebtablesethtoolsocat
3. En primer lugar, vamos a instalar la CLI de Azure.

Puede instalar la CLI de Azure ejecutando un solo comando:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
También puede usar estas instrucciones para instalarla de manera manual.
Obtenga el paquete necesario:
sudo apt-get install ca-certificates curl apt-transport-https lsb-release
gnupg
Obtenga e instale la clave de firma:
curl -sL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor
|
sudo tee /etc/apt/trusted.gpg.d/microsoft.asc.gpg> /dev/null
sudo apt-add-repository \
https://packages.microsoft.com/repos/azure-cli
curl -L https://packages.microsoft.com/keys/microsoft.asc \
| sudo apt-key add -
sudo apt update
sudo apt install azure-cli

4. Para instalar PowerShell y VS Code, usamos “snaps”, que son paquetes de software
universal similares a aplicaciones portátiles para Windows:
sudo snap install --classic powershell
sudo snap install --classic vscode

También puede usar los siguientes comandos para instalar PowerShell Core:
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add
-
curl https://packages.microsoft.com/config/ubuntu/18.04/prod.list | sudo

tee /etc/apt/sources.list.d/microsoft.list
sudo apt update
sudo apt install -y powershell

5. Escriba pwsh para iniciar PowerShell Core:
admin123@kubes:~$ pwsh
Si PowerShell Core se inicia correctamente, verá la siguiente salida:
Figura 10.1: Inicio de PowerShell Core
6. Instale el cmdlet de Azure para Azure:

sudo pwsh -Command "Install-Module PowerShellGet -Force"
sudo pwsh -Command "Install-Module -Name AzureRM.Netcore \

-AllowClobber"
sudo chown -R $USER ~/.local/

7. Instale Docker:
curl -sSL https://get.docker.com/ | sudo sh
sudo usermod -aG docker $USER
Obtendrá los detalles de la versión de Docker como se indica a continuación:
Figura 10.2: Detalles de la versión de Docker
8. Detenga Docker por ahora:

Sudo systemctl stop docker.service
Instalación de kubectl
Kubectl es una interfaz de la línea de comandos que se puede utilizar para administrar
los clústeres de Kubernetes. Se puede utilizar para muchas operaciones. Por ejemplo,
use kubectl create para crear uno o más archivos y use kubectl delete para eliminar
recursos de un archivo. Vamos a usar la CLI de Azure para instalar kubectl y ejecutar
los siguientes comandos como raíz para conceder los permisos necesarios:
sudo -i
az login
az aks install-cli
En primer lugar, debe descargar la versión más reciente con el siguiente comando:
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.3/
bin/linux/amd64/kubectl
A continuación, hágalo ejecutable:

chmod +x ./kubectl
Ahora, muévalo a su PATH:

Sudo mv ./kubectl /usr/local/bin/kubectl
Para comprobar la instalación, pida la información de la versión:

kubectl version
Habilite el autocompletado, con lo que podría ahorrarse escribir mucho. Para Bash
y Zsh en kubectl, ejecute lo siguiente:
kubectl completion bash > ~/.kube/completion.bash.inc
printf"
# Kubectl shell completion
source '$HOME/.kube/completion.bash.inc'
">> $HOME/.bash_profile
source $HOME/.bash_profile
Para Zsh, ejecute lo siguiente:
sudo -i
kubectl completion zsh>"${fpath[1]}/_kubectl"
exit
source <(kubectl completion zsh)

Cómo empezar a usar AKS | 379
Hasta ahora, hemos instalado la versión más reciente del binario kubectl con un
comando curl en Linux y habilitado el autocompletado del shell para kubectl.
Ahora estamos listos para usar AKS.
Nota
Si usa kubectl y recibe mensajes de error similares a Error from server
(NotAcceptable): unknown (get nodes) [Error del servidor (NotAcceptable):
desconocido (obtener nodos)], cambie a una versión anterior del cliente con
https://dl.k8s.io/v1.10.6/kubernetes-client-linux-amd64.tar.gz.
Aunque esto está completamente fuera del alcance de este libro, personalmente nos
gusta usar el shell Zsh con una personalización genial, Spaceship. La notificación le
ofrece más información sobre dónde está y lo que hace mientras trabaja con AKS.
Así puede realizar la instalación rápida:
sudo apt install zshnpm fonts-powerline
zsh # and create a .zshrc file with option 0
npm install spaceship-prompt
chsh -s /bin/zsh
Cómo empezar a usar AKS

Azure AKS hace que implementar y administrar sus aplicaciones en contenedores sea
fácil. Puede definir, implementar y depurar rápidamente las aplicaciones de Kubernetes,
además de crear contenedores de manera automática en sus aplicaciones con Azure
AKS. Puede automatizar la supervisión, la actualización, la reparación y el escalado,
lo que disminuye el mantenimiento manual de la infraestructura. Con kubectl instalado,
es momento de configurar y explorar el entorno de Kubernetes en Azure:
1. Cree un clúster.
2. Obtenga información sobre el clúster.
3. Implemente una carga de trabajo sencilla.
Creación de un clúster con la CLI de Azure

En Kubernetes, vamos a trabajar con clústeres. Un clúster contiene un plano de control
o un plan maestro que controla todo y uno o varios nodos de trabajo. En Azure, no
tenemos que preocuparnos por el maestro, solo por los nodos.
Es buena idea crear un grupo de recursos para los propósitos de este capítulo:
az group create --location eastus--name MyKubernetes
Implementaremos el clúster en este grupo de recursos:

az aks create --resource-group MyKubernetes \
--name Cluster01 \
--node-count 1 --generate-ssh-keys
Este comando puede tardar hasta 10 minutos. Tan pronto como vuelva a recibir el
mensaje, compruébelo con lo siguiente:
az aks list
En la salida, encontrará gran cantidad de información, como el nombre de dominio

completo, el nombre del clúster, etc.:
Figura 10.3: Detalles del clúster implementado

Hay una interfaz web disponible llamada Panel de Kubernetes que puede utilizar para
acceder al clúster. Para que esté disponible, ejecute lo siguiente:
az aks browse --name Cluster01 --resource-group MyKubernetes
Abra el explorador en http://127.0.0.1:8001:
Figura 10.4: Panel de Kubernetes
La utilidad az tuneliza el portal al localhost. Presione Ctrl + C para salir del túnel.
Para poder usar la utilidad kubectl, tenemos que combinar la configuración con el
archivo de configuración local:
az aks get-credentials --resource-group MyKubernetes \
--name Cluster01
La salida del comando anterior es la siguiente:
Figura 10.5: Combinación de la configuración con el archivo de configuración local

Con nuestro sofisticado símbolo del sistema, puede ver que cambiamos del clúster
local de Kubernetes al clúster en Azure. Para ver los clústeres disponibles, ejecute
lo siguiente:
kubectl config get-contexts
Figura 10.6: Visualización de los clústeres disponibles
Puede cambiar al otro clúster si usa kubectl config use-context <cluster>.

También puede usar kubectl para buscar información sobre el clúster:
kubectl cluster-info
Figura 10.7: Información sobre el clúster
Aquí creamos un clúster de Kubernetes denominado Cluster01 con el comando

az aks create. Ahora vamos a enumerar los nodos, que son las máquinas de trabajo
de Kubernetes y están administrados por un nodo maestro:
kubectl get nodes
Figura 10.8: Enumeración de los nodos
Primera implementación en AKS

AKS le permite compilar e implementar aplicaciones en un clúster de Kubernetes
administrado, que administra la conectividad y la disponibilidad de la aplicación en
contenedor. Puede usar un comando kubectl create sencillo para implementar un
contenedor Docker en AKS:
Kubectl createnginx --image=nginx --port=80
Y en cuestión de segundos, hay un mensaje: deployment.apps/nginx created.

Use lo siguiente para comprobar la implementación:
kubectl get deployment
Figura 10.9: Comprobación de la implementación de la imagen
Cuando se ejecutó el comando run, el contenedor Docker se implementó en el

clúster. O, más específicamente, se creó un pod con el contenedor en ejecución en
él. Un pod es un grupo de contenedores con recursos compartidos, como recursos
de almacenamiento y red, y también contiene la especificación de cómo ejecutar los
contenedores. Para ver el pod que se creó, ejecute lo siguiente:
kubectl get pods
La salida del comando anterior devuelve la lista de nombres del pod, los estados del pod
(en ejecución, pendientes, correcto, con errores o desconocido), el número de reinicios
y el tiempo de actividad, de la siguiente manera:
Figura 10.10: Detalles de los pods
Los pods van y vienen; se crean de manera dinámica mientras se escala/disminuye

verticalmente, entre otras cosas. Con el comando explain, puede ver todos los tipos
de información sobre el pod:
kubectl explain pods/nginx-57867cc648-dkv28
Vamos a eliminar el pod:

kubectl delete pod nginx-57867cc648-dkv28
Vuelva a ejecutar kubectl get pods; debería ver que hay disponible un nuevo pod.
Creación de servicios
Pero en realidad, no debe preocuparse por el pod: lo más importante es el servicio.
Un servicio es un objeto que hace que la aplicación sea accesible para el mundo
exterior. Detrás del servicio, hay uno o más pods. El servicio mantiene un seguimiento
de los pods y sus direcciones IP y es una abstracción de un conjunto lógico de pods
y sus directivas. Puede usar el siguiente comando para enumerar todos los servicios
en un espacio de nombres:
kubectl get services
Figura 10.11: Enumeración de todos los servicios en un espacio de nombres

Solo se encuentra un servicio, CLUSTER-IP. Puede encontrar más detalles con el

siguiente comando:
kubectl describe services/kubernetes
Figura 10.12: Obtención de la descripción de los servicios de Kubernetes
Vamos a deshacernos de nuestra primera implementación:

kubectl delete deployment nginx
Figura 10.13: Eliminación de la primera implementación
Creemos una nueva:

kubectl run nginx --image=nginx
Figura 10.14: Creación de una nueva imagen de nginx

Tenga en cuenta que no expusimos los puertos. Para enumerar los pods, use
kubectl get pods. Para que el recurso sea accesible, agregamos un servicio del
tipo LoadBalancer:
kubectl expose pod <pod name> --port=80 --target-port=80 \
--type=LoadBalancer
Figura 10.15: Enumeración de los pods y adición de un servicio del tipo LoadBalancer
Use la dirección EXTERNAL-IP en el explorador. Verá la página principal de nginx.
Pods de varios contenedores

Un pod también es una capa de abstracción que Kubernetes utiliza para mantener
el contenedor. Hay muchos casos de uso y escenarios reales que tienen varios
contenedores en un solo pod para admitir aplicaciones de contenedor de microservicios
que se comunican entre sí, como se muestra en el siguiente diagrama. El almacenamiento
persistente en este diagrama muestra cómo se comunica cada contenedor para
las operaciones de lectura y escritura durante la vida útil del pod y los datos de
almacenamiento persistentes compartidos se pierden cuando elimina el pod:
Figura 10.16: Arquitectura de pods de varios contenedores

Sin embargo, hay casos de uso que se basan en el hecho de que un pod proporciona
recursos compartidos para los contenedores dentro del pod, como:
• Contenedores con aplicaciones auxiliares, como el registro y la supervisión
• Servidores proxy inversos
Hasta ahora, usamos el parámetro —image para crear un pod sencillo. Para un pod más
complejo, necesitamos hacer una especificación en formato YAML. Cree un archivo
llamado myweb.yaml con el siguiente contenido:
apiVersion: v1
kind: Pod
metadata:
name: myweb
spec:
restartPolicy: Never
volumes:
- name: logger
emptyDir: {}
containers:
- name: nginx
image: nginx
volumeMounts:
- name: logger
mountPath: /var/log/nginx
readOnly: false
- name: logmachine
image: ubuntu
volumeMounts:
- name: logger
mountPath: /var/log/nginxmachine
En este archivo, se crea un volumen compartido, denominado journal. La directiva

emptydir garantizar que se cree el volumen mientras se crea el pod.
Para comprobarlo, ejecute lo siguiente:
kubectl exec myweb -c nginxfindmnt | grep logger
Este comando se ejecuta en el pod myweb en el contenedor nginx mediante el comando

findmnt. Creamos contenedores, pods y almacenamiento compartido. Ahora cambiemos
el enfoque a Helm, que es el administrador de paquetes para Kubernetes.
Nota
La opción anterior no se puede usar como solución de clúster y probablemente
sea necesario montar uno de los sistemas de archivos de los contenedores como
de solo lectura con la marca mountOptions.
Cómo trabajar con Helm

Helm (https://helm.sh y https://github.com/helm) es un administrador de paquetes
de aplicaciones para Kubernetes. Lo puede comparar con apt y yum para Linux. Ayuda
a administrar Kubernetes mediante gráficos, los que definen, instalan y actualizan la
aplicación que quiere implementar en Kubernetes.
Hay muchos gráficos disponibles en el repositorio de GitHub de Helm y Microsoft,
que es uno de los mayores colaboradores de este proyecto, también proporciona un
repositorio con ejemplos.
Instalación de Helm
Si está en un sistema Ubuntu, tiene dos opciones: puede instalar Helm con un paquete
snap o simplemente descargar el archivo binario en https://github.com/kubernetes/
helm/releases. Usar el archivo binario funciona en todas las distribuciones de Linux
y el repositorio snap no siempre tiene la versión más reciente de Helm. Por lo tanto,
vamos a usar https://github.com/helm/helm/releases para buscar la versión más
reciente de Helm y cambiar la x en el nombre de archivo helm-vx.x.x-linux-amd64.
taz.gz, según corresponda:
cd /tmp
wget https://storage.googleapis.com/kubernetes-helm/\
helm-v2.9.1-linux-amd64.tar.gz
sudo tar xf helm-v2.9.1-linux-amd64.tar.gz --strip=1 -C \

/usr/local/bin linux-amd64/helm
Cómo trabajar con Helm | 389
Compruebe siempre la versión más reciente en el sitio web y cambie el comando

según corresponda.
Los usuarios de macOS pueden usar Brew (https://brew.sh/):
brew install kubernetes-helm
El cliente está instalado y, con este cliente, podemos implementar la parte del servidor,
Tiller, en nuestro clúster de Kubernetes:
helm init
Figura 10.17: Implementación de Tiller en el clúster de Kubernetes
Compruebe las versiones:

helm version
Figura 10.18: Comprobación de la versión de Helm

Para permitir que Helm obtenga acceso al clúster de Kubernetes, se debe crear una
cuenta de servicio con un rol correspondiente:
kubectl create serviceaccount \
--namespace kube-system tiller
Como se muestra en la siguiente captura de pantalla, creamos una cuenta de servicio
de Tiller en el espacio de nombres kube-system con el comando kubectl create:
Figura 10.19: Creación de una cuenta de servicio de Tiller en el espacio de nombres kube-system
Conceda acceso de administrador del clúster a los recursos de Kubernetes para realizar
tareas administrativas:
kubectl create clusterrolebinding tiller-cluster-rule \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller
Como se muestra en la siguiente captura de pantalla, puede crear un rol personalizado
basado en sus requisitos:
Figura 10.20: Creación de rol personalizado
Helm es el cliente instalado en su máquina local y Tiller es el servidor que está instalado
en su Kubernetes. Para volver a configurar Helm, es decir, para asegurarse de que la
versión de Tiller coincida con su instancia de Helm local, ejecute:
helm init --service-account tiller --upgrade
Administración de repositorios de Helm

Un repositorio de Helm es un servidor HTTP que puede servir archivos YAML y consta
de gráficos empaquetados y un archivo index.yml que se hospeda en el mismo servidor.
Hay dos repositorios que se agregan durante la instalación:
• https://kubernetes-charts.storage.googleapis.com/
• http://127.0.0.1:8879/charts
Agreguemos el repositorio desde Microsoft:

helm repo add azure \
https://kubernetescharts.blob.core.windows.net/azure
Figura 10.21: Agregar el repositorio desde Microsoft
Compruebe los repositorios disponibles:

helm repo list
Figura 10.22: Comprobación de los repositorios disponibles
Para actualizar la información del repositorio, ejecute lo siguiente:

helm repo update
También puede quitar repositorios con el parámetro remove.
Instalación de aplicaciones con Helm

Veamos lo que está disponible en los repositorios:
helm search wordpress
Figura 10.23: Búsqueda del repositorio de WordPress

Si desea información sobre el gráfico, cómo usarlo, los parámetros disponibles, etc.,
puede usar el comando helm inspect. Por ahora, solo vamos a implementarlo:
helm install stable/wordpress
El registro de salida de la instalación del comando anterior contiene los detalles

necesarios para acceder a la instancia WordPress.
Compruebe el estado de los gráficos de Helm en el clúster mediante el siguiente comando:
helm ls
La salida del comando anterior devuelve el nombre de la revisión, la marca de tiempo de

actualización, el estado, el gráfico y su espacio de nombres de la siguiente manera:
Figura 10.24: Comprobación del estado de los gráficos de Helm
Revise la salida anterior del proceso de instalación:

helm status contrasting-chicken
Este comando devuelve la marca de tiempo de la implementación, el espacio de

nombres y el estado, además de detalles del recurso como v1/PersistentVolumeClaim,
v1/Service, extensions/Deployment, v1/Secret y los detalles de connection del servidor
de base de datos:
Figura 10.25: Revisión del estado de Helm
Y, por supuesto, kubectl también le mostrará los siguientes resultados:
Figura 10.26: Uso de kubectl para obtener detalles de la implementación

La siguiente captura de pantalla muestra la salida del comando kubectl get service:
Figura 10.27: Salida del comando kubectl get service
Quitemos nuestra implementación (para encontrar el nombre, use helm ls):

helm delete <NAME>
Figura 10.28: Eliminación de la implementación con el comando helm delete
Para personalizar la aplicación, ejecute lo siguiente:

helm inspect stable/wordpress
Luego, busque la configuración de WordPress:
Figura 10.29: Búsqueda de la configuración de WordPress

Cree un archivo YAML, por ejemplo, custom.yaml, con el siguiente contenido:

image:
registry: docker.io
repository: bitnami/wordpress
tag: 4-ol-7
wordpressUsername: linuxstar01
wordpressEmail: linuxstar01@example.com
wordpressFirstName: Kamesh
wordpressLastName: Ganesan
wordpressBlogName: Linux on Azure – 2nd Edition!
Luego, implemente la aplicación WordPress:

helm install stable/wordpress -f custom.yaml
Para comprobar los resultados, use el comando kubectl. En primer lugar, obtenga
el nombre del pod:
kubectl get pod
Figura 10.30: Comprobación de la implementación de la aplicación WordPress

Después de eso, ejecute el siguiente comando:

kubectl describe pod <podname>
Figura 10.31: Obtención de la descripción del pod
Por ejemplo, en la sección Eventos, verá que se extrae la imagen docker.io/bitnami/

wordpress:4-ol-7.
Limpie todo:
helm delete stable/wordpress
kubectl scale sts --all --replicas=0
kubectl delete pod --all
kubectl delete sts --all --cascade=false
No se preocupe por los conjuntos con estado (sts): esta aplicación los crea para tener
una implementación ordenada y un almacenamiento persistente compartido.
Creación de gráficos de Helm

Los gráficos de Helm son similares a los paquetes de software utilizados en las
distribuciones de Linux y puede examinar la estructura de directorios del repositorio
de paquetes (gráfico) con el cliente Helm. Hay muchos gráficos ya creados y también
puede crear gráficos propios.
En primer lugar, cree un directorio de trabajo y prepárelo para usarlo:
helm create myhelm
cd myhelm
El comando anterior debería tener una salida similar a esta:
Figura 10.32: Creación de un directorio de trabajo
Se crean algunos archivos y directorios:

• El archivo Chart.yaml: este archivo contiene información básica sobre el gráfico.
• El archivo values.yaml: el archivo de configuración predeterminado.
• El directorio charts: los gráficos de dependencia.
• El directorio templates: se usa para crear archivos de manifiesto para Kubernetes
Además, puede agregar un archivo LICENSE, un archivo README.md y un archivo con

requisitos, requirements.yaml.
Modifiquemos un poco el archivo Chart.yaml:
apiVersion: v1
appVersion: 1.15.2
description: My First Nginx Helm
name: myhelm
version: 0.1.0
maintainers:
- name: Kamesh Ganesan
email: kameshg@example.com
url: http://packtpub.com
El archivo se explica casi solo: los mantenedores son opcionales. En este ejemplo,
appVersion hace referencia a la versión de nginx.
Compruebe la configuración con lo siguiente:
helm lint
Tómese un tiempo para investigar los archivos del directorio templates y el archivo
value.yaml. Por supuesto, hay un motivo por el que usamos nginx como ejemplo,
porque los archivos que crea helm create también usan nginx como ejemplo.
En primer lugar, ejecute un simulacro:
helm install --dry-run --debug ../myhelm
De esta manera, puede ver el manifiesto que se usará para implementar la aplicación.
Después de eso, está listo para instalarla:
helm install ../myhelm
Después de la instalación, al observar la ejecución del simulacro, nos dimos cuenta

de que hay algo que no está bien: la versión de nginx es nginx: stable, que es la
versión 1.14.0. Abra el archivo values.yaml y cambie tag: stable a tag: 1.15.2.
Use helm ls para buscar el nombre y actualizarlo:
helm upgrade <name> ../myhelm
Se creará un nuevo pod y se eliminará el anterior:
Figura 10.33: Actualización de la versión del pod
Incluso hay una opción rollback si quiere volver a la versión anterior:

helm rollback <RELEASE> <REVISION>
Solo tiene que especificar la versión y la revisión a la que quiere volver.
Cómo trabajar con Draft

Por lo general, Helm es algo que va a usar, como desarrollador, en aplicaciones que
están listas más o menos listas para producción y que se deben mantener. También
es muy probable que hospede el código en un sistema de control de versiones
como GitHub.
Aquí es donde Draft (https://github.com/Azure/draft) entra en escena. Intenta
optimizar el proceso, partiendo por el código, en el clúster de Kubernetes.
La herramienta está en pleno desarrollo. Draft es cada vez más popular y estable
y se agregan nuevos lenguajes y características de manera periódica.
Si la fase de desarrollo se convierte en algo que se pudiera usar, de todos modos puede
usar Draft, pero es más probable que también cambie a Helm.
Cómo trabajar con Draft | 399
Para saber qué lenguajes de programación son compatibles con Draft, puede ejecutar
los siguientes comandos después de la instalación:
draft pack list
Available Packs:
github.com/Azure/draft/clojure
github.com/Azure/draft/csharp
github.com/Azure/draft/erlang
github.com/Azure/draft/go
github.com/Azure/draft/gradle
github.com/Azure/draft/java
github.com/Azure/draft/javascript
github.com/Azure/draft/php
github.com/Azure/draft/python
github.com/Azure/draft/ruby
github.com/Azure/draft/rust
github.com/Azure/draft/swift
Instalación de Draft
Para poder usar Draft, se debe instalar y configurar Helm.
Obtenga su copia de https://github.com/Azure/draft/releases:
cd /tmp
wget https://azuredraft.blob.core.windows.net/draft/\
draft-v0.15.0-linux-amd64.tar.gz
sudo tar xf draft-v0.15.0-linux-amd64.tar.gz --strip=1 \

-C /usr/local/bin linux-amd64/draft
Compruebe siempre la versión más reciente en el sitio web y cambie el comando

según corresponda.
Los usuarios de macOS pueden instalarlo con Brew:
brew tap azure/draft && brew install draft
Puede ver que los desarrolladores que trabajan en Helm también participan en
el desarrollo de Draft. En ambos casos, muchos de ellos son desarrolladores de
Microsoft. Al igual que lo que ocurre con Helm, después de instalar el cliente,
tiene que inicializar Draft:
draft init
Esto instalará algunos complementos predeterminados y configurará los repositorios

que puede usar en Draft.
Compruebe la versión con lo siguiente:
draft version
En el momento de la redacción de este libro, su versión es 0.16.0:
Figura 10.34: Comprobación de la versión de Draft
El último paso consiste en configurar un repositorio Docker, Docker Hub o Azure.

Para los propósitos de este libro, estamos usando Azure.
Cree un registro de contenedor de Azure (ACR):
az acr create --resource-group MyKubernetes --name LinuxStarACR --sku Basic
Inicie sesión en LinuxStarACR:

az acr login --name LinuxStarACR
Figura 10,35: Inicio de sesión en LinuxStarACR

Configure el repositorio:
draft config set registry LinuxStarACR
Inicie sesión en el registro:

az acr login --name LinuxStarACR
Cree confianza entre Draft y ACR:

export AKS_SP_ID=$(azaks show \
--name <Kubernetes Cluster>
--query "servicePrincipalProfile.clientId" -o tsv)
export ACR_RESOURCE_ID=$(azacr show \

--resource-group <resource group>\
--name <ACR Name> --query "id" -o tsv)
az role assignment create --assignee $AKS_SP_ID --scope $ACR_RESOURCE_ID

--role contributor
Instalamos Draft v0.16.0 y creamos ACR correctamente. Por último, creamos confianza

entre Draft y ACR. Es hora de seguir y empezar a usar Draft.
Uso de Draft
Vamos a desarrollar un código de Draft sencillo. Para esto, crearemos un directorio y le
pondremos mynode. En este directorio, crearemos un archivo denominado mynode.js con
el código siguiente:
var http = require('http');
var server = http.createServer(function(req, res) {

res.writeHead(200);
res.end('Hello World!');
});
server.listen(8080);
Este es un servidor web sencillo que presenta una página al decir Hello World!. Estamos
en una etapa muy temprana del proceso de desarrollo. Para crear un archivo package.
json, ejecute lo siguiente:
npminit
Complete la información:
name: (mynode)
version: (1.0.0) 0.0.1
description: My first Node App
entry point: (mynode.js)
test command: node mynode.js
git repository:
keywords: webapp
author: Kamesh Ganesan
license: (ISC)
Ya estamos listos para ejecutar Draft:

draft create
Figura 10.36: Creación de un Dockerfile con el comando draft create
Esto creará un Dockerfile y toda la información para Helm.

La última línea de la salida, Ready to sail, en realidad significa que está listo para
la ejecución:
draft up
El comando anterior genera la siguiente salida:
Figura 10.37: Creación e inserción de la imagen de Docker
Esto creará la imagen y lanzará la aplicación.

La ejecución de helm ls mostrará la aplicación mynode:
Figura 10.38: Obtención de los detalles de la aplicación mynode
Use kubectl get services para mostrar el servicio:
Figura 10.39: Uso de kubectl get services para mostrar el servicio
Todo parece estar en orden, pero kubectl get pod nos indica lo contrario:
Figura 10.40: Comprobación del estado del pod

El comando draft logs no muestra ningún error, así es que veamos qué opina Kubernetes:
kubectl logs <Pod Name>
Indica npm ERR! missing script: start. Cometimos un error a propósito en el archivo
package.json. Cambie el contenido, modificando los valores según el siguiente ejemplo:
{
"name": "mynode",
"version": "0.0.2",
"description": "My first Node App",
"main": "mynode.js",
"scripts": {
"start": "node mynode.js",
"test": "echo \"Error: no test specified\"& exit 1"
},
"keywords": [
"webapp"
],
"author": "Kamesh Ganesan",
"license": "ISC"
}
Para actualizar la aplicación, vuelva a ejecutar lo siguiente:

draft update
Conéctese a la aplicación:
draft connect
Figura 10.41: Conexión a la aplicación

Administración de Kubernetes | 405
Abra otro terminal:

curl localhost:39053
La salida debe ser Hello World!.

Presione Ctrl + C en el terminal, ejecute draft connect y quite la implementación:
draft delete
Revise los recursos del clúster con kubectl get all y límpielo, si es necesario.
Administración de Kubernetes
Creamos un clúster de Kubernetes y aprendimos sobre la utilidad kubectl y sobre
algunas de las herramientas que están disponibles para desarrollar y mantener sus
aplicaciones en un clúster de Kubernetes.
Entonces, si recordamos las tres preguntas que hicimos en la introducción de este
capítulo, ya respondimos la primera pregunta. En esta sección, vamos a responder
las otras dos preguntas y también trataremos de actualizar la versión de Kubernetes.
Actualización de aplicaciones
Anteriormente, usábamos Helm y Draft para administrar la aplicación, lo que significaba
que todo el trabajo duro se hacía por nosotros. Pero también puede actualizar la carga
de trabajo con la ayuda de kubectl.
Normalmente, el clúster estará vacío ahora, así es que volvamos a implementar
rápidamente el pod nginx:
kubectl run nginx --image=nginx
Observe cuidadosamente la implementación:
Figura 10.42: Implementación del pod nginx
En realidad, esto nos indica que queríamos una instancia, que hay una en ejecución,
que está actualizada (el número de instancias que se actualizaron para coincidir con la
capacidad deseada) y que está disponible. La versión de la ejecución de nginx no es la
más reciente, por lo que queremos actualizarla a la versión 1.17.5. Ejecute lo siguiente:
kubectl edit deployment/nginx
Cambie la imagen a nginx:1.17.5:
Figura 10.43: Cambio de la imagen a nginx:1.17.5
El comando kubectl rollout se puede usar para administrar la implementación de

recursos. Algunas de las opciones de implementación válidas son estado, historial,
pausar, reiniciar, reanudar y deshacer. kubectl rollout status muestra el estado actual
de una implementación, mientras que kubectl rollout history muestra las revisiones
y configuraciones anteriores.
kubectl rollout status deployment nginx
kubectl rollout history deployment nginx
Incluso mejor, también puede usar el comando describe, que proporciona una salida
más detallada que los dos comandos anteriores combinados:
kubectl describe deployment nginx
Figura 10.44: Información detallada de la implementación de nginx
Otra forma de actualizar la implementación es usar el comando set image para

implementar los contenedores nginx actualizados con la versión nueva (1.17.5) de la
implementación mediante la actualización de la imagen, tal como se muestra aquí:
kubectl set image deployment/nginxnginx=nginx:1.17.5 --record
Como puede ver en la captura de pantalla anterior, la imagen del contenedor nginx se
actualizó correctamente a la versión 1.17.5.
Escalado de aplicaciones
Por el momento, hay un pod en ejecución, pero para manejar toda la carga que entra,
es posible que necesite más instancias y equilibrar la carga del tráfico entrante. Para
hacerlo, necesitará réplicas para definir un número especificado de réplicas de pod que
se ejecutan en un momento determinado.
Volvamos a kubectl y obtengamos la implementación actual:
Figura 10.45: Obtención del estado de la implementación actual
El estado deseado (configurado) en este momento es 1. La situación actual es

1 y hay 1 disponible.
Para escalar hasta tres instancias, ejecute lo siguiente:
kubectl scale deployment nginx --replicas=3
Vuelva a ejecutar kubectl get deployments; después de eso, observe los pods disponibles:
kubectl get pods -o wide
Figura 10.46: Comprobación de los pods disponibles después del escalado vertical
Cree un servicio de equilibrador de carga:

kubectl expose deployment nginx --type=LoadBalancer \
--name=nginx-lb --port 80
kubectl get services
Figura 10.47: Creación de un servicio de equilibrador de carga

Ahora, el equilibrador de carga toma cada solicitud HTTP y el tráfico se distribuye en

las instancias.
También puede usar escalado automático. En primer lugar, instale el servidor de métricas:
git clone https://github.com/kubernetes-incubator/metrics-server.git
kubectl create -f metrics-server/deploy/1.8+/

Configure el escalado automático: si la carga supera el 50 por ciento, se crea una
instancia adicional, hasta un máximo de 10:
kubectl autoscale deployment nginx --cpu-percent=50 --min=3 --max=10
Por supuesto, en este escenario, tiene sentido tener al menos dos nodos disponibles en
su clúster:
azaks scale --name Cluster01 \
--resource-group MyKubernetes \
--node-count 2
kubectl get nodes

Tenga en cuenta que este proceso tardará unos 10 minutos. Para ver el estado del
escalado automático, ejecute lo siguiente:
kubectl get hpa
Figura 10.48: Enumeración de los autoescaladores
Actualización de Kubernetes
Al igual que con cualquier software o aplicación, debe mantener actualizados los
clústeres de Kubernetes. La actualización es muy importante para obtener las
correcciones de errores más recientes y todas las características de seguridad críticas
junto con las características más recientes de Kubernetes. También es necesario tener
varios nodos disponibles si desea actualizar el plano de control de Kubernetes sin
tiempo de inactividad. Los siguientes pasos le mostrarán cómo actualizar rápidamente
sus clústeres de Kubernetes.
En primer lugar, vea la versión actual:

az aks list --query "[].kubernetesVersion"
Figura 10.49: Visualización de la versión actual de Kubernetes
Pregunte por las versiones disponibles en su ubicación:

az aks get-versions --location eastus --output table | egrep "^1.13.12"
Figura 10.50: Versiones disponibles para la ubicación Este de EE. UU.
Podemos actualizar a la versión 1.14.8:

az aks upgrade --resource-group MyKubernetes
--name Cluster01 \
--kubernetes-version 1.14.8 --yes --no-wait
Agregar el parámetro --no-wait tiene el efecto de que volverá a recibir la notificación
casi directamente.
De esta manera, después de unos tres minutos, puede empezar a usar kubectl para
obtener el estado de los nodos y pods (use el parámetro -owide, por ejemplo, kubectl
get pods -o wide) y descubra que se creó un nodo con la versión más reciente. La carga
de trabajo se vuelve a crear en ese nodo y el otro nodo se actualiza. Después de eso,
el último que queda se vacía y se actualiza.
Almacenamiento persistente
En el capítulo anterior, dijimos que hay varias formas de usar el almacenamiento
persistente en nuestro contenedor y también hablamos de esto en este capítulo.
Kubernetes puede configurar el almacenamiento persistente, pero debe proporcionarlo,
por ejemplo, a través de un contenedor NFS o mediante la implementación de una
matriz virtual de StorSimple iSCSI (que resulta especialmente útil si necesita acceso de
lectura/escritura desde varios contenedores). Incluso si usa Azure Storage, hay muchas
decisiones que tiene que tomar. ¿Quiere usar discos o Azure Storage? ¿Quiere crearlos
sobre la marcha (dinámicamente) o usar los existentes (estáticamente)? La mayoría de
estas preguntas se responden en función del costo y la necesidad de servicios como la
replicación, la copia de seguridad y las instantáneas.
En esta sección, queremos abarcar las opciones dinámicas; en cuanto a la orquestación,
es una mejor opción, ya que puede hacer todo dentro de Kubernetes (o usar las
herramientas que lo rodean).
Ya sea que use discos o Azure Storage, necesitará una cuenta de almacenamiento en el
mismo grupo de recursos que Kubernetes:
az storage account create --resource-group MyKubernetes \
--name mystorageest1 –sku Standard_LRS
Vuelva a consultar el Capítulo 2, Introducción a la nube de Azure, para conocer la sintaxis
del comando anterior. Recuerde que el nombre debe ser exclusivo.
Azure Disks para Kubernetes

Puede aprovisionar de manera dinámica o estática el volumen persistente para su
uso con uno o varios pods de Kubernetes en un clúster de AKS. Hay dos clases de
almacenamiento: Azure Disks estándar (el valor predeterminado) y Azure Disks
premium, que es una clase de almacenamiento premium administrado:
1. En primer lugar, cree un archivo YAML para crear la clase de almacenamiento.
Esto permite aprovisionar automáticamente el almacenamiento:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: storageforapp
provisioner: kubernetes.io/azure-disk
parameters:
storageaccounttype: Standard_LRS
location: eastus
kind: shared
Almacenamiento persistente | 411
2. Aplíquelo con lo siguiente:

kubectlapply -f storageclass.yaml
Reemplace el nombre de archivo por el nombre del archivo que acaba de crear.
3. Se necesita otro archivo YAML para reclamar el volumen persistente, o en otras
palabras, crearlo:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: claim-storage-for-app
annotations:
volume.beta.kubernetes.io/storage-class: storageforapp
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
4. Tenga en cuenta que la coincidencia se hace en las anotaciones. Aplique también
este archivo:
kubectlapply -f persistentvolume.yaml
5. Compruebe el resultado con lo siguiente:
kubectl get sc
Figura 10.51: Comprobación de la creación de la clase de almacenamiento

6. Para utilizar el almacenamiento en un pod, puede usarlo de forma similar al

siguiente ejemplo:
kind: Pod
apiVersion: v1
metadata:
name: my-web
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: volume
volumes:
- name: volume
persistentVolumeClaim:
claimName: claim-storage-for-app
Azure Files para Kubernetes

Cuando monte el disco de Azure con el tipo de modo de acceso ReadWriteOnce, solo
estará disponible para un solo pod en AKS. Como tal, debe usar Azure Files para
compartir un volumen persistente en varios pods. La configuración de Azure Files no es
diferente de Azure Disks, como se describe en la sección anterior. El archivo YAML para
crear la clase de almacenamiento es el siguiente:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azurefile
provisioner: kubernetes.io/azure-file
Almacenamiento persistente | 413
mountOptions:
- dir_mode=0888
- file_mode=0888
- uid=1000
- gid=1000
- mfsymlinks
- nobrl
- cache=none
parameters:
skuName: Standard_LRS
Use la notificación de volumen persistente para aprovisionar el recurso compartido de

archivos de Azure mediante la ejecución del siguiente archivo YAML:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azurefile
spec:
accessModes:
- ReadWriteMany
storageClassName: azurefile
resources:
requests:
storage: 5Gi
Aplique estos dos archivos YAML de la siguiente manera:
.
Figura 10.52: Uso de la solicitud de volumen persistente para crear un archivo de Azure
El resultado de ejecutar el archivo YAML de creación de almacenamiento de archivos de

Azure y el archivo YAML de notificación de volumen de almacenamiento es el siguiente:
Figura 10.53: Comprobación de la creación de archivos de Azure y discos de Azure
Como puede ver, la especificación en el pod sigue siendo la misma. Con estas
implementaciones paso a paso, creamos correctamente los discos de Azure y los
archivos de Azure para nuestros requisitos de almacenamiento persistente.
Resumen
Este capítulo se trató de Kubernetes. Comenzamos este capítulo describiendo un
posible entorno de trabajo para un desarrollador: una buena estación de trabajo
con herramientas para iniciar el desarrollo local, incluso con Kubernetes instalado
localmente. Usamos Ubuntu Desktop como ejemplo pero, de hecho, realmente no
importa, siempre y cuando esté satisfecho con su entorno de desarrollo.
Con todo implementado en el entorno local, cubrimos la configuración de los clústeres
de Kubernetes en Azure mediante la CLI de Azure y PowerShell.
La implementación de cargas de trabajo en Azure puede ser tan simple como ejecutar
kubectl run, pero también exploramos escenarios más complejo, como las aplicaciones
de múltiples contenedores.
Como desarrollador, tiene dos herramientas disponibles que le ayudarán a agilizar su
proceso de desarrollo: Draft and Helm. Draft se usa para la fase de desarrollo inicial
y Helm se usa posteriormente para instalar y mantener la aplicación.
Kubernetes es una herramienta para administrar los contenedores, lo que facilita
la implementación, el mantenimiento y la actualización de las cargas de trabajo.
La escalabilidad es una de las ventajas de usar Kubernetes; incluso es posible escalar
automáticamente en función de los recursos de CPU y memoria requeridos.
Preguntas | 415
En la última sección de este capítulo se cubrió el uso del almacenamiento persistente

en Kubernetes, lo que es mucho mejor que almacenar datos en un contenedor
o conectar el almacenamiento directamente a un contenedor.
En el siguiente capítulo, volveremos a la parte de Operaciones de DevOps, es decir,
solucionar problemas y supervisar sus cargas de trabajo, y por cargas de trabajo,
nos referimos a máquinas virtuales con Linux instalado, contenedores y AKS.
Preguntas
1. ¿Qué es un pod?
2. ¿Cuál sería una buena razón para crear un pod de múltiples contenedores?
3. ¿Qué métodos puede utilizar para implementar la aplicación en Kubernetes?
4. ¿Qué métodos puede utilizar para actualizar la aplicación en Kubernetes?
5. ¿Necesita crear nodos adicionales en Kubernetes si quiere actualizar el plano
de control?
6. ¿Puede pensar en alguna razón por la que querría una solución iSCSI?
7. Como ejercicio, vuelva a crear el pod de varios contenedores con almacenamiento
persistente.
Lectura adicional
El objetivo de este capítulo era proporcionar un enfoque práctico para que su carga de
trabajo se ejecutara en la nube de Azure. Esperamos que sea el comienzo de su viaje al
mundo de Kubernetes. ¡Hay mucho más por descubrir!
Nigel Poulton, autor que ya escribió un excelente libro sobre Docker, también escribió
un libro sobre Kubernetes, The Kubernetes Book (El libro de Kubernetes). Es un buen
punto de partida si realmente es nuevo en Kubernetes. Gigi Sayfan escribió Mastering
Kubernetes (Dominar Kubernetes). Asegúrese de comprar la segunda edición, no solo
porque la primera edición no fue tan buena, sino simplemente porque es una necesidad
y proporciona mucha más información que la primera edición.
Como desarrollador, debería tratar de leer Kubernetes for Developers (Kubernetes para
desarrolladores): Joseph Heck puede contarle mucho sobre el ciclo de vida del desarrollo
mediante Kubernetes, con ejemplos en Node.js y Python. En el último capítulo de su
libro, menciona proyectos emergentes como Helm y Brigade. Esperamos que esto se
explore con más detalle en una edición posterior, o quizás, incluso en otro libro.
A propósito de Brigade, https://brigade.sh se describe en su propio sitio web como
“una herramienta para ejecutar tareas automatizadas y con scripts en la nube, como
parte de su clúster de Kubernetes”. Va mucho más allá del alcance de este libro y está más
o menos en las primeras etapas de desarrollo. Como desarrollador, debe invertir algo de
tiempo en leer más sobre Brigade y probarlo.
Por último, pero no menos importante, otro origen importante que vale la pena
mencionar es Open Service Broker for Azure (OSBA: https://osba.sh). No aparece
en este capítulo porque, en el momento en que se escribe este libro, no está
completamente listo para producción. OSBA es un estándar abierto para comunicarse
con servicios externos, como bases de datos y almacenamiento. Es otra solución para
proporcionar datos y almacenarlos desde el contenedor.
Solución de problemas
11
y supervisión de sus
cargas de trabajo
La solución de problemas y el registro están muy relacionados; debe empezar a analizar
los registros de Evento, Servicio y Sistema cuando experimente problemas.
La solución y corrección de los problemas encontrados en un entorno de nube pueden
ser diferentes de la solución de problemas en implementaciones más clásicas. En este
capítulo se explican las diferencias, los desafíos y las nuevas posibilidades de la solución
de problemas de las cargas de trabajo de Linux en el entorno de Azure.
418 | Solución de problemas y supervisión de sus cargas de trabajo

• Use distintas herramientas para lograr analizar el rendimiento en un sistema Linux.
• Supervise las métricas, como la CPU, la memoria, el almacenamiento y los detalles
de la red.
• Use las herramientas de Azure para identificar y solucionar problemas.
• Use las herramientas de Linux para identificar y solucionar problemas.
Para este capítulo, necesitará una o dos VM que ejecuten una distribución de Linux.
Puede usar el tamaño más pequeño si lo desea. Se debe instalar el demonio audit
y, con el fin de tener registros del sistema de auditoría para analizarlos y entenderlos,
se recomienda instalar Apache y un servidor MySQL/MariaDB.
El siguiente es un ejemplo en CentOS:
sudo yum groups install ''Basic Web Server''
sudo yum install mariadbmariadb-server
sudo yum install setroubleshoot
sudosystemctl enable --now apache2
sudosystemctl enable --now mariadb
auditd proporciona detalles minuciosos sobre el rendimiento y la actividad del servidor
mediante reglas de auditoría que se pueden modificar en función de sus necesidades.
Para instalar el demonio audit, use lo siguiente:
sudo yum list audit audit-libs
Al ejecutar el comando anterior, recibirá esta salida:
Figura 11.1: Instalación del demonio de auditoría

Si puede ver la lista de paquetes de auditoría instalados como se mostró anteriormente,

entonces ya está instalado. Si no es así, ejecute el siguiente comando:
sudo yum install audit audit-libs
Después de instalar correctamente auditd, tiene que iniciar el servicio auditd para
empezar a recopilar registros de auditoría y, luego, almacenar los registros:
sudo systemctl start auditd
Si quiere iniciar auditd en el momento del arranque, debe usar el siguiente comando:
sudo systemctl enable auditd
Ahora comprobemos si auditd se instaló correctamente y si empezó a recopilar

registros con el siguiente comando:
tail -f /var/log/audit/audit.log
Figura 11.2: Comprobación de la instalación correcta de auditd y de la recopilación de registros
En este capítulo, hablaremos de la administración general de Azure y Azure Monitor.

El agente de Log Analytics para Linux, que es necesario para recopilar información
desde la VM, no es compatible con todas las distribuciones de Linux; visite https://docs.
microsoft.com/es-xl/azure/virtual-machines/extensions/oms-linux antes de tomar
una decisión sobre qué distribución quiere usar en este capítulo.
Nota
En términos generales, Operations Management Suite (OMS) se retiró y se
pasó a Azure y el nombre “OMS” ya no se usa en ningún lado, excepto en algunos
nombres de variables. Ahora se conoce como Azure Monitor. Para obtener
más información sobre los cambios de nomenclatura y terminología, consulte
https://docs.microsoft.com/es-xl/azure/azure-monitor/terminology o también
puede obtener información detallada sobre la transición en https://docs.microsoft.
com/es-xl/azure/azure-monitor/platform/oms-portal-transition.
Acceso al sistema
Aprender a solucionar problemas de las cargas de trabajo lo ayudará en su trabajo diario.
La solución de problemas en Azure no es diferente de hacerlo en otros entornos. En esta
sección, vamos a ver algunas sugerencias y trucos que lo ayudarán en su trabajo diario.
Sin acceso remoto

Cuando no tiene acceso a su VM de Azure a través de SSH, puede ejecutar comandos
a través de Azure Portal.
Para ejecutar un comando en la VM de Azure desde Azure Portal, inicie sesión en Azure
Portal, vaya a su VM y seleccione Ejecutar comando:
Figura 11.3: Navegación a la sección VM dentro de Azure Portal
También puede usar la línea de comandos, como se muestra a continuación:

az vm run-command invoke --name <vm name> \
--command-id RunShellScript \
--scripts hostnamectl \
El comando az vm run se puede usar para ejecutar scripts de shell en la VM para una
administración general de la máquina o de las aplicaciones y para diagnosticar problemas.
Acceso al sistema | 421
Independientemente de si lo hace a través de la línea de comandos o en Azure Portal,

el comando az vm solo funciona si el agente de Linux para Microsoft Azure se sigue
ejecutando y es accesible.
Nota
Puede obtener el repositorio de Microsoft Azure PowerShell en https://github.com/
Azure/azure-powershell, que tiene los pasos de instalación y su uso. az reemplaza
a AzureRM y todas las características nuevas de Azure PowerShell estarán
disponible solo de az en adelante.
Según el procedimiento recomendado de seguridad, para cambiar la contraseña, debe

iniciar sesión en su cuenta de Azure y con az vm user para restablecer la contraseña
como se indica a continuación:
az vm user update \
--resource-group myResourceGroup \
--name myVM \
--username linuxstar \
--password myP@88w@rd
Esto solo funciona si tiene un usuario que está configurado con una contraseña. Si
implementó la VM con claves SSH, tiene suerte: la opción Restablecer contraseña de
la misma sección servirá.
Esta opción usa la extensión VMAccess (https://github.com/Azure/azure-linux-
extensions/tree/master/VMAccess). Al igual que la opción Ejecutar comando que
se mencionó anteriormente, necesita el agente de VM de Azure.
Cómo trabajar en el puerto

La razón por la que no tiene acceso remoto puede estar relacionada con la red. En el
Capítulo 5, Administración avanzada de Linux, el comando ip se presentó brevemente
en la sección Redes. Puede usar este comando para comprobar la dirección IP y la tabla
de rutas.
En el sitio de Azure, se deben comprobar la red y los grupos de seguridad de red, como
se indica en el Capítulo 3, Administración básica de Linux. En la VM, puede usar el
comando ss, como ip, que forma parte del paquete iproute2 para mostrar los puertos
UPD (-u) y TCP (p) que tengan un estado de escucha, junto con el ID del proceso (-p)
que abrió el puerto:
Figura 11.4: Uso del comando ss -tulpn para comprobar los puertos
Puede hacer una comprobación rápida de las reglas de firewall con firewall-cmd --list-
all --zone=public; si tiene varias zonas e interfaces, necesita ejecutarlo para cada zona.
Para incluir las reglas creadas por Azure Service Fabric, iptables-save puede ayudar:
Figura 11.5: Inclusión de las reglas creadas por Azure Service Fabric
Lamentablemente, no hay ningún comentario disponible para ver todas las reglas de
acceso configuradas en el nivel de unidad systemd. Recuerde comprobarlas, como se
indicó en el Capítulo 6, Administración de seguridad e identidades de Linux.
Uso de nftables
nftables es más fácil de usar que iptables y combina todo el marco iptables con
una sintaxis simple. nftables se basa en un subsistema netfilter que se puede usar
para crear reglas de filtrado complejas y agrupadas. nftables tiene muchas ventajas
sobre iptables. Por ejemplo, le permite realizar varias acciones con una sola regla.
Usa la herramienta de la línea de comandos nft, que también se puede usar en modo
interactivo con el comando nft -i:
1. Instale nftables con el siguiente comando:
sudo apt install nftables
2. Luego instale compat, lo que carga la compatibilidad con el subsistema de kernel
nftables:
apt install iptables-nftables-compat
3. Por último, habilite el servicio nftables con el siguiente comando:
sudo systemctl enable nftables.service
4. Puede ver la configuración actual de nft con esto:
nft list ruleset
5. Además, puede iniciar sesión en el modo interactivo de nft con el siguiente
comando:
nft –i
6. Ahora puede mostrar el conjunto de reglas existente con el comando list:
nft> list ruleset
7. Vamos a crear una tabla nueva, rule_table1:
nft>add table inet rule_table1
8. Ahora tendremos que agregar el comando chain para aceptar el tráfico entrante/
saliente de la siguiente manera:
nft>add chain inet rule_table1 input { type filter hook input priority 0 ;
policy accept; }
nft>add chain inet rule_table1 output { type filter hook input priority 0 ;
policy accept; }
9. Puede usar el siguiente comando para agregar reglas para aceptar los puertos TCP
(Protocolo de control de transmisión):
nft>add rule inet rule_table1 input tcpdport { ssh, telnet, https, http }
accept
nft>add rule inet rule_table1 output tcpdport { https, http } accept

10. Esta es la salida de la nueva configuración de nftables:
nft> list ruleset
table inet rule_table1 {

chain input {
type filter hook input priority 0; policy accept;
tcpdport { ssh, telnet, http, https } accept
}
chain output {
type filter hook input priority 0; policy accept;
tcpdport { http, https } accept
}
}
Diagnóstico de arranque
Supongamos que creó su VM, quizás orquestada y probablemente su propia VM, pero
no arranca.
Antes de habilitar el diagnóstico de arranque en las VM, necesitará una cuenta
de almacenamiento para poder almacenar los datos. Puede enumerar las cuentas
de almacenamiento que ya están disponibles con el comando az storage account
list y, si es necesario, puede crear una con el comando az storage account create.
Ahora habilitaremos el diagnóstico de arranque con el siguiente comando en la CLI
de Azure:
az vm boot-diagnostics enable --name <vm name>\
--storage <url>
La diferencia es que no necesita el nombre de la cuenta de almacenamiento, sino que

el nombre del blob de almacenamiento, que se puede encontrar con el comando az
storage account list como una propiedad de la cuenta de almacenamiento.
Ejecute lo siguiente en la CLI de Azure para recibir el registro de arranque:
az vm boot-diagnostics get-boot-log \
--name <virtual machine> \
La salida también se almacena automáticamente en un archivo; en la CLI de Azure,
se recomienda canalizarla a través de less o redirigirla a un archivo.
Inicio de sesión en Linux

Muchos procesos, servicios y aplicaciones se ejecutan en sistemas Linux típicos, que
generan distintos registros, como registros de aplicación, evento, servicio y sistema,
que se pueden usar para la auditoría y la solución de problemas. En los capítulos
anteriores, encontramos el comando journalctl, que se usa para consultar y mostrar
registros. En este capítulo, analizaremos este comando con mucho más detalle
y veremos cómo puede fragmentar los registros con la utilidad journalctl.
En distribuciones de Linux, como las versiones más recientes de RHEL/CentOS, Debian,
Ubuntu y SUSE, que usan systemd como su sistema init, el demonio systemd-journald
se usa para registro. Este demonio recopila la salida estándar de una unidad, un mensaje
de syslog y (si la aplicación lo permite) dirige los mensajes de la aplicación a systemd.
Los registros se recopilan en una base de datos que se puede consultar con journalctl.
Cómo trabajar con journalctl
Si ejecuta systemctl status <unit>, puede ver las últimas entradas del registro. Para
ver el registro completo, journalctl es la herramienta que necesita. Hay una diferencia
con systemctl: puede ver el estado en otros hosts con el parámetro -H. No puede usar
journalctl para conectarse a otros hosts. Ambas utilidades tienen el parámetro –M para
conectarse a los contenedores systemd-nspawn y Rkt.
Para ver las entradas en la base de datos del diario, ejecute esto:
Sudo journalctl --unit <unit>
Figura 11.6: Visualización de las entradas en la base de datos del diario

De manera predeterminada, el registro se pagina con less. Si quiere otro control de

paginación, como more, puede configurarlo mediante el archivo /etc/environment.
Agregue la siguiente línea:
SYSTEMD_PAGER=/usr/bin/more
Este es un ejemplo de la salida:
Figura 11.7: Uso del comando journalctl para obtener las entradas de registro de los procesos
Examinemos la salida:
• La primera columna es la marca de tiempo. En la base de datos, se define en tiempo
de EPOCH, por lo que si cambia la zona horaria, no hay problema: se traducirá.
• La segunda columna es el nombre de host, como muestra el comando hostnamectl.
• La tercera columna contiene un identificador y el ID del proceso.
• La cuarta columna es el mensaje.
Puede agregar los siguientes parámetros para filtrar los registros:

• --dmesg: mensajes de kernel, reemplazo del antiguo comando dmesg
• --identifier: cadena de identificador
• --boot: mensajes durante el proceso de arranque actual; también puede seleccionar
arranques anteriores si la base de datos es persistente a través de los reinicios
Filtros
Por supuesto, puede usar grep en la salida estándar, pero journalctl tiene algunos
parámetros que realmente ayudan a filtrar la información que quiere:
• --priority: filtre según alert, crit, debug, emerg, err, info, notice y warning.
La clasificación de estas prioridades es la misma que en la especificación del
protocolo syslog.
• --since y --until: filtre según la marca de tiempo. Consulte man systemd.time
para ver todas las posibilidades.
• --lines: el número de líneas, similar a tail.
• --follow: comportamiento similar a tail -f.
• --reverse: pone primero la última línea.
• --output: cambia el formato de salida a formatos como JSON o agrega más detalles
a la salida.
• --catalog: agrega una explicación del mensaje si encuentra una disponible.
Todos los filtros se pueden combinar, como aquí:

sudo journalctl -u sshd --since yesterday --until 10:00 \
--priority err
Figura 11.8: Filtro de las entradas de registro mediante el uso de varios filtros con journalctl
Filtrado basado en campos

También podemos filtrar según los campos. Escriba esto:
sudojournactl _
Ahora presione Ctrl + I dos veces; verá todos los campos disponibles. El mismo principio
se aplica a estos filtros; es decir, puede combinarlos:
sudo journalctl _UID=1000 _PID=1850
Incluso puede combinarlos con filtros normales:

sudo journalctl _KERNEL_DEVICE=+scsi:5:0:0:0 -o verbose
Persistencia de bases de datos

Ahora puede que necesite almacenar los registros durante un determinado período
de tiempo por motivos de cumplimiento o debido a los requisitos de auditoría. Por lo
tanto, puede usar un agente de Azure Log Analytics para recopilar registros de distintos
orígenes. De manera predeterminada, la base de datos de registro no es persistente.
Para que sea persistente, por cualquier motivo relacionado con la auditoría o el
cumplimiento (aunque almacenar los registros en localhost no sea un procedimiento
recomendado), tiene que editar el archivo de configuración, /etc/systemd/journald.conf.
Cambie la línea #Storage=auto a esto:
Storage=persistent
Reinicie el demonio systemd-journald con force:

sudo systemctl force-reload systemd-journald
Use esto para ver los arranques registrados:

sudo journalctl --list-boots
Figura 11.9: Visualización de los arranques guardados
Puede agregar el ID de arranque como filtro con el parámetro --boot:

journalctl --priority err --boot <boot id>
Por este medio, la salida de hostnamectl muestra el ID de arranque actual.

La base de datos del diario no depende del demonio. Puede verlo con los parámetros
--directory y --file.
Protocolo Syslog
Se habilitó el inicio de sesión en Linux y otros miembros de la familia Unix durante
la implementación del protocolo syslog. Todavía se usa para enviar registros
a servicios remotos.
Es importante entender que este protocolo usa las estructuras y la gravedad. Ambas
están estandarizadas en RFC 5424 (https://tools.ietf.org/html/rfc5424). Aquí, una
estructura especifica el tipo de programa que está registrando el mensaje; por ejemplo,
el kernel o cron. La etiqueta de gravedad está allí para describir el impacto, como
informativo o crítico.
La página man de los programadores para (man 3 syslog) también ofrece una buena
visión de estas estructuras y gravedades, y muestra cómo un programa puede usar este
protocolo. Las malas noticias sobre syslog es que solo funciona si la aplicación lo admite
y la aplicación se ejecuta lo suficiente para proporcionar esta funcionalidad. journald
es capaz de obtener todo lo relacionado con la salida de un programa.
Agregar entradas de registro
Puede agregar manualmente entradas a un registro. Para syslog, está disponible
el comando logger:
logger -p <facility.severity> "Message"
Para journald, está systemd-cat:

systemd-cat --identifier <identifier> --priority <severity><command>
Veamos un ejemplo:
systemd-cat --identifier CHANGE --priority info \
echo "Start Configuration Change"
Como identificador, puede usar cadenas libres o estructuras de syslog. Tanto logger
como systemd-cat se pueden usar para generar entradas en el registro. Puede usarlo si
la aplicación no tiene compatibilidad con syslog; por ejemplo, puede usar esta directiva
en una configuración de Apache:
errorlog "tee -a /var/log/www/error/log | logger -p local6.info"
También puede usar esto como parte de la administración de cambios.

Integración de journald con RSYSLOG

Para recopilar sus datos para su propio servicio de supervisión, el servicio de supervisión
necesita compatibilidad con syslog. Algunos buenos ejemplos de estos servicios de
supervisión están disponibles como VM listas para usar en Azure: Splunk y Elastic Stack.
RSYSLOG es la implementación de protocolo de syslog más usada en la actualidad.
Viene instalado de manera predeterminada en las distribuciones basadas en Ubuntu,
SUSE y Red Hat.
RSYSLOG puede funcionar muy bien junto con la base de datos del diario con el módulo
imjournal. En las distribuciones basadas en SUSE y Red Hat, esto ya está configurado;
en Ubuntu, debe hacer una modificación en el archivo /etc/rsyslog.conf:
# module(load="imuxsock")
module(load="imjournal")
Después de la modificación, reinicie RSYSLOG:
sudo systemctl restart rsyslog
Con la configuración que hay en /etc/rsyslog.d/50-default.conf, se registra en

archivos de texto sin formato.
Para enviar todo lo que viene de syslog local a un servidor syslog remoto, debe agregar
lo siguiente a este archivo:
*. * @<remote server>:514
Nota
Este es el nombre del archivo en Ubuntu. En otras distribuciones, use /etc/
rsyslog.conf.
Use @@ si quiere el protocolo TCP en lugar del protocolo UDP.

Otros archivos de registro
Puede encontrar archivos de registro de aplicaciones que no admiten syslog ni
systemd-journald en la estructura de directorios /var/log. Un archivo importante que
hay que tener en cuenta es el archivo /var/log/waagent.log, que contiene el registro del
agente de VM de Azure Linux. También existe el directorio /var/log/azure, que contiene
el registro de otros agentes de Azure (como Azure Monitor) y extensiones de VM.
Azure Log Analytics | 431
Azure Log Analytics

Azure Log Analytics es una parte de Azure Monitor que recopila y analiza datos de
registro y realiza las acciones adecuadas. Es un servicio de Azure que recopila los datos
de registro de varios sistemas en un solo almacén de datos en una ubicación central.
Consta de dos componentes importantes:
• Azure Log Analytics Portal, con características de análisis, informes y alertas.
• El agente de Azure Monitor, que se debe instalar en una VM.
También hay disponible una aplicación móvil (en la tienda iOS y Android, puede
encontrarla bajo el nombre Microsoft Azure) si quiere ver el estado de las cargas de
trabajo mientras está en movimiento.
Configuración del servicio Log Analytics

En Azure Portal, seleccione Todos los servicios en la barra de la izquierda y busque
Log Analytics. Seleccione Agregar y cree una nueva área de trabajo de Log Analytics.
En el momento de la redacción de este libro, no está disponible en todas las regiones.
El uso del servicio no se limita a la región: si una VM está en otra región, de todos
modos puede supervisarla.
Nota
Este servicio no tiene costos por adelantado, usted paga lo que usa. Lea
http://aka.ms/PricingTierWarning para obtener más detalles.
Otra manera de crear el servicio es con la CLI de Azure:

az extension add -n application-insights
Después de la creación del servicio, aparece una ventana emergente que le permite
navegar al recurso recién creado. También puede volver a buscar en Todos los servicios.
Observe, en la parte superior derecha del panel de recursos, Azure Monitor y el ID
del área de trabajo; necesitará esta información más adelante. Vaya a Configuración
avanzada para encontrar la clave del área de trabajo.
En la CLI de Azure, puede recopilar esta información mediante lo siguiente:

az monitor app-insights component create --app myapp
--location westus1
--resource-group my-resource-grp
Para enumerar todas las áreas de trabajo de su suscripción a Azure, puede usar el
siguiente comando de la CLI de Azure:
az ml workspace list
Puede obtener información detallada sobre un área de trabajo en formato JSON con
el siguiente comando de la CLI de Azure:
az ml workspace show -w my-workspace -g my-resource-grp
Instalación del agente de Azure Log Analytics

Antes de instalar el agente de Azure Monitor, asegúrese de que el paquete audit (en
auditd) está instalado.
Para instalar el agente de Azure Monitor en una VM Linux, tiene dos posibilidades:
habilitar la extensión OMSAgentforLinux de la VM o descargar e instalar el agente de
Log Analytics en Linux.
En primer lugar, establezca algunas variables para facilitar el scripting:
$rg = "<resource group>"
$loc = "<vm location>"
$omsName = "<OMS Name>"
$vm = "<vm name">
Necesita el ID del área de trabajo y la clave. El cmdlet Set-AzureVMExtension necesita las

claves en formato JSON, por lo que se necesita una conversión:
$omsID = $(Get-AzOperationalInsightsWorkspace '
-ResourceGroupName $rg -Name $omsName.CustomerId)
$omsKey = $(Get-AzOperationalInsightsWorkspaceSharedKeys '

-ResourceGroupName $rg -Name $omsName).PrimarySharedKey
$PublicSettings = New-Object psobject | Add-Member '

-PassThruNotePropertyworkspaceId $omsId | ConvertTo-Json
$PrivateSettings = New-Object psobject | Add-Member '

-PassThruNotePropertyworkspaceKey $omsKey | ConvertTo-Json
Ahora puede agregar la extensión a la VM:
Set-AzureVMExtension -ExtensionName "OMS" '
-ResourceGroupName $rg -VMName $vm '
-Publisher "Microsoft.EnterpriseCloud.Monitoring"
-ExtensionType "OmsAgentForLinux" -TypeHandlerVersion 1.0 '
-SettingString $PublicSettings
-ProtectedSettingString $PrivateSettings -Location $loc
El procedimiento anterior es bastante complejo y toma un tiempo. El método de

descarga es más sencillo, pero tiene que iniciar sesión en su VM a través de SSH
como invitado. Por supuesto, ambos métodos se pueden automatizar u orquestar:
cd /tmp
wget \
https://github.com/microsoft/OMS-Agent-for-Linux \
/blob/master/installer/scripts/onboard_agent.sh
sudo -s
sh onboard_agent.sh -w <OMS id> -s <OMS key> -d \

opinsights.azure.com
Si tiene problemas durante la instalación del agente, consulte los archivos de

configuración /var/log/waagent.log y /var/log/azure/Microsoft.EnterpriseCloud.
Monitoring.OmsAgentForLinux/*/extension.log.
La instalación de las extensiones también crea un archivo de configuración para

rsyslog,/etc/rsyslogd.d/95-omsagent.conf:
kern.warning @127.0.0.1:25224
user.warning @127.0.0.1:25224
daemon.warning @127.0.0.1:25224
auth.warning @127.0.0.1:25224
syslog.warning @127.0.0.1:25224
uucp.warning @127.0.0.1:25224
authpriv.warning @127.0.0.1:25224
ftp.warning @127.0.0.1:25224
cron.warning @127.0.0.1:25224
local0.warning @127.0.0.1:25224
local1.warning @127.0.0.1:25224
local2.warning @127.0.0.1:25224
local3.warning @127.0.0.1:25224
local4.warning @127.0.0.1:25224
local5.warning @127.0.0.1:25224
local6.warning @127.0.0.1:25224
local7.warning @127.0.0.1:25224
Esto básicamente significa que los mensajes de syslog (facility.priority) se envían al
agente de Azure Monitor.
En el panel inferior del recurso nuevo, hay una sección titulada

Introducción a Log Analytics:
Figura 11.10: Sección Introducción a Log Analytics en Azure Portal
Haga clic en Máquinas virtuales (VM) de Azure. Verá las VM disponibles en esta área
de trabajo:
Figura 11.11: VM disponibles en el área de trabajo
La captura de pantalla anterior representa las VM disponibles en el área de trabajo.

También muestra que nos conectamos al origen de datos.
Cómo obtener los datos

En la sección Configuración avanzada de este recurso, puede agregar orígenes de datos
de syslog y rendimiento. Puede acceder a todos los datos a través de la búsqueda de
registros mediante un lenguaje de consulta especial. Si nunca ha usado este lenguaje,
debe visitar https://docs.microsoft.com/es-xl/azure/azure-monitor/log-query/
get-started-queries?toc=%2Fazure%2Fazuremonitor%2Ftoc.json y https://docs.
loganalytics.io/index.
Por ahora, simplemente ejecute esta consulta:
search *
Para ver si hay datos disponibles, limite la búsqueda a una VM:

search * | where Computer == "centos01"
Como alternativa, para obtener todos los mensajes de syslog, como prueba, puede
reiniciar la VM o intentar esto:
logger -t <facility>. <priority> "message"
Ejecute la siguiente consulta en syslog para ver los resultados:

Syslog | sort
También hay muchos ejemplos disponibles si hace clic en el botón Búsquedas guardadas.
Las soluciones de supervisión proporcionan un complemento muy interesante para
simplificar aún más este proceso. En el panel Recurso, haga clic en Ver soluciones:
Figura 11.12: Navegación a la opción de soluciones de supervisión

Seleccione la opción deseada y haga clic en Agregar:
Figura 11.13: Soluciones de administración dentro de Log Analytics
Service Map es un servicio importante. Ofrece una excelente información general

de sus recursos y proporciona una interfaz fácil para los registros, los contadores de
rendimiento, etc. Después de instalar Service Map, tiene que instalar un agente en
la máquina Linux, o bien puede iniciar sesión en el portal e ir a la VM, lo que instalará
automáticamente el agente:
cd /tmp
wget --content-disposition https://aka.ms/dependencyagentlinux \

-O InstallDependencyAgent-Linux64.bin
sudo sh InstallDependencyAgent-Linux64.bin -s
Después de la instalación, seleccione Máquinas virtuales > Supervisión > Conclusiones

> Service Map.
Ahora haga clic en Resumen:
Figura 11.14: La sección Resumen de Service Map
Puede supervisar sus aplicaciones, ver los archivos de registro, etc.:
Figura 11.15: Información general de Service Map

Log Analytics y Kubernetes

Para administrar los contenedores, necesita información detallada del uso de la CPU, de
la memoria, del almacenamiento y la red, además de información sobre el rendimiento.
Azure Monitor se puede usar para ver registros, eventos y métricas de Kubernetes, lo
que permite la supervisión de contenedores desde una sola ubicación. Puede habilitar
Azure Monitor para contenedores para sus implementaciones de AKS nuevas o
existentes mediante la CLI de Azure, Azure PowerShell, Azure Portal o Terraform.
Para crear un clúster nuevo de AKS (Azure Kubernetes Service), use el comando
az aks create:
az aks create --resource-group MyKubernetes --name myAKS --node-count 1
--enable-addons monitoring --generate-ssh-keys
Para habilitar Azure Monitor para el clúster existente de AKS, use el comando az aks
con esta modificación:
az aks enable-addons -a monitoring -n myAKS -g MyKubernetes
Puede habilitar la supervisión del clúster de AKS en Azure Portal si selecciona

Supervisar y, luego, Contenedores. Aquí, seleccione los Clústeres no supervisados,
elija el contenedor y haga clic en Habilitar:
Figura 11.16: Supervisión del clúster de AKS desde Azure Portal

Log Analytics para la red

Otra solución en Azure Log Analytics es el Análisis de tráfico. Visualiza el tráfico de
red hacia y desde sus cargas de trabajo, incluidos los puertos abiertos. Es capaz de
generar alertas para las amenazas de seguridad, por ejemplo, si una aplicación intenta
llegar a una red a la que no se le permite acceder. Además, proporciona opciones de
supervisión detalladas con opciones de exportación de registros.
Si quiere usar el Análisis de tráfico, primero tiene que crear una instancia de Network
Watcher para cada región que quiere analizar:
New-AzNetworkWatcher -Name <name> '
-ResourceGroupName<resource group> -Location <location>
Después de eso, tendrá que volver a registrar el proveedor de red y agregar Microsoft
Insights para que Network Watcher pueda enlazarse:
Register-AzResourceProvider -ProviderNamespace '
"Microsoft.Network"
Register-AzResourceProvider -ProviderNamespaceMicrosoft.Insights
No puede usar esta solución con otros proveedores, como Microsoft.ClassicNetwork.

El siguiente paso implica usar el grupo de seguridad de red (NSG), que controla el
flujo del registro al permitir o denegar el tráfico entrante. En el momento de redactar
este libro, solo es posible con Azure Portal. En la barra de la izquierda de Azure Portal,
seleccione Supervisar>Network Watcher y, luego, Registros de flujo de NSG. Ahora
puede seleccionar el NSG para el que quiere habilitar un registro de flujo de NSG.
Habilítelo, seleccione una cuenta de almacenamiento y seleccione su área de trabajo de
Log Analytics.
Supervisión del rendimiento | 441
Tomará un tiempo antes de que la información entre y se recopile. Después de unos

30 minutos, la primera información debería ser visible. Seleccione Supervisar en la
barra de la izquierda de Azure Portal, vaya a Network Watcher y, luego, Análisis de
tráfico. También puede empezar en el área de trabajo de Log Analytics:
Figura 11.17: Visualización de la distribución del flujo de tráfico de la red con Análisis de tráfico
Supervisión del rendimiento

En Azure Monitor, hay muchas opciones disponibles para la supervisión. Por ejemplo,
los contadores de rendimiento le ofrecen una gran cantidad de información sobre su
carga de trabajo. También hay opciones específicas de la aplicación.
Aunque no use Azure Monitor, Azure puede proporciona todo tipo de métricas para
cada VM, pero no en una ubicación central. Simplemente vaya a su VM. En el panel
Información general, puede ver los datos de rendimiento de la CPU, la memoria y el
almacenamiento. La información detallada está disponible en la sección Métricas,
en Supervisión. Todos los tipos de datos están disponibles, como los datos de CPU,
almacenamiento y red:
Figura 11.18: Visualización de los datos de rendimiento de la VM

El problema con muchas de estas soluciones es que son específicas de la aplicación

o que está mirando el resultado final sin saber cuál es la causa. Si necesita información
sobre el rendimiento general de los recursos utilizados por las máquinas virtuales,
use la información que proporciona Azure. Si necesita información sobre el servidor
web o la base de datos que ejecuta, busque y vea si hay una solución de Azure. Sin
embargo, en muchos escenarios, es muy útil si también puede solucionar problemas
de rendimiento en la VM. En cierto modo, vamos a empezar donde terminó la sección
Administración de proceso del Capítulo 3, Administración básica de Linux.
Antes de empezar, hay varios métodos y formas de solucionar los problemas de
rendimiento. ¿Este libro puede proporcionar el único método que debe usar o indicarle
cuál es la única herramienta que necesitará? No, lamentablemente, no. Pero lo que sí
puede hacer es mostrarle las herramientas que están disponibles y describir al menos su
uso básico. Para necesidades más específicas, siempre puede profundizar en las páginas
man. En esta sección investigamos especialmente qué es la carga y qué es lo que la causa.
Y un último alcance: esta sección se llama Supervisión del rendimiento, pero quizás no
sea el título perfecto. Equilibra la supervisión, la solución de problemas y el análisis.
Sin embargo, ¿no es lo que pasa en la vida diaria de cada ingeniero de sistemas?
No todas las herramientas mencionadas están disponibles de forma predeterminada
en el repositorio de Red Hat/CentOS. Tendrá que configurar el repositorio epel: yum
install epel-release.
Visualización de procesos de Linux con top

Si investiga un tema, como la supervisión del rendimiento y Linux, verá que siempre se
menciona top. Es el primer comando que se usa para obtener rápidamente una idea de
lo que se ejecuta en un sistema.
Con top, puede mostrar mucha información e incluye una excelente página man, donde
se explican todas las opciones. Centrémonos en las más importantes, comenzando en la
parte superior de la pantalla:
Figura 11.19: Visualización del uso de los recursos con el comando top
Echemos un vistazo a las opciones mencionadas en la captura de pantalla anterior:

• Wait IO (wa): si este valor suele estar sobre 10 %, significa que el almacenamiento
subyacente ralentiza el servidor. Este parámetro muestra el tiempo de espera
de CPU para los procesos de I/O. Las VM de Azure utilizan discos HDD en lugar
de SSD y usar varios HDD en una configuración de RAID puede resultar útil,
pero es mejor migrar a SSD. Si eso no es suficiente, también hay soluciones SSD
premium disponibles.
• Userspace CPU (us): el uso de CPU por parte de las aplicaciones. Tenga en cuenta
que el uso de CPU se suma entre todas las CPU.
• System CPU (sy): el tiempo que la CPU dedica a las tareas del kernel.
• Swap: paginación de la memoria debido a la memoria insuficiente para las
aplicaciones. La mayor parte del tiempo debería ser cero.
En la parte inferior de la pantalla top también hay algunas columnas interesantes:
Figura 11.20: Las entradas inferiores de la salida obtenidas del comando top
Personalmente, no le aconsejamos preocuparse por la prioridad ni los valores deseados

por ahora. El efecto en el rendimiento es mínimo. El primer campo interesante es
VIRT (memoria virtual). Hace referencia a la cantidad de memoria a la que el programa
puede acceder en la actualidad. Incluye la memoria compartida con otras aplicaciones,
la memoria de video, los archivos que la aplicación lee en la memoria, etc. También
incluye la memoria inactiva, memoria intercambiada y memoria residencial. La memoria
residencial es una memoria que este proceso usa en términos físicos. SHR es la cantidad
de memoria que se comparte entre las aplicaciones. Esta información puede darle una
idea de la cantidad de swap que debe configurar en el sistema: tome los cinco procesos
principales, sume VIRT y reste RES y SHR. No es perfecto, pero es un buen indicador.
La columna S en la captura de pantalla anterior es el estado de la máquina:

• D es una suspensión sin interrupción, la mayoría de las veces causada por esperar
de almacenamiento o I/O de red.
• R significa que está en ejecución, es decir, consumiendo CPU.
• S significa que está en suspensión: espera en I/O, sin uso de CPU. En espera de un
desencadenador por parte de un usuario o de otro proceso.
• T significa que la detiene la señal de control del trabajo, la mayoría de las veces
porque el usuario presiona Ctrl + Z.
• Z indica que es “zombie”: el proceso principal terminó. La etiqueta de “zombie” la
asigna el kernel mientras está ocupado realizando una limpieza. En las máquinas
físicas, también puede ser una indicación de CPU con errores (producto de la
temperatura o BIOS deficiente); en ese escenario, es posible que vea muchos
“zombies”. En Azure, esto no sucederá. Los “zombies” no hacen daño, así es que
no es necesario exterminarlos; el kernel se preocupa de ellos.
Alternativas para top

Hay muchas utilidades similares a top, como htop, que se ve más sofisticado y es más
sencillo de configurar.
Muy similar pero incluso más interesante es atop. Contiene todos los procesos y el
uso de los recursos, incluso los procesos que se extinguieron entre las actualizaciones
de pantalla de atop. Esta contabilización integral resulta muy útil para entender los
problemas con los procesos individuales de corta duración. atop también puede
recopilar información sobre la ejecución de contenedores, redes y almacenamiento.
Otra alternativa es nmon, que es similar a atop, pero se centra más en las estadísticas
y brinda información más detallada, especialmente con respecto a la memoria
y el almacenamiento:
Figura 11.21: Detalles de rendimiento de memoria, CPU y almacenamiento
nmon también se puede usar para recopilar datos:

nmon -f -s 60 -c 30
El comando anterior recopila 30 rondas de información cada minuto en un formato de

archivo separado por comas que es fácil de analizar en una hoja de cálculo. En el sitio
web para desarrolladores de IBM, http://nmon.sourceforge.net/pmwiki.php?n=Site.
Nmon-Analyser, puede encontrar una hoja de cálculo de Excel con la que este trabajo
es muy fácil de hacer. Incluso ofrece algunas opciones adicionales de análisis de datos.
glances también está teniendo gran popularidad últimamente. Se basa en Python

y proporciona información actualidad sobre el sistema, el tiempo de actividad, la CPU,
la memoria, el intercambio, la red y el almacenamiento (archivo e I/O de disco):
Figura 11.22: Uso de la utilidad glances para ver el rendimiento
glances es la alternativa más avanzada a top. Ofrece todas las características de las
alternativas y, además de eso, la puede usar de forma remota. Necesita proporcionar
el nombre de usuario y la contraseña del servidor para iniciar glances:
glances --username <username> --password <password> --server
Ejecute también lo siguiente en el cliente:

glances --client @<ip address>
De manera predeterminada, se usa el puerto 61209. Si usa el parámetro –webserver

en vez de --server, ni siquiera necesita un cliente. Hay disponible una interfaz web
completa en el puerto 61208.
glances es capaz de exportar registros en muchos formatos y se puede consultar
mediante una API. También está en camino la compatibilidad experimental con el
protocolo SNMP (Protocolo simple de administración de redes).
Sysstat: una colección de herramientas para la supervisión del rendimiento

El paquete sysstat contiene utilidades para la supervisión del rendimiento. Las más
importantes en Azure son sar, iostat y pidstat. Si también usa Azure Files, cifsiostat
puede igualmente resultarle muy útil.
sar es la utilidad principal. La sintaxis principal es la siguiente:
sar -<resource> interval count
Por ejemplo, use este comando para notificar las estadísticas de CPU cinco veces con
un intervalo de un segundo:
sar -u 1 5
Para supervisar los núcleos 1 y 2, use esto:

sar -P 1 2 1 5
(Si quiere supervisar individualmente todos los núcleos, puede usar la palabra clave ALL).
Estos son otros recursos importantes:
• -r: memoria
• -S: intercambio
• -d: disco
• -n <type>: tipos de red, como estos:
DEV: muestra las estadísticas de los dispositivos de red
EDEV: muestra las estadísticas de errores de los dispositivos de red
NFS: muestra las actividades del cliente NFS (Network File System)
SOCK: muestra los sockets que se usan para IPv4
IP: muestra el tráfico de red IPv4
TCP: muestra el tráfico de red TCPv4
UDP: muestra el tráfico de red UDPv4
ALL: muestra toda la información anterior
pidstat puede recopilar datos de CPU desde un proceso específico con su ID de

proceso. En la siguiente captura de pantalla, puede ver que se muestran dos ejemplos
cada cinco segundos. pidstat puede hacer lo mismo para la memoria y el disco:
Figura 11.23: Visualización de las estadísticas de CPU con pidstat
iostat es una utilidad, como el nombre lo indica, que puede medir I/O, pero que
también crea informes para el uso de CPU:
Figura 11.24: Obtención de estadísticas e informes de CPU y dispositivo con iostat

tps se refiere al número de transferencias por segundo emitidas al servicio. kb_read/s

y kB_wrtn/s son los números de kilobytes medidos durante un segundo; la columna
avg-cpu de la captura de pantalla anterior es el número total de estadísticas desde el
momento en que se inicia el sistema Linux.
Durante la instalación del paquete sysstat, se instaló un trabajo cron en el archivo
/etc/cron.d/sysstat.
Nota
En los sistemas Linux modernos, tanto systemd-timers como el método anterior
con cron están disponibles. sysstat todavía usa cron. Para comprobar si cron
está disponible y en ejecución, vaya a systemctl | grep cron.
cron ejecuta el comando sa1 cada 10 minutos. Recopila la actividad del sistema y la
almacena en una base de datos binaria. Una vez al día, el comando sa2 se ejecuta
para generar un informe. Los datos se almacenan en el directorio /var/log/sa.
Puede consultar esa base de datos con sadf:
Figura 11.25: Consulta de la base de datos con sadf para ver la actividad del sistema
Esta captura de pantalla muestra los datos del 6 de noviembre, entre las 09:00:00 y las
10:10:00. De manera predeterminada, muestra estadísticas de CPU, pero se puede
personalizar con los mismos parámetros que sar:
sadf /var/log/sa/sa03 -- -n DEV
Esto muestra las estadísticas de red de cada interfaz de red del 6 de noviembre.
dstat
sysstat está disponible para los informes históricos, mientras que dstat se usa para los
informes en tiempo real. Si bien top es la versión supervisada de ps, es dstat la versión
de supervisión de sar:
Figura 11.26: Obtención de informes en tiempo real con dstat
Si no quiere verlo todo de una vez, puede usar estos parámetros:

• c: CPU
• d: disco
• n: red
• g: paginación
• s: intercambio
• m: memoria
Estadísticas de red con iproute2

Anteriormente en este capítulo hablamos de ip. Este comando también proporciona
una opción para obtener las estadísticas de la interfaz de red:
ip -s link show dev eth0
Figura 11.27: Obtención de las estadísticas de la interfaz de red
Analiza la información del directorio /proc/net. Otra utilidad que puede analizar esta
información es ss. Puede solicitar un resumen sencillo con esto:
ss -s
Usar el parámetro -t no solo muestra los puertos con un estado de escucha, sino
también el tráfico entrante y saliente en esta interfaz específica.
Si necesita más detalles, el paquete iproute2 proporciona otra utilidad: nstat. Con el
parámetro –d, incluso se puede ejecutar en modo de intervalo:
Figura 11.28: Obtención de un informe detallado sobre los puertos con un estado de escucha
Esto ya es mucho más que un resumen sencillo de ss. Sin embargo, el paquete iproute2
tiene más para ofrecer: lnstat.
Este es el comando que proporciona estadísticas de red, como el enrutamiento de
estadísticas de caché:
lnstat––d
Figura 11.29: Obtención de las estadísticas de red con Instat -d
Esto le muestra todo lo que puede mostrar o supervisar. Es de nivel muy bajo, pero
solucionamos algunos problemas relacionados con el rendimiento del firewall con
lnstat -f/proc/net/stat/nf_conntrack, a la vez que supervisamos el contador drops.
Supervisión de redes con IPTraf-NG

Puede obtener detalles de red a partir de herramientas como nmon, pero si quiere
obtener más detalles, IPTraf-NG es una muy buena herramienta para una solución de
supervisión de red basada en consola en tiempo real. Es una utilidad de supervisión de
red basada en consola que recopila todos los datos de dirección IP, TCP, UDP e ICMP de
la red y es capaz de desglosar la información de acuerdo con el tamaño de TCP/UDP.
También se incluyen algunos filtros básicos.
Todo está en una interfaz basada en menús, por lo que no hay parámetros que tenga
que recordar:
Figura 11.30: Ventana de menú de IPTraf-NG
tcpdump
Por supuesto, tcpdump no es una solución de supervisión de rendimiento. Esta utilidad
es una excelente herramienta para supervisar, capturar y analizar el tráfico de red.
Para ver el tráfico de red en todas las interfaces de red, ejecute lo siguiente:
tcpdump -i any
Para una interfaz específica, intente esto:

tcpdump -i eth0
En general, se recomienda no resolver los nombres de host:

tcpdump -n -i eth0
Para agregar distintos niveles de detalle, repita el parámetro v hasta un nivel de detalle
máximo de tres:
tcpdump -n -i eth0 -vvv
Puede filtrar el tráfico en función del host:

tcpdump host <ip address> -n -i eth0
Como alternativa, puede filtrar en función de la dirección IP de origen o de destino:

tcpdump src <source ip address> -n -i eth0
tcpdump dst <destination ip address> -n -i eth0
También es posible filtrar según un puerto específico:

tcpdump port 22
tcpdumpsrc port 22
tcpdump not port 22

Todos los parámetros se pueden combinar:
tcpdump -n dst net <subnet> and not port ssh -c 5
Se agregó el parámetro –c, así es que solo se capturaron cinco paquetes. Puede guardar
los datos capturados en un archivo:
tcpdump -v -x -XX -w /tmp/capture.log
Se agregaron dos parámetros para aumentar la compatibilidad con otros analizadores

que pueden leer el formato de tcpdump:
• -XX: imprime los datos de cada paquete en formato hexadecimal y ASCII
• -x: agrega encabezados a cada paquete
Para leer los datos con una marca de tiempo completa en formato legible para las
personas, use este comando:
tcpdump -tttt -r /tmp/capture.log
Nota
Otro gran analizador de red es Wireshark. Es una herramienta gráfica que está
disponible para muchos sistemas operativos. Este analizador puede importar los
datos capturados de tcpdump. Incluye un gran filtro de búsqueda y herramientas
de análisis para muchos protocolos y servicios de red diferentes.
Tiene sentido hacer la captura en su VM y descargarla a su estación de trabajo con

el fin de analizar aún más los datos en Wireshark.
Estamos seguros de que ahora podrá lograr un buen análisis de rendimiento en un

sistema Linux con diferentes herramientas para supervisar métricas como la CPU,
la memoria, el almacenamiento y los detalles de la red.
Resumen
En este capítulo, analizamos varios temas relacionados con la solución de problemas, el
registro, la supervisión e incluso el análisis. A partir de la obtención de acceso a una VM,
investigamos el registro en Linux tanto de manera local como remota.
Hay una delgada línea entre la supervisión del rendimiento y la solución de problemas
de rendimiento. Hay muchísimas utilidades diferentes disponibles para descubrir la
causa de sus problemas de rendimiento. Cada uno tiene un objetivo diferente, pero
también hay una gran superposición. Hemos hablado de las utilidades más populares
en Linux y algunas de las opciones disponibles.
En el primer capítulo, vimos que Azure es un entorno muy apto para open source,
y que Microsoft se ha esforzado mucho por hacer que Azure sea una solución de nube
abierta y estándar que tiene en cuenta la interoperabilidad. En este capítulo, vimos que
Microsoft no solo ha hecho un gran esfuerzo por admitir a Linux mientras implementa
su aplicación, sino también en Azure Monitor.
Preguntas
1. ¿Por qué debe tener al menos un usuario con una contraseña en una VM?
2. ¿Cuál es el propósito de este demonio de systemd-journald?
3. ¿Qué son las estructuras de syslog?
4. ¿Qué prioridades hay disponibles en syslog?
5. ¿Cómo puede agregar entradas a un registro y por qué hacerlo?
6. ¿Qué servicios hay disponibles para ver las métricas en Azure?
7. ¿Por qué top solo es útil para echar un primer vistazo a los problemas relacionados
con el rendimiento? ¿Qué utilidad o utilidades pueden corregir eso?
8. ¿Cuál es la diferencia entre las utilidades sysstat y dstat?
9. ¿Por qué debe instalar Wireshark en su estación de trabajo?
Lectura adicional
Una excelente fuente de información es el sitio web de Brendan D Gregg
(http://www.brendangregg.com), donde comparte una lista increíblemente larga
de documentación, diapositivas, videos y más sobre el rendimiento de Linux. Además,
hay otras utilidades muy buenas. Él fue quien me enseñó, en 2015, que es importante
identificar correctamente un problema:
• ¿Qué le hace pensar que hay un problema?
• ¿Hubo alguna vez en que no hubo problemas?
• ¿Ha cambiado algo recientemente?
• Intente buscar descripciones técnicas, como latencia, errores en tiempo de
ejecución, etc.
• ¿Es solo la aplicación o también afecta a otros recursos?
• Proporcione una descripción exacta del entorno.
También debe tener en cuenta lo siguiente:

• ¿Qué causa la carga (qué proceso, dirección IP, etc.)?
• ¿Por qué se llamó a la carga?
• ¿Qué recursos usa la carga?
• ¿La carga cambia? Si es así, ¿cómo cambia con el tiempo?
Por último, pero no menos importante, está la Red Hat Enterprise Linux Troubleshooting
Guide (Guía para la solución de problemas de Red Hat Enterprise Linux), de Benjamin
Cane. Sé que algunas partes del libro están obsoletas, ya que se imprimió en 2015 y, sin
duda, espero una segunda edición, pero, sobre todo si es su primera vez en Linux, le
recomiendo comprar este libro.
12 Apéndice
En este capítulo se presenta un conjunto de soluciones para todas las preguntas que se
hicieron en los capítulos anteriores. Si ya respondió estas preguntas, puede comprobar
la exactitud de sus respuestas. Si no pudo encontrar una solución en ese momento,
puede consultar las respuestas que se dan aquí para los capítulos respectivos.
Capítulo 1: Exploración de la nube de Microsoft Azure

1. Puede virtualizar los recursos informáticos, de red y de almacenamiento.
Por supuesto, al final del día, de todos modos necesitará hardware en algún lugar
del mundo para ejecutar los hipervisores y, posiblemente, una plataforma de
nube además.
2. La virtualización emula el hardware y los contenedores emulan un sistema operativo
en el que varios contenedores se ejecutan en un sistema operativo subyacente.
En la virtualización, cada máquina virtual tiene su propio kernel; no usan el kernel
del hipervisor/hardware. En la virtualización de hardware, todo se transforma en
software. En la virtualización de contenedores, solo los procesos están aislados.
460 | Apéndice
3. Depende; ¿desarrolla la aplicación en la misma plataforma? Si es así, PaaS es el tipo

de servicio para usted; de lo contrario, use IaaS. SaaS proporciona una aplicación;
no es una plataforma de hospedaje.
4. Depende. Azure cumple y lo ayuda a cumplir con las normas legales y las directivas
de seguridad/privacidad. Además, existe el concepto de diferentes regiones si
hay alguna preocupación con respecto a tener datos en otras partes del mundo.
Sin embargo, siempre hay excepciones: la mayoría de las veces, las directivas de
la empresa o las normas gubernamentales.
5. Es muy importante para la escalabilidad, el rendimiento y la redundancia.
6. Es un servicio de administración de identidades basado en la nube para controlar
el acceso a la nube y al entorno híbrido local. Le permite iniciar sesión y acceder
a entornos locales y en la nube en lugar de usar sus propios servidores de AD
y administrarlos.
Capítulo 2: Introducción a la nube de Azure

1. Ayuda con la automatización. Además, el portal basado en la Web cambia con
frecuencia y la interfaz de línea de comandos es mucho más estable. En nuestra
opinión, también le ofrece una mejor comprensión de la tecnología subyacente,
gracias a su flujo de trabajo más o menos estricto.
2. Proporciona acceso para almacenar todos sus objetos de datos. Necesitará uno
para los diagnósticos de arranque y los datos de Azure Cloud Shell. Puede obtener
más detalles en el Capítulo 4, Administración de Azure.
3. La cuenta de almacenamiento debe ser globalmente exclusiva en Azure.
4. Una oferta es un grupo de imágenes relacionadas que ofrece un publicador, como
Ubuntu Server. Una imagen es una imagen específica.
5. Una máquina virtual de Azure detenida conserva los recursos asignados, como las
direcciones IP públicas dinámicas, e incurre en costos, mientras que una máquina
virtual desasignada libera todos los recursos para que deje de incurrir en costos
de recursos. Sin embargo, ambos incurren en costos de almacenamiento.
6. La autenticación basada en claves ayuda en la automatización, ya que se puede
usar sin exponer secretos/contraseñas en sus scripts.
7. Se creará una clave pública y una privada (si aún son necesarias) y se almacenarán
en el directorio principal (~/.ssh); la clave pública se agregará al archivo
authorized_keys en la máquina virtual.
Capítulo 3: Administración básica de Linux | 461
Capítulo 3: Administración básica de Linux

1. for user in Lisa John Karel Carola; useradd $user; done.
2. Ejecute passwd <user> y escriba welc0meITG y le pedirá escribir nuevamente la
contraseña para confirmar, así es que vuelva a escribir welc0meITG.
3. getent<user>.
4. groupadd finance; groupadd staff.
5. groupmems -g <group_name> -a <user_name>; y, como alternativa, usermod –a –G
<group_name> <user_name>.
6. Para crear el directorio y establecer la propiedad del grupo, ejecute lo siguiente:
mkdir /home/staff
chown staff /home/staff
chgrp staff /home/staff
Del mismo modo, para finance, ejecute estos comandos:
mkdir /home/finance
chown finance /home/finance
chgrp finance /home/finance
7. chmod –R g+r /home/finance.
8. La lista de control de acceso get predeterminada (getfacl -d) mostrará la ACL de
un usuario.
Capítulo 4: Administración de cargas de trabajo de Azure

1. No necesita nada cuando crea una máquina virtual mediante Azure Portal. Cuando
usa la línea de comandos, necesita redes virtuales con lo siguiente:
Un grupo de recursos
Azure Virtual Network (red virtual)
Una subred configurada
Un grupo de seguridad de red
Una dirección IP pública
Una interfaz de red
2. Necesita servicios de nombre, como Diagnósticos y Supervisión, que requieren
una cuenta de almacenamiento.
462 | Apéndice
3. A veces (por ejemplo, para una cuenta de almacenamiento), el nombre debe ser
exclusivo. Un prefijo combinado con un número generado aleatoriamente es una
buena manera de hacer que el nombre sea reconocible y único.
4. Para definir el intervalo IP que se puede usar dentro de una red virtual.
5. Para crear una o más subredes dentro de la red virtual que se pueden aislar
o enrutar entre sí, sin salir de la red virtual.
6. Un grupo de seguridad de red proporciona listas de control de acceso para la red
y proporciona enrutamiento de puertos a las máquinas virtuales o los contenedores.
7. El tráfico de la máquina virtual a Internet se envía a través de Traducción de
direcciones de red de origen (SNAT). Esto significa que la dirección IP del paquete
de origen se reemplaza por la dirección IP pública, que se necesita para TCP/IP
para el enrutamiento de salida y de entrada.
8. Se lanzará una dirección IP pública asignada dinámicamente cuando se desasigne
la máquina virtual. Cuando la máquina virtual vuelva a iniciarse, obtendrá otra
dirección IP. Puede crear y asignar una dirección IP pública estática cuando sea
obligatorio mantener la misma dirección IP incluso después de que cambie la
dirección IP del servicio.
Capítulo 5: Administración avanzada de Linux

1. El kernel de Linux.
2. systemd-udevd.
3. ls /sys/class/net e ip link show.
4. El agente de Azure para Linux.
5. ls /sys/class/net y lsblk. El comando lsscsi también puede ser útil.
6. Es buena idea usar RAID 0 para mejorar el rendimiento y permitir un mejor
desempeño en comparación con el uso de un disco único.
7. En el nivel de sistema de archivos, con el sistema de archivos de árbol en B
(BTRFS) o el sistema de archivos Z (ZFS), o bien, en el nivel de bloque, con Linux
Software RAID (mdadm) o Administrador de discos lógicos (LVM) (del que no se
habla en este capítulo).
8. Cree el RAID, dele formato y cree un punto de montaje:
mdadm --create /dev/md127 --level 0 --raid-devices 3 \
/dev/sd{c,d,e}
mkfs.xfs -L myraid /dev/md127
mkdir /mnt/myraid
Capítulo 6: Administración de seguridad e identidades de Linux | 463
Cree un archivo de unidad, /etc/systemd/system/mnt-myraid.mount:

[Unit]
Description = myRaid volume
[Mount]
Where = /mnt/myraid
What = /dev/md127
Type = xfs
[Install]
WantedBy = local-fs.mount
Inicie y habilítelo en el arranque:
systemctl enable --now mnt-myraid.mount
Capítulo 6: Administración de seguridad e identidades de Linux

1. Con el archivo firewall-cmd o mediante la implementación de los archivos
Extensible Markup Language (XML) en el directorio /etc/firewalld.
2. El parámetro --permanent hace que sea persistente entre los reinicios y que se
ejecute durante la configuración de inicio.
3. En Linux, puede restringir el acceso con las listas de control de acceso en systemd.
Algunas aplicaciones también proporcionan otras opciones para autorizar o denegar
un host. En Azure, tiene los grupos de seguridad de red y el servicio Azure Firewall.
4. El control de acceso discrecional (DAC) se usa para restringir el acceso en función
de los usuarios o grupos y de los permisos en los archivos. El control de acceso
(MAC) restringe aún más el acceso en función de las etiquetas de clasificación de
cada objeto de recurso.
5. Si alguien obtuvo acceso de manera ilegal a una aplicación o sistema, con DAC no
hay manera de evitar un mayor acceso, en especial para los archivos con el mismo
propietario de grupo o usuario y archivos con permisos para otros.
6. Cada dispositivo tendrá una dirección MAC única y podrá buscar la dirección MAC de
su máquina virtual con ipconfig/ all y, a continuación, buscar la dirección física.
Los marcos de MAC que usan módulos de seguridad de Linux son los siguientes:
SELinux: distribuciones basadas en Red Hat y SUSE
AppArmor: Ubuntu y SUSE
El menos conocido TOMOYO (SUSE), del que no se habla en este libro
464 | Apéndice
7. Además del hecho de que SELinux puede proteger más objetos de recursos,
AppArmor trabaja directamente con las rutas de acceso, mientras que SELinux
protege todo el sistema con un control de acceso pormenorizado.
8. Necesita los siguientes requisitos previos antes de unirse a un dominio de AD:
Un cliente Kerberos para la autorización
Demonio de servicios de seguridad del sistema (SSSD): un back-end que es
responsable de la configuración y utilización de características como el uso
y el almacenamiento en caché de credenciales
Bibliotecas de Samba para admitir las opciones o características de Windows
Algunas utilidades para unirse al dominio y administrarlo, como realm, adcli
y el comando net
Capítulo 7: Implementación de sus máquinas virtuales

1. Usamos la implementación automatizada para ahorrar tiempo, para que un entorno
reproducible se ponga en marcha rápidamente y para evitar errores manuales.
2. Además de la respuesta a la pregunta anterior, un entorno de trabajo
estandarizado hace posible desarrollar aplicaciones basadas en equipos.
3. La creación de scripts es muy flexible. Los scripts son más fáciles de crear
y se pueden invocar manualmente en cualquier momento. El proceso de
automatización lo pueden desencadenar eventos como agregar código a Git
mediante git push o la detención o inicio de las máquinas virtuales.
4. Azure Resource Manager es la más importante. Además, puede usar Terraform,
Ansible y PowerShell.
5. Vagrant implementa una carga de trabajo en Azure; Packer crea una imagen
personalizada que puede implementar.
6. Por varias razones, las más importantes son las siguientes:
Seguridad, para proteger la imagen con los estándares de CIS
Cuando se necesita personalización para una imagen estándar
No depende de las ofertas de un tercero
Capturar una máquina virtual existente
Convertir una instantánea en una imagen
Capítulo 8: Exploración de la automatización de la configuración continua | 465
7. Puede crear su propia imagen mediante la creación de su propio archivo VHD.

Estas son las opciones para hacerlo:
Cree una máquina virtual en Hyper-V o en VirtualBox, que es un hipervisor
gratuito disponible para Windows, Linux y macOS.
Cree su máquina virtual en VMware Workstation o KVM, y úsela en Linux
qemu-img para convertir la imagen.
Capítulo 8: Exploración de la automatización de la configuración

continua
Los scripts de ejemplo están disponibles en GitHub en https://github.com/
PacktPublishing/Hands-On-Linux-Administration-on-Azure---Second-Edition/tree/
master/chapter12/solutions_chapter08.
Capítulo 9: Virtualización de contenedores en Azure

1. Puede usar contenedores para empaquetar y distribuir sus aplicaciones, que
pueden ser independientes de la plataforma. Los contenedores eliminan la
necesidad de la administración del sistema operativo y la máquina virtual
y lo ayudan a lograr alta disponibilidad y escalabilidad.
2. Los contenedores no son adecuados si tiene una gran aplicación monolítica que
requiere todos los recursos de las máquinas virtuales subyacentes.
3. Los contenedores Linux (LXC) son una solución óptima que se puede aprovisionar
en Azure.
4. Las herramientas como Buildah hacen que sea posible crear máquinas virtuales
que se pueden usar en cada solución. Rkt (que se pronuncia “rocket”) también
admite el formato Docker. Open Container Initiative trabaja arduamente para
crear estándares que facilitan aún más la creación de máquinas virtuales.
5. Puede desarrollar todo en Azure o puede desarrollarlo localmente y luego
insertarlo en un entorno remoto.
6. Es independiente de la plataforma de contenedores y la herramienta
Buildah es más fácil de usar que otras herramientas. Puede explorar más
en https://github.com/containers/buildah.
7. Los contenedores se pueden construir, reemplazar, detener y destruir a petición
sin ningún impacto sobre la aplicación o los datos, por lo que no se recomienda
almacenar ningún dato en el contenedor. En lugar de eso, almacénelos en
un volumen.
466 | Apéndice
Capítulo 10: Cómo trabajar con Azure Kubernetes Service

1. Un pod es un grupo de contenedores con recursos compartidos, como recursos de
almacenamiento y red, así como también una especificación de cómo ejecutar los
contenedores.
2. Una buena razón para crear un pod de varios contenedores es admitir procesos
auxiliares coubicados y coadministrados para la aplicación principal.
3. Hay varios métodos disponibles, incluidos Draft y Helm, que se describieron en el
capítulo además de Azure Kubernetes Service (AKS).
4. Puede usar kubectl para actualizar su aplicación en AKS. Además, también puede
usar Helm y Draft.
5. No es necesario que lo haga usted mismo de manera manual; los AKS lo harán
automáticamente.
6. Necesitará una solución iSCSI y un sistema de archivos en clúster cuando quiera
leer y escribir simultáneamente desde varios contenedores.
7. El código de ejemplo se proporciona en GitHub en https://github.com/
MicrosoftDocs/azure-docs/blob/master/articles/aks/azure-disks-dynamic-pv.md.
Capítulo 11: Solución de problemas y supervisión de sus cargas

de trabajo
1. Puede acceder a su máquina virtual con la consola serie de Azure como raíz sin
contraseña, a menos que se bloquee de manera específica.
2. Para recopilar toda la salida estándar, los mensajes de syslog y los mensajes
relacionados del kernel, los procesos de systemd y las unidades.
3. syslog usa la siguiente lista de gravedades (por aplicación):
Alert: la acción se debe tomar de inmediato.
Critical: condiciones críticas.
Error: condiciones de error.
Warning: condiciones de advertencia.
Notice: condiciones normales, pero significativas.
Informational: mensajes informativos.
Debug: mensajes en el nivel de depuración.
Capítulo 11: Solución de problemas y supervisión de sus cargas de trabajo | 467
4. 0-Emergency, 1-Alert, 2-Critical, 3-Error, 4-Warning, 5-Notice, 6-Informational,

7-Debug.
5. Use logger o systemd-cat. Puede usarlo si una aplicación o un script no
admite syslog. Otra opción es agregar entradas de registro como parte de la
administración de cambios.
6. El servicio Azure Log Analytics se usa para ver las métricas de una máquina virtual.
7. La utilidad top tiene varias deficiencias; por ejemplo, no puede ver los procesos de
corta duración. Las utilidades atop y dstat son las soluciones para este problema.
8. La utilidad sysstat proporciona los datos históricos, mientras que dstat
proporciona supervisión en tiempo real.
9. Hace que la colección de datos que provienen de tcpdump de la máquina virtual de
Azure (estación de trabajo) sea más fácil de leer y tiene un gran potencial de análisis.

Admin Prac Linux Azure v2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Admin Prac Linux Azure v2

Cargado por

Copyright:

Formatos disponibles

Descargue

Kamesh Ganesan, Rithin Skaria y Frederik Vos

Capítulo 1: Exploración de la nube de Microsoft Azure 1

Conceptos básicos de la informática en la nube ................................................ 2

Capítulo 2: Introducción a la nube de Azure 15

Requisitos técnicos ............................................................................................... 16

Capítulo 3: Administración básica de Linux 47

El shell de Linux ..................................................................................................... 48

Administración de recursos de Azure con la CLI de Azure y PowerShell ....... 98

Requisitos técnicos ............................................................................................. 132

Capítulo 6: Administración de seguridad e identidades de Linux 183

Sugerencias de seguridad para Linux .............................................................. 184

Escenarios de implementación ......................................................................... 234

Capítulo 9: Virtualización de contenedores en Azure 325

Introducción a la tecnología de contenedores ............................................... 326

Capítulo 10: Cómo trabajar con Azure Kubernetes Service 371

Requisitos técnicos ............................................................................................. 373

Requisitos técnicos ............................................................................................. 418

Capítulo 12: Apéndice 459

Acerca de Administración práctica de Linux en Azure:

Acerca de los autores

Recursos para descargar

Después de eso, explicaremos la distinta terminología que se usa en la tecnología de nube.

Conceptos básicos de la informática en la nube

Demos un vistazo a cada uno de estos conceptos y comprendamos a qué se refieren.

Este tipo de virtualización propició una revolución en los centros de datos:

Con SDN, tiene ventajas similares a las de la virtualización de informática:

En 2009, se inició el desarrollo del almacenamiento definido por software (SDS) en

Seleccionar una de estas implementaciones en la nube depende de varios factores.

Definición de la nube de Microsoft Azure

Una breve historia de la nube de Microsoft Azure

En 2008, Microsoft anunció el inicio de Azure, y con su lanzamiento público en 2010,

Figura 1.1: Arquitectura de Azure

Azure y Open Source

En 2016, Microsoft ingresó a la organización Linux Foundation como un miembro

En el primer capítulo, abordamos la historia de la virtualización y la informática en la

En función de la experiencia personal, recomendamos usar Google Chrome o un

Cómo obtener acceso a Azure

Inicio de sesión con Azure Portal

Cómo obtener acceso de línea de comandos a Azure

En este libro, utilizaremos la CLI de Azure en el shell de Bash y PowerShell con el

Instalación de la CLI de Azure

Inicio de sesión con la CLI de Azure

Figura 2.1: Detalles de la suscripción en formato JSONC

Se recomienda usar valores separados por tabulaciones (TSV) si la salida es un valor

Figura 2.2: Detalles de la suscripción separados por tabulaciones

Figura 2.3: Detalles de la suscripción en formato tabular

A fin de facilitar la lectura de la salida JSON, también puede consultar campos

Puede proporcionar un nombre para la aplicación, pero no se permiten algunos

De forma predeterminada, se utiliza el rol de colaborador. Este rol tiene permisos

Lamentablemente, no hay una forma de almacenar el nombre de usuario, appID o tenant

Después de la instalación de PowerShell, está listo para instalar el módulo Az. La

PowerShell utiliza el cmdlet PowerShellGet para descargar el módulo y sus dependencias

Responda la pregunta de la lista con [A] Yes to All.

De forma predeterminada, se utilizará la versión más reciente, a menos que use el

Inicio de sesión con PowerShell

Si no crea un script de PowerShell y solo ejecuta comandos dentro del entorno

En primer lugar, averigüe dónde está su perfil de PowerShell en el sistema de archivos.

Abra o cree este archivo en un editor de texto y agregue la siguiente línea:

Ahora puede ejecutar todos los comandos disponibles para Azure.

Ahora, vuelva a iniciar sesión con el ID de inquilino que encontró:

Si tiene varias suscripciones, también puede agregar el parámetro -Subscription y el

Si no menciona DisplayName, que es el nombre descriptivo de la entidad de servicio,

La contraseña se puede almacenar en una variable, que se cifrará y debemos descifrarla:

Capítulo 1: Exploración de la nube de Microsoft Azure   1

Conceptos básicos de la informática en la nube ................................................  2

Capítulo 2: Introducción a la nube de Azure   15

Requisitos técnicos ...............................................................................................  16

Capítulo 3: Administración básica de Linux   47

El shell de Linux .....................................................................................................  48

Administración de recursos de Azure con la CLI de Azure y PowerShell .......  98

Requisitos técnicos .............................................................................................  132

Capítulo 6: Administración de seguridad e identidades de Linux   183

Sugerencias de seguridad para Linux ..............................................................  184

Escenarios de implementación .........................................................................  234

Capítulo 9: Virtualización de contenedores en Azure   325

Introducción a la tecnología de contenedores ...............................................  326

Capítulo 10: Cómo trabajar con Azure Kubernetes Service   371

Requisitos técnicos .............................................................................................  373

Requisitos técnicos .............................................................................................  418

Capítulo 12: Apéndice   459