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:
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!
