How to install PenPot on docker using Portainer and Traefik? - docker

I am trying to install PenPot using Portainer and Traefik. I have entered my docker-compose file into Portainer and created the stacks. In Traefik I have created a proxy network for the frontend of PenPot to connect to. On the back end I am using the default network for the backend of PenPot and the database to use. As far as I can tell (and I am just starting out with Docker, so I am trying to learn) everything looks to be set up correctly.
However when I look into the logs for backend PenPot, I see that it can't connect to the database. It fails with the following message:
FATAL: password authentication failed for user "penpot"
I have checked the password used and it is spelt correctly in both instances and the password doesn't use any special characters. I have gone over the settings multiple times and I can't for the life of me figure out why I am getting this error. Can I not have multiple networks? Am I missing something in my configuration?
This is my docker-compose file. Hopefully someone can point out the error that I am making.
version: "3.5"
networks:
default:
external: false
proxy:
external: true
volumes:
postgres_data:
assets_data:
services:
frontend:
image: "penpotapp/frontend:latest"
hostname: frontend.penpot
volumes:
- assets_data:/opt/data
depends_on:
- penpot-backend
- penpot-exporter
networks:
- default
- proxy
labels:
- traefik.enable=true
- traefik.docker.network=proxy
- traefik.constraint-label=proxy
- traefik.http.routers.penpot-http.rule=Host(`penpot.mydomain.com`)
- traefik.http.routers.penpot-http.entrypoints=http
- traefik.http.middlewares.penpot-https-redirect.redirectscheme.scheme=https
- traefik.http.routers.penpot-http.middlewares=penpot-https-redirect
- traefik.http.routers.penpot-https.rule=Host(`penpot.mydomain.com`)
- traefik.http.routers.penpot-https.entrypoints=https
- traefik.http.routers.penpot-https.tls=true
- traefik.http.routers.penpot-https.tls.certresolver=le
- traefik.http.services.penpot.loadbalancer.server.port=80
penpot-backend:
image: "penpotapp/backend:latest"
hostname: backend.penpot
volumes:
- assets_data:/opt/data
depends_on:
- postgres
- redis
environment:
## Standard database connection parameters (only postgresql is supported):
- POSTGRES_DB=penpot
- POSTGRES_USER=penpot
- POSTGRES_PASSWORD=penpot
## Redis is used for the websockets notifications.
- PENPOT_REDIS_URI=redis://penpot-redis/0
## Should be set to the public domain where penpot is going to be served.
- PENPOT_PUBLIC_URI=https://penpot.mydomain.com
## Feature flags.
- PENPOT_FLAGS=enable-registration enable-login disable-email-verification
## By default, files uploaded by users are stored in local
## filesystem. But it can be configured to store in AWS S3.
- PENPOT_ASSETS_STORAGE_BACKEND=assets-fs
- PENPOT_STORAGE_ASSETS_FS_DIRECTORY=/opt/data/assets
## Telemetry. When enabled, a periodical process will send anonymous
## data about this instance.
- PENPOT_TELEMETRY_ENABLED=false
## Email sending configuration. By default, emails are printed in the
## console, but for production usage is recommended to setup a real
## SMTP provider. Emails are used to confirm user registrations.
- PENPOT_SMTP_ENABLED=true
- PENPOT_SMTP_DEFAULT_FROM=Penpot <no-reply#mydomain.com>
- PENPOT_SMTP_DEFAULT_REPLY_TO=Penpot <no-reply#mydomain.com>
- PENPOT_SMTP_HOST=mail.mydomain.com
- PENPOT_SMTP_PORT=587
- PENPOT_SMTP_USERNAME=XXXX
- PENPOT_SMTP_PASSWORD=XXXX
- PENPOT_SMTP_TLS=true
- PENPOT_SMTP_SSL=false
networks:
- default
penpot-exporter:
image: "penpotapp/exporter:latest"
environment:
# Don't touch it; this uses internal docker network to
# communicate with the frontend.
- PENPOT_PUBLIC_URI=http://frontend.penpot
networks:
- default
postgres:
image: "postgres:14"
restart: always
stop_signal: SIGINT
environment:
- POSTGRES_INITDB_ARGS=--data-checksums
- POSTGRES_DB=penpot
- POSTGRES_USER=penpot
- POSTGRES_PASSWORD=penpot
volumes:
- postgres_data:/var/lib/postgresql/data
networks:
- default
redis:
image: redis:7
restart: always
networks:
- default

Related

Local proxy server using Traefik/Docker

I'm trying to create some kind of reverse proxy server that would serve a port running on my local network (192.168.0.15:5083) through either another port (192.168.0.15:<ANOTHER PORT>) or through another path on the IP address (192.168.0.15/pathname). I want this to be reachable from other computers on the same network.
I'm trying to achieve this using Traefik with Docker through a docker-compose.yml file. Currently I have it set up like this:
lms:
container_name: lms
image: epoupon/lms
user: ${PUID}:${PGID}
ports:
- 5083:5082
volumes:
- ${USERDIR}/docker/lms:/var/lms
- /media/music:/music:ro
environment:
- TZ=${TZ}
- PUID=${PUID}
- PGID=${PGID}
labels:
- "traefik.enable=true"
- "traefik.http.routers.lms.rule=Path(`/lms`)"
restart: unless-stopped
reverse-proxy:
image: traefik:v2.6
command: --api.insecure=true --providers.docker
ports:
- "80:80"
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
What I'm trying to do here is to create a path on the servers IP address (192.168.0.15/lms) that would serve port 5083 (192.168.0.15:5083). The purpose of this is to then be able to apply CORS headers to the proxy server.
When visiting 192.168.0.15/lms from another machine on the same network as the server, I get this error message:
Fatal error: failed loading /js/jquery-1.10.2.min.js
I interpret this as if it gets a connection to port 5083, but the assets/resources being used on the front end on that port is not loading correctly.
Am I doing this right or should I do it in a different way to succeed?

Jira in Docker on Apple Silicone (M1)

I'm recently trying to get a local Jira instance run in a docker container on an Apple Silicone M1 chip.
I'm using Postgres for the database (also tried mariaDB) and an arm image of Jira that I've found on GitHub.
However, whenever I docker-compose the setup I run into an error 500 "Error writing database configuration file."
Both, Jira and the DB container seem to start up fine.
I guess that the database might be not reachable but I have no idea how to check that.
TLDR: How can I check whether my DB is reachable to my Jira container OR rather how to fix the error 500 from Jira "Error writing database configuration file."
Below is the compose file I'm using:
services:
jira:
dchevell/jira-software-arm64
#image: ghcr.io/eugenmayer/jira:${JIRA_VERSION}
depends_on:
- db
container_name: jirasoftwarevomeugen
volumes:
- jiradata:/var/atlassian/jira
ports:
- '80:8080'
environment:
- 'JIRA_DATABASE_URL=postgresql://jira#db/jiradb'
- 'JIRA_DB_PASSWORD=jellyfish'
- 'CATALINA_OPTS= -Xms256m -Xmx1g'
- 'JIRA_PROXY_NAME='
- 'JIRA_PROXY_PORT='
- 'JIRA_PROXY_SCHEME='
# need for the wait-for-db statement
- 'JIRA_DB_HOST=db'
- 'JIRA_DB_PORT=5432'
db:
image: postgres
hostname: postgresql
volumes:
- postgresqldata:/var/lib/postgresql/data
environment:
- 'POSTGRES_USER=jira'
- 'POSTGRES_PASSWORD=jellyfish'
- 'POSTGRES_DB=jiradb'
- 'POSTGRES_ENCODING=UTF8'
- 'POSTGRES_COLLATE=C'
- 'POSTGRES_COLLATE_TYPE=C'
# uncomment this to run against mysql
# db:
# image: mariadb:10.3
# hostname: mysql
# volumes:
# - mysqldata:/var/lib/mysql
# environment:
# - 'MYSQL_ROOT_PASSWORD=verybigsecretrootpassword'
# - 'MYSQL_DATABASE=jiradb'
# - 'MYSQL_USER=jira'
# - 'MYSQL_PASSWORD=jellyfish'
volumes:
jiradata:
external: false
postgresqldata:
external: false
mysqldata:
external: false
newdb:
external: false
When Jira starts up, it will try to write configuration files into the Jira data directory. This type of problem can occur if the directory you have mounted is not writable by the Jira user.
You may want to investigate the UID:GID of the Jira user in the image you have chosen, then spin up a standalone container to run a shell (which also mounts the jiradata container), chown -R the mounted directory to the correct user:group (if it is not what you expect), and then try restarting Jira.
I took a build in arm architecture and uploaded it to the hub. You can access it here. You can use the following docker compose as an example.
version: "3.1"
volumes:
jira_volume:
postgres_volume:
services:
postgres:
image: postgres:10
ports:
- 5435:5432
volumes:
- postgres_volume:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: admin
jira:
image: yasinmert/atlassian-jira-software-arm64
ports:
- 7030:8080
volumes:
- jira_volume:/var/atlassian/application-data/jira
environment:
ATL_TOMCAT_CONTEXTPATH: /jira
ATL_JDBC_URL: jdbc:postgresql://postgres:5432/jira
ATL_JDBC_USER: postgres
ATL_JDBC_PASSWORD: admin
ATL_DB_DRIVER: org.postgresql.Driver
depends_on:
- postgres

Mailcow Reverse Proxy using Traefik not routing to the correct Nginx Service

I am trying to follow the community documentation on mailcow dockerized and I am using Traefik as my load balancer.
I have successfully obtained a SSL certificate and the certdump is working as expected when I check the logs.
The issue I have having is that the nginx-mailcow container is not receiving the requests when I visit mail.example.com. My Traefik logs show this:
level=error msg="entryPoint \"secure\" doesn't exist" routerName=moo#docker entryPointName=secure
level=error msg="no valid entryPoint for this router" routerName=moo#docker
My docker-compose.override.yml looks like this (not much different to the community documentation):
version: '2.1'
services:
nginx-mailcow:
networks:
traefik:
web:
labels:
- traefik.enable=true
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
- traefik.http.routers.moo.tls=true
- traefik.http.routers.moo.tls.certresolver=godaddy
- traefik.http.routers.moo.middlewares=redirect#file
- traefik.http.routers.moo.service=nginx-mailcow
- traefik.http.services.moo.loadBalancer.passHostHeader=true
- traefik.http.middlewares.https-redirect.redirectscheme.scheme=https
- traefik.http.middlewares.https-redirect.headers.customrequestheaders.X-Forwarded-Proto=https
- traefik.http.routers.moo.middlewares=https-redirect
- traefik.http.services.moo.loadbalancer.server.port=80
- traefik.http.routers.moo.entrypoints=secure
- traefik.docker.network=web
certdumper:
image: humenius/traefik-certs-dumper
container_name: traefik_certdumper
network_mode: none
volumes:
- acme:/traefik:ro
- ./data/assets/ssl/:/output:rw
environment:
- DOMAIN=${MAILCOW_HOSTNAME}
networks:
traefik:
external: true
web:
external: true
volumes:
acme:
name: "traefik_acme"
Can anyone see what I am doing wrong?
I have also tried with only:
labels:
- traefik.enable=true
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
- traefik.http.routers.moo.tls=true
- traefik.http.routers.moo.tls.certresolver=godaddy
- traefik.http.services.moo.loadbalancer.server.port=80
- traefik.http.routers.moo.entrypoints=secure
- traefik.docker.network=web
This still did not work.
When you define a name for a service, you must use the same name in your service configuration, like this:
traefik.http.routers.moo.service=nginx-mailcow
traefik.http.services.moonginx-mailcow.loadBalancer.passHostHeader=true
The loadBalancer.servers (notice the s in servers) doesn't have a port key, only url:
traefik.http.services.moo.loadbalancer.server.port=80
traefik.http.services.nginx-mailcow.loadbalancer.servers.url=['http://nginx-mailcow:80']
But as you are using defaults, you can omit all of the above =)
One more thing, I don't know how your Traefik container is configured but if your Traefik is running with a defined traefik network (internal) and a web network (public), you should use the traefik network in your Mailcow container as you want to route all external traffic through Traefik.
traefik.docker.network=web
labels:
- traefik.enable=true
- traefik.http.routers.moo.rule=Host(`${MAILCOW_HOSTNAME}`)
- traefik.http.routers.moo.tls=true
- traefik.http.routers.moo.tls.certresolver=godaddy
- traefik.http.routers.moo.middlewares=redirect#file
- traefik.http.middlewares.https-redirect.redirectscheme.scheme=https
- traefik.http.middlewares.https-redirect.headers.customrequestheaders.X-Forwarded-Proto=https
- traefik.http.routers.moo.middlewares=https-redirect
- traefik.http.routers.moo.entrypoints=secure
- traefik.docker.network=traefik
#30daysofstackoverflow

Traefik: Aggregate multiple docker services into a single logical backend

I'm running minio using its official docker-compose file which creates 4 services (containers): minio1,minio2,minio3,minio4. Traefik treats them as 4 unique services, but in reality, they should be treated as a single backend, that is, I want Traefik to generate 1 frontend an 1 backend (with 4 servers) for minio.
I tried putting them into a single group(servicefabric.groupname) but to no avail.
I have the following labels set for each minio service:
labels:
- "traefik.servicefabric.groupname=minio"
- "traefik.basic.frontend.rule=Host:foo.bar.com"
- "traefik.weight=10" # 10,20,30,40 incremented per service
- "traefik.frontend.rule=Host:traefik"
- "traefik.port=9000"
container_name: minio*
Is there any way to achieve this?
#Riverman
I had the same issue as you and I solved it by playing around as it's not fully documented in Traefik documentation. What you need to do is specify the traefik.backend value for all the services to be the same name and set traefik.frontend.backend to that traefik.backend value. You can't use the service piece for this. Below is an example.
services:
minio01:
image: minio/minio
hostname: minio01
restart: always
volumes:
- minio01-data:/export
networks:
- minio
- traefik
command: server http://minio01/export http://minio02/export
labels:
- 'traefik.enable=true'
- 'traefik.docker.network=traefik'
- 'traefik.frontend.rule=Host:minio.local'
- 'traefik.frontend.backend=minio'
- 'traefik.port=9000'
- 'traefik.protocol=http'
- 'traefik.backend=minio'
minio02:
image: minio/minio
hostname: minio02
restart: always
volumes:
- minio02-data:/export
networks:
- minio
- traefik
command: server http://minio01/export http://minio02/export
labels:
- 'traefik.enable=true'
- 'traefik.docker.network=traefik'
- 'traefik.frontend.rule=Host:minio.local'
- 'traefik.frontend.backend=minio'
- 'traefik.port=9000'
- 'traefik.protocol=http'
- 'traefik.backend=minio'
All minio services have to have the same frontend rule and the same backend name.
labels:
- "traefik.frontend.rule=Host:minio.${DOMAIN}"
- "traefik.backend=minio"
- "traefik.port=9000"
Also I think you misunderstood the meaning of "backend". A backend is a server to which Traefik route traffic based on the frontend rules. Same as "upstream"/"location" in nginx.
Edit
As stated in the comment, this configuration creates multiple frontends all pointing to the same backend, although functional this looks ugly. A quick solution is to just have one service with ‘frontend’ but if that service goes down, the frontend will be gone too.
A better way to do this is to set it in the config file, traefik.toml:
[frontends]
[frontends.frontend1]
backend = "minio"
[frontends.frontend1.minio]
rule = "Host: minio.${DOMAIN}”

Docker: HTTPS Proxy with LetsEncrypt

I'm trying to make a secure docker proxy as a proof of concept. This seems like it's close to working (port 80 works and the "It Works!" page comes up for b.example.com). However, the console shows an error on generating keys.
docker-compose.yml:
version: '2'
services:
nginx-proxy:
image: jwilder/nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- ./certs:/etc/nginx/certs:ro
- /etc/nginx/vhost.d
- /usr/share/nginx/html
- /var/run/docker.sock:/tmp/docker.sock:ro
nginx-letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
volumes:
- ./certs:/etc/nginx/certs:rw
- /var/run/docker.sock:/var/run/docker.sock:ro
volumes_from:
- nginx-proxy:rw
environment:
- LETSENCRYPT_TEST=true
site-b:
image: httpd
networks:
- reverse-proxy
- back
environment:
- VIRTUAL_PORT=1234
- VIRTUAL_HOST=b.example.com
- LETSENCRYPT_HOST=b.example.com
Error:
nginx-letsencrypt_1 | 2018-04-27 11:41:40,244:ERROR:simp_le:1446: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v01.api.letsencrypt.org/acme/authz/HsDmBtfcqucZ2j7gT5rGkCf1ESqHaxbkNxZRRWwXfFQ

Resources