Neste tutorial eu explico fundamentos e conceitos para a execução do Docker no Fedora 20. Passos similares ao que apresento aqui também podem ser seguidos no RHEL 7. Então, eu exploro um caso: a instalação e a configuração do WildFly e do RHQ nesse ambiente.

Desenvolvi esse trabalho para apresentá-lo, inicialmente, na minha palestra no JUDCon 2014 Brazil. Contudo, mesmo após esse evento, meu tutorial continua em evolução.

1. Background teórico sobre o Docker

1.1. O que é o Docker?

1.1.1. Porque os desenvolvedores gostam dele?

  • Desenvolvedores utilizam o docker para criar aplicações que rodam de maneira padrão em qualquer lugar:

    • Laptops com OS X, Linux e, até mesmo (pasmem) Windows

    • Servidores na nuvem rodando Ubuntu, Red Hat, …​

1.1.2. Porque os sysadmins gostam dele?

  • Sysadmins utilizam o docker para prover ambientes para times de:

    • Desenvolvimento, Quality assurance (QA), produção

1.1.3. Arquitetura

  • O docker possui uma arquitetura cliente/servidor

  • Docker client conversa com Docker daemon

    • Client pode se conectar a um daemon remoto ou local (mesmo sistema)

    • Client e daemon se comunicam via sockets ou através de uma API RESTful

    • Client aceita comandos do usuário e faz a comunicação com o daemon

  • Docker daemon executa na máquina Host

    • O usuário nunca interage diretamente com o daemon mas sim com o client

Architecture

1.1.4. Componentes internos

  • Docker images

    • São templates (somente leitura)

      • Podem conter um sistema operacional e aplicações instaladas

    • São utilizadas para criar contêineres

  • Docker Registries

    • Armazenam imagens docker

      • Provêem upload e download de imagens docker

    • São privados ou públicos

  • Docker contêineres

    • São similares a diretórios

    • Armazenam tudo o que é necessário para uma aplicação ser executada

    • São executados, iniciados, parados, movidos e removidos

    • Cada contêiner é uma plataforma segura e isolada de aplicações

1.1.5. Como o Docker funciona?

  • Você contrói imagens que armazenam suas aplicações

  • Você cria contêineres a partir dessas imagens para executar suas aplicações

  • Você compartilha suas imagens via Docker Hub ou no seu próprio registry

2. Instalando o Docker no Fedora

Os passos para a instalação do Docker num Fedora são descritos na página http://docs.docker.com/installation/fedora/. Também gosto de referenciar um post do Marek Goldman relativo a essa questão.

O Docker pode ser executado numa máquina virtual (VM) ou real. O fato é que ele foi desenvolvido para rodar num kernel Linux executando numa arquitetura de 64 bits.

2.1. Baixando e executando uma VM Fedora no VirtualBox

Para seguirmos este tutorial, utilizaremos uma VM que executará um Fedora 20 x86_64. Eu utilizarei o OS X para rodar essa VM no VirtualBox. Se for o caso, você também pode utilizar um Linux para seguir esse tutorial ou até mesmo um Windows com um Cygwin instalado. Não é problema. Mas, talvez você precise adaptar alguns dos comandos que apresentarei.

Então, faremos o download, extrairemos e executaremos minha vm-fedora (leia os procedimentos que escrevi para criá-la se desejar mais detalhes a seu respeito). Para descompactar essa VM, precisaremos do 7zip instalado e seguiremos os seguintes passos:

cd ~/VirtualBox\ VMs/
bash <(curl -L http://j.mp/vm-fedora-download)
7za x vm-fedora.7z.001
VBoxManage registervm "$PWD/vm-fedora/vm-fedora.vbox"
VBoxManage startvm vm-fedora

Observação: poderíamos utilizar o Vagrant (leia o tutorial que escrevi a seu respeito) mas, neste tutorial, não estou utilizando-o.

2.2. Configurando a VM para acesso a partir de uma console do HOST

A VM que baixamos só possui uma interface de rede (configurada com o IP 10.0.2.5). A partir dela conseguimos navegar na Internet através de um NAT com a máquina HOST (nossa máquina, que está executando o VirtualBox). Tecnicamente, não há como fazer um ping ou mesmo acesar o IP da VM através da máquina HOST, nesse caso. Mas, há uma alternativa para isso que consiste na criação de um túnel reverso fazendo um ssh da console da VM para o HOST. Para testarmos essa alternativa, loguemos no console da VM (usuário aluno, senha @lun0123) e executemos:

ssh -f -N -R 2222:localhost:22 pj@base

Obviamente, você deverá substituir o meu usuário (pj) pelo o usuário que você tem em tua máquina. Detalhe: o host base tem o IP 10.0.2.2, que é o IP NAT padrão configurado no HOST pelo VirtualBox.

Dessa forma, a partir de um shell aberto no HOST, poderíamos acessar a VM com os seguintes comandos:

ssh-copy-id -p 2222 aluno@localhost
ssh -p 2222 aluno@localhost

O problema de fazer isso é que, mais a frente nesse tutorial, testaremos o acesso ao WildFly através de um IP válido para o HOST ao invés de fazermos túneis para as portas utilizadas pelo WildFly. Por isso precisaremos parar a VM e fazer algumas configurações. Adicionaremos uma rede de comunicação entre o HOST e a VM ajustando o IP 192.168.0.253 para o HOST. Também criaremos uma nova interface de rede na VM e configuraremos um IP para ela.

Encerrando o ssh com a VM (Ctrl+D) e voltando para o console do HOST, paremos a execução da VM:

VBoxManage controlvm vm-fedora acpipowerbutton

Aguardemos a VM ser finalizada e, assim que isso ocorrer, executemos:

VBoxManage hostonlyif create
VBoxManage hostonlyif ipconfig vboxnet0 --ip 192.168.0.253 --netmask 255.255.255.0
VBoxManage modifyvm vm-fedora --nic2 hostonly --hostonlyadapter2 vboxnet0
VBoxManage startvm vm-fedora
f=/etc/hosts; grep -v vm-fedora $f | sudo tee $f
echo -e "192.168.0.254\tvm-fedora" | sudo tee -a $f
cat $f

Façamos mais uma vez o logon na console da VM como usuário aluno. Executemos novamente o comando de criação do túnel reverso (sugestão: utilize um Ctrl+R para encontrá-lo):

ssh -f -N -R 2222:localhost:22 pj@base

Observemos que, agora, há uma nova interface de rede nessa máquina (p7p1). Vejamos isso através da execução do comando a seguir:

ip a s

Precisamos configurar um IP estático para essa nova interface. Será esse IP que utilizaremos termos o acesso do HOST na VM. De volta ao console da máquina HOST, executemos:

ssh -p 2222 aluno@localhost

Temos acesso remoto para a console da VM utilizando nosso HOST. Copiemos e colemos os comandos a seguir nessa console (detalhe: copia/colar não seria possível de fazer, diretamente, do HOST para a VM pois o VirtualBox não oferece esta facilidade quando estamos trabalhando no modo texto, o que é o caso):

cat <<'EOF' | sudo tee /etc/sysconfig/network-scripts/ifcfg-static-p7p1
DEVICE=p7p1
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.254
PREFIX=24
GATEWAY=192.168.0.254
EOF
sudo nmcli con reload
sudo nmcli con up "System static-p7p1"

Os comandos executados acima servem para configurar o IP estático 192.168.0.254 para a interface p7p1. É com esse IP que iremos acessar a VM, que nomeamos vm-fedora no arquivo /etc/hosts da nossa máquina HOST. Para verificar se tudo deu certo, façamos um ping para IP 192.168.0.253 do HOST:

ping 192.168.0.253

Por fim, instalemos alguns utilitários que serão utilizados no decorrer desse tutorial:

sudo yum -y install vim tree lynx

Voltemos ao console do HOST digitando um Ctrl+D e, em seguida, executemos:

ping vm-fedora
ssh aluno@vm-fedora

De agora em diante, executaremos todos os procedimentos que apresentarei no console da VM (a menos que eu dê alguma outra instrução).

2.3. Instalando o Docker

Façamos a instalação do Docker (e a configuração para sua inicialização automática) com os seguintes comandos:

sudo yum -y install docker-io
sudo systemctl start docker
sudo systemctl enable docker

3. Primeiros passos na utilização do Docker

3.1. Procurando contêineres no Docker Hub

Busquemos contêineres executando as instruções a seguir. O | less após o docker search é interessante pois serão listadas várias imagens.

sudo docker search fedora | less
sudo docker search wildfly | less
sudo docker search rhq | less

3.2. Docker Hello World

Executemos o "Docker Hello World":

sudo docker run fedora echo 'Hello World'

Obervamos que a execução do comando acima fez o download da imagem fedora e, em seguida, imprimiu um Hello World na console da VM. Toda a execução de uma imagem é um contêiner e fica registrada pelo Docker. Podemos ver esse registro através do comando a seguir:

sudo docker ps -a

Se repetirmos o primeiro comando teremos a criação de um novo contêiner. Experimentemos isso, executando:

!-2
!-2

A saída do último comando deve nos apresentar uma listagem como esta:

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                      PORTS               NAMES
3568e2848ea9        fedora:latest       "echo 'Hello World'"   15 seconds ago      Exited (0) 14 seconds ago                       drunk_bartik
de9be19a40a4        fedora:latest       "echo 'Hello World'"   33 seconds ago      Exited (0) 32 seconds ago                       boring_ardinghelli

Removamos os dois contêineres criados, executando o comando a seguir (adeque o comando de acordo com os ids apresentados na sua saída que você obteve; note também que, se não houverem repetições, apenas os três primeiros dígitos do 'Container ID' bastam para que o docker consiga identificá-lo):

sudo docker rm 356 de9

Podemos pedir ao Docker que remova o contêiner de seu registro logo após o término de sua execução. Para testarmos isso, executemos:

sudo docker run --rm fedora echo 'Hello World'
sudo docker ps -a

Concluindo, notamos que a adição do parâmetro --rm ao comando docker run elimina o registro do contêiner no Docker.

3.3. Por dentro de um contêiner

Executemos:

sudo docker run -i -t fedora /bin/bash

Os parâmetros passados ao docker significam o seguinte:

  1. run - executa um contêiner (como vimos anteriormente);

  2. -i - mantem o stdin aberto, mesmo que não haja nada anexado;

  3. -t - aloca um pseudo terminal, dessa forma podermos interagir diretamente com o contêiner;

  4. fedora - ID da imagem, pode ser uma tag ou um hash (id);

  5. /bin/bash - o comando que será executado após o contêiner ser iniciado;

Alguns detalhes que podemos observar sobre a execução desse comando:

  1. Se a imagem do contêiner não estiver no cache local ela será baixada (nessa execução ela já estava no cache);

    1. Se quiséssesmos apenas baixar a imagem, sem criar nenhum contêiner, poderíamos simplesmente executar o comando sudo docker pull fedora;

  2. O prompt de comando apresentado será da forma root@<id>;

Como estamos dentro do contêiner, executemos alguns comandos para observar seu comportamento:

ls -la
ps -ef
env | grep -i hostname
ip a s
df -h
free -m

Pela saída dos comandos acima, notamos várias coisas:

  1. O contêiner tem um sistema de arquivos próprio e independente do host;

  2. O contêiner só está executando o comando que lhe foi solicitado executar;

  3. O nome configurado para o contêiner é o seu id;

  4. Há duas interfaces de rede configuradas: a de loopback, e outra com um IP específico;

  5. O espaço em disco alocado para a partição root (/) é de 9.8G;

  6. A memória alocada para o contêiner tem o mesmo tamanho que a memória alocada para a VM;

Criemos um arquivo temporário e façamos a instalação de um pacote:

echo 'Teste' > /tmp/teste
yum -y install tree

Paremos o contêiner pressionando Ctrl+D. Ele será parado mas poderá ser reiniciado ou removido na hora que quisermos.

3.4. Gerenciamento básico de um contêiner

Para removermos o contêiner, vimos que precisaremos saber seu id e para isso, executamos um sudo docker ps. A saída desse comando, entretanto, só nos mostra os ids dos contêineres em execução. Para listarmos os ids de todos os contêineres, até mesmo os que não estão em execução, executaremos esse mesmo comando informando o parâmetro -a:

sudo docker ps -a

Nossa saída deverá ser similar a esta:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
d30ae9376851        fedora:latest       "/bin/bash"         27 minutes ago      Exited (0) 24 minutes ago                       drunk_curie

Para vermos que arquivos foram adicionados, removidos ou modificados no contêiner, executemos (substitua o id que informo abaixo pelo que é apresentado na tua saída para o comando acima):

sudo docker diff d30

Removamos o contêiner:

sudo docker rm d30

Criemos um novo contêiner com o seguinte comando:

sudo docker run -it -p 4242:4242 fedora /bin/bash

Em relação ao que já discutimos, a única diferença é a adição do parâmetro -p na linha de comando. Ele serve para informar que haverá um redirecionamento da porta 4242 da VM para o contêiner. Isso é necessário pois, mais a frente, acessaremos a URL http://vm-fedora:4242.

Agora criaremos um contêiner que seja capaz de fazer a construção deste site que estamos lendo e, em seguida, geraremos uma imagem desse contêiner para fazer seu upload no Docker Hub. Nosso primeiro passo será instalar o Ruby 2.1 dentro desse contêinter, utilizando o RVM e seguindo os seguintes passos:

yum -y install which
curl -sSL https://get.rvm.io | sudo -E bash -s stable
source /etc/profile.d/rvm.sh
rvm install 2.1

Verifiquemos se a instalação do Ruby foi bem sucedida:

ruby -v

Este site, como eu disse, foi construído com o uso do Awestruct e do Asciidoctor. O Asciidoctor é instalado automaticamente quando instalamos o Awestruct. Esse último, por sua vez, tem outras dependências como o Nokogiri. No Fedora, para que o Nokogiri seja instalado, precisamos instalar alguns pacotes a mais. Executemos:

yum -y install libxml2-devel libxslt-devel

Instalemos o Awestruct:

gem install awestruct

Para que possamos obter a versão mais atual deste site com o objetivo de fazermos sua contrução, também precisaremos instalar o Git. Executemos:

yum -y install git

Agora nosso contêiner tem tudo o que precisamos para construir este site. Mas, ainda precisamos testar essa construção baixando sua versão mais atual publicada no GitHub. Executemos:

useradd -G rvm -m -s /bin/bash judcon
su - judcon
git clone http://github.com/paulojeronimo/JUDCon-2014-Brazil
cd JUDCon-2014-Brazil
rvm use 2.1@JUDCon-2014-Brazil --create --ruby-version
bundle install
rake

Os comandos acima fizeram a adição do usuário judcon. Também fizeram o root se logar como ele, clonaram a última versão publicada do meu repositório JUDCon-2014-Brazil no GitHub, entraram no diretório clonado e solicitaram a construção do site pela execução do Awestruct.

Antes de parar esse contêiner, testemos o acesso a URL http://vm-fedora:4242.

Se conseguirmos fazer esse acesso e verificamos o site em execução, estamos prontos para gerar a imagem do contêiner!

Conseguimos! Agora, geremos a imagem do contêiner. Para isso, paremos sua execução. Para isso, dêmos um Ctrl+C na execução do comando em execução (rake). Em seguida, façamos o logout do usuário judcon (dititando um Ctrl+D). Por fim, encerremos o contêiner (mais um Ctrl+D).

Queremos transformar as alterações que fizemos nesse contêiner numa imagem. Dessa forma poderemos gerar novos contêineres a partir dela e esses já conterão todas as ferramentas que precisamos para fazer a reconstrução de nosso site JUDCon-2014-Brazil. Nosso próximo passo será fazer um commit das mudanças que fizemos no contêiner e isso pode ser realizado com a execução dos seguintes comandos (substitua a string que representa meu usuário (paulojeronimo) por outro nome de tua preferência):

CID=$(sudo docker ps -a | sed -n '2p' | cut -d ' ' -f 1)
sudo docker commit $CID paulojeronimo/judcon-2014-brazil

A execução desse commit demora um pouquinho. Mas, nada que nos atrapalhe significativamente. Além disso, esse tempo de construção da imagem só foi um pouco demorado em virtude de termos realizado várias mudanças em relação a imagem original (fedora) somando a ela muitos pacotes e mudanças no sistema de arquivos. Como resultado dos comandos acima, agora temos uma nova imagem nomeada paulojeronimo/judcon-2014-brazil (ou teu-nome/judcon-2014-brazil). Confiramos isso com a execução do seguinte comando:

sudo docker images

Podemos remover o contêiner que nos serviu de base para a criação da imagem e, em seguida, criar um novo contêiner para testarmos a construção de nosso site. Para isso, executemos:

sudo docker rm $CID
sudo docker run -it --rm -p 4242:4242 paulojeronimo/judcon-2014-brazil /bin/bash

Após obtermos o prompt do contêiner, executemos:

su - judcon
cd JUDCon-Brazil-2014
rake

Em seguida, testemos o acesso ao site gerado acessando a URL http://vm-fedora:4242.

Encerremos a execução do contêiner repetindo os passos que executamos antes de gerarmos sua imagem.

Agora, queremos publicar nossa imagem no Docker Hub para que outras pessoas possam utilizá-la, assim como nós fizemos. Para isso, nosso primeiro passo para isso deve ser efetuar o logon nesse serviço. (É óbvio que se você ainda não possui uma conta no Docker Hub, você deve criá-la primeiro!)

Executemos:

sudo docker login

Seremos solicitados a informar um usuário, uma senha e um email. Por fim, executemos o comando a seguir para subir a imagem:

sudo docker push paulojeronimo/judcon-2014-brazil

O processo de upload pode demorar um pouco dependendo do tamanho da imagem que você está subindo para o Docker Hub. De qualquer forma, após publicada a imagem fica disponível numa URL como essa: https://registry.hub.docker.com/u/paulojeronimo/judcon-2014-brazil/

4. Docker em projetos JBoss

Vários projetos do grupo JBoss estão utilizando o Docker. Leia mais sobre isso nos seguintes links:

Neste tutorial, executaremos apenas dois projetos JBoss no Docker: o WildFly e o RHQ. Mas, nos links acima há receitas para a execução de outros projetos.

4.1. WildFly no Docker

As instruções para o boot do WildFly no Docker estão na página https://registry.hub.docker.com/u/jboss/wildfly/.

4.1.1. Executando em modo standalone

Executar o WildFly no modo standalone com o Docker é simples assim:

sudo docker run -it --rm jboss/wildfly

Contudo, temos um problema: como acessar uma aplicação executando num contêiner? (Essa aplicação poderia ser, por exemplo, a própria interface administrativa do WildFly).

Para acessar o WildFly na porta 8080 (dentro da VM), é necessário descobrir o IP do contêiner. Façamos essa descoberta abrindo um novo console na VM e executando os seguintes comandos:

CID=$(sudo docker ps -a | grep -i up | awk '{print $1}'); echo CID

Esse primeiro comando serve para que possamos recuperar o identificador do contêiner (Container ID) e armazená-lo na variável CID. De posse desse identificador, podemos inspecionar o contêiner em busca do IP que o Docker associou a ele executando:

IP=$(sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' $CID); echo $IP

Agora, sabemos o IP. Poderemos abrir um browser dentro da VM e acessar a URL http://$IP:8080. O problema é que não temos uma interface gráfica instalada nessa VM para rodar um browser como o Firefox, por exemplo. Outra questão é que o IP obtido para o contêiner também só é acessível de dentro da VM! Então, para contornar esta situação, testemos o acesso a essa URL utilizando um browser em modo texto (lynx), executando-o na própria linha de comando da VM:

lynx http://$IP:8080

Para acessarmos o WildFly a partir do HOST a solução é pedir que o docker crie mais dois túneis de acesso (para as portas 8080 e 9990) entre a VM e o contêiner. Façamos isso encerrando a execução corrente do WildFly (dando um Ctrl+C na sua console) e, em seguida, executando:

sudo docker run -it --rm -p 8080:8080 -p 9990:9990 jboss/wildfly

Podemos agora acessar, do HOST, a URL http://vm-fedora:8080. Só que para acessarmos a interface administrativa, ainda precisamos da adição um usuário administrativo. Modificaremos nosso contêiner adionando esse usuário.

Paremos novamente o contêiner em execução (Ctrl+C) e executemos:

mkdir -p ~/demos/01-wildfly-management
cd !$
cat > Dockerfile <<EOF
FROM jboss/wildfly
RUN /opt/wildfly/bin/add-user.sh admin Admin#70365 --silent
EOF
sudo docker build -t wildfly-management .

O que fizemos agora foi criar uma imagem própria, derivada da imagem jboss/wildfly, onde apenas adicionamos as configurações necessárias para a inclusão de um usuário de administração do WildFly.

Executemos o comando sudo docker images. Com isso, obteremos a seguinte saída:

REPOSITORY           TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
wildfly-management   latest              31961a1179fa        20 seconds ago      929 MB
fedora               latest              7d3f07f8de5f        About an hour ago   374.1 MB
jboss/wildfly        latest              bf5508a3f1c7        12 hours ago        929 MB

Executemos novamente o WildFly de forma que, agora, consigamos acesso a sua interface administrativa:

sudo docker run -it --rm -p 8080:8080 -p 9990:9990 wildfly-management

Recarregando a URL http://vm-fedora:8080 no HOST, teremos acesso a console de administração após informar o usuário admin e a senha Admin#70365.

O Docker nos oferece uma forma de visualizar as diferenças entre a imagem (somente leitura) e o contêiner. Para isso, precisamos executar um docker ps -a (façamos isso em outra console da VM, enquanto o WildFly está executando). Sua saída será similar a esta:

CONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS                           PORTS                                            NAMES
23661d0835ee        wildfly-management:latest   "/opt/wildfly/bin/st   45 minutes ago      Up 45 minutes                    0.0.0.0:8080->8080/tcp, 0.0.0.0:9990->9990/tcp   naughty_archimedes
aa4272a565ca        jboss/wildfly:latest        "/opt/wildfly/bin/st   About an hour ago   Exited (130) 55 minutes ago                                                       dreamy_nobel
746e8e569540        jboss/wildfly:latest        "/opt/wildfly/bin/st   About an hour ago   Exited (130) About an hour ago                                                    tender_tesla
75653974d524        fedora:latest               "/bin/bash"            About an hour ago   Exited (0) About an hour ago                                                      agitated_goodall

Notemos a coluna NAMES nessa saída e utilizemos o seu valor para o contêiner 236 (primeiros três dígitos do CONTAINER ID), na execução do comando a seguir:

sudo docker diff naughty_archimedes

A saída desse comando, apresentada abaixo, lista as mudanças no sistema de arquivos, em relação a imagem:

C /opt/wildfly-8.1.0.Final/standalone
C /opt/wildfly-8.1.0.Final/standalone/configuration
C /opt/wildfly-8.1.0.Final/standalone/configuration/logging.properties
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history/current
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history/snapshot
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history/standalone.boot.xml
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history/standalone.initial.xml
A /opt/wildfly-8.1.0.Final/standalone/configuration/standalone_xml_history/standalone.last.xml
A /opt/wildfly-8.1.0.Final/standalone/data
A /opt/wildfly-8.1.0.Final/standalone/data/content
A /opt/wildfly-8.1.0.Final/standalone/data/timer-service-data
A /opt/wildfly-8.1.0.Final/standalone/data/tx-object-store
A /opt/wildfly-8.1.0.Final/standalone/data/tx-object-store/ShadowNoFileLockStore
A /opt/wildfly-8.1.0.Final/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore
A /opt/wildfly-8.1.0.Final/standalone/log
A /opt/wildfly-8.1.0.Final/standalone/log/server.log
C /opt/wildfly-8.1.0.Final/standalone/tmp
A /opt/wildfly-8.1.0.Final/standalone/tmp/vfs
A /opt/wildfly-8.1.0.Final/standalone/tmp/vfs/temp
C /tmp/hsperfdata_wildfly
A /tmp/hsperfdata_wildfly/53

Paremos o WidlFly dando um Ctrl+C na console em que ele está sendo executando.

Existe um comando no Docker que podemos rodar para ver o histório de uma imagem. Executemos:

sudo docker history wildfly-management

Agora vamos criar uma nova imagem, adicionando um pacote que deverá ser implantado (feito o deploy), automaticamente, quando instanciarmos o WildFly. Executemos:

mkdir -p ~/demos/02-wildfly-app
cd !$
cat > Dockerfile <<'EOF'
FROM wildfly-management
ADD node-info.war /opt/wildfly/standalone/deployments/
EOF
#curl -O http://paulojeronimo.github.io/JUDCon-2014-Brazil/node-info.war
scp pj@base:~/Projects/github.com/goldmann/goldmann.pl/.presentations/2014-vjbug-docker/demos/03-bundle/node-info.war .
sudo docker build -t wildfly-app .

Executemos novamente o comando para ver o histórico de uma imagem mas, dessa vez, informando o nome da imagem que derivamos de wildfly-management:

sudo docker history wildfly-app

Notemos, pela saída do comando anterior, que a imagem wildfly-app cresceu (em espaço ocupado em disco) cerca de 8.000 kB. Esse é, aproximadamente, o tamanho do pacote que mandamos adicionar ao conteúdo da imagem.

4.1.2. Executando em modo domain

Executemos o WildFly em modo domain:

sudo docker run -it --rm -p 8080:8080 -p 9990:9990 wildfly-app /opt/wildfly/bin/domain.sh -b 0.0.0.0 -bmanagement 0.0.0.0

Observando a console de execução do WildFly, notamos que dois servidores (server-one e server-two) são iniciados (em poucos segundos) e alguns avisos aparecem.

Tentemos acessar a console de administração do WildFly através da URL http://vm-fedora:8080. Ooopss …​ parece que caímos no problema de não termos um usuário administrativo.

sudo docker run -it --rm wildfly-app
bin/add-user.sh -dc domain/configuration/ -m -u admin -p Admin#70365 -s

Em outro console, executemos:

sudo docker commit d953
sudo docker ps -a
sudo docker diff high_wilson

4.1.3. Explorando mais

Dá para explorar várias coisas a mais …​ Para isso, veja estas referências:

4.2. RHQ no Docker

O RHQ é um produto de monitoração que é a base para o JON. Para instalá-lo via Docker, executemos:

git clone https://github.com/rhq-project/docker.git rhq-docker
cd !$/dockerfile
sudo ./build.sh
sudo ./run.sh

Explore mais detalhes nos seguintes links:

5. Para reiniciar este tutorial

  • Removamos a vm-fedora:

VBoxManage unregistervm vm-fedora --delete
  • Removamos a interface hostonlyif: