SPAM é uma batalha sem fim. Cria-se uma forma de mitigar ou diminuir e são apenas algumas semanas de sossego. Logo eles acham uma forma de burlar as barreiras que criamos. Como faz tempo que não trabalho com mail de larga escala e controlo apenas a da VM do servidor desse domínio aqui, eu não tenho nem idéia do tamanho do problema que grandes empresas como Google têm. A quantidade de SPAM que tenho de lidar já é mais que suficiente pra eu me aborrecer.
Eu já implementei SPF pra verificação de origem dos mails, mailassassin, white e black list e... o volume continua alto.
Mailassassin era um dos mais promissores mas consome muita CPU a cada verificação. Além disso ele é um software muito burro (desculpem ao autores e fãs) pois ele recebe o mail pra fazer análise. Porque não fazer logo na conexão alguma verificação e descartar logo? No fim gastou banda, CPU e memória pra ver algo óbvio. Quando recebo um mail vindo de algo como "helio-a414c-loureiro.eng.
Pois o projeto OpenBSD resolveu cuidar disso. Eles criaram um daemon que enferniza a vida de spammers. É um verdadeiro saci pererê dos e-mails. O spamd recebe o mail e funciona de uma forma muuuuuuito lenta, com a conexão bem degradada. Após terminar a tentativa de envio do mail, ele simplesmente fecha a conexão e pede que tente novamente. Se o servidor tentar novamente, muito provavelmente não é uma máquina de SPAM. Como essa tentativa seguida faz parte do protocolo SMTP, servidores legítimos continuaram tentando enquanto spammers vão pra outra pobre vítima.
No último hackathon que participei eu tentei fazer um port desse daemon pro Linux. Encontrei um port já em andamento chamado obspamd no github, que estava com o build quebrado, e consegui arrumar o que estava com problemas. Minha idéia era fazer um daemon funcional e completo portado pra Linux, com autoconf e configure. E foi num dos bug reports que eu estava respondendo que alguém mandou outra mensagem avisando que existia um port já bem funcional do mesmo, o greyd.
Fiquei surpreso ao descobrir que até site oficial já tinha, o http://greyd.org, pois eu nunca tinha ouvido falar. Até onde vi não existem pacotes para ele em Debian ou em Ubuntu. Então boa parte da instalação foi feita manualmente.
O que eu gostaria de fazer com o obspamd, de criar um sistema de build com autoconfigure, já está pronto no greyd. Além disso ele já implementa as chamadas de kernel pra adicionar as regras de firewall necessárias pro funcionamento do greyd.
Por quê do firewall? Tanto o original, spamd, quanto o greyd funcionam ouvindo na porta 8025. Então todo pacote que não foi classificado, baseado em IP de origem, ao tentar conectar na porta 25, padrão de mail, é redirecionado à porta 8025. O greyd segue com a conexão e marca esse tipo de pacote como provável whitelist (lista branca). Na segunda tentativa de conexão esse pacote já vai direto pro servidor de mail, que no meu caso é um postfix. Esse controle é feito através do firewall iptables com regras no PREROUTING e ipset do kernel, marcando tipos de pacote com IP de origem. E precisa do módulo conntrack do kernel.
Como é um programa bem recente, não existem pacotes pra ele. Ao menos em Debian/Ubuntu. Então ele ainda exige a compilação e instalação manual.
Para baixar o greyd diretamente do github:
# git clone https://github.com/mikey-austin/greyd.git
Pra compilação, eu escolhi usar sqlite3 como formato de arquivo de whitelist, então precisei incluir os cabeçalhos e bibliotecas referentes.
# apt-get install libsqlite3-dev libnetfilter-log-dev libnetfilter-conntrack-dev \
libpcap0.8 libspf2-dev # cd greyd # autoreconf -vi # ./configure \ --with-sqlite \ --with-netfilter \ --with-spf \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --docdir=/usr/share \ --libdir=/usr/lib \ --localstatedir=/var \ GREYD_PIDFILE=/var/run/greyd.pid \ GREYLOGD_PIDFILE=/var/run/greylogd.pid \ DEFAULT_CONFIG=/etc/default/greyd.conf # make
O greyd também precisa que sejam criados 2 usuários: greyd e greydb, que controlam daemon e base de dados da lista. No seu repositório existe um diretório que ajuda a criar pacotes. Nele é possível ver os comandos pra realizar essa tarefa manualmente em greyd/packages/debian/postinst:
# adduser --quiet --system --home /var/run/greyd --group \
--uid 601 --gecos "greyd" --shell /bin/false --disabled-login greyd
# adduser --quiet --system --home /var/lib/greyd --group
--uid 602 --gecos "greydb" --shell /bin/false --disabled-login greydb
Em seguida é preciso criar o diretório onde a base de dados em squlite3 ou bsddb será escrita.
# mkdir -p /var/greydb # chown -R greydb:greydb /var/greydb
Com a configuração de compilação, as configuração serão armazenadas em /etc/default/greyd.conf. O spamd do OpenBSD por padrão roda em um ambiente chroot() pra proteção do sistema. Eu não consegui fazer o mesmo com o greyd. As configurações que estou usando no momento são (usando diff pra comparar):
# diff -u ./etc/greyd.conf /etc/default/greyd.conf
--- ./etc/greyd.conf 2016-07-07 13:47:43.000000000 -0300
+++ /etc/default/greyd.conf 2016-07-08 09:49:28.000000000 -0300
@@ -5,8 +5,8 @@
#
# Debugging options and more verbose logs.
#
-debug = 0
-verbose = 0
+debug = 1
+verbose = 1
daemonize = 1
#
@@ -17,7 +17,7 @@
#
# Address to listen on.
#
-bind_address = "127.0.0.1"
+bind_address = "200.123.234.321"
#
# Main greyd port.
@@ -32,7 +32,7 @@
#
# Enable listening on IPv6 socket.
#
-enable_ipv6 = 0
+enable_ipv6 = 1
bind_address_ipv6 = "::1"
#
@@ -60,7 +60,7 @@
#
# Chroot enable & location for main daemon.
#
-chroot = 1
+chroot = 0
chroot_dir = "/var/empty/greyd"
#
@@ -82,11 +82,13 @@
# Specify the maximum number of connections.
#
# max_cons = 800
+max_cons = 30
#
# Specify the maximum number of blacklisted connections to tarpit.
#
# max_cons_black = 800
+max_cons_black = 30
#
# The firewall configuration.
@@ -114,8 +116,8 @@
#
section database {
#driver = "/usr/lib/greyd/greyd_bdb_sql.so"
- #driver = "/usr/lib/greyd/greyd_sqlite.so"
- driver = "/usr/lib/greyd/greyd_bdb.so"
+ driver = "/usr/lib/greyd/greyd_sqlite.so"
+ #driver = "/usr/lib/greyd/greyd_bdb.so"
path = "/var/greyd"
db_name = "greyd.db"
Em geral ele funciona apenas na interface de loopback, mas por usar um Debian mais velho, o Wheezy, precisei ajustar pra ouvir na interface pública, a eth0.
Feito isso, basta iniciar o daemon e o daemon de controle de log:
# /etc/init.d/greylogd start # /etc/init.d/greyd start
Para quem já usa sistemas com systemd:
# systemctl start greylogd # systemctl start greyd
O próprio systemd cuidará de adicionar e habilitar esses serviços.
Mas ainda falta o firewall. São necessárias algumas regras na inicialização:
# ipset create greyd-whitelist hash:ip family inet hashsize 1024 maxelem 65536 # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
--match-set greyd-whitelist src -j LOG --log-prefix "[GREYD WHITED]" # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
--match-set greyd-whitelist src -j NFLOG --nflog-group 155 # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -m set \
--match-set greyd-whitelist src -j ACCEPT # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
--log-prefix "[GREYD 25 DNAT]" # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j DNAT \
--to-destination 200.123.234.321:8025 # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
--log-prefix "[GREYD 25 REDIRECTED]" # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j REDIRECT \
--to-ports 8025 # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 25 -j LOG \
--log-prefix "[GREYD FAILED]" # iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8025 -j LOG \
--log-prefix "[GREYD 8025 JAILED]" # iptables -t filter -A INPUT -p tcp --dport smtp -j ACCEPT # iptables -t filter -A INPUT -p tcp --dport 8025 -j ACCEPT
Eu adicionei mais logs pra poder também acompanhar os pacotes, pra ver se estão sendo marcados ou não de acordo.
De início eu fiquei na dúvida se eu estava recebendo algum e-mail ou não, mas logo percebi que estava funcionando de acordo.
A fila de mails indesejados, que ficavam travados por não ter endereço de retorno, praticamente zeraram. O uso de memória aumento um pouco, assim como o conntrack no kernel. Por enquanto nada absurdo. E parece estar funcionando bem até agora. Se não respondi algum mail seu, já sabe o motivo.
Acabaram os SPAMs? Não! Spam é spam. Enquanto houver mail, existirá spammers. É fácil de implementar e barato. Mas eles diminuíram. E ao saber que estou gastando a conexão deles fazendo nada já me alegra o suficiente.
Meu próximo passo será gerar um pacote no meu ppa no launchpad: https://launchpad.net/~helioloureiro
Pra saber mais como lutar contra spam: http://antispam.br/
Nem mal instalei o Ubuntu 16.04 com KDE5 e já quebrei o sistema. Não sei bem o que fiz, mas as fontes ficaram simplesmente impossível de enxergar. E olha que estou usando o desktop numa TV de 47 polegadas de LED.
Tentei de tudo quanto foi jeito pra tentar ao menos ler os menus do KDE5, mas estava impossível. Tentei reverter alguma possível mudança feita removendo os diretórios ~/.kde* ~/.config/k* e... nada! Continuei com fontes micro.
Dando uma pesquisada na Internet encontrei alguns problemas semelhantes pra quem tinha placa NVIDIA, meu caso, que alguma atualização mudou os DPI (dot per inch, ou pontos por polegada) que afeta diretamente a resolução.
Encontrei uma boa descrição com solução no askubuntu: http://askubuntu.com/questions/197828/how-to-find-and-change-the-screen-dpi
Eu alterei o /etc/X11/Xsession.d/99x11-common_start e adicionei antes do fim a seguinte linha:
xrandr --dpi 96
E problema resolvido.
Só não entendi muito bem como cai nesse tipo de problema. Talvez algum update no driver da NVIDIA.
Quando do lançamento da versão LTS do Ubuntu, a 16.04, vi várias receitas exotéricas de upgrade. Depois do terceiro ou quarto artigo que li, tive a nítida sensação de que um copiou do outro, pois seguiam mais ou menos os mesmos passos.
Como eu não tinha tentado o upgrade, pois eu sempre espero um pouco pra fazer o upgrade já que é normal que vários bugs apareçam e depois de mais ou menos 1 mês estão corrigidos, achei que realmente essas formas de upgrade eram necessárias uma vez que o sistema de init mudou do 14.04 de sysvinit pra systemd no 16.04.
Agora finalmente fiz o upgrade e usei a forma anterior. Não sei o motivo de ninguém ter mencionado mas... a forma de fazer upgrade é rodando o seguinte comando:
sudo do-release-upgrade
Pronto! Upgrade será feito. Como todo bom upgrade, vai dar umas zique-ziras que se resolve com um reboot seguido de "dpkg --configure -a" e "apt-get -f install", mas nada de muito grande.
Desculpem se foi curto, mas upgrade é coisa simples. Sempre foi.
Quem participa dos grupos que faço parte, principalmente no FaceBook, sabem que uma das minhas respostas mais comuns é "leia o guia foca Linux".
O objetivo é trollar quem pergunta, sempre, mas também fazer a pessoa abrir os olhos sobre a documentação que existe na Internet. Mas claro que é mais fácil perguntar primeiro, e ler depois. Isso quando lêem. Também sei que o nome mudou pra "guia foca gnu/linux", mas prefiro chamar pelo nome mais curto. Questão de simplicidade, mesmo que gladiadores da liberdade não gostem.
O guia surgiu pela iniciativa de Gleydson Mazioli pra suprir uma demanda de material sobre Linux, acessível e em português. Claro que atualmente abudam os livros, os sites e os blogs, mas na época em que o guia foi lançado isso não era tão verdadeiro assim. Longe disso. Era 1999.
O guia ajudou muita gente a iniciar e aprender Linux e Unix. As bases são quase as mesmas nos últimos 40 anos de Unix (mesmo Linux não sendo Unix). Mas como tudo em tecnologia, o guia está defasado. Faltam coisas como systemd, novas distros, e até mesmo sobre git.
Então chegou a hora de poder contribuir. Se algum dia fez uso de algum material disponível gratuitamente na Internet como o guia foca gnu/linux, ou mesmo do guia em si, aproveite pra contribuir e melhorar o mesmo, para que mais pessoas possam entrar nesse nosso mundo tão pequeno de software livre.
Eu criei um repositório do guia no GitHub: https://github.com/helioloureiro/guiafocalinux
basta fazer um clone do dele, criar ou atualizar os documentos e mandar seus pull requests.
Não é um fork do guia. A idéia é melhorar o guia com atualizações e enviar as sincronizações pro próprio Gleydson, para atualizar no site.
Como contribuir? O guia está escrito em SGML, que é um tipo de HTML mais direcionado para documentos. Mas não precisa ficar preocupado com isso. Basta adicionar o documento que queira implementar, e depois eu dou uma revisada e adiciono as tags necessárias. O importante é escrever. Se quiser começar de forma mais simples, pode editar um dos arquivos existentes e atualizar o mesmo. É necessário utilizar o pacote debiandoc-sgml para ter os templates usados no documento no lugar e poder gerar o guia. Então é mais fácil usar um Debian/Debian-alike como distro. Claro que não é necessário e Docker sempre pode ajudar se for preciso.
Até agora eu converti somente os arquivos de iso-8859-1 para utf-8 e criei um Makefile para gerar o guia em pdf. O próximo passo será descrever systemd. E você? Já pensou em como vai contribuir?
Aguardo seus pull requests :)
Quando li sobre docker e containers pela primeira vez, meu pensamento foi "ah... outra forma de ter uma VM". Eu não sabia das facilidades que isso gerariam no meu dia-a-dia de trabalho em relação aos outros métodos de virtualização.
Docker, ao contrário de outras formas de virtualização, não é um sistema isolado onde se carrega um sistema operacional inteiro. Por exemplo em KVM/Qemu ou KVM/Xen é possível instalar Windows, Android ou FreeBSD pois é um sistema completo de virtualização, que emula até uma camada de BIOS. Já containers, como o Docker, não. Eu não consigo rodar outro sistema que não seja aquele que roda na minha máquina em termos de versão de kernel e libc. Então enquanto Qemu e Xen rodam em servidores com Linux ou FreeBSD, Docker é inerente somente ao Linux.
A parte de containers é relativamente nova no Linux. Ela já existe faz uns 10 anos no FreeBSD com jails e mais ainda em Solaris com o zoneadm. Depois que implementaram o cgroups no kernel que Linux começou a explorar essa possibilidade. Os primeiros containers que surgiram no Linux foram através de LXC, que criava um segundo ambiente dentro do seu. Em FreeBSD e Solaris containers significam compartilhar seu sistema em vários pequenos sistemas, o que faz sentido afinal, mas em Linux... Linux é um kernel. Dizemos Linux por simplicidade, mas o sistema operacional que inclui kernel, Linux, e aplicativos, GNU por exemplo, é o que chamamos de distro. Ubuntu é um sistema operacional, RedHat é outro sistema operacional, Debian outro ainda e assim por diante. Então eles não rodam com as mesmas bibliotecas, nem usam o mesmos sistemas de pacotes. E isso é um problema. Os containers em LXC são capazes de criar um ambiente baseado no que está rodando, mas não uma outra distro dentro dessa distro original.
Nesse ambiente de possibilidades surgiu o Docker. Docker permite rodar um container que tenha uma outra distro completamente diferente daquela que roda no sistema principal. Mais ainda: Docker tem um repositório no estilo de GitHub que permite carregar ou baixar máquinas virtuais criadas por outras pessoas.
Então basta instalar Docker para começar a brincar. Apesar de ter servidores Debian, eu rodo bastante Docker no meu laptop. Então sei o procedimento pra Ubuntu via ppa, mas acredito que Debian deve ser bem parecido. Outras distros não devem ser muito diferentes.
Adicione diretamente o repositório nas configurações de fontes do apt:
root@laptop:~# cat << EOF > /etc/apt/sources.list.d/docker.list deb https://get.docker.io/ubuntu docker main EOF
Depois atualize a listagem de pacotes disponíveis e instale docker.io.
root@laptop:~# apt-get update; apt-get install docker.io
Então é preciso adicionar seu usuário ao grupo docker pra poder rodar sem precisar usar "sudo":
root@laptop:~# usermod -a -G docker helio
Reiniciada sua sessão (não precisa rebootar), docker deve estar disponível pra uso.
Com o Docker é possível verificar quais imagens estão disponíveis pra uso no repositório público.
helio@laptop:~$ docker search centos NAME DESCRIPTION STARS OFFICIAL AUTOMATED centos The official build of CentOS. 1575 [OK] ansible/centos7-ansible Ansible on Centos7 60 [OK] jdeathe/centos-ssh-apache-php CentOS-6 6.6 x86_64 / Apache / PHP / PHP m... 11 [OK] blalor/centos Bare-bones base CentOS 6.5 image 9 [OK] jdeathe/centos-ssh CentOS-6 6.6 x86_64 / EPEL/IUS Repos / Ope... 8 [OK] torusware/speedus-centos Always updated official CentOS docker imag... 7 [OK] million12/centos-supervisor Base CentOS-7 with supervisord launcher, h... 7 [OK] nimmis/java-centos This is docker images of CentOS 7 with dif... 6 [OK] feduxorg/centos 3 [OK] nathonfowlie/centos-jre Latest CentOS image with the JRE pre-insta... 3 [OK] centos/mariadb55-centos7 2 [OK] tcnksm/centos-node Dockerfile for CentOS packaging node 2 [OK] nathonfowlie/centos-jira JIRA running on the latest version of CentOS 1 [OK] feduxorg/centos-postgresql Centos Image with postgres 1 [OK] lighthopper/orientdb-centos A Dockerfile for creating an OrientDB imag... 1 [OK] yajo/centos-epel CentOS with EPEL and fully updated 1 [OK] layerworx/centos CentOS container with etcd, etcdctl, confd... 1 [OK] feduxorg/centos-apache Run Apache Event MPM on Centos 1 [OK] blacklabelops/centos Blacklabelops Centos 7.1.503 base image wi... 0 [OK] feduxorg/centos-rack Centos to run rack applications like Ruby ... 0 [OK] jsmigel/centos-epel Docker base image of CentOS w/ EPEL installed 0 [OK] lighthopper/openjdk-centos A Dockerfile for creating an OpenJDK image... 0 [OK] jasonish/centos-suricata Suricata base image based on CentOS 7. 0 [OK] pdericson/centos Docker image for CentOS 0 [OK] feduxorg/centos-geminabox Gem in a box on centos 0 [OK]
É possível adicionar outros repositórios e, claro, fazer sua própria instalação. Um problema sobre esse repositório público é que não existe garantia de não ter um malware junto. Se o seu uso for como o meu, corporativo, não use. Se for pra brincar e testar, vale o tempo.
A beleza do Docker é que pra rodar, basta chamar o comando. Se o container não existe, ele busca imediatamente no repositório e roda.
helio@laptop:~$ docker run -it centos bash Unable to find image 'centos:latest' locally latest: Pulling from centos 47d44cb6f252: Pull complete 168a69b62202: Pull complete 812e9d9d677f: Pull complete 4234bfdd88f8: Pull complete ce20c473cd8a: Pull complete centos:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security. Digest: sha256:3aaab9f1297db9b013063c781cfe901e2aa6e7e334c1d1f4df12f25ce356f2e5 Status: Downloaded newer image for centos:latest [root@1512dcd70309 /]# hostname 1512dcd70309
Então, em outro terminal é possível ver a instância de Docker ativa.
helio@laptop:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1512dcd70309 centos:latest "bash" 2 minutes ago Up 2 minutes jolly_sinoussi
A cada nova chamada pra rodar Docker, uma nova instância é criada.
helio@laptop:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3b48633e67cc centos:latest "bash" 8 seconds ago Up 6 seconds romantic_turing 1512dcd70309 centos:latest "bash" 4 minutes ago Up 4 minutes jolly_sinoussi
Como se deve imaginar, cada instância de Docker é completamente diferente uma da outra. E não persistente. Uma vez terminada a sessão, os dados adicionados são removidos. Assim, se aplicar um upgrade no container e quiser manter, tem de criar um "snapshot" dele. Então pra salvar uma atualização no container:
[root@1512dcd70309 /]# yum update Loaded plugins: fastestmirror base | 3.6 kB 00:00:00 extras | 3.4 kB 00:00:00 systemdcontainer | 2.9 kB 00:00:00 updates | 3.4 kB 00:00:00 (1/5): base/7/x86_64/group_gz | 154 kB 00:00:00 [... várias coisas seguem...]
é preciso fazer:
helio@laptop:~$ docker commit -m "Atualizado com yum update" 1512dcd70309 centos-atualizado ff0f333c4abd4d9045ff074121df8fea7d109e87cc1dcb88317254fa0cfd66e4
É preciso usar o ID do container uma vez que várias instâncias podem existir originados da mesma imagem "centos". Pra verificar suas imagens de containers, basta usar:
helio@laptop:~$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE centos-atualizado latest ff0f333c4abd 40 seconds ago 269.9 MB fedora2 latest d97facef5329 31 minutes ago 398.7 MB fedora latest c7d2f0130dae 5 days ago 204.3 MB centos latest ce20c473cd8a 3 weeks ago 172.3 MB susebuilder4 latest 97c67ab3589f 4 weeks ago 882.1 MB susebuilder3 latest 15af476bea7b 4 weeks ago 784.6 MB susebuilder2 latest 299ff2fa953d 4 weeks ago 685.6 MB susebuilder latest 9ca4e4487b77 4 weeks ago 661.3 MB kiwi latest a037d86af491 12 weeks ago 436.7 MB aekeroth/synapse latest a56b155c49a4 5 months ago 450.4 MB
Pra remover alguma dessas images, como por exemplo esse aekeroth/synapse que nem lembro o motivo de estar ali, onde todos os "snapshots" relacionados serão removidos também:
helio@laptop:~$ docker rmi aekeroth/synapse Untagged: aekeroth/synapse:latest Deleted: a56b155c49a427661055b1a45c9233107b59fc6ec801467f04a29659a8330624 Deleted: b1c70ec40fcc659efd9da36beade75b8c2505c56c53499b231be692e29330d15 Deleted: 051d6978b0a8d3f344c0b6fdbdcae3e172f8e24c839d3969e118f2e6c1c64174 Deleted: b856d151b9c77a47d3d706e64880f898939afeb8312727a8fb5d715ef64ccf86 Deleted: c908ae302de39cb78669241ab2a65dfa1c750eb7f0818820286551bc450b5b0d Deleted: 8927bb4878535574411efe47e5006049662fffa3f8984288b00ea49436fe5caf Deleted: a055b38089a89db6f97c4bef2de139ebe06fd56976a87ef442ce6a9f5047497d Deleted: 1057eb355528fc473af4bb6e9f529fdd70d7b8b02b764bf873166d7650341bd0 Deleted: 7bfe65031a48db2cc6206d6b4af9e52063a7d538a8e3d13b2f6e4f5d888e0f08 Deleted: cec2959569e4d51aee4bcc0409cebfc4a0a46b9d42142e4611c0fe6294824a8b Deleted: ed5b1f07a6c393d55598770da45ec197be4682bfedabdf26bbab0208d5b7061a Deleted: 2103b00b3fdf1d26a86aded36ae73c1c425def0f779a6e69073b3b77377df348 Deleted: 4faa69f72743ce3a18508e840ff84598952fc05bd1de5fd54c6bc0f8ca835884 Deleted: 76b658ecb5644a4aca23b35de695803ad2e223da087d4f8015016021bd970169 Deleted: f0dde87450ec8236a64aebd3e8b499fe2772fca5e837ecbfa97bd8ae380c605e Deleted: 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
Depois dessa rápida introdução ao Docker e containers, fica a pergunta: cadê a tal vantagem? Pois precisei fazer uso dela recentemente por causa do LSB, Linux Standard Base.
Quando ouvi falar de LSB achei que era algo como padronização de diretórios como "/opt" e "/usr/local" além de localização de arquivos de inicialização em "/etc/init.d". É, mas não é só isso. LSB cria uma base comum pra se compilar um binário em uma distro e rodar em outra. Isso evita precisar ter ambientes diferentes com distros diferentes e versões dessas distros diferentes. É uma facilidade. Mas... Debian, e consequentemente Ubuntu, não seguem mais a LSB. Primeiro que é algo complicado, pois envolve verificação de compatibilidade de ABI, segundo que se não tem um interesse econômico, leia-se alguém pra pagar por isso, não vale a pena manter.
Como na empresa desenvolvemos binários pra RedHat e Suse, meu laptop se tornou um local inóspito pra compilar os binários que usamos. São de OpenSAF, um projeto de software livre, mas é complicado manter um ambiente de compilação pra cada sistema. E caro. A solução inicial que adotamos foi instalar servidores com as versões de RedHat e Suse pra podermos compilar e verificar.
Daí lembrei do Docker :)
Bastou criar um container com os pacotes de compilação necessários como gcc, g++ e rpmbuild. Mas o repositório está no laptop, que roda Ubuntu. Como compilar? Como acessar os dados?
Primeiramente criei um usuário no container Docker com mesmo UID e GID que o meu, pra não criar tudo como root. Em seguida chamei o Docker com parâmetros pra usar meu filesystem:
helio@laptop:~$ docker run -it -v /home/helio/OpenSAF:/opensaf --user=helio -w /opensaf susebuilder4 ./configure
e pronto! Binários compilados num ambiente que suporta LSB. Docker mapeia meu diretório local "/home/helio/OpenSAF" como "/opensaf" no container. Inicia como usuário "helio" dentro do diretório "/opensaf" e roda o comando "./configure". E pronto. Quando termina o comando, o container desaparece.
Sim, saem lágrimas dos olhos de tão lindo.
Docker permite isso. Imagine então rodar um ambiente virtual com servidor web ou qualquer outra aplicação. Uma vez terminada, some o container. Quer aumentar capacidade? Só criar outro container. Eu não comentei muito, mas é possível mapear portas locais pra portas internas do container, além de rodar o próprio como daemon.
Docker é um monstro de tão bom. Não é uma baleia, mas um Moby Docker! Vale testar.
