Transferir VPS de un proyecto Public Cloud OVH a otro
Tengo que decir que soy un enamorado de lo que yo llamo "virtualización de última generación". Como no soy ningún doctor en terminología - ni mucho menos - hablo de Docker, OpenVZ, Proxmox, OpenStack... que habitualmente tienen herramientas e interfaces más que asequibles para resolver muchos de los problemas que, a nivel de sistemas, se presentan hoy día.
En este caso concreto tenía un cliente al que administro una máquina muy básica, una especie de LAMP para sus proyectos personales y de desarrollo web. Hasta hace nada tenía esa máquina en mi cuenta de OVH y, por varios motivos nos apetecía transferirla a su cuenta de OVH, donde gestiona pagos, dominios y el resto de productos.
Para más datos la máquina es un VPS de un proyecto Public Cloud en el que tengo otras instancias que nada tienen que ver con ella (mea culpa, debería haber tenido un proyecto por cliente, ojalá lo hubiera sabido cuando decidí probar el public cloud).
Despues de varias consultas telefónicas al soporte técnico de OVH España y a través de la cuenta de Twitter (@ovh_support_es) conseguí los enlaces a las correspondientes guías que juegan con este tipo de servicios, me hice un café y me lié la manta a la cabeza dispuesto a divertirme un rato. Y así fue.
Poner en orden los términos
Dentro de OVH tenemos la tecnología Cloud, donde podemos crear proyectos (proyectos Public Cloud). Dentro de esos proyectos es donde albergamos los VPS. En mi caso concreto tengo un sólo proyecto Public Cloud y como quiero transferir un VPS de ese proyecto a otro cliente tengo dos opciones:
- Crear otro proyecto public cloud distinto que será el destinatario.
- Entrar en la cuenta del cliente y crear un proyecto public cloud que actuará como destinatario.
Cualquiera de las dos opciones es válida, a fin de cuentas vamos a trabajar "de proyecto public cloud a proyecto public cloud" independientemente de quien sea el propietario de los mismos.
OVH trabaja con OpenStack de fondo. OpenStack es un proyecto computación en la nube para proporcionar una infraestructura como servicio (IaaS). Es open source y distribuido bajo la licencia Apache. Consiste en varios proyectos relacionados entre sí que controlan estanques de control de procesamiento, almacenamiento y recursos de red a través de un centro de datos, todos administrados a través de un panel de control que permite a los administradores controlar mientras potencia a sus usuarios proveyendo los recursos a través de una interfaz web. (vía Wikipedia). Algunos de esos proyectos o componentes que nos interesa tener en mente:
- Compute (Nova): Es el controlador de la estructura cloud, escrito en Python (yay!), diseñado para escalar horizontalmente en hardware standard.
- Dashboard (Horizon): Proporciona una interfaz gráfica (web) para el acceso, provisión y automatización de los recursos basados en cloud. También gestiona los recursos de seguridad y/o acceso a API.
- Servicio de Imagen (Glance): Proporciona servicios de descubrimiento, de inscripción y de entrega de los discos y del servidor de imágenes.
Creo que con eso es suficiente, usaremos Nova como cliente de OpenStack, Horizon para crear usuarios y acceso a API y Glance para trabajar con las imágenes.
Crear acceso Horizon
El primer paso es crear el acceso a Horizon, la interfaz web dashboard de OpenStack. Para ello vamos al manager de cada uno de nuestros proyectos cloud (recordad que estamos trabajando con dos proyectos, el que tiene el VPS y el que lo quiere), Gestión y consumo del proyecto → OpenStack y creamos un nuevo usuario. Insisto, haremos ésto por cada uno de los dos proyectos que tenemos.
Una vez creamos el usuario ya tenemos acceso a Horizon para obtener las claves API, que será el siguiente paso.
Preparar el entorno para usar OpenStack
Ahora debemos preparar una máquina para que actúe como cliente de OpenStack e interactuar con los proyectos y las máquinas virtuales que tenemos, como las guías referencia de OVH hablan de Debian, CentOS y Windows cogemos una máquina Debian cualquiera que tengamos por ahí perdida - que tenga espacio suficiente y, si está en ovh mejor que mejor por la transferencia de red - e instalamos los clientes de nova y glance:
# apt-get update # apt-get install python-glanceclient python-novaclient -y # nova help # glance help
Ahora nos vamos a nuestro Horizon (hemos creado el usuario en el paso anterior) y creamos un acceso para poder trabajar contra él con el cliente vía api, en la barra lateral vemos Accesos y seguridad → Acceso a la API → Descargar fichero RC de OpenStack. Hacemos lo mismo con los dos proyectos que tenemos y conseguimos estos dos archivos:
3653162169886180-openrc.sh(mis proyecto público, con varias instancias).8844589259929700-openrc.sh(el de mi cliente, con ninguna).
Una vez tenemos los archivos los transferimos a la máquina que actuará como cliente OpenStack para poder trabajar contra ambos proyectos (he decidido guardar todo lo que tenga que ver con OpenStack en la ruta /home/openstack, cada uno es libre de hacerlo donde quiera):
# scp 3653162169886180-openrc user@host:/home/openstack/micloud.sh # scp 8844589259929700-openrc.sh user@host:/home/openstack/clientecloud.sh
Ya tenemos los archivos de entorno, cargamos con el que queramos trabajar primero (la contraseña la tenemos en el panel donde anteriormente hemos creado el usuario para horizon), en este caso voy a cargar el de micloud.sh porque empezaré trabajando en ese proyecto:
# source micloud.sh Please enter your OpenStack Password:
Transferir snapshot de una cuenta a otra
Teóricamente ya tenemos todo listo para interactuar desde la máquina que actúa de cliente con proyectos, instancias y las copias de seguridad. Recordamos que en el último comando del paso anterior hemos cargado las variables de entorno de micloud.sh, vamos a comprobar que todo es correcto, listamos las instancias:
# nova list +--------------------------------------+--------------------+--------+------------+-------------+ | ID | Name | Status | Task State | Power State | +--------------------------------------+--------------------+--------+------------+-------------+ | ed677883-9c70-4b56-a21a-7dde34b4b149 | cliente.vps | ACTIVE | - | Running | | d12531a-d151-4d5a-9219-d9665094e4a64 | mi.vps | ACTIVE | - | Running | +--------------------------------------+--------------------+--------+------------+-------------+
También podemos usar glance para listar las imágenes que tenemos a nuestra disposición:
# glance image-list +--------------------------------------+----------------------------------+-------------+------------------+--------------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+----------------------------------+-------------+------------------+--------------+--------+ | 92087692-94fd-4958-9784-61hy5a317590 | Centos 6 | raw | bare | 8589934592 | active | | c17f13b5-587f-4304-b550-eb939738289a | Centos 7 | raw | bare | 2149580800 | active | | 07dcb6a0-0a9a-47ed-bc36-546523ef65e3 | CoreOS stable 899.15.0 | raw | bare | 9116319744 | active | | 73958794-ecf6-4e68-ab7f-1506eadab05b | Debian 7 | raw | bare | 2149580800 | active | | bdcb5042-3548-40d0-b06f-79551d3c4377 | Debian 8 | raw | bare | 2149580800 | active | | 7250cc02-ccc1-4a46-8361-a3d6d9111177 | Fedora 19 | raw | bare | 2149580800 | active | | 57b9722a-e6e8-4a55-8146-3e36a4777b78 | Fedora 20 | raw | bare | 2149580800 | active | | a5006914-ef04-41f3-8b90-6b99d0261a99 | FreeBSD 10.3 UFS | raw | bare | 5242880000 | active | | 5a13b9a6-02f6-4f9f-bbb5-b131852848e8 | FreeBSD 10.3 ZFS | raw | bare | 5242880000 | active | | 3bda2a66-5c24-4b1d-b850-83333b581674 | Ubuntu 12.04 | raw | bare | 2149580800 | active | | 9bfac38c-688f-4b63-bf3b-69155463d0e7 | Ubuntu 14.04 | raw | bare | 10737418240 | active | | 0c58e90e-168e-498a-a819-26792e4c769e | Ubuntu 15.10 | qcow2 | bare | 309854720 | active | | cdc798d0-8688-45c1-bd7c-69bec0c2a0b2 | Ubuntu 16.04 | raw | bare | 2361393152 | active | | 7d983a54-d06b-488f-986c-ba0eaa980a51 | ubuntu-14.04-rescue | raw | bare | 1073741824 | active | | bb37762b-5a82-4c2b-b72b-91ea1016a941 | Windows-Server-2012-r2 | raw | bare | 107374182400 | active | | 3e092033-906b-4ef1-bdfb-76155126f5ac | snapshot.mi.vps | qcow2 | bare | 10324344832 | active | +--------------------------------------+----------------------------------+-------------+------------------+--------------+--------+
Bien, ahora que lo tenemos todo, nos disponemos a crear una snapshot del servidor que queremos transferir (cliente.vps), puesto que no tenemos ninguna creada:
# nova image-create ed677883-9c70-4b56-a21a-7dde34b4b149 cliente_snapshot # glance image-list | grep cliente | 9c5d7d92-5b48-42be-8a49-f4f33b0235a4 | cliente_snapshot | raw | bare | | queued |
Esperamos que pase de queued a active para tenerla disponible antes de continuar, una vez disponible nos fijamos en el id y la descargamos a disco:
# glance image-download --file cliente_snapshot.qcow 9c5d7d92-5b48-42be-8a49-f4f33b0235a4
Una vez tenemos la imagen descargada cambiamos las variables de entorno para trabajar contra el otro proyecto. Nota: Podemos trabajar directamente contra otro proyecto de otra cuenta de cliente, no hace falta hacerlo en la misma cuenta de OVH. Vemos que se trata del otro proyecto porque, en este caso, no tenemos ninguna instancia ejecutándose:
# source clientecloud.sh Please enter your OpenStack Password:
# nova list +----+------+--------+------------+-------------+----------+ | ID | Name | Status | Task State | Power State | Networks | +----+------+--------+------------+-------------+----------+ +----+------+--------+------------+-------------+----------+
El siguiente paso será enviar el snapshot que acabamos de crear a este proyecto y - finalmente - crear la tan esperada instancia vps partiendo de esa imagen:
# glance image-create --name cliente_snapshot --disk-format qcow2 --container-format bare --file cliente_snapshot.qcow +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | 411b684734ae0a07bda42bb0da5f9166 | | container_format | bare | | created_at | 2016-05-12T09:23:47 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | ab64a222-433a-4d89-8285-ed4a726b3b24 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | cliente_snapshot | | owner | 4g4456hs21s121d12e6ff8d8r8qa8928 | | protected | False | | size | 4524015616 | | status | active | | updated_at | 2016-05-12T09:29:55 | | virtual_size | None | +------------------+--------------------------------------+
Para la creación de la nueva instancia recomiendo hacerlo directamente a través de la interfaz web de ovh (o en horizon), porque será más sencillo seleccionar las características adecuadas al VPS, de todas formas también se puede hacer a través del cliente, el comando sería el siguiente:
# nova boot --key_name SSHKEY --flavor 98c1e679-5f2c-4069-b4da-4a4f7179b758 --image ab64a222-433a-4d89-8285-ed4a726b3b24 clientserver_from_snap
Y con ésto ya estaría el VPS transferido de un proyecto public cloud de una cuenta de ovh a otro proyecto public cloud de otra cuenta distinta. Ha sido un poco lioso pero el esfuerzo y la diversión han merecido la pena.
Bola Extra
¡Las guías!, sin ellas no habría sido capaz de hacer asolutamente nada:
- Guía para crear un acceso a Horizon
- Guía para preparar una máquina como cliente OpenStack
- Guía para conseguir el fichero de variables en Horizon
- Guía para cargar el entorno de proyecto desde el cliente OpenStack
- Guía para transferir una copia de seguridad entre cuentas