Wordpress implementado con JUJU usando LXC falla

Wordpress implementado con JUJU usando LXC falla

Cuando implemento los accesos de wordpress y mysql con juju en mi controlador maas de esta manera:

juju deploy --to lxc:0 wordpress
juju deploy --to lxc:0 mysql
juju add-relation wordpress:db mysql:db --debug

la salida muestra algo como

DEBUG juju.api api.go 492 API hostnames unchanged - not resolving

con un poco más de paciencia, wordpress fallará y el comando de estado de juju muestra lo siguiente:

wordpress/0
 workload-status:
  current: error
  message: 'hook failed: "db-relation-changed" for mysql:db'

estado de juju --form tabular devolvió esto para la sección de unidad:

[Units]     
ID          WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS    PUBLIC-ADDRESS  MESSAGE                                         
juju-gui/0  unknown        idle        1.24.0  0       8080/tcp HP22.rigonet.nl                                                 
mysql/0     unknown        idle        1.24.0  0/lxc/2          192.168.50.86                                                   
wordpress/0 error          idle        1.24.0  0/lxc/7 80/tcp   192.168.50.83   hook failed: "db-relation-changed" for mysql:db 

Fui a buscar en juju ssh wordpress/0 el archivo /var/log/juju/unit-wordpress-0.log y encontré:

2015-07-15 15:42:16 INFO worker.uniter.jujuc server.go:138 running hook tool "relation-get" ["password"]
2015-07-15 15:42:16 DEBUG worker.uniter.jujuc server.go:139 hook context id "wordpress/0-db-relation-changed-1875247148271195053"; dir "/var/lib/juju/agents/unit-wordpress-0/charm"
2015-07-15 15:42:16 INFO worker.uniter.jujuc server.go:138 running hook tool "relation-get" ["private-address"]
2015-07-15 15:42:16 DEBUG worker.uniter.jujuc server.go:139 hook context id "wordpress/0-db-relation-changed-1875247148271195053"; dir "/var/lib/juju/agents/unit-wordpress-0/charm"
2015-07-15 15:42:17 DEBUG juju.worker.leadership tracker.go:138 wordpress/0 renewing lease for wordpress leadership
2015-07-15 15:42:17 DEBUG juju.worker.leadership tracker.go:165 checking wordpress/0 for wordpress leadership
2015-07-15 15:42:17 DEBUG juju.worker.leadership tracker.go:180 wordpress/0 confirmed for wordpress leadership until 2015-07-15 15:43:17.202318193 +0000 UTC
2015-07-15 15:42:17 INFO juju.worker.leadership tracker.go:182 wordpress/0 will renew wordpress leadership at 2015-07-15 15:42:47.202318193 +0000 UTC
2015-07-15 15:42:26 INFO juju.worker.uniter.context context.go:534 handling reboot
**2015-07-15 15:42:26 ERROR juju.worker.uniter.operation runhook.go:107 hook "db-relation-changed" failed: exit status 2**
2015-07-15 15:42:26 INFO juju.worker.uniter modes.go:546 ModeAbide exiting
2015-07-15 15:42:26 INFO juju.worker.uniter modes.go:544 ModeHookError starting
2015-07-15 15:42:26 DEBUG juju.worker.uniter.filter filter.go:597 want resolved event
2015-07-15 15:42:26 DEBUG juju.worker.uniter.filter filter.go:591 want forced upgrade true
2015-07-15 15:42:26 DEBUG juju.worker.uniter.filter filter.go:727 no new charm event
2015-07-15 15:42:26 DEBUG juju.worker.uniter modes.go:31 [AGENT-STATUS] error: hook failed: "db-relation-changed"
2015-07-15 15:42:26 DEBUG juju.worker.leadership tracker.go:154 wordpress/0 got wait request for wordpress leadership loss
2015-07-15 15:42:26 DEBUG juju.worker.leadership tracker.go:248 wordpress/0 still has wordpress leadership

El archivo machine-0-lxc-7.log que encontré

2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "rsyslog"
2015-07-15 15:40:15 DEBUG juju.worker.rsyslog worker.go:105 starting rsyslog worker mode 1 for "machine-0-lxc-7" ""
2015-07-15 15:40:15 DEBUG juju.worker.logger logger.go:60 logger setup
2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "stateconverter"
2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "diskmanager"
2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "storageprovisioner-machine"
2015-07-15 15:40:15 DEBUG juju.network network.go:220 no lxc bridge addresses to filter for machine
2015-07-15 15:40:15 INFO juju.worker.machiner machiner.go:94 setting addresses for machine-0-lxc-7 to ["local-machine:127.0.0.1" "local-cloud:192.168.50.83" "local-machine:::1"]
2015-07-15 15:40:15 DEBUG juju.worker.proxyupdater proxyupdater.go:151 new proxy settings proxy.Settings{Http:"", Https:"", Ftp:"", NoProxy:""}
2015-07-15 15:40:15 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=DEBUG;unit=DEBUG"
2015-07-15 15:40:15 INFO juju.worker.diskmanager diskmanager.go:62 block devices changed: []
2015-07-15 15:40:15 DEBUG juju.network network.go:220 no lxc bridge addresses to filter for machine
2015-07-15 15:40:15 INFO juju.worker.apiaddressupdater apiaddressupdater.go:78 API addresses updated to [["HP22.rigonet.nl:17070" "192.168.50.16:17070" "127.0.0.1:17070" "[::1]:17070"]]
2015-07-15 15:40:15 DEBUG juju.worker.reboot reboot.go:82 Reboot worker got action: noop
2015-07-15 15:40:15 DEBUG juju.worker.rsyslog worker.go:213 making syslog connection for "juju-machine-0-lxc-7" to 192.168.50.16:6514
2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "networker"
2015-07-15 15:40:15 INFO juju.worker runner.go:261 start "authenticationworker"
2015-07-15 15:40:15 INFO juju.networker networker.go:163 networker is disabled - not starting on machine "machine-0-lxc-7"
2015-07-15 15:40:15 DEBUG juju.worker.proxyupdater proxyupdater.go:170 new apt proxy settings proxy.Settings{Http:"", Https:"", Ftp:"", NoProxy:""}

Lo único interesante que pude encontrar en /var/log/syslog es:

Jul 15 15:41:22 HP22 kernel: [1280629.664746] type=1400 audit(1436974882.268:99): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/rpc_pipefs/" pid=7655 comm="mount" fstype="rpc_pipefs" srcname="rpc_pipefs" flags="rw"
Jul 15 15:41:22 HP22 kernel: [1280629.664831] type=1400 audit(1436974882.268:100): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/rpc_pipefs/" pid=7655 comm="mount" fstype="rpc_pipefs" srcname="rpc_pipefs" flags="ro"
Jul 15 15:41:22 HP22 kernel: [1280629.687213] type=1400 audit(1436974882.288:101): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/rpc_pipefs/" pid=7668 comm="mount" fstype="rpc_pipefs" srcname="rpc_pipefs" flags="rw"
Jul 15 15:41:22 HP22 kernel: [1280629.687302] type=1400 audit(1436974882.288:102): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/rpc_pipefs/" pid=7668 comm="mount" fstype="rpc_pipefs" srcname="rpc_pipefs" flags="ro"
Jul 15 15:41:22 HP22 kernel: [1280629.729821] type=1400 audit(1436974882.332:105): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/rpc_pipefs/" pid=7692 comm="mount" fstype="rpc_pipefs" srcname="rpc_pipefs" flags="rw"

En el controlador maas también tengo instalado webmin para ver rápidamente mis zonas DNS BIND. Noté que el servidor DHCP le da al host una dirección IP estática. Los contenedores lxc en esa máquina reciben direcciones DHCP dentro del rango que había definido para el clúster en MAAS, pero el nombre de su máquina (máquina-0-lxc-7) no está registrado en el servidor DNS. Me resulta extraño que los contenedores LXC tampoco aparezcan en MAAS.

¿Qué puedo hacer para depurar más y ponerlo en funcionamiento?

Saludos, joham

información relacionada