7 ms·

Exactly! This person gets it. Oh, and not only build their app, they can take it a step further and setup the entire new vps and app building in one simple scr

Exactly! This person gets it. Oh, and not only build their app, they can take it a step further and setup the entire new vps and app building in one simple script!

Sammi 2y ago
I'm doing it :) I split it into multiple scripts that get called from one, just for my own sanity.
ghomem 2y ago
Once you do it for long enough it might be worth it to consider configuration management where you declare native structured resources (users, firewall rules, nginx reverse proxies, etc) rather than writing them in shell. I use Puppet for distribution of users, firewall rules, SSH hardening + whitelisting, nginx config (rev proxy, static server, etc), Let's Encrypt certs management + renewal + distribution, PostgreSQL config, etc. The profit from this is huge once you have say 20-30 machines instead of 2-3, user lifecycle in the team that needs to be managed, etc. But the time investment is not trivial - for a couple of machines it is not worth it.
- throwaway894345 2y ago
  Honestly not having to use Puppet or Ansible are among my reasons for using Docker. I do some basic stuff in cloud-init (which is already frustrating enough) to configure users, ssh, and docker and everything else is just standard Docker tooling.
  - pxc 2y ago
    > I do some basic stuff in cloud-init (which is already frustrating enough) What do you find frustrating about cloud-init? I'm relatively new to it.
    - throwaway894345 2y ago
      The YAML structure seems poorly thought out, the documentation is low quality, the iteration loop is tedious, etc.
      - pxc 2y ago
        > the iteration loop is tedious I feel that about the cloud as a whole, tbf. It's incredibly painful to me.
        throwaway894345 2y ago
        Yeah, I mean you're kind of eating shit either way. You either have to deal with cloud friction or Linux friction, and at least cloud friction is mostly stuff like IAM where the friction is mostly about nudging you toward a better security posture. In Linux the friction is boring stuff like "every component has a different configuration file format and different expectations about where those configuration files are on disk and where it keeps its application data and how it names its command line arguments" and so on. This isn't bad for a small team, but it becomes increasingly painful as you scale, but it's really hard to make it work smoothly for bigger teams (the sysadmin team becomes a bottleneck for everyone's deployment, deployments slow to a crawl so everyone builds these enormous, buggy releases, testing becomes a once-a-month thing instead of a continuous thing, etc). And the teams that do it well basically end up reinventing a big chunk of the cloud without any of the benefits of a standard, well-documented, widely-understood cloud platform anyway.
grutetc 2y ago
I feel y’all are too focused on the end product. I deploy to pared down bare metal, but I use containerization for development, both local and otherwise, for me and contributors. So much easier than trying to get a local machine to be set up identically to a myriad of servers running multiple projects with their idiosyncratic needs. I like developing on my Qubes daily driver so I can easily spin up a server imitating vm, but if I’m getting your help, especially without paying you, then I want development for you to be as seamless as possible whatever your personal preferred setup. I feel containerization helps with that.

Exactly! This person gets it. Oh, and not only build their app, they can take it a step further and setup the entire new vps and app building in one simple script!

Sammi 2y ago

I'm doing it :) I split it into multiple scripts that get called from one, just for my own sanity.

ghomem 2y ago

Once you do it for long enough it might be worth it to consider configuration management where you declare native structured resources (users, firewall rules, nginx reverse proxies, etc) rather than writing them in shell. I use Puppet for distribution of users, firewall rules, SSH hardening + whitelisting, nginx config (rev proxy, static server, etc), Let's Encrypt certs management + renewal + distribution, PostgreSQL config, etc. The profit from this is huge once you have say 20-30 machines instead of 2-3, user lifecycle in the team that needs to be managed, etc. But the time investment is not trivial - for a couple of machines it is not worth it.

throwaway894345 2y ago
Honestly not having to use Puppet or Ansible are among my reasons for using Docker. I do some basic stuff in cloud-init (which is already frustrating enough) to configure users, ssh, and docker and everything else is just standard Docker tooling.
- pxc 2y ago
  > I do some basic stuff in cloud-init (which is already frustrating enough) What do you find frustrating about cloud-init? I'm relatively new to it.
  - throwaway894345 2y ago
    The YAML structure seems poorly thought out, the documentation is low quality, the iteration loop is tedious, etc.
    - pxc 2y ago
      > the iteration loop is tedious I feel that about the cloud as a whole, tbf. It's incredibly painful to me.
      - throwaway894345 2y ago
        Yeah, I mean you're kind of eating shit either way. You either have to deal with cloud friction or Linux friction, and at least cloud friction is mostly stuff like IAM where the friction is mostly about nudging you toward a better security posture. In Linux the friction is boring stuff like "every component has a different configuration file format and different expectations about where those configuration files are on disk and where it keeps its application data and how it names its command line arguments" and so on. This isn't bad for a small team, but it becomes increasingly painful as you scale, but it's really hard to make it work smoothly for bigger teams (the sysadmin team becomes a bottleneck for everyone's deployment, deployments slow to a crawl so everyone builds these enormous, buggy releases, testing becomes a once-a-month thing instead of a continuous thing, etc). And the teams that do it well basically end up reinventing a big chunk of the cloud without any of the benefits of a standard, well-documented, widely-understood cloud platform anyway.

grutetc 2y ago

I feel y’all are too focused on the end product. I deploy to pared down bare metal, but I use containerization for development, both local and otherwise, for me and contributors. So much easier than trying to get a local machine to be set up identically to a myriad of servers running multiple projects with their idiosyncratic needs. I like developing on my Qubes daily driver so I can easily spin up a server imitating vm, but if I’m getting your help, especially without paying you, then I want development for you to be as seamless as possible whatever your personal preferred setup. I feel containerization helps with that.