Comments (33)
Wow there's a lot of misinformation in this thread!
Yes, starting with your comments. You do realize that most of the comments here were made when Caddy wasn't even 1.0 yet? Just look at the dates my dude.
I'm disappointed. I expected more from the author of Caddy, a truly nice piece of software that makes my life real easy on a daily basis.
Caddy changed so much from the time this ticket was open that pretty much all issues raised here were resolved. All the points raised here were valid at the time, now they are not.
Edit: I know this all comes off as harsh. Due to an unfortunate vocal minority and some mob/hype mentality (e.g. bad takes headlining on Hacker News and other outlets), misinformation and negativity have plagued our project, and I don't know what else to do to stop it except to nip it in the bud.
What you should do is say that most or all of the issues raised here were fixed in recent versions, offer your help to clarify any lingering doubts and point people to your help/support pages/forums/slack/whatever else. That's what you should do. No snarky comments, no sarcasm, no cheap shots, just a polite reminder that those issues are no longer valid.
You have a good product, let it speak for itself.
So, that said: are you happy with Caddy or are you looking for reasons to use something else? Reading this thread, it looks like you've been trying to get rid of it for about 3 years now. Why haven't you switched yet?
I can't speak for wemake-services, but I'd assume the reason why they didn't replace Caddy was because it wasn't worth it?
and why not open feature requests or ask on our forums instead of complaining here?
🤦♂️
from wemake-django-template.
Wow there's a lot of misinformation in this thread! Where are you getting your information from?? Where is the actual research? Are you reading tabloids?
license, you can only use "compile-from-source" for open-source projects
You can compile from source for any use that is in compliance with the Apache 2.0 open source license, which has no usage or redistribution restrictions (as long as you preserve copyright, license, and state changes, etc). We have several official distributions for convenience as well: https://caddyserver.com/docs/install#official-packages
how it is built: plugins should be added or removed at the compile time
This is important for maintaining the static nature of the binaries, making deployment smoother. Would you rather bork your server at build-time or in production at deploy-time? Besides, adding plugins is easy with xcaddy:
$ xcaddy build --with module@version
governance: we already had a case of ads in headers and telemetry by default
Ah, so no hate for Firefox, Windows, Ubuntu, Chrome, VS Code, Brave, and other software which does the same thing, but for commercial benefit (whereas our telemetry was for the non-profit research community)? Regardless, this hasn't been the case for about 3 years now. Get with the times.
Traefik should be as simple or even simpler than Caddy, with the added benefits of having better* (safer) defaults, a better license overall and no ads.
Citations needed, yeah? What defaults are safer in Traefik? Why is their license better than Apache 2.0? Where are the "ads" in Caddy? Show me the evidence.
Performance: https://docs.traefik.io/v1.5/benchmarks/
Is your web server really your bottleneck? Are you really maxing out tens of thousands of requests per second that only a server written in C can handle, which Traefik or Caddy are truly incapable of serving? Google, Netflix, and Cloudflare run Go on their edge, surely you can too.
Besides, web server benchmarks are mostly meaningless.
Caddy@2 is broken as hell: no more config files. We should 100% migrate.
This is absolutely untrue and it was never part of the plan to get rid of config files.
Caddy 2 does not require config files. Otherwise, it's the same as v1: plop a Caddyfile down on disk and run caddy run
and you're good to go. You can of course change the name and path of the config file using the --config
flag: https://caddyserver.com/docs/command-line
Docs for the Caddyfile: https://caddyserver.com/docs/caddyfile
It's very similar to v1, with many improvements. You may use the API to adjust Caddy's config, but the CLI wraps up the API calls for you so you can still use files.
Caddy's config API allows for on-line changes with graceful reloads in production. You can use it with or without files. We go over this very thoroughly in the Getting Started guide -- you should try it! https://caddyserver.com/docs/getting-started
Caddy's native config format is JSON but any other config format can be used, to your liking.
I've played around with it a bit for a personal project.
Thank you for actually trying it and doing a little research, instead of just listening to the hype.
I am disappointed. I expected more due diligence from a professional team such as wemake-services.
Edit: I know this all comes off as harsh. Due to an unfortunate vocal minority and some mob/hype mentality (e.g. bad takes headlining on Hacker News and other outlets), misinformation and negativity have plagued our project, and I don't know what else to do to stop it except to nip it in the bud. We (and yes, there's a small community of us) want to make the project better, but what I'm reading here is a lot of FUD that won't help us do that, and I don't want that to be a detriment to your project or our efforts to improve the software.
So, that said: are you happy with Caddy or are you looking for reasons to use something else? Reading this thread, it looks like you've been trying to get rid of it for about 3 years now. Why haven't you switched yet? What do you want to be better, and why not open feature requests or ask on our forums instead of complaining here?
from wemake-django-template.
The project docs are pretty good, I usually just reference https://docs.traefik.io whenever I need, but they have documentations for most of the common scenarios:
- Docker: https://docs.traefik.io/configuration/backends/docker/
- Docker with Let's Encrypt: https://docs.traefik.io/user-guide/docker-and-lets-encrypt
- Kubernetes: https://docs.traefik.io/user-guide/kubernetes/
- Consul, etcd, zookeeper, etc.: https://docs.traefik.io/user-guide/kv-config/
Aside from that, I had a few bookmarks from when I first researched it, the most up to date seems to be this one: https://beenje.github.io/blog/posts/running-your-application-over-https-with-traefik/
from wemake-django-template.
One major issue with traefic
is that it does not serve static files. https://stackoverflow.com/questions/46503797/is-there-a-way-to-serve-static-resources-with-traefik
Discussion: traefik/traefik#4240
You have several ways to serve your static/media files with it:
- Use
django
to do it withwhitenoise
or similar. But, I would not rely on it - Use extra
nginx
container to serve your files. But, in this case you can ask yourself: why not just usenginx
for everything?
I am still not sure how to fix this problem. Other things looks fine.
from wemake-django-template.
@hermanocabral Well, you're totally right. And I totally had a reply like that comin' I suppose.
This issue was brought to my attention in connection with several other unreasonably negative pieces of feedback I had received all in the same day/weekend, and I wrote the post before looking at the dates on the comments. I didn't notice them until my later edits when I was too tired to do anything else about it.
The strains of negativity as is depicted in this thread is still a heavy burden we carry with this project, though. I would have appreciated being contacted about your (<-- plural) thoughts/questions regarding those issues rather than just having them fester here in a thread.
But I'm satisfied if you're satisfied that the issues are fixed.
from wemake-django-template.
@mholt first of all, thanks a lot for building Caddy. It is really great!
I really wanted to switch back at the time due to the issues listed here, but there was no alternatives. Zero. Because Caddy raises the bar very high. The simplicity in deploying, configuring, and usage is just insane!
And the main idea of this template is to be as simple as possible. But, to still include all the best practices like HTTPS, etc. Ones your project provides out of the box.
However, there was a serious issue for me that made me to switch our internal webserver to nginx: privacy. We work with large Russian corporations, their security teams know and trust nginx. But, when we were discussing Caddy as a replacement back in the days when the built-in telemetry was a thing (I don't know if this is still an issue), the discussion was quite short 🙂
I have seen that caddy@2
was released several days ago, I will totally give it a try! I hope that it will fit our needs and I can update https://github.com/wemake-services/caddy-docker and close this issue.
P.S. Extra points for taking your time to explain things that happened to the project! I was not following the CHANGELOG for a long time.
from wemake-django-template.
@mholt Many thanks for this project! Honestly, I always felt like I was wasting my time messing around with nginx setup which was always a pain but especially so with SSL certs. In contrast Caddy (even v1) is really a pleasure to use.
I hope you can understand where folks were coming from with the default telemetry backlash in v1, it can be a touchy topic. It was an issue for us at the office and I'm very happy that v2 is ready for action (congrats on the release).
I have seen that
caddy@2
was released several days ago, I will totally give it a try! I hope that it will fit our needs and I can update https://github.com/wemake-services/caddy-docker and close this issue.
@sobolevn Check out the official v2 docker image (https://hub.docker.com/_/caddy). I've only used it for one personal project so far but I was able to do all config from docker-compose and didn't need to extend the dockerfile. I could imagine the wemake setup could potentially work without a separate caddy repo, thus less to maintain.
from wemake-django-template.
Nope, it is not a replacement.
It is a companion.
from wemake-django-template.
I am also still not sure about either we need a load-balancer in front of traefic
or not.
from wemake-django-template.
Caddy@2 is broken as hell: no more config files. We should 100% migrate.
from wemake-django-template.
Okay, so I was able to play around with caddy 2 this weekend to gain a bit more familiarity before making this PR. Every thing went quite smooth but I did come across this in the official docker image documentation:
Most users deploying production sites will not want to rely on mounting files into a container
It is then suggested to make this sort of Dockerfile:
FROM caddy:2.0.0
COPY Caddyfile /etc/caddy/Caddyfile
COPY site /site
However, I don't really see why this is necessary. I personally prefer to mount things like this in compose and not create my own dockerfiles if the dockerhub image can do what I need already. The current wemake-django setup seems to take docker-compose mounting approach too:
volumes:
- ./docker/caddy/certs:/root/.caddy # saving certificates
- ./docker/caddy/Caddyfile:/etc/Caddyfile:ro # configuration
- django-static:/var/www/django/static:ro # serving django's statics
- django-media:/var/www/django/media:ro # serving django's media
@sobolevn I know you have particular ideas with your setups, still okay with this mounting approach (and thus ditch wemake-services/caddy-docker if we can)?
from wemake-django-template.
FYI in Caddy v2, the cert data is in /data
and the autosave.json
is in /config
-- you should persist those as volumes like caddy_data:/data
and caddy_config:/config
. Also the default location for the Caddyfile is /etc/caddy/Caddyfile
.
Regarding the following:
Most users deploying production sites will not want to rely on mounting files into a container
That's just a subjective suggestion/reminder about how many people like to deploy their sites, as a pre-built docker image that can just be run in production. It's typically done that way if you put it in some orchestration like Kubernetes or something. There's nothing wrong with using the mounted volume approach, it's really just a preferential decision based on the deployment strategy you plan on taking. I mount volumes for my PHP sites for example. That's all to say, keep on keepin' on.
from wemake-django-template.
Sorry to reopen this, but have you given any thought to replacing caddy after the whole debacle with their license?
from wemake-django-template.
@hermanocabral thanks I will check it out.
from wemake-django-template.
Related:
- cookiecutter/cookiecutter-django#1282 (comment)
- cookiecutter/cookiecutter-django@b312d51#diff-e1e4b3088f1565fc3df91d0e4075bdef
- cookiecutter/cookiecutter-django#1714
It can be paired with whitenoise
for serving static files with the docs to use CDN with collectfast
in production.
from wemake-django-template.
Caddy seems to have backed up from commercial licensing: caddyserver/caddy#2786
from wemake-django-template.
@francislavoie I appreciate the compose tips!
Props to you and the other folks working on the official caddy image. Really a lot more accessible now compared to v1.
from wemake-django-template.
@hermanocabral yes, I am also not quite happy with their plugin system and telemetry.
I am open to any suggestions.
from wemake-django-template.
Well, I'm using traefik in prod on several small to mid size projects and so far got no problems, it's stable and I've had no issues with it whatsoever.
What were your reasons for initially looking for a replacement for Caddy?
from wemake-django-template.
@hermanocabral my favourite thing about Caddy
is its simplicity.
You install it with one command, write 10 lines of config. And you are getting a fully working https website.
The things I don't like:
- license, you can only use "compile-from-source" for open-source projects
- how it is built: plugins should be added or removed at the compile time
- governance: we already had a case of ads in headers and telemetry by default
from wemake-django-template.
Well, in that case Traefik should be as simple or even simpler than Caddy, with the added benefits of having better* (safer) defaults, a better license overall and no ads.
from wemake-django-template.
@hermanocabral do you have any code samples that you can share? Or maybe some tutorials / best practices with django and docker?
from wemake-django-template.
Performance: https://docs.traefik.io/v1.5/benchmarks/
from wemake-django-template.
Broken as hell because a configuration format has changed... looks like a quick analysis:
https://github.com/caddyserver/caddy/wiki/v2:-Documentation#config-adapters
from wemake-django-template.
Awesome news!
from wemake-django-template.
Caddy@2 is broken as hell: no more config files. We should 100% migrate.
I've played around with it a bit for a personal project. Caddyfile format is still supported through an adapter, and seems to work alright. Also, it seems that they have abandoned telemetry in v2!
I like the caddy project from a usability standpoint but open to alternatives and very interested in what the consensus will be here.
from wemake-django-template.
Thank you for understanding. 🙂
from wemake-django-template.
Caddy is my favorite web server that I have worked with. I reckon if you don't need Traefik, Caddy does all you could want.
But maybe it isn't as dynamic as Traefik can be? I'm not so sure.
In the second case, the two work very well together.
from wemake-django-template.
@damienallen great news! Are you willing to contribute v2
caddy setup?
from wemake-django-template.
If you're not in a hurry I can probably throw together a PR in the coming weeks.
from wemake-django-template.
No hurry at all, thank you!
from wemake-django-template.
Sounds like this upcoming PR would resolve #1049? Looking forward to it if so!
from wemake-django-template.
I also prefer volumes
over custom dockerfiles.
from wemake-django-template.
Related Issues (20)
- Add `gunicorn --check-config`
- Use `pytest-modified-env` plugin
- Expected type 'Type[BindableLogger] | None', got 'Type[BoundLogger]' instead HOT 3
- Dependency Dashboard
- Consider using `django-upgrade` in CI HOT 1
- Consider using django-urlconfchecks HOT 2
- update compose v2 HOT 1
- Poetry not added to PATH? HOT 1
- Consider using `django-fastdev` HOT 1
- Build failing on Apple Silicon because of libpq. HOT 2
- [docs] Mention of `sql/` folder - is still available? HOT 1
- Change path for CaddyFile in docker-compose.prod.yml HOT 1
- Consider adding tests for django admin panel
- mypy complaints for custum settings: 'Settings' object has no attribute 'TESTXYZ' HOT 1
- Upgrade to 4.2
- Consider using `djlint` HOT 2
- Gitlab-CI pipeline configuration link is dead
- Poetry add {packageName} raises an isssue HOT 1
- Add logging tests HOT 2
- Replace `nplusone` with `zealot`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wemake-django-template.