I’m having issues deploying Discourse to a VM in my test environment. The VM is configured with 1 core and 1gb of ram. It is running on ubuntu 18.04, via docker’s basic install method. I am running these as root. I’ve removed sensitive data from the output below.
root@progcodedev-01:/var/discourse# ./discourse-setup
The configuration file containers/app.yml already exists!
. . . reconfiguring . . .
Saving old file as app.yml.2019-03-11-153340.bak
Stopping existing container in 5 seconds or Control-C to cancel.
app was not started !
Found 1GB of memory and 1 physical CPU cores
setting db_shared_buffers = 128MB
setting UNICORN_WORKERS = 2
containers/app.yml memory parameters updated.
ENTER to continue, 'n' to try again, Ctrl+C to exit:
Configuration file at updated successfully!
Updates successful. Rebuilding in 5 seconds.
Building app
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
cd /pups && git pull && /pups/bin/pups --stdin
docker: Failed to create the container ID file: open cids/app_bootstrap.cid: no such file or directory.
See 'docker run --help'.
cat: cids/app_bootstrap.cid: No such file or directory
"docker rm" requires at least 1 argument.
See 'docker rm --help'.
Usage: docker rm [OPTIONS] CONTAINER [CONTAINER...]
Remove one or more containers
rm: cannot remove 'cids/app_bootstrap.cid': No such file or directory
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one
root@progcodedev-01:/var/discourse#
Any idea what could be going on?
Here are the current directory permissions:
root@progcodedev-01:/var/discourse# ls -la
total 128
drwxr-xr-x 11 root root 4096 Mar 11 14:34 .
drwxr-xr-x 14 root root 4096 Mar 11 14:34 ..
drwxr-xr-x 2 root root 4096 Mar 11 14:34 bin
drwxr-xr-x 2 root root 4096 Mar 11 15:27 cids
drwxr-xr-x 2 root root 4096 Mar 11 15:35 containers
-rwxr-xr-x 1 root root 11394 Mar 11 14:34 discourse-doctor
-rwxr-xr-x 1 root root 20820 Mar 11 14:34 discourse-setup
drwxr-xr-x 8 root root 4096 Mar 11 15:20 .git
-rw-r--r-- 1 root root 309 Mar 11 14:34 .gitignore
drwxr-xr-x 8 root root 4096 Mar 11 14:34 image
-rwxr-xr-x 1 root root 22215 Mar 11 14:34 launcher
-rw-r--r-- 1 root root 1099 Mar 11 14:34 LICENSE
-rw-r--r-- 1 root root 8900 Mar 11 14:34 README.md
drwxr-xr-x 2 root root 4096 Mar 11 14:34 samples
drwxr-xr-x 2 root root 4096 Mar 11 14:34 scripts
drwxr-xr-x 2 root root 4096 Mar 11 14:34 shared
drwxr-xr-x 3 root root 4096 Mar 11 14:34 templates
-rw-r--r-- 1 root root 1266 Mar 11 14:34 Vagrantfile
I believe I got this working now. I noticed while looking at syslog that the docker container was having issues with it’s networking. When I originally installed Ubuntu, I opted to use the installer supplied version of docker. I re-rolled the instance and this time used the script on get.docker.com to install docker. This version of docker worked fine and discourse is now running without issues (as far as I can tell.)
На всякий случай, если кто-то столкнётся с этим снова…
У меня была та же проблема с Docker, установленным через snap на Ubuntu 20.04. В системном журнале (syslog) было полно ошибок, связанных с интерфейсом docker0.
Jan 30 14:28:17 mel kernel: [169365.081105] veth23ac856: renamed from eth0
Jan 30 14:28:17 mel networkd-dispatcher[782]: WARNING:Unknown index 103 seen, reloading interface list
Jan 30 14:28:17 mel systemd-udevd[103811]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 30 14:28:17 mel systemd-networkd[730]: veth7651758: Link DOWN
Jan 30 14:28:17 mel kernel: [169365.208636] docker0: port 1(veth7651758) entered disabled state
Jan 30 14:28:17 mel kernel: [169365.212027] device veth7651758 left promiscuous mode
Jan 30 14:28:17 mel kernel: [169365.212031] docker0: port 1(veth7651758) entered disabled state
Jan 30 14:28:17 mel systemd-udevd[103811]: veth23ac856: Failed to get link config: No such device
Проблему решил самый свежий пакет, загруженный напрямую из репозитория docker.com..
Я думаю, это связано с установкой Docker в Ubuntu через snap со своей собственной виртуальной файловой системой. Я бы рекомендовал придерживаться этой конфигурации, настроив /var/discourse так, чтобы он был виден для демона Docker.
Хорошо, могу подтвердить, что изоляция snap была проблемой в моём случае. (Возможно, дело не в монтировании тома, а в --cidfile, как предполагалось, поскольку он работает и не используется)
Поскольку Ubuntu «всё ещё работает над этим» (или, по крайней мере, я не нашёл, как экспонировать файловые системы), а опция --classic также не работает для docker snap:
snap remove docker && snap install --classic docker
Warning: flag --classic ignored for strictly confined snap docker
Я выбрал «простой» путь и использовал /home/discourse вместо /var/discourse в качестве базовой директории. (Это даже не обязательно запускать от имени этого пользователя).
Я понимаю, что вы можете требовать официальный docker, но с другой стороны, я также понимаю Ubuntu, поддерживающую свою версию, так что для пользователей это выбор между молотом и наковальней.