-
-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: New "Introduction" tutorial #266
base: master
Are you sure you want to change the base?
Conversation
I've been following Caddy and you for a long time now so I think I have a pretty good sense of how reluctant you are to teach Caddy users how to use computers so first of all thanks for giving this a try! While in theory and in the ideal world, I agree with you, system administration is outside the scope of Caddy, in practice most users (me a few years ago included, you can see me struggle in the forum 😂) want a default, recommended by the vendor way of deploying the software, as it makes the onboarding experience much smoother. Downloading a binary and not knowing what to do with it can be overwhelming for newbies. Advances users already know they have many different ways of doing it to fit their needs best and are less likely to just follow the official docs. So the review from me is that this looks very good, is concise, clear, very easy to follow and clearly highlights the few nuances that you should be aware of. Thumbs up 👍👍 I would like to add just a few nitpicks for your consideration.
I would add quick note saying that caddy can do that for you using caddy-dynamicdns, not explaining how it's done, as it would add a bit of unnecessary noise to the tutorial but a quick mentions would help with discoverability of that very very handy plugin.
|
example.com { | ||
root * /var/www/html | ||
file_server | ||
reverse_proxy /api/* 127.0.0.1:9000 | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would need a mention about directive sorting, otherwise it's not obvious why this would work (they might try using a matcher and assume it'll "just work" but it might not depending on the combination of directives).
example.com { | ||
root * /var/www/html | ||
file_server | ||
php_fastcgi /api/* 127.0.0.1:9000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is misleading, because most of the time, this won't work.
For PHP apps, you need to configure root
to your app's webroot, which should almost never be the actual root of the project, but actually a public/
dir inside of the project. This is important for security so that random PHP scripts as part of the actual app can't be directly executed, or metadata/secret files (like a .env
) can't be served by the file server.
And if you use a path matcher, it doesn't change the try_files
logic within the directive, so it will still look for index.php
at the configured root
, and not inside of some /api
directory within the project.
Just FYI I'm considering this feedback for our new Caddy website which I'm working on. |
Our current Getting Started tutorial (as of early September 2022) is a classic guide on our Caddy 2 site. It is required reading, as it demonstrates the basic
caddy
commands, how to load configuration both as native JSON and config adapters, and helps you choose how to run and configure Caddy. It sets a crucial foundation, then lets you choose how to take it from there.I really like that guide and it needs to stay (in some form or another). But we get a lot of feedback that it's not very practical. It doesn't help them actually "get started" with the web server. There's too many directions to take it once you know how to load config and such. But I think that's OK. You just gotta write your config and then apply what you learned in Getting Started. It, along with our other quick-starts and tutorials, are excellent universal guides for using Caddy, IMO.
In this PR, I've added a new "Introduction" tutorial to be more practical, inspired by https://ellen.dev/serve-static-site-using-caddy.html. It's probably more comprehensive for beginners. Unfortunately, it steps outside the scope of Caddy and goes into sysadmin territory, which I don't like doing, because it's not our job to document Linux or systemd.
Another problem is that this revision in its current form is Linux-only. That is the vast majority of users by far, but it doesn't represent everyone, especially many who are just trying it "at home" (Windows and Mac). This tutorial should be universal, and I don't want to maintain 3 versions of it, or multiple versions of sub-sections, for various OSes, frankly. I still think it is reasonable to expect that readers know how to use their computers already. To learn how to use the computer is outside the scope of our documentation and is a better fit for our wiki.
Additionally, this tutorial is harder. There's more to read, it moves more slowly, and it feels more complex. The problem is that this reflects poorly on Caddy even though the slowness and complexity is entirely due to how Linux and systemd work.
Lots of people are suggesting using Docker for this universal tutorial, but I have a hard reservation against that, as Docker is often the cause of many complications and confusion in our experience. I think Docker would be fine for an advanced tutorial, but I maintain that the point of our docs is to teach Caddy, not sysadmin.
There is currently not a great transition from Introduction to Getting Started.
Still a WIP.
If you're new here and want to read this locally, it's easy:
then open
https://localhost