Tangential at best: where can you get a hold on a Raspberry Pi 4 in Europe? Every store is sold-out and the ones that aren't only allow one per customer.
ive reflashed old routers with openWRT into a server cluster, they are a lot more portable, quiet and power efficient, of course this doesnt scale up well as the hardware has its limits. keep in mind you dont have to host the entire website on one server, so you can balance the load that way if you need to.
Thanks, looks like a nice choice! Unfortunately they only have 2 (4GB model, rest is out of stock) in stock at the moment ("Available quantity: 2" it says), but will keep an eye for when they get re-stocked.
It's a bit more work, but for single-digit quantities you could just buy one per store from a bunch of vendors, possibly repeating weekly or whatever until you get the desired number?
I was initially looking at this to see how they automated their Let's Encrypt and if it was better than just using Caddy. I was disappointed to find they are just creating a self-signed RootCA and issuing certs.
> Now if you go into Chromium browser settings and search "certificates", in the Security tab, Manage Certificates, you can add an Authority. Import 'ca.pem'. Tell the browser to Trust this certificate for identifying websites. This should add 'org-test-ca' to your browser. This allows HTTPS certificates signed by that to be seen as valid in your browser.
Basically, inotifywait on the config directory and request new certificates as needed. Grep the config files for hostnames (and ignore if labeled NOSSL). And a configuration snippet to include the same SSL config for anything that needs SSL (including the .well-known/acme-challenge directory). Oh, and use cron to renew periodically.
Just be aware that nginx needs a self-signed certificate in the very beginning, to serve the .well-known/acme-challenge directory. To simplify the initial setup, I include a default "snake oil" certificate, which gets overwritten.
With apache2 httpd, you can of course serve the challenge over insecure HTTP, but httpd won't start if you say it should use a cert that doesn't actually exist, so for the sake of automated setup and not having to edit the config multiple times it's way easier to write a self-signed cert and then overwrite it with LE. I think the situation is the same with nginx but not 100% sure.
You can use IfFile to gate the TLS part of the server until the certificate file exists, if you really don't want to edit your config files during TLS bootstrap.
How I solve this is that I deactivate all configuration files that have missing certificates, and then reactivate them again after the files have been created.
> I was disappointed to find they are just creating a self-signed RootCA and issuing certs.
Agreed. Not sure why you'd go through the trouble of importing a self-signed CA when you can provision certs for any internal service with LE. I dont use self-signed and instead have been using LE certs provisioned for internal services for the last couple years. Extra nice to be able to leverage DNS challenge for cert provisioning at home to get around overloading common ports.
I know a lot of people mention Caddy but I find Traefik [0] (pronounced "traffic") more flexible. It's routing and middleware configurations are fantastic. Especially when you want to stick a reverse proxy in front of things that are a pain to provision certs into (switches, routers, old embedded web interfaces, etc).
For development I'm sure SimpleHTTPServer is fine for most use-cases (except SPAs, of course), but for more serious use, nginx and SimpleHTTPServer couldn't be more different.
I am not a fan of docker for everything but 'apt install nginx' would not give you https out of the box. I am beginning to like Caddy which comes with https enabled but I have never used it in production yet.
If you want https you can just run certbot. It will bootstrap the nginx config. I dislike programs that change the configuration automatically, and thus run dehydrated instead of certbot, but running apt install nginx certbot and some certbot incantation to make it bootstrap your domains is not really any more bothersome, than having to figure out how docker works, and how to manage changes to my nginx config with it over time, etc..
I totally disagree with this reply, and agree with the thread starter... I really, really do not see the point of this.
One command? Did you read the github page?
At the end, this doc even has you hand editing your nginx for SSL?!? Why on earth... why not just use certbot automation? This seems totally counter to the idea. Again, am I being dense? Is this just "look what I can do with docker that makes my life more complicated"? Honestly, at this point it feels like more work for less output.
This seems way harder than installing nginx and certbot, and now I have a hard dependency on docker and whatever else you pulled in.
Seems like optimizing a thing that's already pretty quick and easy to set up (and using docker and similar does not mean you don't need to understand how nginx works).
Hacking is called mutilating now? Give the guy/girl a break. I don't think this is meant to be a production setup so whatever is fine, and you can always reflash it if needed so not sure I'd call this "mutilation"
I'm ashamed that I was so naïve about this, but I was disappointed to realize that hosting a website to the entire public internet on my Pi was non-trivial. Of course once I dug into the idea it was obvious why it was difficult and furthermore that it would be a dangerous thing to do. Just sharing and curious if anyone has done it or knows useful documentation on the topic.
Why was is complicated? I'm hosting https://talumriel.de for my German novels on a Rapberry Pi 3b, using Nginx and Letsencrypt with cryptbot. It's probably not super-secure, but the setup was very easy. I basically just followed one of the tutorials on the Net.
It sounds like you Pi doesn't have a public IP address. So you need some way to tunnel requests to it. On solution would to be SSH into one of your own public boxes somewhere and use reverse port forwarding (-R). Although that's probably not very reliabile on its own as you have to make sure the connection stays alive. More professional solutions are probably ngrok or cloudflare tunnel. The latter is meant exactly for what you describe: expose a service on a private machine as a public facing web site.
Port forwarding from your router is another option, redirect all 443/80 traffic from the public interface of the router to your Raspberry, preferably on a separate VLAN and also firewalls on both your router and Raspberry before enabling that.
This guide is just for hosting locally. If you want to host to the outside internet you also need to do port forwarding on your router. So that when someone connects to your outside IP your router relays that to the pi specifically.
It's not super dangerous, just make sure you keep everything updated (your linux OS, your server software). And make sure that you only open the ports you need to.
I've been hosting my application on a 3B+ for years. What makes the Pi different to any other machine that you have on your home network? Assuming you have a static IP, all you have to do is forward ports 80/443 (or whatever) to the right machine/ports.
They're great little machines for this exact purpose. No need to have a full blown PC serving trivial stuff. Only problem is, they use SD cards and eventually. I've had a quality 128GB card in mine that has died/been corrupted about 3 times in 4 years. That's my biggest issue with these amazing little machines
Instead of opening ports on your firewall, you could introduce a mesh. I'm using nebula by slack, rest is 90's style with apache /nginx, lego for le dns-challenged certs, and the nebula lighthouse as a proxy. Works fine, is secure and does not bind 443 on your router to.a specific pi.
I agree if the container brings any benefits. In this case there is nothing that a standard distro-packaged apache/nginx wouldn't do. There is no automation of build steps, lets-encrypt or similar.
Installing docker and running that daemon for just this is not the right way.
> Seriously. Adding a docker layer to a device as lightweight as a Raspberry Pi just seems like insanity.
Your definition of insanity is perplexing. Docker in this context is pretty trivial to setup and run, and it's used mainly to manage packaging and deployment. Do you happen to have any experience at all with Docker?
Yes, and it's doubly pointless here, because it isn't doing anything that couldn't be done better by the OS's own package manager. Better, probably, because you will get timely security updates.
> Yes, and it's doubly pointless here, because it isn't doing anything that couldn't be done better by the OS's own package manager.
No, not really. With Docker, packaging is a solved problem, and you also get for free a deployment history which you can roll back and forward at will. You also get introspection and blue/green deployments, and if you really want to you can also setup a cluster of nodes for free where you can run whole application stacks with a one-liner.
There is really no excuse to do things the hard way.
It still does have a non-zero cost, especially in the long run, when security vulnerabilities pop up. With distribution package management, on Ubuntu, you can rely on your Nginx being updated and restarted automatically while you sleep. With Docker, you need to subscribe to a security mailing list in order to know about the vulnerability in the first place, and then run some commands manually that re-create the container.
> It still does have a non-zero cost, especially in the long run, when security vulnerabilities pop up.
It really doesn't. Unless you were planning on doing a one-and-done deployment, it's trivial to update and redeploy Docker images. Even in my side projects I have CI/CD pipelines updating and redeploying Docker images daily.
> With distribution package management, on Ubuntu, you can rely on your Nginx being updated and restarted automatically while you sleep.
Whatever you can do with Ubuntu, you can do precisely the same with Docker when running a base image of Ubuntu.
> With Docker, you need to subscribe to a security mailing list in order to know about the vulnerability in the first place, and then run some commands manually that re-create the container.
No, you really don't. Just pull the latest base image, build your images by calling apt to update your dependencies, and you're done.
Whatever you can do with a bare metal/VM install, you can do with Docker.
There is nothing magical stopping you from doing the basic stuff with Docker.
the goal was to run nginx in docker, if you want to run nginx without docker you can just not do the docker parts. not sure what you mean about properly configure software - you can configure nginx the same whether you use docker or not?
79 comments
[ 0.20 ms ] story [ 147 ms ] threadWhich I assume means something like "This product is limited to 1 per customer"
You might want to also grab the sd card from there.
I recommend getting the power supply, case and fan from Digikey.
https://git.inportb.com/jyio/docker-nginx-auto
Basically, inotifywait on the config directory and request new certificates as needed. Grep the config files for hostnames (and ignore if labeled NOSSL). And a configuration snippet to include the same SSL config for anything that needs SSL (including the .well-known/acme-challenge directory). Oh, and use cron to renew periodically.
I like this idea. I'm going to start using this.
Though... I think I'd still include the snake oil cert and serve everything over SSL, because it simplifies the configuration.
https://github.com/JonasAlfredsson/docker-nginx-certbot
Agreed. Not sure why you'd go through the trouble of importing a self-signed CA when you can provision certs for any internal service with LE. I dont use self-signed and instead have been using LE certs provisioned for internal services for the last couple years. Extra nice to be able to leverage DNS challenge for cert provisioning at home to get around overloading common ports.
I know a lot of people mention Caddy but I find Traefik [0] (pronounced "traffic") more flexible. It's routing and middleware configurations are fantastic. Especially when you want to stick a reverse proxy in front of things that are a pain to provision certs into (switches, routers, old embedded web interfaces, etc).
[0] https://traefik.io/traefik/
ok fun guy
One command? Did you read the github page?
At the end, this doc even has you hand editing your nginx for SSL?!? Why on earth... why not just use certbot automation? This seems totally counter to the idea. Again, am I being dense? Is this just "look what I can do with docker that makes my life more complicated"? Honestly, at this point it feels like more work for less output.
This seems way harder than installing nginx and certbot, and now I have a hard dependency on docker and whatever else you pulled in.
Sure, I could install lighttpd myself, but docker-compose gives me a common configuration file format.
It's not super dangerous, just make sure you keep everything updated (your linux OS, your server software). And make sure that you only open the ports you need to.
They're great little machines for this exact purpose. No need to have a full blown PC serving trivial stuff. Only problem is, they use SD cards and eventually. I've had a quality 128GB card in mine that has died/been corrupted about 3 times in 4 years. That's my biggest issue with these amazing little machines
Install apache (or nginx or lighttpd) on your box using your distros package manager of choice.
Configure https on apache.
I run a few containers on my RPi and cannot tell a difference in performance.
Installing docker and running that daemon for just this is not the right way.
Your definition of insanity is perplexing. Docker in this context is pretty trivial to setup and run, and it's used mainly to manage packaging and deployment. Do you happen to have any experience at all with Docker?
No, not really. With Docker, packaging is a solved problem, and you also get for free a deployment history which you can roll back and forward at will. You also get introspection and blue/green deployments, and if you really want to you can also setup a cluster of nodes for free where you can run whole application stacks with a one-liner.
There is really no excuse to do things the hard way.
It really doesn't. Unless you were planning on doing a one-and-done deployment, it's trivial to update and redeploy Docker images. Even in my side projects I have CI/CD pipelines updating and redeploying Docker images daily.
> With distribution package management, on Ubuntu, you can rely on your Nginx being updated and restarted automatically while you sleep.
Whatever you can do with Ubuntu, you can do precisely the same with Docker when running a base image of Ubuntu.
> With Docker, you need to subscribe to a security mailing list in order to know about the vulnerability in the first place, and then run some commands manually that re-create the container.
No, you really don't. Just pull the latest base image, build your images by calling apt to update your dependencies, and you're done.
Whatever you can do with a bare metal/VM install, you can do with Docker.
There is nothing magical stopping you from doing the basic stuff with Docker.