• Parte 0: Introducción a la creación automática de plantillas con Packer.
• Parte 1: Creación de plantilla de Windows automatizada.

Escogiendo builder de Packer para VMware

Como comenté en la entrada anterior, existen builders creados por Hashicorp para la gran mayoría de plataformas de virtualización y cloud del mercado. En el caso del plugin de vSphere existe VMware-iso, un builder que permite la creación de imágenes a través de una ISO de sistema operativo.

El handicap de VMware-iso es que se conecta a través de SSH para la interacción con la plataforma, y como sabemos no siempre es adecuado tener el acceso SSH abierto a nuestra infraestructura o incluso se puede dar el caso de que no dispongamos de los permisos necesarios para habilitarlo.

Es por eso que yo me decanto por utilizar vSphere-iso, un builder desarrollado por Jetbrains que utiliza la API nativa de vSphere para realizar todas las operaciones contra la plataforma, por lo que lo único que necesitaremos será un usuario de vSphere con suficientes privilegios para realizar las acciones que necesitemos.

Antes de empezar

La única infraestrucura necesaria para seguir con esta entrada será la siguiente:

• Una infraestructura vSphere sobre la que realizar el deploy de la plantilla.
• Una máquina con Packer instalado, tal como vimos en la anterior entrada (puede ser nuestra propia máquina sin problemas).
• Un servidor DHCP en la VLAN en la que vayamos a desplegar la plantilla (Packer necesita que la plantilla tenga una IP para conectarse por WinRM después de la instalación).

En mi caso voy a ejecutar Packer desde una máquina con CentOS 7, pero el código debería funcionar independientemente de la plataforma que ejecute Packer.

Para hacer todo esto más fácil he creado un repositorio en GitHub con el código que vamos a utilizar en esta entrada, por lo que en algunos archivos solo resaltaré las partes más destacadas que tendremos que editar para hacerlo funcionar. Para que el ejemplo funcione deberemos respetar la estructura de carpetas del «proyecto»:

.
├── setup
│   ├── autounattend.xml
│   ├── setup.ps1
│   └── vmtools.cmd
├── template_ws2016.json
└── vars_ws2016.json

¡Empecemos!

Creando el archivo de variables

Como comenté en la entrada anterior, podemos utilizar variables en nuestras templates que nos ayudarán a crear archivos mucho más reusables y claros. Éstas variables pueden ser definidas tanto en la propia template como en un archivo externo al que llamaremos cuando vayamos a construir nuestra plantilla. Si decidís utilizar los archivos del repositorio como base para vuestra implementación éste es el archivo que más deberéis modificar.

Para esta entrada utilizaremos el archivo vars_ws2016.json que podemos encontrar en el repositorio de GitHub de la entrada.

{
    "vsphere_server": "vcsa.sobrebits.local",
    "vsphere_user": "packer@vsphere.local",
    "vsphere_password": "Vsphere.12345",
    "vsphere_template_name": "Template-Windows2016",
    "vsphere_folder": "Templates",
    "vsphere_dc_name": "SobrebitsDatacenter",
    "vsphere_compute_cluster": "SobrebitsCluster",
    "vsphere_host": "esxi01.sobrebits.local",
    "vsphere_portgroup_name": "VM Network",
    "vsphere_datastore": "Datastore1",
    "winadmin_password": "Template.12345",
    "cpu_num": "2",
    "mem_size": "4096",
    "disk_size": "32768",
    "os_iso_path": "[Datastore1]_ISOs/Windows2016.iso",
    "vmtools_iso_path":"[Datastore1]_ISOs/vmtools.iso"
}

He intentado que los nombres de las variables sean lo más autoexplicativos posibles, pero igualmente los repasaremos por si hay dudas:

• vsphere_server: Servidor vSphere al que nos conectaremos para desplegar la plantilla.
• vsphere_user: Usuario con el que conectaremos a vSphere.
• vsphere_password: Password del usuario.
• vsphere_template_name: Nombre que recibirá la plantilla que creemos.
• vsphere_folder: Carpeta de vSphere en la que crearemos la plantilla.
• vsphere_dc_name: Datacenter en el que se ubicará la plantilla.
• vsphere_compute_cluster: Cluster en el que se ubicará la plantilla.
• vsphere_host: Servidor que alojará la plantilla.
• vsphere_portgroup_name: Red (tipo portgroup) que asociaremos a la plantilla.
• cpu_num: Número de CPUs con los que se creará la plantilla.
• mem_size: Cantidad de RAM en MB con la que se creará la plantilla.
• disk_size: Cantidad de disco en MB con el que se creará la plantilla.
• os_iso_path: Ubicación de la ISO que se montará en la plantilla para la instalación del sistema operativo (un datastore que pueda ver el servidor ESXi que ejecuta la plantilla).
• vmtools_iso_path: Ubicación de la ISO con las VMware Tools (un datastore que pueda ver el servidor ESXi que ejecuta la plantilla).

Deberemos configurar el archivo de variables para adaptarse a nuestro entorno y a las configuraciones que deseemos para nuestra plantilla. Una vez tengamos las variables definidas ya podemos pasar a diseñar la plantilla de Packer que las utilizará.

Diseñando la plantilla de instalación

Para construir nuestra plantilla de sistema operativo, Packer utiliza un archivo de template en formato Json en el que tenemos que ajustar todas las configuraciones que querremos para la misma. Para esta parte nos centraremos en el archivo template_ws2016.json del repositorio de GitHub y veremos las distintas configuraciones a aplicar.

Vamos a repasar por partes el archivo:

  "variables": {
    "vsphere_server": "",
    "vsphere_user": "",
    "vsphere_password": "",
    "vsphere_template_name": "",
    "vsphere_folder": "",
    "vsphere_dc_name": "",
    "vsphere_compute_cluster": "",
    "vsphere_host": "",
    "vsphere_portgroup_name": "",
    "vsphere_datastore": "",
    "winadmin_password": "",
    "cpu_num": "",
    "mem_size": "",
    "disk_size": "",
    "os_iso_path": "",
    "vmtools_iso_path":""
  },
  "sensitive-variables": ["vsphere_password", "winadmin_password"],

En el primer bloque (variables) declaramos todas las variables que hemos definido en nuestro archivo y que serán necesarias para la ejecución de la plantilla. En el segundo bloque (sensitive-variables) indicamos que vsphere_password y winadmin_password tienen contenido sensible y que no queremos que se muestren sus valores por consola en el momento de la ejecución de Packer.

En la entrada anterior ya hablamos de los builders, que son los encargados de conectarse con nuestra infraestructura y desplegar las plantillas. Veamos como queda nuestro builder de vSphere:

  "builders": [
    {
      "type": "vsphere-iso",

      "vcenter_server":      "{{user `vsphere_server`}}",
      "username":            "{{user `vsphere_user`}}",
      "password":            "{{user `vsphere_password`}}",
      "insecure_connection": "true",

      "vm_name": "{{user `vsphere_template_name`}}",
      "folder" : "{{user `vsphere_folder`}}",
      "datacenter": "{{user `vsphere_dc_name`}}",
      "cluster":     "{{user `vsphere_compute_cluster`}}",
      "host": "{{user `vsphere_host`}}",
      "network": "{{user `vsphere_portgroup_name`}}",
      "datastore": "{{user `vsphere_datastore`}}",
      "convert_to_template": "true",
      "shutdown_command": "C:/Windows/System32/Sysprep/sysprep.exe /oobe /shutdown",

      "guest_os_type": "windows9Server64Guest",

En esta primera parte básicamente nos dedicamos a configurar todos los aspectos relacionados con la infraestructura vSphere que ya hemos explicado en variables. Algunas cosas nuevas son:

• type: Aquí hemos definido nuestro builder, que para esta entrada como hemos explicado anteriormente será vsphere-iso.
• insecure_connection: Indicamos que no valide el certificado SSL de nuestro vCenter (mi experiencia me dice que la gran mayoría de infraestructuras vSphere tienen certificado autofirmado).
• convert_to_template: Definimos que queremos que al finalizar la construcción de la plantilla la marque como template en nuestro vCenter.
• shutdown_command: Indicamos que para realizar el apagado del sistema operativo al finalizar la construcción de la plantilla se ejecute sysprep para sellar la misma.
• guest_os_type: Establecemos el tipo de sistema operativo invitado que tendrá nuestra máquina virtual (en este caso Windows Server 2016).

Sigamos con el archivo:

      "communicator": "winrm",
      "winrm_username": "Administrador",
      "winrm_password": "{{user `winadmin_password`}}",

Una vez haya finalizado la instalación, Packer deberá conectarse a la máquina virtual para aplicar las configuraciones que le indiquemos. Aquí estamos definiendo que lo haga por WinRM (tal y como vimos con PowerShell Remoting) utilizando el usuario Administrador y el password definido en nuestro archivo de variables.

      "CPUs":             "{{user `cpu_num`}}",
      "RAM":              "{{user `mem_size`}}",
      "firmware": "bios",

      "disk_controller_type":  "lsilogic-sas",
      "disk_size":        "{{user `disk_size`}}",
      "disk_thin_provisioned": true,

      "network_card": "vmxnet3",

      "iso_paths": [
        "{{user `os_iso_path`}}",
        "{{user `vmtools_iso_path`}}"
      ],

Aquí definimos los recursos de la máquina así como algunas configuraciones de hardware como el tipo de tarjeta, la bios o el formato thin del disco.

Además indicamos las rutas de las iso que se montarán en la plantilla y que ya habíamos definido en el archivo de variables: la iso de Sistema Operativo y la iso de las VMware Tools.

Vamos con la última parte que veremos hoy:

      "floppy_files": [
        "/root/packer/test/setup/autounattend.xml",
        "/root/packer/test/setup/setup.ps1",
        "/root/packer/test/setup/vmtools.cmd"
      ]

Aquí definimos la ubicación de los achivos que pasaremos como floppy cuyo path deberemos editar para que cuadre con la ubicación de la carpeta de nuestro proyecto. Estos archivos serán los encargados de (ahí va spoiler de la próxima entrada):

• Establecer los parámetros de configuración de la instalación de Windows.
• Configuración de WinRM para la ejecución de Provisioners.
• Instalar las VMware Tools.

Conclusión

Y hasta aquí la primera parte de nuestra guía de creación de plantilla de Windows automatizada con Packer. En la próxima entrada acabaremos de descubrir las distintas partes implicadas en la instalación y configuración de nuestra plantilla y descubriremos qué más cosas podremos realizar con ésta.

¡Espero veros por aquí!

La entrada Packer para VMware (Parte 1): Creación de plantilla de Windows automatizada aparece primero en Sobrebits.

¿Qué es Packer?

Packer es una herramienta de software libre desarrollada por Hashicorp que nos permite crear imágenes de sistema operativo de forma automatizada y utilizando archivos de configuración para tal efecto.

Una vez creada la configuración (que veremos en próximas entradas) Packer se conectará a la infraestructura de destino, creará la máquina virtual y aplicará todas las configuraciones que hayamos definido en nuestros archivos. Todo esto mientras nos tomamos un rico café.

Packer incluye la funcionalidad necesaria para trabajar con las grandes plataformas del mercado sin la necesidad de instalar ningún plugin adicional:

• Aws.
• Azure.
• DigitalOcean.
• Docker.
• Google Cloud Platform.
• Hyper-V.
• VMware.

Podéis consultar la lista completa aquí.

Además, Packer funciona con todos los grandes sistemas operativos del mercado, permitiéndonos crear imágenes de cualquiera de ellos, así como la capacidad de trabajar con las herramientas de gestión de configuración más importantes como Ansible, Chef o Puppet.

Si queréis más información sobre esta impresionante herramienta os recomiendo que os paséis por su sitio web donde disponen de muchísima información al respecto.

¿Qué ventajas tiene crear plantillas con Packer?

La generación automatizada de plantillas con Packer puede aportarnos muchos beneficios a nuestro flujo de trabajo:

• Velocidad de aprovisionado: Con Packer nuestras plantillas pueden disponer siempre de las últimas versiones de sistema operativo y de aplicaciones, con lo que podemos desplegar una plantilla siempre lista para su uso en cuestión de segundos o pocos minutos.
• Consistencia: Utilizando Packer nos aseguramos de que todas las máquinas virtuales que despleguemos partirán de la misma configuración.
• Consistencia multiplataforma: Siguiendo con el punto anterior, con Packer podemos partir de imágenes idénticas si disponemos de entornos híbridos. En todo momento estaremos seguros que nuestra instancia de Compute Engine de GCP es identica a nuestra máquina virtual de VMware vSphere.
• Versionado de configuración: Tener nuestras configuraciones en archivos de texto nos permite versionarlas de forma muy sencilla, por ejemplo, con Git, con lo que siempre podremos echar la vista atrás a la hora de hacer troubleshooting de nuestras máquinas.

Cómo funciona Packer

Packer utiliza templates en formato JSON con los que definiremos las distintas configuraciones necesarias para el despliegue, configuración y post procesado de nuestras plantillas.

Una template de Packer dispone de los siguientes elementos de configuración (subrayados los más importantes) para generar nuestras imágenes:

• Variables (opcional): Una sección de nuestra template en la que podremos definir variables que utilizaremos posteriormente en la misma. Es opcional pero más que recomendable utilizar variables para facilitar el uso de nuestra template. Las variables pueden ser definidas en un archivo separado de nuestra template.
• Descripción (opcional): Un campo en el que podemos definir qué hace nuestra template.
• Builders (obligatorio): En esta sección definiremos los «constructores» de nuestra plantilla, esto es, la parte encargada de conectarse con la infraestructura destino (VMware, GCP, AWS…) y que construirá la plantilla.
• Versión mínima de packer (opcional): Un campo en el que definiremos la mínima versión necesaria de packer necesaria para desplegar nuestra plantilla.
• Provisioners (opcional): La sección donde configuraremos todo lo necesario para instalar y configurar el software del sistema operativo. Aquí tenemos la opción de hacerlo mediante scripts o con una herramienta externa de gestión de configuración.
• Post processors (opcional): La sección encargada de definir los pasos posteriores a la creación de la imágen, como subirla a otra infraestructura, renombrar, convertir a plantilla…

Cómo instalar Packer

Existen distintas formas de instalar Packer, podéis consultar todas ellas en su documentación.

De largo la forma más sencilla es descargar sus binarios precompilados y ubicarlos en el path de nuestro usuario. Si queremos conocer las posibles ubicaciones:

• Linux / MacOS: Desde un terminal ejecutamos echo $PATH.
• Windows: Desde PowerShell ejecutamos $Env:Path.

Una vez copiados los ejecutables en dichas ubicaciones deberíamos ser capaces de ejecutar desde nuestra terminal el comando packer sin problemas.

Conclusión

Hasta aquí esta entrada introductoria sobre Packer. En próximas entradas empezaremos a construir plantillas de sistema operativo y veremos todo el potencial que oculta esta increíble herramienta.

¡Nos leemos en la próxima!

La entrada Introducción a la creación automática de plantillas con Packer aparece primero en Sobrebits.

$ProgressPreference, la encargada de ocultar la barra de progreso en PowerShell

Muchos de los comportamientos que tiene nuestra consola de PowerShell son configurables a través de las llamadas preference variables. Para ocultar la barra de progreso en PowerShell podremos utilizar la variable $ProgressPreference. Si mostramos el contenido de la variable en nuestra consola deberíamos ver el estado actual de la misma:

PS C:\>$ProgressPreference
Continue

El valor por defecto de la variable es Continue, pero éstos son los valores que le podemos asignar:

• Stop: Para la ejecución y muestra un error en el caso de que se vaya a utilizar una barra de progreso.
• Inquire: No muestra la barra de progreso y pregunta al usuario si quiere continuar.
• Continue: Muestra la barra de progreso y continua con la ejecución.
• SilentlyContinue: No muestra la barra de progreso pero continua con la ejecución.

A decir verdad no se me ocurre la utilidad de las primeras dos opciones, no obstante la que nos interesa para esta entrada es SilentlyContinue. Ahora sí, si queremos ocultar la barra de progreso en PowerShell y PowerCLI ejecutaremos en nuestra consola:

PS C:\>$ProgressPreference = 'SilentlyContinue'

Si a posteriori ejecutamos algún cmdlet que muestre barra de progreso como, por ejemplo, New-Snapshot de PowerCLI veremos como éste ya no muestra barra de progreso.

Hay que tener en cuenta que si cerramos y abrimos nuestra consola la variable volverá a coger su valor por defecto, es decir, Continue. Si queremos alterar éste comportamiento podemos añadir la línea anterior a nuestro perfil de PowerShell como vimos en entradas anteriores, o bien si se trata de la ejecución de un script, dar el valor deseado a la variable al principio de éste.

Conclusión

Si bien como decía en la introducción cuando ejecutamos una sesión interactiva ver la barra de progreso nos puede ser útil, en ejecución de scripts y sobretodo si son programados es más un estorbo que otra cosa, por lo que $ProgressPreference nos puede ayudar a tener ejecuciones más limpias de nuestros scripts.

Espero que os sirva.

¡Hasta la próxima!

La entrada Cómo ocultar la barra de progreso en PowerShell y PowerCLI aparece primero en Sobrebits.

¿Qué es vCloud Director?

Si bien a VMware se la conoce especialmente por vSphere, ésta tiene una gran cantidad de productos la mar de interesantes en el mercado (muchas apoyadas en vSpere).

vCloud Director es una plataforma de VMware con la que se ofrecen las características necesarias para crear un servicio de Cloud, ya sea para que un proveedor de servicios ofrezca un servicio de Cloud público como para que un cliente final ofrezca un servicio de Cloud privado para su empresa, encima de una plataforma tan conocida como VMware vSphere.

Los cmdlets de PowerCLI para vCloud Director

Cuando instalamos PowerCLI en nuestra máquina con el módulo VMware.PowerCLI instalamos todos estos módulos:

• Windows TerminalVMware.DeployAutomation
• VMware.ImageBuilder
• VMware.PowerCLI
• VMware.Vim
• VMware.VimAutomation.Cis.Core
• VMware.VimAutomation.Cloud
• VMware.VimAutomation.Common
• VMware.VimAutomation.Core
• VMware.VimAutomation.Hcx
• VMware.VimAutomation.HorizonView
• VMware.VimAutomation.License
• VMware.VimAutomation.Nsxt
• VMware.VimAutomation.Sdk
• VMware.VimAutomation.Security
• VMware.VimAutomation.Srm
• VMware.VimAutomation.Storage
• VMware.VimAutomation.StorageUtility
• VMware.VimAutomation.Vds
• VMware.VimAutomation.Vmc
• VMware.VimAutomation.vROps
• VMware.VumAutomation

Para interactuar con vCloud Director utilizaremos el módulo VMware.VimAutomation.Cloud, cuyos cmdlets podemos listar, como siempre, con Get-Command:

Get-Command -Module VMware.VimAutomation.Cloud

Utilizando PowerCLI para vCloud Director como usuario

Cuando interactuamos con PowerCLI para vCloud Director en modo usuario podremos realizar tareas relacionadas con la administración de nuestras máquinas virtuales, vApps, Edge Gateways…

Lo primero que deberemos hacer será conectarnos a nuestra organización. Para ello utilizaremos el cmdlet Connect-CIServer, que tiene un uso muy similar al mítico Connect-VIServer:

# Conectamos a la infraestructura
Connect-CIServer -Server vcloud.sobrebits.com -Org sobrebits_Org

# Cuando hemos acabado las respectivas acciones desconectamos
Disconnect-CIServer -Server vcloud.sobrebits.com -Confirm:$false

Lo importante aquí es tener en cuenta que será necesario especificar siempre el parámetro -Org para entrar en modo usuario.

Ahora que ya tenemos conexión contra nuestra organización podemos realizar toda clase de operativa directamente desde nuestra consola favorita. Veamos algunos de los cmdlets más interesantes:

• Trabajar con nuestras vApps y VMs:

# Listar, crear, parar o eliminar vApps
Get-CIVApp
New-CIVApp
Stop-CIVApp
Remove-CIVApp

# Listar, crear, parar o eliminar VMs 
Get-CIVM
New-CIVM
Stop-CIVM
Remove-CIVM

• Interactuar con catálogos, plantillas y medios:

# Listar catálogos
Get-Catalog

# Listar, crear o eliminar plantillas de vApp
Get-CIVAppTemplate
New-CIVAppTemplate
Remove-CIVAppTemplate

# Listar archivos de medios
Get-Media

• Interactuar con nuestros firewalls virtuales y redes:

# Listar nuestros Edge Gateways
Get-EdgeGateway

# Listar, crear, modificar o eliminar Org Networks
Get-OrgVdcNetwork
New-OrgVdcNetwork
Set-OrgVdcNetwork
Remove-OrgVdcNetwork

Utilizándolo como administrador

Cuando utilizamos vCloud Director como administrador encontramos dos diferencias básicas respecto a la interacción como usuario:

• Tenemos visibilidad sobre todos los recursos de la plataforma: Esto quiere decir que si, por ejemplo, utilizamos Get-CIVApp en este modo podremos listar las vApps de todas las organizaciones de la infraestructura.
• Podremos interactuar contra elementos de la infraestructura que no son visibles para el usuario.

Aquí van algunas de las cosas interesantes que podemos hacer:

# Listar los detalles del Provider VDC
Get-ProviderVDC

# Listar y añadir Datastores
Get-CIDatastore
Add-CIDatastore

# Hacer búsquedas avanzadas sobre la infraestructura
Search-Cloud
Get-CIView

Conclusión

Muchas de las cosas que hemos visto sobre PowerCLI en el blog pueden ser traducidas a PowerCLI para vCloud Director, espero que con esta entrada introductoria y con lo visto en anteriores entradas os ayude a llevar también la automatización a ésta plataforma. Os recomiendo que tanto si sois usuarios como administradores de la misma le deis una oportunidad.

¡Nos leemos en la próxima!

La entrada Primeros pasos con PowerCLI para vCloud Director aparece primero en Sobrebits.

¿Por qué parar VMs con PowerCLI?

Existen varios motivos por los que querríamos automatizar la parada de VMs con PowerCLI:

• Asegurarnos de que VMs no productivas no consuman los recursos de las que sí lo son.
• Parar VMs que no se utilizan durante todas las franjas horarias.
• Controlar el gasto de nuestra infraestructura de pago por uso generado por nuestras máquinas de test.

En nuestro caso fue la última de las opciones la que nos hizo implementar esta medida, puesto que tenemos una carpeta de vSphere de test donde muy frecuentemente las máquinas quedaban encendidas después de su último uso durante semanas o meses, incurriendo en costes de licenciamiento en nuestra infraestructura absolutamente innecesarios.

Cmdlets implicados

Realizar esta automatización nos llevará muy pocas líneas de código. Para parar las máquinas virtuales nos valdremos de dos cmdlets de PowerCLI:

• Shutdown-VMGuest: Para parar máquinas virtuales con VMware Tools «de forma amigable».
• Stop-VM: Para parar máquinas virtuales sin VMware Tools, en este caso de forma un poco más «agresiva».

Manos a la obra

Ya podemos empezar a construir el script. Primero definiremos un área de configuración:

#### Configuración ####
# Conexión a vCenter
$VcenterIp = "192.168.168.168"
$VcenterCreds = Import-Clixml -Path "$PSScriptRoot\Credenciales\VMware.xml"
# Carpetas con VMs de pruebas
$VmFolders = 'Test','Pruebas'

Nada que no hayamos hecho varias veces en entradas del blog, pero vamos a repasarlo:

• Líneas 3-4: Definimos los parámetros de conexión a vCenter, IP del servidor y las credenciales tal como vimos en entradas anteriores.
• 6: Definimos las distintas carpetas de vSphere que querremos parar.

Y ahora podemos pasar a la acción:

#### Cuerpo ####
# Conectamos al vCenter
Connect-VIServer -Server $VcenterIp -Credential $VcenterCreds -WarningAction SilentlyContinue | Out-Null

# Recorremos las carpetas
ForEach ($VmFolder in $VmFolders) {
    # Obtenemos las VMs encendidas
    $VMs = Get-Folder $VmFolder | Get-VM | Where-Object PowerState -eq 'PoweredOn'
    # Recorremos las VMs
    ForEach ($VM in $VMs) {
        # Obtenemos el estado de las tools
        $VmTools = $VM.ExtensionData.config.tools.toolsVersion

        # Apagamos forzosamente si no hay tools o amigablemente si sí que hay
        If ($VmTools -eq 0) {
            $VM | Stop-VM -Confirm:$false
        }
        Else {
            $VM | Shutdown-VMGuest -Confirm:$false
        }
    }
}

# Desconectamos del vCenter
Disconnect-VIServer -Confirm:$false

Aquí ya tenemos algo más que explicar:

• Línea 3: Conectamos a la infraestructura vSphere con los datos de la sección de configuración.
• 6-22: Recorremos las carpetas de VMs definidas en la sección de configuración.
  • 8: Obtenemos todas las VMs encendidas de la carpeta.
  • 10-20: Recorremos las VMs una a una.
    • 12: Obtenemos el estado de las VMware Tools.
    • 15-17: Si la VM no tiene VMware Tools la paramos de forma forzosa con Stop-VM.
    • 18-20: Si la VM sí que tiene VMware Tools la paramos de forma amigable con Shutdown-VMGuest.
• 25: Desconectamos de la infraestructura.

Como siempre, programaremos la ejecución del script de PowerShell como habitualmente y lo ajustaremos a la periodicidad con la que queremos que se apaguen las VMs, en el caso de las VMs de test nosotros las apagamos cada noche.

Conclusión

A partir del script que os propongo podéis realizar las modificaciones que a vosotros os vengan bien, apagando VMs concretas y no carpetas, apagando todas las VMs de un servidor… Como siempre el límite es nuestra imaginación.

Espero que el script os sea de ayuda. ¡Hasta la próxima!

La entrada Parar VMs con PowerCLI de forma masiva y programada aparece primero en Sobrebits.

¿Por qué hay que eliminar snapshots antiguos en VMware?

En vSphere los snapshots pueden suponer una herramenta increíblemente útil en nuestro día a día o una pesadilla dependiendo del uso que le demos. VMware facilita una serie de buenas prácticas en ésta entrada.

Como indica VMware, no debereíamos tener snapshots más antiguos de 72 horas o podemos incurrir en:

• Llenado del storage por culpa de que el snapshot no para de crecer.
• Bajada de rendimiento en el sistema.

Yo por mi parte añadiría que eliminar un snapshot de varios cientos de GB o de más de 1TB no es la mejor de las experiencias .

Listando snapshots antiguos con PowerCLI

Vamos a ver el pequeño script que nos ayudará a mantener a raya los snapshots antiguos con PowerCLI:

Spoiler: si únicamente quieres el one-liner para obtener las VMs puedes dirigirte directamente a las líneas resaltadas del script

#### Variables ####
# Conexión a vCenter
$VcenterIP = "192.168.168.168"
$VcenterCreds = Import-Clixml -Path "$PSScriptRoot\Credenciales\VMware_rw.xml"

# Antigüedad snapshot
$Days = 3

# Configuración del correo
$Body = "Snapshots con más de $Days días: `n`n"
$From = "monitorizacion@sobrebits.com"
$To = "admin@sobrebits.com"
$Subject = "VMs con Snapshot anterior a $Days días"
$SmtpServer = "mailserver.sobrebits.com"
$SmtpPort = 25

#### Cuerpo del script ####

# Conectamos al vCenter
Connect-VIServer -Server $VcenterIP -Credential $VcenterCreds -WarningAction SilentlyContinue | Out-Null

# Recuperamos todas las VMs con snapshot antiguos
$Vms = (Get-VM | Get-Snapshot | Where-Object {$_.Created -lt (Get-Date).AddDays(-$Days)}).VM.Name | Sort-Object

# Enviamos correo con el listado (en caso de que hubiera alguna VM con snapshot antiguo)
if ($Vms) {
    $Body += $Vms -join "`n"
    Send-MailMessage -From $From -To $To -Subject $Subject -Body $Body -SmtpServer $SmtpServer -Port $SmtpPort
}

# Desconectamos del vCenter
Disconnect-VIServer -Confirm:$false

Veamos qué hemos hecho aquí:

• Líneas 3-4: Declaramos la IP y las credenciales del servidor vCenter.
  • Para las credenciales utilizamos lo que vimos en la entrada: Cómo gestionar las credenciales de un script de PowerShell.
• 7: Declaramos la cantidad de días de antigüedad del snapshot. En nuestro caso seguimos las buenas prácticas de VMware y configuramos 3.
• 10-15: Configuramos los parámetros para el envío de correo.
  • Más sobre esto en: Enviar correo desde PowerShell.
• 20: Conectamos a vCenter.
• 23: Aquí está la «chicha» del script, donde obtenemos todas las máquinas virtuales con snapshot anterior a 3 días:
  • Get-VM: Obtenemos todas las máquinas virtuales.
  • Get-Snapshot: Obtenemos todos los snapshots de las máquinas virtuales.
  • Where-Object {$_.Created -lt (Get-Date).AddDays(-$Days)}: Nos quedamos únicamente con los snapshots cuya fecha de creación ($_.Created) sea anterior (-lt) a la fecha actual menos 3 días ((Get-Date).AddDays(-$Days)).
  • .VM.Name: Seleccionamos únicamente el nombre de la VM a la que pertenece dicho snapshot.
• 26-29: Si existen máquinas dentro de $Vms enviamos el correo con el listado de las máquinas virtuales.
• 32: Desconectamos del vCenter.

Resumiendo, cada vez que el script se ejecute revisará todas las máquinas vituales del entorno y revisará si contienen snapshots y si éstos son anteriores a 3 días. De existir alguno nos enviará un resumen de las máquinas virtuales afectadas directamente a nuestra bandeja de correo para que seamos nosotros mismos los que gestionemos el caso.

Conclusión

Si utilizamos la ejecución programada de scripts de PowerShell para realizar este check de forma diaria nos vamos a asegurar de tener siempre controlada la existencia de snapshots antiguos con PowerCLI, con lo que tendremos una infraestructura más optimizada.

Para los más atrevidos, podríamos modificar el script para que, en vez de enviar un correo, ejecutara Remove-Snapshot para eliminar directamente sin preguntar los snapshots antiguos.

¡Nos leemos en la próxima!

La entrada Listar máquinas virtuales con snapshots antiguos con PowerCLI aparece primero en Sobrebits.

Para ver las distintas funciones que podemos realizar de una forma práctica en esta entrada crearemos un script que:

• Crea una OU con PowerShell.
• Rompe la herencia de la OU.
• Elimina los permisos autogenerados en dicha OU.
• Añade permisos personalizados.

Antes de empezar

Para entender mejor el contenido de esta entrada es conveniente que tengas una base sobre cómo funcionan los permisos en Windows y, específicamente, sobre los permisos en Active Directory. Durante la entrada me referiré a dos terminos de forma constante:

• ACL: La Access Control List, es decir, la lista de permisos completa que está asociada al objeto (en esta entrada a una OU).
• ACE: La Access Control Entry, es decir, un permiso conceto dentro de la ACL.

¡Con esto dicho ya podemos empezar!

Crear Unidad Organizativa con PowerShell

Para poder hacer nuestras pruebas de modificación de permisos de OU con PowerShell lo primero que necesitaremos será una OU de prueba que, como no, crearemos con PowerShell.

Como siempre os recomiendo que hagáis siempre vuestros desarrollos sobre un entorno de prueba ya que es muy fácil que acabemos liando una gorda, y nadie quiere recrear permisos a mano sobre un árbol de Active Directory.

# Definimos el path donde crear nuestra OU de prueba
$OuPath = 'DC=sobrebits,DC=local'

# Creamos la OU "OUTest" en la ubicación definida
New-ADOrganizationalUnit -Name 'OUTest' -Path $OuPath

En primer lugar hemos definido el path de la OU que vamos a crear con PowerShell. Después utilizamos New-ADOrganizationalUnit para crear una OU con el nombre OUTest.

Romper la herencia de OU con PowerShell

Ahora que tenemos nuestra Unidad Organizativa creada es momento de trastear con sus permisos. Justo después de crear la OU podemos ver como existen multitud de permisos heredados del nivel superior:

Lo primero que haremos para asegurarnos de que podemos juguetear con todos ellos será romper la herencia de permisos de OU:

# Generamos el Path completo de la OU creada
$OuPath = "OU=OUTest,$OuPath"

# Obtenemos las ACL de nuestra OU
$Acl = Get-Acl "AD:\\$OuPath"

# Rompemos la herencia preservando las ACLs heredadas
$Acl.SetAccessRuleProtection($True,$True)

# Escribimos la ACL en la OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

Lo que hemos hecho ha sido obtener un objeto que representa todas las entradas de permisos de nuestra OU, lo hemos modificado para que deje de heredar permisos (copiando los que ya tenía heredados) y escribiendo éste objeto modificado en la ACL de la OU. Veamos línea a línea cómo lo hemos hecho:

• Línea 2: Construimos el path completo de la OU que acabamos de generar para operar con ella en futuras líneas mediante $OuPath.
• 5: Utilizamos el cmdlet Get-Acl para obtener los permisos (ACL) de la OU de Active Directory.
  • AD:\\ es un PSDrive que apunta a la raíz del directorio.
• 8: Utilizamos el método SetAccessRuleProtection de nuestro objeto de ACL (System.DirectoryServices.ActiveDirectorySecurity) con el que podemos modificar el comportamiento de la heréncia.
• 11: Con Set-Acl escribimos la ACL modificada en el comando anterior utilizando el parámetro -AclObject junto con el objeto modificado.

Si comprobamos ahora los permisos de nuestra OU de prueba veremos como tiene los mismos permisos que anteriormente pero éstos ya no son heredados del nivel superior:

Eliminar permisos de OU con PowerShell

Lo siguiente que vamos a ver será cómo eliminar estos permisos. El procedimiento es muy parecido: obtenemos la ACL actual, eliminamos los permisos (ACE) uno a uno del objeto y escribimos nuestra ACL modificada en la OU:

# Volvemos a obtener las ACLs de nuestra OU
$Acl = Get-ACL "AD:\\$OuPath"

# Recorremos las ACLs y las eliminamos una a una
ForEach ($Ace in $Acl.Access) {
        $Acl.RemoveAccessRule($Ace) | Out-Null
    }

# Escribimos la ACL de nuevo en nuestra OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

Veamos paso por paso:

• Línea 2: Obtenemos las ACL de la OU de nuevo.
  • Debemos tener en cuenta que tras cada modificación de los permisos de la OU deberemos «refrescar» nuestro objeto $Acl para que tenga la versión actualizada de los permisos.
• 5: Recorremos todas las ACL contenidas en la propiedad «Access» de nuestro objeto $Acl.
  • 6: Utilizamos el método RemoveAccessRule del objeto $Acl para eliminar la ACE.
• 10: Con Set-Acl escribimos la ACL modificada en el comando anterior utilizando el parámetro -AclObject junto con el objeto modificado.

Después de eso, si volvemos a revisar los permisos de la OU veremos como no existe ninguno:

Añadir permisos de OU con PowerShell

Con nuestra ACL limpia llega el momento de añadir permisos a la Unidad Organizativa. Esta es quizás la parte más compleja, puesto que deberemos construir a mano un objeto ActiveDirectoryAccessRule, es decir, deberemos crear la ACE de forma manual. Vamos a ver cómo sería la cosa:

# Volvemos a obtener las ACLs de nuestra OU
$Acl = Get-ACL "AD:\\$OuPath"

# Construimos la ACE para el usuario Marc
$User = (Get-ADUser 'Marc')
$Sid = [System.Security.Principal.SecurityIdentifier]$User.Sid
$Identity = [System.Security.Principal.IdentityReference]$Sid
$Rights = [System.DirectoryServices.ActiveDirectoryRights]"GenericRead"
$Type = [System.Security.AccessControl.AccessControlType]"Allow"
$Inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"All"
$Ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity,$Rights,$Type,$Inheritance

# Añadimos la ACE a la ACL
$Acl.AddAccessRule($Ace)

# Escribimos la ACL de nuevo en nuestra OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

Repasemos paso por paso:

• Línea 2: Obtenemos las ACL de la OU de nuevo.
• 5-10: Obtenemos todas las propiedades que necesitamos para construir nuestro objeto ActiveDirectoryAccessRule.
  • 5: Obtenemos el usuario a añadir en la ACE.
  • 6: Sacamos el SID (identificador de seguridad) del usuario.
  • 7: Mediante el SID obtenemos el identificador del usuario, necesario para construir el objeto.
  • 8: Creamos un objeto de permisos de Active Directory con permisos de lectura. Podéis obtener todos los valores disponibles aquí.
  • 9: Determinamos el tipo de permiso en «permitir».
  • 10: Aplicamos la herencia de permisos a todos los objetos «descendientes».
• 11: Mediante las propiedades definidas en el bloque anterior creamos un nuevo objeto de ACE mediante New-Object.
• 14: Añadimos la ACE generada a la ACL que hemos obtenido en la línea 2.
• 17: Con Set-Acl escribimos la ACL modificada en el comando anterior utilizando el parámetro -AclObject junto con el objeto modificado.

Si ahora vemos la ACL de la OU podemos ver como se ha añadido la entrada:

A partir de aquí, si queremos añadir más permisos a la ACL únicamente tendremos que generar tantas ACE como sea preciso y añadirlas a nuestra ACL mediante Set-Acl.

El resultado final del script sería este:

# Definimos el path donde crear nuestra OU de prueba
$OuPath = 'DC=sobrebits,DC=local'

# Creamos la OU "OUTest" en la ubicación definida
New-ADOrganizationalUnit -Name 'OUTest' -Path $OuPath

# Generamos el Path completo de la OU creada
$OuPath = "OU=OUTest,$OuPath"

# Obtenemos las ACL de nuestra OU
$Acl = Get-Acl "AD:\\$OuPath"

# Rompemos la herencia preservando las ACLs heredadas
$Acl.SetAccessRuleProtection($True,$True)

# Escribimos la ACL en la OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

# Volvemos a obtener las ACLs de nuestra OU
$Acl = Get-ACL "AD:\\$OuPath"

# Recorremos las ACLs y las eliminamos una a una
ForEach ($Ace in $Acl.Access) {
        $Acl.RemoveAccessRule($Ace) | Out-Null
    }

# Escribimos la ACL de nuevo en nuestra OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

# Volvemos a obtener las ACLs de nuestra OU
$Acl = Get-ACL "AD:\\$OuPath"

# Construimos la ACE para el usuario Marc
$User = (Get-ADUser 'Marc')
$Sid = [System.Security.Principal.SecurityIdentifier]$User.Sid
$Identity = [System.Security.Principal.IdentityReference]$Sid
$Rights = [System.DirectoryServices.ActiveDirectoryRights]"GenericRead"
$Type = [System.Security.AccessControl.AccessControlType]"Allow"
$Inheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]"All"
$Ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $Identity,$Rights,$Type,$Inheritance

# Añadimos la ACE a la ACL
$Acl.AddAccessRule($Ace)

# Escribimos la ACL de nuevo en nuestra OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

Bola extra: Copiar los permisos de una OU a otra con PowerShell

Es posible que después de este último punto hayas pensado que escribir una ACL compleja puede hacer que te quede un script extremadamente largo (algo que muchas veces se ve como algo bueno cuando no debería serlo), y razón no te falta. Un truco si vas a estar recreando los mismos permisos muchas veces es el siguiente:

• Creas una OU y le asignas permisos que necesites a mano (no siempre hay que hacerlo todo desde la línea de comandos).
• Haces que el script copie esos permisos en tu nueva OU.

Lo mejor de éste método es que lo puedes implementar en dos líneas:

# Obtenemos las ACL de la OU plantilla
$Acl = Get-ACL "AD:\\OU=PlantillaPermisos,DC=sobrebits,DC=local"

# Escribimos la ACL en la nueva OU
Set-Acl "AD:\\$OuPath" -AclObject $Acl

Conclusión

Mediante esta forma de asignación de permisos en OUs con PowerShell podremos automatizar un paso más en nuestros procesos de creación de usuarios, algo que puede ahorrarnos una gran cantidad de horas.

¡Espero que os sea útil!

La entrada Active Directory: Gestionar permisos de OU con PowerShell aparece primero en Sobrebits.

Conociendo serverless y Azure Functions

Antes de empezar con el how-to propiamente dicho creo que es importante que tengamos clara la base de todo esto.

Serverless es el «palabro» elegido por la industria para definir un servicio en el que el desarrollador se desentiende del servidor donde se ejecuta su código. En un servicio serverless el desarrollador simplemente copia su código y el proveedor de servicios es el encargado de aprovisionar la infraestructura necesaria para que éste funcione, escale y se mantenga disponible.

No me gusta particularmente la palabra serverless pues puede llevar al error de pensar que realmente no existe un «servidor» que ejecute el código. Lo que nos tiene que quedar claro es que éste no desaparece, sino que pasa a ser transparente para el usuario.

Azure Functions es el servicio serverless de Microsoft, un servicio que nos va a permitir ejecutar funciones o scripts de PowerShell en «la nube» de forma muy sencilla sin tener que desplegar un servidor para ello.

Creando la Azure Function

Ahora que ya conocemos un poco más de serverless y de las Azure Functions vamos a explorar un poco el servicio creando una función de prueba.

Accediendo a Azure

Lo primero que deberemos hacer para empezar con Azure Functions será entrar en nuestra cuenta de Azure. Si no dispones de una puedes crearla de forma gratuita desde su página web. Con tu nueva cuenta dispondrás de:

• 12 meses de algunos servicios de forma gratuita.
• 170€ de crédito para usar con cualquier servicio.
• Muchos servicios de forma gratuita siempre.

En nuestro caso con Azure Functions nos valdremos de su tier gratuito, que es más que suficiente para hacer toda clase de pruebas con él.

Creando nuestra primera Azure Function App

Una vez logeados en nuestra cuenta de Azure podemos proceder a crear nuestra Azure Function App (el contenedor que hospedará nuestras funciones). Para ello nos dirigiremos a su respectivo apartado en el menú lateral izquierdo:

Posteriormente pulsaremos sobre el botón Crear Function App y rellenaremos sus campos:

Repasemos los campos configurados:

• Nombre de la aplicación: El nombre de la aplicación, que a su vez definirá la URL de la misma.
• Suscripción: Seleccionar cuál de nuestros planes de suscripción utilizaremos. Como esta es una cuenta nueva utilizamos la Evaluación gratuita.
• Grupo de recursos: Dejamos que nos genere un nuevo grupo de recursos para la aplicación (más sobre los grupos de recursos aquí).
• OS: Seleccionamos Windows.
• Plan de hospedaje: Dejamos marcado plan de consumo para utilizar el pago por ejecución (no vamos a pagar nada puesto que utilizaremos el tier gratuito).
• Ubicación: Seleccionamos una ubicación cercana a nosotros.
• Pila de tiempo de ejecución: Elegimos .NET para ejecutar PowerShell.
• Storage: Marcamos la creación de un storage nuevo para nuestra aplicación.

Después de rellenar los campos pulsaremos sobre el botón Crear y esperaremos hasta que la aplicación se cree. Una vez creada deberíamos ver algo así en el apartado Function App:

Por último, antes de pasar a crear la función en si, deberemos cambiar a la versión 1 el runtime de nuestra Funcion App, puesto que la versión 2 no soporta la ejecución de PowerShell. Para ello pincharemos sobre el nombre de nuestra Function App y posteriormente en Configuración de Function App.

Y en Versión en tiempo de ejecución marcaremos ~1.

Creando nuestra función de PowerShell en Azure Functions

Ahora que tenemos el entorno de ejecución creado y configurado podemos pasar a crear la función en si. Para ello pincharemos sobre el botón + de al lado de Funciones y posteriormente pulsaremos sobre Crear su propia función personalizada.

En Elegir una plantilla a continuación:

• Habilitamos la Compatibilidad de lenguaje experimental para poder utilizar PowerShell. (PowerShell en Azure Functions se encuentra en estado experimental, por lo que no se deberían poner cargas críticas en éste servicio)
• Seleccionamos HTTP trigger como modo de ejecución de nuestra función para esta prueba.

En el menú de creación de la función seleccionamos PowerShell como lenguaje y le damos nombre a la función.

Una vez finalizada la creación ya deberíamos ver nuestra flamante nueva función de prueba:

Entendiendo el script de prueba

El script de prueba que se nos proporciona nos puede ayudar a entender de una forma fácil algunas de las particularidades de la ejecución de PowerShell en Azure Functions.

Básicamente lo que hace este pequeño script será buscar un parámetro Name en nuestra petición (tanto si es GET como si es POST) y devolvernos un string con Hello $name. Vamos a examinarlo:

# POST method: $req
$requestBody = Get-Content $req -Raw | ConvertFrom-Json
$name = $requestBody.name

# GET method: each querystring parameter is its own variable
if ($req_query_name) 
{
    $name = $req_query_name 
}

Out-File -Encoding Ascii -FilePath $res -inputObject "Hello $name"

• Líneas 1-3: Parte del script orientada a peticiones POST.
  • 2: Obtenemos el cuerpo de la petición contenido en la variable $req y lo convertimos de json a un objeto. En Azure Functions el cuerpo de la petición POST siempre vendrá contenido en esta variable.
  • 3: Obtenemos la propiedad name de la petición.
• Líneas 5-9: Parte del script orientada a peticiones GET.
  • 6: Determinamos si existe la variable $req_query_name.
    • En Azure Functions las propiedades que pasemos mediante GET generan una variable automática $req_query_nombrepropiedad. Esto quiere decir que si lanzamos una query con una propiedad «blog» ésta será accesible en nuestro script con $req_query_blog.
  • 8: De existir la variable la almacenamos en $name para posteriormente devolverla en nuestra string.
• Línea 11: Devolvemos nuestra string añadiendo su contenido al archivo de salida ubicado en la ruta de la variable $res.
  • En Azure Functions $res es una variable especial que apunta al archivo utilizado para la salida de nuestra función.

Todo esto puede parecer muchas cosas a tener en cuenta pero básicamente hablamos de 3:

• Si queremos procesar solicitudes POST nos valdremos de $req para obtener los parámetros.
• En caso de querer procesar solicitudes GET nos valdremos de $req_query_nombredelparametro para obtener el parámetro.
• Siempre devolveremos el resultado de nuestro script mediante $res.

Ejecutando PowerShell en Azure Functions

Por último, ahora que ya tenemos nuestra Function App y nuestra función de PowerShell podemos probarla. Para ello nos valdremos de Invoke-RestMethod, el cmdlet de referencia para interactuar con APIs REST desde PowerShell.

El primer paso será obtener la URI completa desde la que invocar nuestra función. Desde la vista de nuestra función pulsaremos sobre </> Obtener la dirección URL de la función:

Una vez copiada lo primero que haremos será guardarla en una variable:

$Funcion = "https://sobrebitstest.azurewebsites.net/api/PSSobrebits?code=dKFWt5Ew..."

Y ahora vamos a hacer algunas consultas sobre ella:

Repasemos el resultado de los comandos:

• En la primera ejecución no añadimos a la URI ningún parámetro, con lo que nuestro script no puede concatenar ningún nombre a «Hello».
• En la segunda ejecución añadimos un nombre a la petición añadiéndolo a la URI y, esta vez sí, se concatena a «Hello».
• En la tercera ejecución vemos como para este script el funcionamiento es el mismo tanto con POST como con GET.

Resumen

En la entrada de hoy hemos podido ver como sin desplegar ningún tipo de servidor tenemos código de PowerShell ejecutándose bajo demanda en Azure. Los usos que le podemos dar son muchos y en próximas entradas espero traeros alguno.

Os invito a que exploréis esta forma de ejecutar PowerShell puesto que abre un abanico inmenso de posibilidades y, sin duda, es una forma sencilla de acercarnos al serverless desde una tecnología que todos conocemos.

¡Nos leemos pronto!

La entrada Serverless y PS – Ejecutar PowerShell en Azure Functions aparece primero en Sobrebits.

• Cómo utilizar Git con PowerShell (Parte 1): posh-git.
• Cómo utilizar Git con PowerShell (Parte 2): Git en Visual Studio Code.

Qué necesitas antes de empezar

Como ni el uso de Visual Studio Code en PowerShell es la primera vez que aparece en este blog ni evidentemente el uso de Git en PowerShell tampoco, reciclaremos parte de lo visto en éstas entradas para sentar las bases de ésta (sería un poco incoherente que me gustara tanto la automatización y repetir el mismo trabajo en cada entrada, ¿no?).

Para continuar necesitaremos:

• Una instalación de Visual Studio Code con el complemento de PowerShell instalado (ésto último si queremos resaltado de sintaxis para PowerShell).
• Una instalación de Git para Windows (no es necesario el módulo posh-git).

Inicializando un repositorio de Git desde Visual Studio Code

Tal y como hicimos en la primera parte lo primero que deberemos hacer será crear nuestro repositorio de código para empezar a juguetear con Git.

Lo primero que haremos será crear la carpeta de nuestro ‘proyecto’:

• Abrimos Visual Studio Code.
• Nos dirigimos a Explorer y pulsamos en Open Folder.

• Creamos la carpeta y pulsamos en Seleccionar carpeta.

Como podemos ver nuestra ventana de trabajo de Visual Studio Code ha cambiado ligeramente:

• En la parte superior aparece el nombre del área de trabajo (Sobrebits-VSCode-Git).
• Y en el explorador también vemos el área de trabajo sin archivos dentro.

Con nuestra área de trabajo abierta podemos dirigirnos a Source Control, que debería indicar que no hay proveedores de control de código registrados:

Ésto puede inducir a error ya que parece indicar que no disponemos de Git en nuestra máquina, pero lo que realmente indica es que nuestro repositorio no está inicializado. Para inicializarlo deberemos:

• Pulsar sobre el botón con el logo de Git al lado de SOURCE CONTROL.
• Lo que abrirá la paleta de comandos en la que seleccionaremos nuestra área de trabajo.

Después de ello podremos ver como el error ha desaparecido y ya empezamos a disponer de opciones relacionadas con Git en Visual Studio Code:

Utilizando Git en Visual Studio Code

Ahora sí que ya lo tenemos todo listo para empezar utilizar Git desde nuestro editor. Para probar ésta funcionalidad haremos lo siguiente en nuestro recién creado repositorio:

• Añadir un archivo.
• Realizar un commit del mismo.
• Crear una nueva rama.
• Hacer un merge de la rama a master.

Añadir un archivo

Lo primero que haremos en el repositorio será crear un archivo para que tenga contenido. Para ello:

• Nos dirigimos a Explorer.
• Pulsamos sobre el botón New File.

• Damos nombre al archivo y pulsamos Enter.

Realizar un commit

Después de crear nuestro archivo podemos ver varias cosas interesantes:

• El nombre del archivo aparece en color verde y con una U a su derecha.
• El icono de Source Control tiene un 1.

Lo que se nos está indicando es que existe un archivo en estado ‘untracked’ (la U) y que hay un cambio pendiente (el 1).

Antes de realizar nuestro commit deberemos poner nuestro archivo en estado tracked, es decir, bajo el rastreo de Git:

• Pulsamos sobre el icono de Source Control.
• Hacemos clic sobre el icono ‘+’ al lado del nombre, lo que añadirá el archivo a nuestra staging area.

El archivo ahora pasará al apartado de STAGED CHANGES, indicando que nuestro archivo está preparado para ser commiteado.

Para crear nuestro primer commit lo único que deberemos hacer será rellenar el mensaje del commit y pulsar sobre el check de encima del campo de texto:

Después de realizar el commit la interfaz vuelve a mostrarse como antes de añadir el archivo, indicando que no hay cambios pendientes.

Crear una nueva rama

Para crear una nueva rama utilizaremos la paleta de comandos, una de las funcionalidades más importantes de Visual Studio Code. Desde ella podemos acceder a toda la funcionalidad del editor.

• Abrimos la paleta de comandos de una de estas formas:
  • View > Command Palette.
  • Con la combinación de teclas Ctrl+Shift+P.
• Escribimos en la paleta ‘git branch’ para mostrar todas las opciones relacionadas con las ramas de git.

• Seleccionamos Git: Create Branch…
• Escribimos el nombre de la rama y pulsamos Enter.

• Seleccionamos el puntero HEAD que nos indica la rama actual.

Después de esto nuestra rama ya estará creada y nosotros estaremos situados en ella. En la esquina inferior izquierda podremos ver sobre la rama que nos encontramos:

Si pulsamos sobre el nombre de la misma aparecerá en nuestra paleta de comandos las ramas existentes y la posibilidad de cambiar entre ellas:

Hacer merge de una rama a master

Por último vamos a realizar un merge de nuestra rama a master. Para ello lo primero que haremos será realizar algún cambio en la rama:

Como vemos ahora tanto el color como la letra al lado del nombre del archivo han cambiado. Lo que nos están mostrando en esta ocasión es que el archivo ha sido modificado.

Añadimos la modificación a la staging area y realizamos un commit igual que lo hemos hecho en nuestro primer commit.

Con nuestra modificación ya hecha podemos pasar a realizar el merge:

• Cambiamos a la rama master.
• Abrimos la paleta de comandos de una de estas formas:
  • View > Command Palette.
  • Con la combinación de teclas Ctrl+Shift+P.
• Escribimos git merge y seleccionamos la opción: Git: Merge Branch…
• Seleccionamos la rama que hemos creado como origen del merge.

Después de esto podemos ver como los cambios realizados en nuestro archivo en la rama Test-git ya aparecen en la rama master:

Conclusión

Y hasta aquí esta entrada doble en la que hemos podido ver dos de las mejores formas de disfrutar de Git en PowerShell. Sin duda la opción que hemos visto en esta entrada es la más sencilla de las dos, puesto que Visual Studio Code nos abstrae de los comandos de Git para centrarnos simplemente en producir.

Mi recomendación es que si no estáis utilizando ya Git para vuestros desarrollos de PowerShell lo empecéis a utilizar cuanto antes, te cambia la forma de desarrollar para bien.

¡Nos vemos en la próxima

La entrada Cómo utilizar Git con PowerShell (Parte 2): Git en Visual Studio Code aparece primero en Sobrebits.

Antes de empezar…

En esta entrada voy a suponer que ya dispones de cierta base acerca del funcionamiento de Git. De no ser así te recomiendo que antes de entrar en la parte práctica te empapes un poco del funcionamiento de Git, existen multitud de recursos tanto online como offline para ello. Te aseguro que cada minuto que emplees en ello será un minuto aprovechado.

Insalar Git en Windows

Sea cual sea la forma en la que queramos consumir Git en PowerShell lo primero que deberemos hacer será instalar el cliente de Git para Windows. Para ello descargaremos la aplicación con nuestro navegador desde ésta URL.

La instalación básicamente es un siguiente > siguiente, pero vamos a verla paso por paso por si nos interesa cambiar algo:

• Information: Aceptamos los terminos y condiciones.
• Select destionation location: Elegimos la ruta de instalación del cliente.
• Select components: Para una instalación básica dejamos los componentes marcados por defecto.
  • Si no queremos añadir entradas en el menú del explorador podemos desmarcar las opciones de Windows Explorer integration.
  • Puede resultar interesante marcar el checkeo automático de las actualizaciones para mantener Git siempre al día.

• Select Start Menu Folder: Dejamos por defecto.
• Choosing the default editor used by Git: Aquí podemos elegir el editor que utilizará Git por defecto. Yo siempre utilizo Vim puesto que es el que utilizo en GNU/Linux, pero tenemos multitud de opciones a nuestra disposición:

• Adjusting your PATH environment: Aquí podemos empezar a ver algo de PowerShell en la opción por defecto. Dejando la opción por defecto nos permitirá invocar comandos de Git desde Git Bash (la consola por defecto de Git) así como en cmd o nuestra querida PowerShell.

• Choosing HTTPS transport backend: Aquí podemos elegir la opción que pefiramos. Si en vez de marcar la opción por defecto marcamos la segunda utilizaremos nuestro almacén de certificados de Windows y podremos validar contra las CA root de nuestro dominio. A gusto del consumidor.
• Configuring the line ending conversions: Dejamos la opción por defecto puesto que será la que nos asegurará mayor compatibilidad si realizamos desarrollos multiplataforma en los saltos de línea (para poder utilizar PowerShell Core para GNU/Linux sin problema).
• Configuring the terminal emulator to use with Git Bash: Dejamos la opción por defecto puesto que nos dejará redimensionarla sin problemas en versiones anteriores a Windows 10. No es una opción que nos interese mucho puesto que la idea es utilizar la propia PowerShell con Git.
• Configuring extra options: Otra vez podemos dejar los settings por defecto para una instalación básica.

Como podéis ver es un instalador con muchas pantallas pero que si no deseamos ningún tipo de personalización podremos pasar a base de siguientes.

Ahora que ya tenemos la instalación finalizada podríamos abri la consola Git bash para empezar a trabajar con Git:

Instalación de posh-git

Ahora que ya tenemos el requisito fundamental para trabajar en Git con PowerShell nos falta el módulo que va a complementar la consola para convertirla en una herramienta completa para el uso de Git. El módulo es posh-git, un módulo muy popular que podemos encontrar dentro de la PowerShell Gallery, y que nos ofrece la siguiente funcionalidad:

• Personalización del prompt al más puro estilo Git en el que podemos ver la rama en la que nos encontramos y los cambios realizados en la misma.
• Autocompletado de comandos de Git así como de nombres de las ramas.

Para instalar el módulo como siempre nos valdremos de Install-Module:

Install-Module posh-git -Scope CurrentUser -Force

Una vez instalado el módulo lo importaremos con Import-Module o utilizaremos la función Add-PoshGitToProfile que añadirá dicho Import-Module a nuestro perfil de PowerShell

# Opción 1: Importamos manualmente el módulo
Import-Module posh-git

# Opción 2: Modificamos nuestro perfil de PowerShell para que cargue automáticamente 
# (cerramos y abrimos la consola para que cargue el módulo)
Add-PoshToGitProfile

Utilizando Git con PowerShell mediante posh-git

Con posh-git ya instalado y cargado podemos empezar a trastear con Git. Para probar su funcionamiento vamos a hacer lo siguiente:

• Crear una nueva carpeta (nuestro «proyecto»).
• Inicializar un repositorio de git en ella.
• Añadir un archivo.
• Realizar un commit.

Antes de empezar configuraremos en Git nuestro correo y nuestro email (algo necesario para poder realizar nuestros commits):

C:\Scripts> git config --global user.email "marc@sobrebits.com"
C:\Scripts> git config --global user.name "Marc"

Con esto hecho podemos empezar con los primeros dos puntos:

En esta captura vemos un par de cosas interesantes:

• Los comandos de Git están disponibles en PowerShell gracias a la configuración del instalador en la pantalla «Adjusting your path environment».
• Una vez inicializado el repositorio nuestro prompt cambia indicando la rama en la que estamos (master) así como el título de la ventana que nos indica tanto el repositorio (Sobrebits-Git) como la rama.

Si ahora creamos un nuevo archivo en el repositorio veremos nuevos cambios en nuestro prompt:

Como podemos observar han aparecido unos números en rojo que nos vienen a indicar unas cuantas cosas:

• +1: Se ha creado un archivo nuevo en el repositorio.
• ~0: No se ha modificado ningún archivo.
• -0: No se ha eliminado ningún archivo.
• !: Existen archivos en el repositorio no trackeados.

Por último vamos a añadir nuestro nuevo archivo a la staging area y a crear nuestro primer commit:

• Al añadir nuestro nuevo archivo a la staging area vemos como la «!» del final se cambia por una «~», que nos indica que tenemos archivos pendientes de ser commiteados.
• Al hacer commit el prompt vuelve a su estado original.

Para más información sobre los cambios en el prompt te recomiendo que revises el README.md del proyecto en GitHub.

Conclusión

Con posh-git disponemos de la capacidad de usar Git con PowerShell sin depender de otras terminales en las que realizar nuestras operaciones de versionado.

En la segunda parte veremos cómo utilizar Git con PowerShell desde Visual Studio Code, el editor de preferencia de muchos para éste lenguaje.

¡Nos vemos en la próxima!

La entrada Cómo utilizar Git con PowerShell (Parte 1): posh-git aparece primero en Sobrebits.