Tales from a Solution Architect vMotioning from Solution Engineering to Solution Architects

Vagrant y vSphere

En el post de hoy, exploraremos como instalar Vagrant sobre CentOS 7.2 y cómo podemos hacer que vagrant up clone un template.

Lo primero de todo, desplegaremos nuestra máquina de desarrollo sobre CentOS 7.2, una vez desplegado, instalaremos vagrant, en el momento de redactar este post la 1.9.1 ya que la 1.9.2 sufre de un bug de dependencias en las gems:

 wget https://releases.hashicorp.com/vagrant/1.9.1/vagrant_1.9.1_x86_64.rpm
 yum localinstall vagrant_1.9.1_x86_64.rpm

Una vez instalado, instalaremos el plugin de vagrant-vsphere, que es el driver que se ocupará de la comunicación con el vCenter/ESXi:

vagrant plugin install vagrant-vsphere

Nos decargaremos el fichero metadate.json que está preparado como template para el driver y lo descomprimiremos:

curl -k https://raw.githubusercontent.com/nsidc/vagrant-vsphere/master/example_box/metadata.json -O
tar cvzf vsphere-dummy.box ./metadata.json

Añadiremos un nuevo box vacío, que nos valdrá como placeholder en la comunicación:

vagrant box add vsphere-dummy ./vsphere-dummy.box

Una vez añadido, podemos verificar que el box se ha creado correctamente

[root@chefdev ~]# vagrant box list

vsphere-dummy (vsphere, 0)

Crearemos un Vagrantfile similar a este:

Vagrant.configure("2") do |config|
  config.vm.box = "vsphere-dummy"
  config.vm.provider :vsphere do |vsphere|
    # The vSphere host we're going to connect to
    vsphere.host = 'vcenter.vfondevilla.com'
   # The ESX host for the new VM
    vsphere.compute_resource_name = 'pCluster'
    # The template we're going to clone
    vsphere.template_name = 'vagrant-centos'
    # The name of the new machine
    vsphere.name = 'vagrant-centos-test'
    # vSphere login
    vsphere.user = 'administrator@vsphere.local'
    # vSphere password
    vsphere.password = 'SuPerPassw0rdComplicada!'
    # If you don't have SSL configured correctly, set this to 'true'
    vsphere.insecure = true
  end
end

Con esto, tendremos la máquina de desarrollo completa, a falta de instalar el software de gestión de configuración que prefieras (Ansible, Chef, Puppet, Salt…), ya solo nos falta crear el template, con los siguientes pasos:

  • Desplegar una nueva VM
  • Añadir el usuario vagrant con la contraseña “vagrant”
  • Añadir el usuario vagrant al fichero sudoers “vagrant ALL=(ALL) NOPASSWD:ALL”
  • Añadir la clave de Vagrant al usuario vagrant
    mkdir -p /home/vagrant/.ssh
    wget --no-check-certificate https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub -O /home/vagrant/.ssh/authorized_keys
    chmod 0700 /home/vagrant/.ssh
    chmod 0600 /home/vagrant/.ssh/authorized_keys
    chown -R vagrant /home/vagrant/.ssh
    

Con estos pasos, podemos proceder a apagar la VM y convertirla en un template. A partir de ese momento, cuando hagamos vagrant up en la máquina de desarrollo, nos creará una nueva VM a partir del template de Vagrant.

[root@chefdev ~]# vagrant up
Bringing machine 'default' up with 'vsphere' provider...
==> default: Calling vSphere CloneVM with the following settings:
==> default:  -- Template VM: Homelab/vm/vagrant-centos
==> default:  -- Target VM: Homelab/vm/vagrant-centos-test
==> default: New virtual machine successfully cloned
==> default: Waiting for the machine to report its IP address...
    default: Timeout: 240 seconds
    default: IP: 10.2.0.142
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 10.2.0.142:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Installing rsync to the VM...
==> default: Rsyncing folder: /root/ => /vagrant

Problemas usando el instalador de VCSA 6.5 en MacOS Sierra

Al ir a actualizar mi laboratorio (sí, voy tarde, lo sé), desde MacOS Sierra, me he encontrado con algún bug del instalador.

Al llegar al paso número 6, que es seleccionar el tamaño del appliance VCSA, da un error Error: ovftool is not available. Esto pasa porque por algún motivo, en vez de ir a /Applications el instalador busca en /private.

Si te descargas el log del instalador (desde la misma ventana), tendrás una línea similar a esta:

2016-12-22T19:44:58.727Z - error: could not find ovftoolCmd: /private/var/folders/f0/gzgd0d8j52s8q5x17j12dq6w0000gn/T/AppTranslocation/vcsa/ovftool/mac/ovftool

La solución es tan simple como copiar el directorio vcsa de de la ISO al directorio de /private/var/folders/f0/randomstring/T/AppTranslocation/

Un vez instalado, ya podrás ejecutar la instalación.

Plugin NFS VAAI de Synology en VMware vSphere 6.0

Como no es la primera vez que me lo preguntan, sí, el plugin de VAAI de vSphere, que según el README de Synology es solo para versión 5.5, funciona correctamente en VMware vSphere 6.0. Lo he instalado en los hosts del laboratorio, con el comando que detalla el README, añadiendo –no-sig-check al final.

Quedaría de la siguiente forma:

esxcli software vib install -v /esx-nfsplugin.vib --no-sig-check

Después de reiniciar los hosts, veremos que en la opción de “Hardware Acceleration” aparecerá “Supported”

Reflexiones sobre el Cloud y sus aplicaciones

A raíz de unas jornadas en mi actual empleador, hemos estado hablando sobre el estado del Cloud y sobre el portfolio de una nueva empresa que se ha incorporado al grupo, provocando que por una vez le de al coco. Voy a evitar hablar sobre Devops, Infrastructure as Code, Continuous integration, Continuous development y demás términos que muchos ya estamos acostumbrados, y voy a centrarme en otro aspecto mucho menos tenido en cuenta, pero que marca una diferencia brutal. La arquitectura.

¿Qué se define exactamente como Cloud?

Según el NIST, y cito textualmente:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

Con las siguientes características:

On-demand self-service.

Broad network access.

Resource pooling.

Rapid elasticity.

Measured service.

Esto significa que no es posible hablar de Cloud fuera de las grandes casas (Amazon Web Services, Microsoft Azure, Google Cloud Platform)? Para nada, se puede desarrollar un cloud interno, apoyado por tecnologías ahora mismo disponibles para las empresas, como VMware vSphere y OpenStack, pero hay mucho proveedor “cloud” que no lo es, por mucho que se empeñen en decir que lo son.

Pero todos sabemos que queda muy cool decir que tal o cual empresa ya está en la nube, cuando realmente sus aplicaciones ni son cloud-ready ni cloud-native-applications.

Y se llega al quid de la cuestión, ¿todas las empresas pueden tener su infraestructura en la nube? Y aquí llega la respuesta de consultor: “Depende”.

Por poder puedes tener la infraestructura que quieras en la nube, pero puede que no le estés sacando todo el rendimiento que crees ni podrás hacerlo, si tus aplicaciones no están pensadas para funcionar en la nube. Lo primero que acarrea el Cloud, es un cambio en el paradigma de la arquitectura de aplicaciones, más que un cambio en la forma de operar las mismas (el archiconocido devops) donde la aplicación deberá ser capaz de funcionar bajo eliminaciones aleatorias de instancias, problemas de conectividad y mil calamidades más.

Este cambio de paradigma queda reflejado en los Twelve factors, que toda aplicación realmente Cloud-Native debería cumplir, actualmente fijados en lo siguiente:

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes ```

¿Qué significan estos factors? Un cambio en la forma de diseñar las aplicaciones. Un cambio en la mentalidad de la arquitectura. Pasar de pets a cattles. Pasar de monolytic architecture a distributed architecture. Pasar de conexiones directas entre servicios al uso de APIs y mensajería asíncrona.

Si no eres capaz de asumir este cambio, lo siento, tu aplicación no está hecha para funcionar en la nube. Por lo menos no permitiéndote mantener tu salud mental. Ni la de tu equipo de Operaciones.

Modificando umbrales de alerta de los ventiladores en Supermicro

En el post de hoy, voy a cubrir lo que hay que hacer para poder cambiar los umbrales de alerta de los ventiladores en las placa base de Supermicro. Si habeis leído la información sobre mi lab, tengo un par de máquinas Supermicro (un Xeon D-1520 y un D-1540), siendo la 1520 fanless y sinceramente, se calienta mucho. Así que le he puesto un ventilador Noctua como he podido, pero funciona tan bien que bajaba a 300 revoluciones, y hacía que saltara una alarma tanto en la IPMI como en vCenter, saturándome el correo siendo muy molesto.

La solución? Modificar los umbrales de la IPMI, pero esto no puede hacerse desde la interfaz web, pero sí mediante línea de comandos.

Primeros instalaremos la herramienta IPMITOOL, en mi caso usando Brew (estoy en un Mac).

A continuación, ejecutaremos el siguiente comando: ipmitool -U ADMIN -P ADMIN -H IP sensor thresh lower FAN2 150 225 300

Donde el primer valor (150) es el error Lower Non-Recoverable, el segundo (225) es el Lower Critical y 300 es el Lower Non-Critical. Con esto, conseguimos modificar los valores. En mi caso no me hizo falta reiniciar, y ya dejaron de llegarme los avisos.