Inicio
En concreto, en otro post hable de como crear un contenedor lxc, que contuviese un gitlab selfhosted corriendo en un docker.
Puedes leer ese artículo aquí
Vamos a mover ese contenedor topical-koi a otro servidor. En este caso será una máquina virtual que corre en un virtualbox.
En el siguiente diagrama voy a explicar un poco la insfraestructura de esta prueba de concepto.
El host (azul) es el equipo donde corre todo lo demás, en este equipo, está instalado lxc, y ahi corre el contenedor lxc topical-koi donde instalamos el gitlab en el otro artículo
En naranja, Virtualbox / ubuntu es un ubuntu server limpio, sin nada instalado, a lo largo de este articulo, vamos a instalar lxc y moveremos el contenedor topical-koi (verde) dentro del Lxc vacío que tenemos en el ubuntu del virtualhost
IPs:
Host -> 192.168.1.99
Virtualbox/ubuntu -> 192.168.1.119
topical-koi -> 10.61.111.52
Algo importante a tener en cuenta es que tenemos que tener la misma version de lxc y lxd en las dos máquinas. Es recomendable que sea la 3.X ya que es mucho mas estable. Para instalarla podemos hacerlo con apt install -t xenial-backports lxd lxd-client
Empezamos!!
En Virtualbox/ubuntu iniciamos lxd
lxd init
athos@ubuntu:~$ lxd init
Would you like to use LXD clustering? (yes/no) [default=no]:
Do you want to configure a new storage pool? (yes/no) [default=yes]:
Name of the new storage pool [default=default]:
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]:
Create a new BTRFS pool? (yes/no) [default=yes]:
Would you like to use an existing block device? (yes/no) [default=no]:
Size in GB of the new loop device (1GB minimum) [default=15GB]:
Would you like to connect to a MAAS server? (yes/no) [default=no]:
Would you like to create a new local network bridge? (yes/no) [default=yes]:
What should the new bridge be called? [default=lxdbr0]:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
Would you like LXD to be available over the network? (yes/no) [default=no]: yes
Address to bind LXD to (not including port) [default=all]:
Port to bind LXD to [default=8443]:
Trust password for new clients:
Again:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:
Podemos dejar todas las opciones por defecto salvo Would you like LXD to be available over the network? (yes/no) [default=no]: yes que pondremos a yes.
Esta configuracion para que lxd tenga funciones de red se puede hacer más adelante, pero lo vamos a dejar configurado ya en el init.
Ahora, en el host ejecutaremos lo siguiente:
lxc remote add virtualboxUbuntu 192.168.1.119
y veremos algo como esto:
lxc remote add virtualboxUbuntu 192.168.1.119
Certificate fingerprint: a133eb48bb6d7651877e69e90b4d15df92da0026b4f144668b3c7be0676720d9
ok (y/n)? y
Admin password for virtualboxUbuntu:
Client certificate stored at server: virtualboxUbuntu
En host, podemos comprobar los remotes y veremos lo siguiente:
lxc remote list
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| NAME | URL | PROTOCOL | AUTH TYPE | PUBLIC | STATIC |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| images | https://images.linuxcontainers.org | simplestreams | | YES | NO |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| local (default) | unix:// | lxd | tls | NO | YES |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | | YES | YES |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | | YES | YES |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
| virtualboxUbuntu | https://192.168.1.119:8443 | lxd | tls | NO | NO |
+------------------+------------------------------------------+---------------+-----------+--------+--------+
Como podemos ver, virtualboxUbuntu se ha añadido correctamente
Vamos a listar los snapshots que tiene nuestro contenedor
lxc info topical-koi |grep snap
snap0 (taken at 2020/02/16 18:05 UTC) (stateless)
Vemos que tiene un snapshot, vamos a hacer otro, que va a ser el que copiaremos a la máquina Virtualbox/ubuntu. Lo haremos con lxc snapshot topical-koi
Copiamos el snapshot del contenedor con lxc copy topical-koi/snap1 virtualboxUbuntu:topical-koi
Veremos algo como esto:
lxc copy topical-koi/snap1 virtualboxUbuntu:topical-koi
Transferring container: topical-koi: 1.62GB (61.52MB/s)
Cuando la transferencia termine, vamos a Virtualbox/ubuntu y hacemos un lxc list y veremos el contenedor en estado STOPPED
lxc list
+-------------+---------+------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+------+------+------------+-----------+
| topical-koi | STOPPED | | | PERSISTENT | 0 |
+-------------+---------+------+------+------------+-----------+
Iniciamos el contenedor con lxc start topical-koi
Aquí lo estamos haciendo en Virtualbox/Ubuntu
athos@ubuntu:~$ lxc list
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+
| topical-koi | RUNNING | 10.64.86.167 (eth0) | fd42:b674:7f2a:be14:216:3eff:fed6:743c (eth0) | PERSISTENT | 0 |
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+
Y aquí en el host
athos@athos-Z97P-D3:~$ lxc list
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+
| topical-koi | RUNNING | 172.17.0.1 (docker0) | fd42:41db:da07:9f1:216:3eff:fecf:1dda (eth0) | PERSISTENT | 2 |
| | | 10.202.6.91 (eth0) | | | |
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+
Podemos comprobar, en el contenedor original, tiene dos interfaces de red, docker0 y eth0, en cambio, en el contenedor copiado, sólo vemos una interface eth0, además, vemos que las interfaces eth0 tienen ips diferentes.
Vamos a conectarnos al contenedor con sólo una interface, y vamos a ver lo que pasa…
lxc exec topical-koi bash
root@topical-koi:~# docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
root@topical-koi:~# /etc/init.d/docker start
[....] Starting docker (via systemctl): docker.serviceJob for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
failed!
Esto sucede, porque al copiar el contenedor, no se ha copiado lo referente al interface de red que nos creo docker al instalarlo. En futuros post intentaremos solucionar esto, pero por el momento reinstalaremos docker.io para solucionar el problema.
apt update && apt purge docker.io -y && apt install docker.io -y
y ya podremos arrancar nuestro docker-compose con docker-compose up -d
En este momento, ya tendríamos nuestro clon de gitlab funcionando. No podemos acceder, ya que como el servidor Virtualbox/ubuntu lo tenemos detras de virtualbox, este crea una red interna y no tenemos acceso, para poder verlo tendriamos que crear unas reglas de redirección de tráfico.