CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
47ec966d1982 local_discourse/app "/sbin/boot" 27 minutes ago Up 27 minutes 0.0.0.0:443->443/tcp, 0.0.0.0:8080->8080/tcp app
First of all, why do you start the container by your own docker command? The launcher script will do it after a successful rebuild/bootstrap. Many people do it in that way without issue.
And whatâs the point of mention python -m BaseHTTPServer 80 works OK? Your docker command mapped external port to 8080, which has nothing to do with whether 80 is accessible. You firewall may still blocking 8080.
What hosing provider are you using? Do they have any external firewall in front of your server?
The netstate -na command you logged indicates that 8080 port is only listened on ipv6 address not ipv4. Is there any setting youâve done regarding this?
Try curl http://127.0.0.1:8080 and curl http://<your server IP>:8080 on your Discourse server to see whether you can access the 8080 port. If yes, that means your Discourse is up but some firewall between your client and server blocked it. If no, that means your Discourse is not listening on ipv4 address.
If useful I see this log many many times by doing > ./launcher logs app :
nginx: [emerg] host not found in upstream âavatars.discourse.orgâ in /etc/nginx/conf.d/discourse.conf:215
Moreover, I have done a ssh tunnel (80->80) towards my local machine and connecting to my localhost:80 the connection is enstablished (TCP: SYN, ACK) but no welcome page (no page at all), the connection does not reach http levelâŚ
I exclude firewall issues since I have 2 proof:
dummy python server listening on port 80 is accessible from outside
ssh tunnel showed also at 127.0.0.1 discourse is not accessible
This is very suspicious. Why you have a upstream pointed to avatars.discourse.org? You may need to upload the content of your app.yml file(with sensitive information removed) so we can check whether there is any incorrect configuration.
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
expose:
- "80:80" # http
- "443:443" # https
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "768MB"
## can improve sorting performance, but adds memory usage per-connection
#db_work_mem: "40MB"
## Which Git revision should this container use? (default: tests-passed)
#version: tests-passed
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 4
## TODO: The domain name this Discourse instance will respond to
DISCOURSE_HOSTNAME: XXX
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'XXX'
## TODO: The SMTP mail server used to validate new accounts and send notifications
DISCOURSE_SMTP_ADDRESS: XXX
DISCOURSE_SMTP_PORT: XXX
DISCOURSE_SMTP_USER_NAME: XXX
DISCOURSE_SMTP_PASSWORD: ""
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## The CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
#DISCOURSE_CDN_URL: //discourse-cdn.example.com
HTTP_PROXY: "http://XXX/"
http_proxy: "http://XXX/"
HTTPS_PROXY: "https://XXX/"
https_proxy: "https://XXX/"
DISCOURSE_ENABLE_CORS: true
DISCOURSE_CORS_ORIGIN: '*'
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Any custom commands to run after building
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "End of custom commands"
I donât see any incorrect settings in your app.yml. If you are following the official docker installation guide, you should have no problem. Could you describe any divergence from the official guide you did during installation?
You may also upload the /etc/nginx/conf.d/discourse.conf file in your discourse container so we can see where the mysterious nginx error came from.
this is part of the > /etc/nginx/conf.d/discourse.conf on which into the logs I see:
nginx: [emerg] host not found in upstream âavatars.discourse.orgâ in /etc/nginx/conf.d/discourse.conf:215
location /letter_avatar_proxy/ {
# Donât send any client headers to the avatars service
proxy_method GET;
proxy_pass_request_headers off;
proxy_pass_request_body off;
# Don't let cookies interrupt caching, and don't pass them to the
# client
proxy_ignore_headers "Set-Cookie";
proxy_hide_header "Set-Cookie";
As far as I remember, nginx just wonât start if it encounter an emerg level problem. I believe thatâs why you cannot access your Discourse - your nginx is just not running, it keeps starting but never can success. So you see a lot of those logs and your site is not accessible.
Even if you donât believe so and try to find and solve the issue elsewhere, you still need to fix this problem eventually, so why not solve it now?
I see ^^
I was guessing it was a warning not so important.
root@XXX# ping avatars.discourse.org
ping: avatars.discourse.org: Name or service not known
root@XXX# ./launcher enter app
which: no docker.io in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/XXX/bin)
root@discuss:/var/www/discourse# ping avatars.discourse.org
ping: unknown host
root@discuss:/var/www/discourse#
Neither from the host machine and into the container is resolved.
Since I see the welcome page⌠it is actually mandatory to make such hostname resolvable? If no, how can I make it permanent so in case of a ./launcher rebuild app I would have a correct configuration?
If you canât resolve avatars.org you definitely have a problematic DNS setup for your server and that should be fixed. You may put /etc/resolv.conf file content here.
What modification? Change the upstream avatars.discourse.org to disourse? You shouldnât do so. Seeing the welcome page up doesnât mean it is running correctly. Iâm not sure but the location for avatars.discourse.org seems are for avatar functions, changing that may cause problems related to that.
