We’re enjoying discourse thus far. I’m having an issue with running a rebuild of the docker container. The container won’t rebuild because for some reason it can’t resolve github.com. I know the host system (debian jessie) can resolve at that time via dig && ping. However if I issue a systemctl restart docker the issue goes away.
I turned to the goog or alphabet machine which suggested starting the docker daemon using the goog’s dns which I’ve done and confirmed that it seems to have taken via a systemctl status docker.
I’ve been able to reproduce on a debian droplet and a virtual box vm.
Also I’ve been able to successfully pull a Ubuntu image, and run the container.
I’m not sure if there’s something in launcher or any other suggestions? Working off of git master, and is up to date.
shortlist:
Debian Jessie Kernel 3.16
Docker version 1.6.2, build 7c8fca2
launch rebuild app
root@alpha:/var/discourse# ./launcher rebuild app
Ensuring discourse docker is up to date
Fetching origin
Discourse Docker is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 10 app
app
cd /pups && git pull && /pups/bin/pups --stdin
fatal: unable to access 'https://github.com/SamSaffron/pups.git/': Could not resolve host: github.com
210c421dbe03e0339d110f1eec9eb3c985b0a0d4e32709d569c9cd1f235a7964
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one
systemctl status - shows --dns
root@alpha:/var/discourse# systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: active (running) since Thu 2015-08-13 03:42:17 UTC; 26min ago
Docs: http://docs.docker.com
Main PID: 22232 (docker)
CGroup: /system.slice/docker.service
└─22232 /usr/bin/docker -d -H fd:// --dns 8.8.8.8 --dns 8.8.4.4
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="+job wait(7d602b0addff82e7626b659c5e30131a11ab7f35034198983a19e2b8861111b5)"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="-job wait(7d602b0addff82e7626b659c5e30131a11ab7f35034198983a19e2b88... = OK (0)"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="DELETE /v1.18/containers/7d602b0addff82e7626b659c5e30131a11ab7f3503...8861111b5"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="+job rm(7d602b0addff82e7626b659c5e30131a11ab7f35034198983a19e2b8861111b5)"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="+job log(destroy, 7d602b0addff82e7626b659c5e30131a11ab7f35034198983...e:1.0.12)"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="-job log(destroy, 7d602b0addff82e7626b659c5e30131a11ab7f35034198983... = OK (0)"
Aug 13 04:03:40 alpha docker[22232]: time="2015-08-13T04:03:40Z" level=info msg="-job rm(7d602b0addff82e7626b659c5e30131a11ab7f35034198983a19e2b8861... = OK (0)"
Aug 13 04:04:15 alpha docker[22232]: time="2015-08-13T04:04:15Z" level=info msg="GET /v1.18/containers/json"
Aug 13 04:04:15 alpha docker[22232]: time="2015-08-13T04:04:15Z" level=info msg="+job containers()"
Aug 13 04:04:15 alpha docker[22232]: time="2015-08-13T04:04:15Z" level=info msg="-job containers() = OK (0)"
Hint: Some lines were ellipsized, use -l to show in full.
docker info
root@alpha:/var/discourse# docker info
Containers: 3
Images: 18
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 24
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
CPUs: 1
Total Memory: 2.879 GiB
Name: alpha
ID: WF4H:KABY:JPTX:RW2U:FWCT:PNKZ:DR2P:2ZFE:ZLUD:AB4R:D3CH:EXCA
WARNING: No memory limit support
WARNING: No swap limit support
Hi @sam thanks for taking the time to review.
I have that option uncommented in /etc/defaults/docker, and I’ve restarted the docker service many times.
To clarify, after restarting the docker service the laucher rebuild will work once, after that I have to restart the service.
Interestingly though, when I ping6 github.com I of course do not recieve a response because github does not have AAAA records i believe. https://i.imgur.com/Qu9OJg9.png
This isn’t a Discourse problem, it’s a Docker problem. You’ll probably get more knowledgeable help at the Docker support forums (which, helpfully, also run Discourse).
I figured out the issue and solution to this problem at least for me.
The issue was that Docker uses 8.8.8.8 and 8.8.4.4 as its DNS and I had an OVH network based firewall blocking ALL IPv4 traffic that did not match port 80, 443, and a few other specific rules. I had to authorize IPv4 traffic for 8.8.8.8 and 8.8.4.4
Estou enfrentando um problema semelhante na versão mais recente do Discourse via Git. Isso começou a acontecer após realizar uma atualização do sistema e/ou do Discourse pela interface web. Agora, quando tento reconstruir o aplicativo, recebo:
[root@forum /var/discourse]# ./launcher rebuild app
Garantindo que o launcher esteja atualizado
Buscando origem
Launcher está atualizado
Parando o contêiner antigo
+ /usr/bin/docker stop -t 60 app
app
cd /pups && git pull && /pups/bin/pups --stdin
fatal: unable to access 'https://github.com/discourse/pups.git/': Could not resolve host: github.com
8f082ebcb977f9efafbdbff15ab69e8d06c0a7e2cb99410f85e1f90b03ae733b
** FALHA NO BOOTSTRAP ** Por favor, role para cima e procure mensagens de erro anteriores; pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
Consigo fazer ping no github.com e no 8.8.8.8, e já tentei editar /etc/default/docker para alternar a opção de DNS: DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"
Onde devo continuar investigando isso?
Isso está sendo executado no Ubuntu 18.04 com as atualizações mais recentes aplicadas.
Se eu forçar o uso da rede host, ele consegue acessar a Internet:
docker run -it --net=host --rm busybox ping -c 1 github.com
PING github.com (140.82.112.4): 56 bytes de dados
64 bytes de 140.82.112.4: seq=0 ttl=53 time=6.902 ms
--- estatísticas de ping do github.com ---
1 pacote transmitido, 1 pacote recebido, 0% de perda de pacotes
min/média/máx do tempo de ida e volta = 6.902/6.902/6.902 ms
Estou também executando o Ubuntu 18.04.4 LTS, tendo atualizado todos os pacotes e instalado todas as atualizações de segurança imediatamente antes de seguir a sequência de atualização do Discourse.
@gekkonen Consegui fazer o meu funcionar novamente. Como solução alternativa, para forçar a Internet a funcionar a partir do Docker, você pode configurar a rede docker0 para usar o modo “promiscuous”:
Em seguida, você deverá ser capaz de usar o launcher para reconstruir o aplicativo, e o fórum Discourse deverá funcionar normalmente. A ressalva é que você provavelmente terá que executar o comando novamente após cada reinicialização.
No CentOS 8, esse erro ocorre porque os pacotes RPM do Docker para RHEL 7 (ainda não existem versões para RHEL 8) não compreendem o novo firewall baseado em nftables. É necessário configurar manualmente o mascaramento para a interface docker0.
Gostaria de confirmar que essa solução funciona. Estou no CentOS 8, com Hetzner.
Especificamente, executei os seguintes comandos na ordem listada abaixo. (fonte) - obrigado a @paulraines68
# O mascaramento permite o tráfego de entrada e saída do Docker (esta é a parte importante)
firewall-cmd --zone=public --add-masquerade --permanent
# Permitir especificamente o tráfego de entrada nas portas 80/443 (nada de novo aqui)
firewall-cmd --zone=public --add-port=80/tcp
firewall-cmd --zone=public --add-port=443/tcp
# Recarregar o firewall para aplicar as regras permanentes
firewall-cmd --reload
