bunkerweb
bunkerweb copied to clipboard
[BUG] Redirects to https despite config disabling this
What happened?
I did a quick test to evaluate this project. I spun it up with a docker compose file. I set the environment variables to disable http to https redirect. But all I got was a splash screen saying "generating config" that then redirects to https.
I have a few issues with this:
- Users should not see a splash screen. Instead, I should be able to skip this whole "generating config step" and bake the config into the docker deployment image. I am evaluating for a scale-to-zero scenario so this extra latency is a negative
- My config appears ineffective
How to reproduce?
Just run this docker compose
Configuration file(s) (yaml or .env)
services:
myapp:
image: nginxdemos/nginx-hello
bunkerweb:
image: bunkerity/bunkerweb:1.5.9
ports:
- 80:8080
- 443:8443
labels:
- "bunkerweb.INSTANCE=yes"
environment:
SERVER_NAME: ingress.example.com
API_WHITELIST_IP: "0.0.0.0/0"
USE_REVERSE_PROXY: yes
AUTO_REDIRECT_HTTP_TO_HTTPS: no
REDIRECT_HTTP_TO_HTTPS: no
REVERSE_PROXY_URL: /
REVERSE_PROXY_HOST: "http://myapp:8080"
MULTISITE: no
Relevant log output
No response
BunkerWeb version
1.5.9
What integration are you using?
Docker
Linux distribution (if applicable)
No response
Removed private data
- [X] I have removed all private data from the configuration file and the logs
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Hello @brandonkal, looks like the scheduler is missing from your compose file.
Yes, I don't want to run a separate scheduler. I am looking for single image solutions
@brandonkal i do not know if bunkerweb is even able to run this way maybe have a look at bunkerized Nginx witch is the previous product if your fine with not receving updates anymore or if you want a simpler setup since all the bunkerized products are kind of advanced with the active Core Rule Set maybe try https://nginxproxymanager.com/
Hi, as of now no all-in-one images are available but maybe in the near future.
For anyone looking for a way to simply run the main bunkweb container, without needing the scheduler, I have created a config for this:
volumes:
nginx-configs:
networks:
some-network:
services:
proxy:
image: "ghcr.io/bunkerity/bunkerweb:1.5.9"
environment:
LOG_LEVEL: notice
...your config here
volumes:
- nginx-configs:/etc/nginx
ports:
- 8080:8080
networks:
some-network:
restart: "unless-stopped"
proxy-config:
image: "ghcr.io/bunkerity/bunkerweb-scheduler:1.5.9"
depends_on:
proxy-docker-sock:
condition: service_started
environment:
- DOCKER_HOST=tcp://proxy-docker-sock:2375
networks:
some-network:
restart: "no"
entrypoint: timeout 120 ./entrypoint.sh
proxy-docker-sock:
image: "docker.io/tecnativa/docker-socket-proxy:0.2.0"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- CONTAINERS=1
- LOG_LEVEL=warning
networks:
some-network:
restart: "no"
command: timeout 120 haproxy -W -db -f /usr/local/etc/haproxy/haproxy.cfg
This type of setup will simply:
- Run the
proxy-config(scheduler) service once, generating all the required configs for bunkerweb to run. - Shut down the scheduler and docker socket services.
- Keep the main nginx bunkerweb service running in front of your apps.
+1 for an all-in-one solution that wouldn't require this config though 👍
The above config does not work on v1.6.0 - the upgraded config is actually simpler:
volumes:
nginx-configs:
networks:
some-network:
services:
proxy:
# Extend proxy-configs so environment var config is duplicated
extends:
service: proxy-config
image: "ghcr.io/bunkerity/bunkerweb:1.5.9"
volumes:
- nginx-configs:/etc/nginx
ports:
- 8080:8080
networks:
some-network:
restart: "unless-stopped"
proxy-config:
image: "ghcr.io/bunkerity/bunkerweb-scheduler:1.5.9"
networks:
some-network:
restart: "no"
entrypoint: timeout 120 ./entrypoint.sh
# the environment variable config moved here
environment:
# new required env var to specify the proxy address for healthchecks
BUNKERWEB_INSTANCES: proxy:5000
LOG_LEVEL: notice
...your config here
# the socket proxy service is no longer required
@brandonkal @spwoodcock The previous tool Bunkerized Nginx was a single container. But since the change to Bunkerweb it is multiple Containers. There must be a reason for that so i do not think this is that easy doable. For example the Let's encrypt cert change is triggered by the Scheduler. I do not think removing that is a good idea. @fl0ppy-d1sk Maybe Mr Pitance could you explain why this was changed?
Hi @MrCybertux, The transition from Bunkerized Nginx, which operated as a single container, to Bunkerweb's multi-container architecture was a deliberate move to align with modern microservices principles and the capabilities of platforms like Docker and Kubernetes.
By decoupling functionalities into separate containers, we achieve greater modularity, scalability, and maintainability. For instance, handling Let's Encrypt certificate renewals through a dedicated scheduler container allows for isolated management and easier updates without disrupting other services.
This separation ensures that each component can be developed, deployed, and scaled independently, adhering to best practices in microservices architecture.
Although we're are thinking about a good all-in-one image without having to tweak too much stuff
@TheophileDiot WOW that was a fast answer 👍️ Thanks for explaning!
Hi @brandonkal, @spwoodcock and @MrCybertux. We have a working all-in-one image that is for now in beta. Feel free to test it -> bunkerity/bunkerweb-all-in-one:dev
If you still wish to deactivate the Scheduler or the Web UI, you can do so by setting the SERVICE_SCHEDULER variable to no and/or the SERVICE_UI variable to no.
Amazing!! Thank you 🙌
We test this out asap
Seems to work nicely 🎉
This is much cleaner than the timeout hack I was using on the scheduler service
Hello @brandonkal @spwoodcock,
It's available in 1.6.1, enjoy : https://docs.bunkerweb.io/latest/integrations/#all-in-one-image