Boa Natal a todos,
Uma coisa que me perguntam constantemente é: “O que faço à minha aplicação legacy agora que o sistema operativo, hardware ou a própria aplicação está sem suporte?”
A pergunta surge em muitos Clientes, e reflete a realidade das empresas que por uma razão ou por outra não conseguem adotar life cycles aplicacionais (por exemplo o RedHat SoE), ou por razões relacionadas com o custo de ter uma aplicação nova e os dados antigos migrados para ela.
A pergunta em si é muito válida.
O Cliente pode efetivamente necessitar de utilizar a aplicação, e quem a fez já não está na empresa.
Já vi Clientes com aplicações que são utilizadas de tempos a tempos (por exemplo histórico de contabilidade) e a empresa que fazia o software faliu.
Todos estes cenários criam o que na gíria um colega meu chama de sarcófago aplicacional: É grande, é uma múmia e não há forma de a matar.
Tipicamente este tipo de aplicações são antigas (>4 a 6 anos desde a altura de entrada em produção), e muito provavelmente estão em sistemas legacy, muitas vezes em hardware que ele próprio já não tem suporte.
Dependendo da importância da aplicação, o IT Manager pode escolher tentar instalar o sistema operativo que corre a aplicação em hardware mais moderno, mas existe uma grande probabilidade que o sistema operativo que corre no novo hardware não consiga executar a antiga aplicação.
Tipicamente nestes casos tenta-se virtualizar o servidor através de um P2V, mas caímos num desperdício de memória, cpu e armazenamento para o sistema operativo virtualizado em si que suporta a aplicação (ver secção de bónus com recursos usados mais abaixo).
Entra em cena o LXC. Mais tarde, em outro post, falaremos do método de fazer mesma coisa com o Docker.
O primeiro projeto baseiam-se na premissa de software de Containers, sendo o Docker um pseudo-wapper extremamente complexo e altamente funcional que consiste no conceito de virtualização de aplicações distribuídas.
Assim sendo o que fazer?
Vamos para este laboratório imaginar um cenário de uma aplicação web com backend em *software proprietário*(sem suporte) que corre em CentOS 4.9.
O processo em si é agradavelmente simples:
1) Instalação de um sistema operativo, moderno, suportado e com security patch releases (no nosso caso usamos para laboratório RedHat Enterprise Linux 6.5).
2) Instalar LXC e validar se o kernel em execução suporta as extensões LXC:
$ yum update
$ yum install libcap-devel libcgroup busybox wget bridge-utils
$ yum groupinstall “Development tools”
(assumo nesta parte que a bridge que irá fornecer o networking ao container já está configurada desde este ponto).
$lxc-checkconfig
— Namespaces —
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled
— Control groups —
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled
— Misc —
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled
E em seguida iremos buscar uma imagem de CentOS aos templates de OpenVZ.
Nota: É possível usar uma instalação típica de CentOS (ou binariamente compatível) efetuando rsync (com copia de permissões) da máquina original para dentro de um diretório de container LXC (por exemplo /var/lib/lxc/centos49/rootfs).
Em seguida, editamos a password de root da máquina em container – É importante lembrar que um container não é uma máquina virtual, pelo que algumas features (como tty’s) podem não estar disponíveis caso os pseudo devices não sejam manualmente criados.
$ sudo chroot /var/lib/lxc/centos49/rootfs
$ sudo passwd
Porque o centOS 4.9 não deteta que está em execução dentro de uma jail LXC é necessário ainda os seguintes passos ainda dentro da chroot:
$ sudo cp /dev/null /sbin/udevstart
$ sudo vi /etc/rc.sysinit
(remover da linha 374 a 434 inclusive).
É importante lembrar que o caso apresentado é para o CentOS49. Cada sysadmin deverá alterar o seu sysinit para a sua realidade.
Finalmente configuraremos a rede, e serviços que queremos que sejam iniciados no arranque do container:
$ cd /var/lib/lxc/centos49/rootfs
Adicionar ao ficheiro de configuração do container a rede (/var/lib/lxc/centos49/config):
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.hwaddr = 02:01:98:2c:b7:4e
lxc.network.ipv4 = XXX.XXX.XXX.XXX/XX
(gravar e sair).
$ sudo chroot /var/lib/lxc/centos49/rootfs
$ sudo chkconfig sshd on
$ sudo chkconfig httpd on
Em seguida, e se fizeram tudo bem, devem ter algo como:
$ sudo lxc-ls –fancy
NAME STATE IPV4 IPV6 AUTOSTART
—————————————————————-
centos49 STOPPED – – NO
centos65 STOPPED – – NO
$ sudo lxc-start –name centos65 -d
$ sudo lxc-ls –fancy
NAME STATE IPV4 IPV6 AUTOSTART
—————————————————————-
centos49 RUNNING 172.16.4.100 – NO
centos65 STOPPED – – NO
$ ssh [email protected]
[root@centos ~]# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 4908 1200 ? Ss 00:41 0:00 init [3]
root 1126 0.0 0.1 3776 1084 ? Ss 00:41 0:00 udevd
root 1799 0.0 0.1 5940 1248 ? Ss 00:41 0:00 syslogd -m 0
root 1810 0.0 0.2 22096 2732 ? Ss 00:41 0:00 /usr/sbin/sshd
root 1828 0.0 0.3 34032 3304 ? Ss 00:41 0:00 sendmail: accepting connections
smmsp 1837 0.0 0.3 28912 3300 ? Ss 00:41 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root 1848 0.0 0.4 79540 4376 ? Ss 00:41 0:00 /usr/sbin/httpd
apache 1851 0.0 0.3 79540 3192 ? S 00:41 0:00 /usr/sbin/httpd
apache 1852 0.0 0.3 79540 3192 ? S 00:41 0:00 /usr/sbin/httpd
root 1863 0.0 0.1 11004 1868 ? Ss 00:41 0:00 crond
root 1922 0.2 0.4 35164 4204 ? Rs 03:55 0:00 sshd: root@pts/10
root 1924 0.5 0.2 7832 2532 pts/10 Ss 03:55 0:00 -bash
root 1950 0.0 0.1 5600 1348 pts/10 R+ 03:55 0:00 ps aux
[root@centos ~]# cat /etc/redhat-release
CentOS release 4.9 (Final)
Para finalizar, migrem a vossa aplicação para o container e já está.
Bónus: Para não deixar a ideia que todo este trabalho é algo em vão (por exemplo versus um típico p2v) julgo importante que se veja a diferença em overhead que um sistema operativo faz em relação a um container:
$ sudo lxc-info –name centos49
Name: centos49
State: RUNNING
PID: 4046
IP: 172.16.4.100
CPU use: 5.69 seconds
Memory use: 10.06 MiB
A memória necessária para correr o sistema operativo (CentOS 4.9) totalmente virtualizado é MUITO maior do que os 10.06 MB’s que a aplicação consome em idle dentro de um container.
Existe assim uma clara vantagem na poupança de recursos.
Lembrem-se que todo este procedimento é um balão de ar para a vossa infraestrutura sem suporte, e que todo este procedimento não vos dá suporte a aplicação ou ao sistema operativo dentro do container.
Serve apenas para garantir que tem uma possibilidade de correr a vossa aplicação.
Caso tenham alguma duvida p.f. disponham. Terei todo o prazer de vos auxiliar.
Despeço-me de todos com um desejo a todos um Feliz Natal e boas Festas!
Abr.