El Dashboard de OpenStack es el equivalente al Portal de Azure o la Consola de AWS, un Portal donde podremos acceder para gestionar los recursos de nuestra nube, en este caso, de nuestra nube privada, complementado con OpenStack CLI para facilitar la automatización. En este Post os voy a contar cómo funciona la organización basada en Proyectos de OpenStack (similar a cómo lo hace Digital Ocean), para continuar con un tour sobre las diferentes pantallas del Dashboard (Proyecto Horizon), tanto como un usuarios regular, como con un usuario Admin, que ayudará mucho a comprender qué es OpenStack, y donde encontraremos de forma gráfica muchas similutes a otros proveedores Cloud como AWS, Azure, GCP o Digital Ocean, y finalmente introduciremos OpenStack CLI.
Continuando con la serie de Posts sobre OpenStack, después de que tratáramos hace unos días cómo instalar OpenStack en CentOS 7 con PackStack así como un breve introducción a OpenStack, en esta ocasión vamos a hablar sobre el Dashboard (proyecto Horizon), algo que además nos ayudará de forma muy visual a comprender qué es OpenStack además de que podremos compararlo con otros proveedores de nube pública, ya que veremos ciertas similitudes, además de hacer una introducción a OpenStack CLI. Comenzamos.
Proyectos y Usuarios en OpenStack
En OpenStack podemos crear Proyectos, así como usuarios de tipo Admin (super usuarios), y usuarios normales con permisos limitados sobre uno o varios Proyectos. Entremos en algo más de detalle.
Un Proyecto en OpenStack es una unidad organizativa de nuestra nube privada, algo similar a un concepto de cuenta o de tenant, a la que podemos dar acceso a usuarios (cada usuario puede acceder a uno o varios proyectos), ya sea con permisos elevados (admin) o limitados. Por defecto se incluyen dos Proyectos, services (donde se registran los diferentes Servicios de OpenStack) y admin, por lo que deberemos crear proyectos adicionales para nuestros usuarios y equipos, y asignar a cada usuario permisos sobre sus Proyectos. Tanto los Proyectos y los usuarios son gestionados a través de Keystone, y los podemos administrar desde la sección Identity del Dashboard, al igual que los grupos de usuarios.
Por ejemplo, la nube pública de Digital Ocean utiliza una aproximación a este concepto de Proyectos de OpenStack, de tal modo que podemos crear varios Proyectos, cada uno de los cuales tendrá unos recursos (ej: máquinas, load balancers, etc).
Si queremos crear un usuario desde el Dashboard, sería a través de Identity -> Users -> Create User, especificaríamos el nombre del usuario, contraseña, proyecto principal, y role (seleccionaremos _member_ para crear un usuario regular, con permisos restringidos), y listo. También tenemos el concepto de Dominios de OpenStack, que sería un nivel de agrupamiento superior a los Proyectos y usuarios, útil en nubes más grandes (por defecto, partimos de tener un único Dominio, el Default). En nuestro caso de ejemple, crearemos un usuario demo, tal y como se muestra en la siguiente pantalla, con acceso restringido al Proyecto admin.
La creación de Proyectos sería a través de Identity -> Projects -> Create Project, bastará con especificar el nombre del nuevo Proyecto, aunque también podemos añadir una descripción del mismo, y dar permisos (mediante roles: admin, member, etc) a usuarios y/o grupos. En nuestro caso de ejemplo, crearemos un Proyecto WebCorp y daremos acceso al usario admin (con role admin) y al usuario demo (con role de member).
Una vez creado el Proyecto podemos editarlo, pero también tenemos algunas opciones adicionales, como por ejemplo ver y modificar sus Quotas.
Las Quotas de un Proyecto permiten asignarle límites de recursos (Soft Limits) de diferentes tipos (Compute, Volume o Network) que se pueden utilizar en dicho Proyecto (ej: número de Instancias, Cores, RAM, volúmenes, redes, segmentos de red, etc.), de tal modo que los usuarios puedan realizar el auto-consumo de recursos, sin exceder dichos límites, y de este modo podamos tener un poco de control, y asegurar que tenemos hardware para ofrecerles el servicio al que nos comprometemos (evitando overbooking de recursos), además de evitar el desaprovechamiento de recursos que se podría producir si no ponemos ningún límite.
En el menú Identity -> Groups, podemos ver, crear, modificar, y eliminar los grupos de usuarios.
En el menún Identity -> Application Credentials, podemos crear aplicaciones o credenciales de aplicación, que pueden ser de utilidad para el acceso programático a OpenStack, evitando tener que utilizar las credenciales de un usuario. Sería algo similar al concepto de Service Principal de Azure, o a crearse un usuario IAM en AWS sin permisos de acceso a la Consola (es decir, sólo con permisos para el acceso programático mediante Access Key). En el caso de OpenStack, un Application Credential no se puede añadir a un grupo.
Recorriendo el Dashboard de OpenStack con un usuario regular
Si accedemos ahora al Dashboard con el usuario Demo, veremos que no nos aparece la sección Admin en el menú lateral derecho, al tratarse de un usuario regular. Podremos cambiar de Proyecto, seleccionando el que deseemos de aquellos sobre los que tenemos permisos, como se muestra en la siguiente imagen, y dentro del Proyecto, podemos navegar para ver la información que queramos, como las Instancias, Imágenes, etc. Es decir, un usuario regular tiene que seleccionar un Proyecto sobre el que tenga permisos, y podrá trabajar en el Dashboard sobre los recursos de ese Proyecto, pudiendo cambiar a otro Proyecto sobre el que tenga permisos siempre que quiera, pero siempre teniendo una visión local del Proyecto en el que está posicionado.
Por ejemplo, en el menu Project -> Compute -> Instances (las Instancias son las VMs que creamos y se ejecutan dentro de nuestra infraestructura de OpenStack), podemos listarlas, crear nuevas Instancias, pararlas, cambiar ciertos atributos, etc, dentro del Proyecto actual (en la siguiente pantalla capturada, sería el Proyecto WebCorp).
En el menú Project -> Compute -> Images, podremos ver las imágenes públicas y las específicas de nuestro Proyecto, además de añadir nuevas imágenes, eliminarlas, etc.
En el menú Project -> Compute -> Key Pairs, podemos crear, eliminar, e importar claves que podemos usar para el acceso SSH a nuestras Instancias sin contraseña, de forma muy similar a como se hace en AWS. En el caso de crear una nueva clave SSH, al crearla nos descargaremos el fichero PEM de forma automática.
En el menú Project -> Compute -> Server Groups, podemos crear grupos de afinidad para servidores, para conseguir por ejemplo que un grupo de Instancias puedan correr en el mismo Nodo, dependiendo de la Política que seleccionemos.
En el menú Project -> Volumes -> Volumes, podemos entre otras cosas ver, crear, editar, extender y eliminar Volúmes, es decir, almacenamiento persistente de tipo Block Storage, lo que viene a ser el Disco Virtual de una VM, el equivalente a los Managed Disks de Azure, EBS de AWS, o Volumes de Digital Ocean. De este modo podemos crear los Volúmenes o Discos que necesitemos, y conectarlos a nuestras Instancias, para dotarlas de almacenamiento persistente.
En el menú Project -> Volumes -> Snapshots, podemos ver, editar y borrar Snapshots, además de poder crear un Volumen desde un Snapshot existente, por ejemplo, por motivos de Backup.
En el menú Project -> Volumes -> Groups, podemos definir grupos de volúmenes, lo que nos proporciona un mecanismo para crear Snapshots consistentes de múltiples volúmenes en el mismo momento del tiempo.
En el menú Project -> Volumes -> Group Snapshots, podemos ver y gestionar los Snapshots de los Volume Groups.
En el menú Project -> Network -> Network Topology, se muestra una representación visual de nuestra red, aunque en nuestro caso con OpenStack recién instalado, no resulta muy visual ni representativo, pero cuando tenemos más redes, es de gran ayuda.
En el menú Project -> Network -> Networks, podemos crear, editar, y eliminar, Networks, Subnets y Ports. Los Ports serían algo equivalente a las NICs, es decir, las tarjetas de red de nuestas Instancias, por lo que nos proporcionarán la forma de conectar una Instancia a un segmento de red con una dirección IP.
En el menú Project -> Network -> Routers, podemos crear, editar, y eliminar Routers, que nos permitirán gestionar en el enrutamiento entre nuestras redes privadas de los Proyectos, o entre nuestras redes de Proyectos y redes externas. Necesitamos tener al menos un Router para acceder de una red a otra, aunque estén en el mismo Proyecto.
En el menú Project -> Network -> Security Groups, podemos crear, editar, y eliminar los Security Groups. Estos objetos permiten definir reglas de filtrado (access control lists) para permitir o denegar tráfico IP para o desde nuestras Instancias, como si fueran unos sencillos firewalls. Una vez creados, los podemos asignar a nuestras Instancias, para securizar el entorno. Son equivalentes a los Network Security Groups (NSG) de Azure, los Security Groups de AWS, o los Firewalls de Digital Ocean.
En el menú Network -> Floating IPs, podemos configurar IPs externas (ej: IPs públicas de Internet o IPs de segmentos de red externos) y mapearlas a las NIC de nuestras Instancias, para que sean accesibles desde el exterior.
En el menú Project -> Network -> Trunks, podemos crear, editar, y eliminar Trunks. Un Trunk es como un Port (una NIC), que permite agregar varios Ports (varias NICs) cada uno de los cuales puede estar en una VLAN diferente, que conectaremos a una Instancia para dotarle de esa conectividad.
En el menú Project -> Object Store -> Containers, podemos crear, editar, y eliminar Contenedores (Object Storage), lo que sería el equivalente a Azure Blob Storage, AWS Bucket S3, o Digital Ocean Spaces. Estos contenedores pueden ser públicos o privados, y dentro podemos crear carpetas y subir ficheros.
En el menú API Access, podemos ver los diferentes endpoints de nuestra instalación de OpenStack.
Recorriendo el Dashboard de OpenStack con un usuario Admin
Al acceder con un usuario Admin al Dashboard, veremos lo mismo que un usuario regular, pero además tendremos disponible la sección Admin en el menú lateral izquierdo. La sección de Admin tiene de especial, que da acceso a algunas configuraciones adicionales que no ven los usuarios regulares (como Hypervisors o Flavors, por poner un ejemplo) y que además podemos y administrar los recursos de todos los Proyectos, no sólo del actual. Lo vemos más gráficamente a continuación.
En el menú Admin -> Compute -> Hypervisors, podemos ver un resumen de los Hypervisors disponibles en nuestra instalación de OpenStack, de qué tipo son (ej: QEMU), cuantos cores y memoria tienen, etc.
En el menú Admin -> Compute -> Host Aggregates, podemos crear, editar, y eliminar Host Aggregates, que consisten en grupos de servidores asociados a una zona de disponibilidad. Además, también podemos ver un resumen de las zonas de disponibilidad y los servidores que la forman.
En el menú Admin -> Compute -> Instances, podemos ver, crear, editar, reiniciar (de forma hard o soft), suspender, y eliminar Instancias, entre otras cosas. También podemos ver el Log de una Instancia, y conectarnos a través de VNC.
En el menú Admin -> Computer -> Flavors, podemos ver, crear, modificar, o eliminar Flavors. Un Flavor define básicamente el tamaño o talla de una instancia.
En el menú Admin -> Compute -> Images, podemos ver, crear, modificar, o eliminar todas las imágenes, tanto las imágenes públicas y las específicas de nuestro Proyecto.
En el menú Admin -> Volume, podemos por un lado crear, modificar y eliminar volúmenes, snapshots, y tipos de volumen, y por otro lado los grupos de volúmnes, grupos de snapshots, y tipos de grupos, independientemente del Proyecto (como comentábamos antes). Por ejemplo, en la siguiente pantalla capturada, estamos posicionados en el Proyecto admin (ver barra superior), y viendo un Volumen del Proyecto WebCorp.
En el menú Admin -> Network, podemos ver, crear, modificar, o eliminar tanto Redes (incluyendo Subnets y Ports), como Routers, Floating IPs, y RBAC Policies, independientemente del Proyecto en el que estemos conectados. En la siguiente imagen, estamos conectados al Proyecto WebCorp, y viendo una Red del Proyecto admin (básicamente, la única Red que tenemos, ya que se trata del entorno de laboratorio que acabamos de instalar en el Post anterior).
En el menú Admin -> System -> Defaults, podemos ver la definición de Quotas por defecto, tanto de Compute como de Volume y Network, que se utilizarán en la creación de nuevos Proyectos. Si queremos cambiar estas Quotas por defecto, para que aplique un valor diferente la próxima vez que se cree un nuevo Proyecto en OpenStack, este es el lugar.
En el menú Admin -> System -> Metadata Definitions, podemos ver y modificar la definición de metadatos de OpenStack.
En el menún Admin -> System -> System Information, podemos ver el estado de diferentes servicios de OpenStack, en qué máquina corre qué servicios, sus EndPoints, y alguna otra información que puede ser de utilidad en alguna ocasión.
OpenStack CLI, trabajando con OpenStack desde línea de comandos
No siempre vamos a querer o necesitar realizar nuestras tareas de forma gráfica desde una GUI, tener una CLI es fundamental.
OpenStack CLI es un paquete del sistema operativo, que podemos instalar en cualquier máquina (no sólo en los servidores OpenStack) y que proporciona la interfaz de línea de comandos de OpenStack, capaz de convertir nuestras instrucciones en llamadas a los EndPoints de los diferentes servicios de OpenStack, para obtener la información solicitada o ejecutar las acciones indicadas.
Inicialmente, cada Proyecto de OpenStack proporcionaba su propia CLI, lo que proporcionaba algo de confusión y mala experiencia de usuario, al tener que estar cambiando de comando (ej: nova, neutron, cinder, etc) en función de que acción queríamos realizar.
Como consecuencia de esto, la CLI unificada de OpenStack ha ido asumiendo las funciones de las CLI de los diferentes Proyectos OpenStack y es la CLI preferente a utilizar (sustituyendo a las CLI locales de cada Proyecto), permitiendo tener un único comando para iteraccionar con OpenStack, a la vez que van quedando deprecadas las CLI de cada Proyecto OpenStack, aunque podríamos encontrarnos con algún caso muy concreto en el que aún necesitemos utilizar la CLI específica de un Proyecto OpenStack, en lugar de la CLI unificada, por algún detalle que aún no este completamente implementado en esta última, pero es algo excepcional.
De este modo, podríamos ver a OpenStack CLI de forma similar a Azure CLI ó AWS CLI.
Para usar OpenStack CLI debemos autenticarnos primero con un usuario con los permisos pertinentes, algo que podemos hacer de dos formas diferentes:
- A través de parámetros de la línea de comandos. Esta opción es la más incómoda y la menos segura.
- A través de variables de entorno del Sistema Operativo (opción recomendada). Tan sencillo como cargar el fichero Bash con nuestras credenciales (ej: el fichero keystonerc_admin que se genera durante la instalación), que definirá las variables de entorno necesarias para la CLI, y listo. Incluso podríamos utilizar varios ficheros de credenciales, si necesitamos autenticarnos con diferentes identidades (y permisos) según la ocasión, no habría problema.
Desde el Dashboard podemos descargar nuestro fichero RC que contiene las variables de entorno para que podamos utilizar la CLI.
A continuación se muestra un ejemplo, en el que intentamos ejecutar OpenStack CLI sin estar autenticados recibiendo un error, y tras autenticarnos mediante el establecimiento de variables de entorno del usuario admin (el fichero RC que se genera durante la instalación de OpenStack), podemos ejecutar con éxito el mismo comando CLI.
Podemos consultar la propia ayuda de OpenStack CLI o incluso listar todos los comandos disponible. Esto último es muy útil, al poder filtrar por el EndPoint que nos interesa, para hacer foco en los comandos de un componente de OpenStack o de otro.
openstack help
openstack command list
openstack command list | grep openstack.object_store -A 20A modo de ejemplo, en la siguiente pantalla captura se puede ver como listar los comandos de object_store.v1.
Despedida y Cierre
Hasta aquí llega este Post de OpenStack, donde a través del Dashboard he intentado transmitirte de forma gráfica en qué consiste OpenStack completando el anterior Post de introducción e instalacción de OpenStack, además de explicar la organización en Proyectos que sigue OpenStack, e introduciendo levemente OpenStack CLI.
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.