Docker-compose.yml traefik, taiga displays strange landing page.
Opened this issue · 11 comments
Hello all,
I am using the following docker-compose.yml file to start Taiga with Traefik.
version: "3"
services:
taiga:
image: quay.io/riotkit/taiga:5.0.6
depends_on:
- postgres
volumes:
- taigamedia:/usr/src/taiga-back/media
networks:
- backend
restart: always
environment:
TAIGA_SECRET_KEY: password_key
TAIGA_HOSTNAME: somehost.com
TAIGA_SCHEME: https
TAIGA_DB_NAME: taiga
TAIGA_DB_USER: taiga
TAIGA_DB_HOST: postgres
TAIGA_DB_PASSWORD: password
labels:
- traefik.enable=true
- traefik.frontend.rule=Host:somehost.com; PathPrefixStrip:/taiga
- traefik.backend=taiga
- traefik.docker.network=frontend
- traefik.port=80
- traefik.frontend.headers.referrerPolicy=no-referrer
- traefik.frontend.headers.SSLRedirect=true
- traefik.frontend.headers.contentTypeNosniff=true
postgres:
image: postgres
restart: always
environment:
POSTGRES_DB: taiga
POSTGRES_PASSWORD: password
POSTGRES_USER: taiga
volumes:
- postgrestaiga:/var/lib/postgresql/data
networks:
- backend
labels:
- traefik.enable=false
volumes:
taigamedia:
postgrestaiga:
networks:
backend:
external: true
The compose file executes successfully, however, when heading to hostname.com/taiga the following is displayed.
Am I missing something obvious here?
Thanks.
Hi,
What does the browser say in the developer tools?
Maybe it could be something related to PathPrefixStrip:/taiga?
We had some issue with traefik in the past, but actually I don't remember if it was resolved - you could look through issues by searching by traefik, we do not have them so many.
At @riotkit-org we run Taiga behind a gateway, but it is on NGINX. So that's where we have it tested all the time.
We use a our own dockerized environment based on docker-compose, which has service-discovery feature, just like Traefik, but based on NGINX.
Example service:
https://github.com/riotkit-org/riotkit-harbor/blob/master/apps/conf/infrastructure.health.yml
What I wanted to express is that we have of course tested it in a configuration behind a centralized gateway, with SSL provided by gateway and stripped down in the docker network.
That's our prod config in Harbor environment:
TAIGA_HOSTNAME: XYZ${DOMAIN_SUFFIX}
TAIGA_SCHEME: https
TAIGA_SECRET_KEY: "${TAIGA_SECRET_KEY}"
TAIGA_DEFAULT_LOCALE: pl
TAIGA_ENABLE_SSL: "false"
TAIGA_REDIRECT_TO_SSL: "false"
TAIGA_DB_NAME: ${TAIGA_DB}
TAIGA_DB_HOST: ${TAIGA_DB_HOST}
TAIGA_DB_USER: ${TAIGA_DB_USER}
TAIGA_DB_PASSWORD: ${TAIGA_DB_PASSWD}
TAIGA_ENABLE_EMAIL: "true"
TAIGA_EMAIL_FROM: no-reply@XYZ
TAIGA_EMAIL_USE_TLS: "false"
TAIGA_EMAIL_HOST: ${SMTP_ADDRESS}
TAIGA_EMAIL_PORT: ${SMTP_PORT}
TAIGA_EMAIL_USER: ${SMTP_USER}
TAIGA_EMAIL_PASS: ${SMTP_PASSWORD}
VIRTUAL_HOST: XYZ${DOMAIN_SUFFIX}
VIRTUAL_PORT: "80"
LETSENCRYPT_HOST: XYZ${DOMAIN_SUFFIX}
LETSENCRYPT_EMAIL: ${LETSENCRYPT_EMAIL}I have looked at PathPrefixStrip - I think if you are trying to setup Taiga instance under a subdirectory, that would not work. Most of the applications would not run in that way. The most safier, most common way is to assign a subdomain to an application.
Why? 1. Security reasons, 2. Common setup, less issues for the application to find it'self whats the url - it's more complex when an application separates frontend from backend - the frontend excepts specific endpoints on the backend eg. /api/something, not /taiga/api/something. That's even mostly hardcoded in the applications and nobody is thinking it could be wrong, because it's not.
Looking in the browser console. I am seeing some odd errors.
The resource from “https://{{Ipaddress}}/apps/files/” was blocked due to MIME type (“text/html”)
I have a instance of nextcloud deployed. Which has a NGINX instance already running, could this be causing issues?
It looks like when I go to /taiga it is getting confused on where do go or something? Tbh I am out of my depth here :/
I don't really have the option to have a subdomain in my setup as it's a local service. I just head to the IP address and is why I am using the PathPrefixStrip to go to the Taiga service.
You are in an internal network? Maybe we can find some solution if you could describe the environment.
I just checked to see if Traefik is routing to the container correctly and it looks like it should be.
Looking in the dashboard I can see the frontend is linked to the appropriate backend. The backend server IP is http://172.31.0.9:80 and using docker inspect the IP for taiga is http://172.31.0.9:80 so that's all correct 🤔
Here are the logs from the container, although nothing looks a miss to me here:
>> Setting user id and group id
usermod: no changes
>> Correcting permissions
>> Preparing configuration files...
HINT: Add your files into /etc/nginx/extensions.d to include them in NGINX configuration
>> Enabling plugins
>> Preparing a database migration
Running database check
Connecting to database:
dbname='taiga' user='taiga' host='postgres' password='somepasswordhere'
>> Updating/migrating plugins...
['']
+ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
+ exec supervisord -c /etc/supervisord.conf
2020-02-13 22:35:58,896 INFO Set uid to user 0 succeeded
2020-02-13 22:35:58,899 INFO supervisord started with pid 1
2020-02-13 22:35:59,904 INFO spawned: 'nginx' with pid 21
2020-02-13 22:35:59,907 INFO spawned: 'backend' with pid 22
2020-02-13 22:36:00,159 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [22] [INFO] Starting gunicorn 19.9.0
2020-02-13 22:36:00,159 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [22] [INFO] Listening at: http://127.0.0.1:8000 (22)
2020-02-13 22:36:00,159 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [22] [INFO] Using worker: sync
2020-02-13 22:36:00,162 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [29] [INFO] Booting worker with pid: 29
2020-02-13 22:36:00,239 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [31] [INFO] Booting worker with pid: 31
2020-02-13 22:36:00,277 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [32] [INFO] Booting worker with pid: 32
2020-02-13 22:36:00,347 DEBG 'backend' stderr output:
[2020-02-13 22:36:00 +0000] [34] [INFO] Booting worker with pid: 34
2020-02-13 22:36:00,651 DEBG 'backend' stderr output:
Trying import local.py settings...
2020-02-13 22:36:00,800 DEBG 'backend' stderr output:
Trying import local.py settings...
2020-02-13 22:36:00,851 DEBG 'backend' stderr output:
Trying import local.py settings...
2020-02-13 22:36:00,930 DEBG 'backend' stderr output:
Trying import local.py settings...
2020-02-13 22:36:00,931 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-13 22:36:00,931 INFO success: backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-02-13 22:36:14,027 DEBG 'nginx' stdout output:
127.0.0.1 - - [13/Feb/2020:22:36:14 +0000] "GET / HTTP/1.1" 200 91976 "-" "curl/7.64.0" "-"
2020-02-13 22:37:14,462 DEBG 'nginx' stdout output:
127.0.0.1 - - [13/Feb/2020:22:37:14 +0000] "GET / HTTP/1.1" 200 91976 "-" "curl/7.64.0" "-"
I'm sure the frontend is looking for the backend to be at "/", that's why it does not connect.
Hmmm. Seems I'm kinda screwed then...