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.
Plataforma aberta para desenvolvedores e sysadmins
Para construir, implantar e executar aplicações distribuídas
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, …
Sysadmins utilizam o docker para prover ambientes para times de:
Desenvolvimento, Quality assurance (QA), produção
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
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 Hub é o registry público
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
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.
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.
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).
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
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.
Executemos:
sudo docker run -i -t fedora /bin/bash
Os parâmetros passados ao docker significam o seguinte:
run
- executa um contêiner (como vimos anteriormente);
-i
- mantem o stdin aberto, mesmo que não haja nada anexado;
-t
- aloca um pseudo terminal, dessa forma podermos interagir diretamente com o contêiner;
fedora
- ID da imagem, pode ser uma tag ou um hash (id);
/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:
Se a imagem do contêiner não estiver no cache local ela será baixada (nessa execução ela já estava no cache);
Se quiséssesmos apenas baixar a imagem, sem criar nenhum contêiner, poderíamos simplesmente executar o comando sudo docker pull fedora
;
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:
O contêiner tem um sistema de arquivos próprio e independente do host;
O contêiner só está executando o comando que lhe foi solicitado executar;
O nome configurado para o contêiner é o seu id;
Há duas interfaces de rede configuradas: a de loopback, e outra com um IP específico;
O espaço em disco alocado para a partição root (/) é de 9.8G;
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.
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/
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.
As instruções para o boot do WildFly no Docker estão na página https://registry.hub.docker.com/u/jboss/wildfly/.
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.
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
Dá para explorar várias coisas a mais … Para isso, veja estas referências:
Apresentação do Marek Goldmann no Virtual JBoss User Group (Setembro/2014):
https://goldmann.pl/blog/2014/03/06/creating-a-minimal-wildfly-docker-image/