LXD – upgrades sem riscos

Este artigo é o 2º da série sobre virtualização com LXD. O 1º artigo fez uma introdução rápida ao lxd.

Já tenho todas as minhas aplicações web instaladas em containers LXD separados, numa vps de 3gb ram e 4 vcores, baseada em kvm. Comprei na última black friday e custa-me 5€/mês. Quem estiver à procura de vps baratas recomendo verem aqui: https://lowendbox.com/.

Nesta altura, tenho 3 máquinas:

~$ lxc list
+------------+---------+----------------------+------+------------+-----------+
|    NAME    |  STATE  |         IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
+------------+---------+----------------------+------+------------+-----------+
| dncplex    | RUNNING | 10.166.62.195 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| planetasig | RUNNING | 10.166.62.245 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| viasigwp   | RUNNING | 10.166.62.152 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+

A máquina “dncplex” é o meu servidor de música, com plex server e o fantástico MyMedia for Alexa! que permite aceder à minha biblioteca de música no meu Echo!

A “planetasig” é obviamente o PlanetaSIG, e a “viasigwp” é este mesmo blog.

Como tive sempre receio de upgrades de versões major no wordpress fui adiando o upgrade da v3 para a v4. E esta já vai na v4.9.5. Está mesmo na altura de fazer o upgrade à prova de falha.

Uma vez que uso o lxd, o plano é copiar o container para um novo, e fazer aí o upgrade. Se correr bem, paro o container antigo v3, e fico com o novo já com o wordpress v4. Se correr mal, apago e recomeço, ou desisto e fico na mesma… risco 0…

Clonar o container original

Para copiar ou clonar um container lxd é muito simples – basta usar o comando copy:

$ lxc copy viasigwp viasigwp4

$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | RUNNING | 10.166.62.152 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | STOPPED | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

Ok, o nosso novo container está parado. Temos de o iniciar…

$ lxc start viasigwp4
$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | RUNNING | 10.166.62.152 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | RUNNING | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

O IP ainda não está atribuído pelo dhcp do lxd, mas é só esperar um pouco e será atribuído um novo IP. (acabou por ser atribuído o ip 10.166.62.181)

Vamos parar o container original para evitar confusões e termos a certeza que vamos realmente usar o novo. O comando para parar containers lxd é stop obviamente:

$ lxc stop viasigwp
Configurar o tráfego no HAProxy

Eu ainda farei um artigo sobre a configuração do tráfego entre a internet e os containers lxd. Por agora, vou apenas rapidamente mostrar a alteração do ip ligado ao domínio do blog.viasig.com. Ou seja, o tráfego que chega à vps usando o nome blog.viasig.com era dirigido para o container original “viasigwp” com ip 10.166.62.245.

Agora, temos um novo container, onde faremos o upgrade, que tem um novo ip 10.166.62.181. É para este novo ip que o HAProxy deve enviar o tráfego do endereço blog.viasig.

Mostro abaixo a parte da configuração do HAProxy relevante para o blog a negrito e laranja (apenas no final da secção abaixo):

$ sudo nano /etc/haproxy/haproxy.cfg

frontend public
 # Listen on port 80
 bind *:80

 mode http

#redirecionamentos de dominios http para https,
#antes de definirmos os servidores http para os dominios http
#1-blog.viasig.com
redirect scheme https code 301 if !{ ssl_fc } { hdr(host) -i blog.viasig.com }

#como uso https no blog, este é o frontend que redireciona o seu trafego
frontend public_https
 bind *:443
 mode tcp
 option tcplog
 tcp-request inspect-delay 5s
 tcp-request content accept if { req_ssl_hello_type 1 }
 default_backend bk_ssl_default

backend bk_ssl_default
 mode tcp
 option tcplog
 acl blogviasig_https req_ssl_sni -i blog.viasig.com

 use-server server1 if blogviasig_https

 option ssl-hello-chk
 #o blog v3 é desativado
 #server server1 10.166.62.152:443 check
 #e o novo v4 é ativado
 server server1 10.166.62.181:443 check

Testamos a configuração só para ter a certeza que está correcta, e carregamos a nova config:

$ sudo haproxy -c -V -f /etc/haproxy/haproxy.cfg
 Configuration file is valid
 $ sudo systemctl reload haproxy
 $ systemctl status haproxy
 ● haproxy.service - HAProxy Load Balancer
 Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset:
 Active: active (running) (Result: exit-code) since Tue 2018-12-04 19:16:08 WE
 Docs: man:haproxy(1)
 file:/usr/share/doc/haproxy/configuration.txt.gz
 Process: 31800 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCC
 Process: 31797 ExecReload=/usr/sbin/haproxy -c -f ${CONFIG} (code=exited, stat
 Process: 995 ExecStartPre=/usr/sbin/haproxy -f ${CONFIG} -c -q (code=exited, s
 Main PID: 1019 (haproxy-systemd)
 Tasks: 3
 Memory: 5.2M
 CPU: 23min 7.777s
 CGroup: /system.slice/haproxy.service
 ├─ 1019 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg
 ├─31808 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy
 └─31809 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy
Upgrade do wordpress

Podemos usar o browser para abrir o endereço blog.viasig.com e fazer o upgrade. É só clicar no botão de upgrade e rapidamente temos o ecrã de sucesso:

Novo wp sem riscos…
Arrumação final

Tudo correu bem. Podemos ver a lista dos containers como ficou:

$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | STOPPED | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | RUNNING | 10.166.62.181 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

Podemos apagar o container  viasigwp quando tivermos a certeza que já não precisamos delete, com o comando lxc delete viasigwp.

Por agora está parado… apenas a ocupar 1,4GB de disco:

$ sudo du -sh /var/lib/lxd/containers/viasigwp
1.4G /var/lib/lxd/containers/viasigwp

Já agora, podemos ver a memória usada pelo wp4:

$ lxc info viasigwp4
Name: viasigwp4
Remote: unix://
Architecture: x86_64
Created: 2018/04/13 21:43 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 30377
Ips:
 eth0: inet 10.166.62.181 vethFNKBJU
 eth0: inet6 fe80::216:3eff:fef9:2084 vethFNKBJU
 lo: inet 127.0.0.1
 lo: inet6 ::1
Resources:
 Processes: 69
 Memory usage:
 Memory (current): 576.75MB
 Memory (peak): 719.80MB
 Network usage:
 eth0:
 Bytes received: 303.39MB
 Bytes sent: 601.68MB
 Packets received: 2521373
 Packets sent: 1531654
 lo:
 Bytes received: 0B
 Bytes sent: 0B
 Packets received: 0
 Packets sent: 0

Podemos ver que depois de 1 semana, o wp 4 usou um máximo de 719MB de memória. Podemos limitar a memória máxima disponível a um container lxd, bem como limitar o uso de processador, espaço em disco e a velocidade de acesso ou IOps,  e da mesma forma para a placa de rede. Tudo  sobre o controle de recursos no lxd pode ser visto aqui com detalhe: https://stgraber.org/2016/03/26/lxd-2-0-resource-control-412/.

No meu caso, limitei a memória máxima do container do plex server a apenas 512MB. Isto porque o plex tem a mania de usar toda a memória que encontra!! O comando que usei foi:

lxc config set dncplex limits.memory 512MB

Podemos ver as configurações com o comando inverso de config show:

$ lxc config show dncplex
architecture: x86_64
config:
 limits.memory: 512MB
 volatile.base_image: e1e62217dabb1acff585f13472af44b2720839546d1c3fb60d6187afa91fc995
 volatile.eth0.hwaddr: 00:16:3e:dd:e6:40
 volatile.idmap.base: "0"
 volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
 volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
 volatile.last_state.power: RUNNING
devices:
 root:
 path: /
 type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

Assim, a memória fica controlada.

E é tudo… se tudo correr bem o próximo artigo será sobre HAProxy…

Saudações virtuais!

Leave a Reply

Your email address will not be published. Required fields are marked *