Formerly /u/Zagorath on the alien site.

  • 9 Posts
  • 149 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle
  • Your 142.x.x.x will be your public IP address. All devices on your network share that public IP. They all have a unique private IP address too, accessible only on your network. It probably starts with 192.168.x.x, but it could be 10.x.x.x or even less likely 172.16–31.x.x.

    If you want to operate a web server that users can go to by typing https://youdomain.com/, you’ll need to forward from ports 80 and 443 through to the internal IP address of your server, using the “port forwarding” settings on your router. What port on the internal IP you route to depends on how your server is configured. But a basic default configuration is fairly likely to be 80 and 443, too.

    Since you have a reverse proxy, all traffic from your router should go to that. Then you use that to send the appropriate traffic to the appropriate server based on whatever rules you want to apply. (e.g. siteone.mydomain.com goes to server 1, sitetwo.mydomain.com goes to server 2, or mydomain.com/siteone goes to server 1, etc.).











  • or a recipe for an insecure mess that could become difficult to maintain

    The concept, or the specific setup the author of that article has? If you mean the latter, I’m not going to argue. But the concept? It shouldn’t have any effect either way on security, but the whole advantage of it is that it’s less of a mess. The same way that running a whole bunch of services on bare metal can quickly become a mess compared to VMs or Docker/LX containers, declared state helps give a single source of truth for what all the services you might be running are. It lets you make changes in repeatable and clearly documented ways, so you can never be left wondering “how did I do that before?” if you need to do it again.

    If everything you run is a Docker container, there’s a good chance Terraform is overkill; a Kubernetes config will probably do the job. But depending on your setup there are a whole bunch of different tools that might be useful.






  • Sorry for the late reply. I’m just disorganised and have way too many unread notifications.

    LXC containers sound really interesting, especially on a machine that’s hosting a lot of services. But how available are they? One advantage of Docker is its ubiquity, with a lot of useful tools already built as Docker images. Does LXC have a similarly broad supply of images? Or else is it easy to create one yourself?

    Re VM vs LXC, have I got this right? You generally use VMs only for things that are intermittently spun up, rather than services you keep running all the time, with a couple of exceptions like HomeAssistant? What’s the reason they’re an exception?

    Possibly related: your examples are all that VMs get access to the discrete GPU, containers use the integrated GPU. Is there a particular reason for that distribution?

    I’m really curious about the cluster thing too. How simple is that? Is it something where you could start out just using an old spare laptop, then later add a dedicated server and have it transparently expand the power of your server? Or is the advantage just around HA? Or something else?


  • Sorry for the late reply. I’m just disorganised and have way too many unread notifications.

    LXC containers sound really interesting, especially on a machine that’s hosting a lot of services. But how available are they? One advantage of Docker is its ubiquity, with a lot of useful tools already built as Docker images. Does LXC have a similarly broad supply of images? Or another easy way to run things?