Hacker News Reader

Comment by goneri | Hacker News Reader

If you've got your configuration properly automated, nothing prevent you from redeploying your bare-metal nodes every weeks. The opposite can actually also be true, it may become risky at some point to reboot a VM with a high uptime.

View on HN

I'm completely clueless about any server administration beyond a LAMP stack on a single machine serving a few dozen people

I always hear about all the great stuff you get practically for free from cloud providers. Is that stuff actually that easy to set up and use? Any time I tried to set up my LAMP stack on a cloud service it was such a confusing and frightening process that I ended up giving up. I'm wondering if I just need to push a little harder and I'll get to Cloud Heaven

It's a mixed bag. It's more standardised, so once you know how to set up one app, you can mostly just repeat it multiple times as needed. Even for custom things, I can't remember the last time I started a CloudFormation stack from scratch - it's mostly copy&customise.

Being able to say "I want a clustered MySQL here with this kind of specs" is much better (time-wise) than doing it on your own. The updates are also nicely wrapped up in the system, so I'm just saying "apply the latest update" rather than manually ensuring failovers/restarts happen in the right order.

So you pay to simplify things, but the gain from that simplification only kicks in with larger projects. If you have something in a single server that you can restart while your users get an error page, it may not be worth it.

The big problem for server operations is not the damned servers but all of the infrastructure you need to keep them running, like power cooling network/storage and internet connectivity.

The cloud is not easy but damn trying to get cooling and power efficiency of an small server room anywhere near the efficiency levels most big data-center publish is next to impossible as is multi vendor internet connectivity.

With the cloud all of that kind of goes away as it's managed by whatever data-center operator that cloud is running on but what people forget is that that is also true for old fashioned colocation services which is often offering a better cost/value then cloud.

And while it's definitely harder to manage stuff like AWS or Azure because it bleeds a lot of abstractions small scall vpc providers hide from you or that you dont really get with a single home server, it's not hard on the scale of having to run a couple of racks worth of vmware servers with SAN based storage.

I think the problem is configuration. Every thing that has its own configuration is basically a new language you must be able to speak perfectly. Configuration languages are not statically typed so when you make an error it typically does not tell you you made a mistake, and where, and thy it is a mistake.

With Cloud stuff you have more configuration to do because it is about configuring virtual servers etc. Instead of carrying the PC in a box to your room you must "configure it" to make it available.

Laravel Forge + Digital Ocean (or Hetzner, your own machine, Vultr ...) is a pretty good solution. You can up & downgrade as you see fit or spin up a new server in a few min (any specs you need, from scratch or using an image of one of your existing machines, it installs what you need and you can of course add whatever is still missing).

DO databases have backups you can configure to your liking, store them on DO Spaces (like S3). DB user management is easy. There's also cache servers for Redis.

You can add a load balancer and connect it to your various web servers.

I think it took me about 30 min to setup 2x web servers, a DB server, cache server, load balancer, a storage server and connect them all as needed using a few simple forms. Can't really beat that.

By your own estimate -- how confident do you feel that these servers and services are secure? "Setting up" web servers to perform their function is rather easy, in my experience. Ensuring those servers can withstand standard-issue hacking attempts, not so much, especially within just 30 minutes.

The added value of these types of service, I think, is that they're fairly well set up with their provisioning script. You're paying for this service after all and if it appears they can be easily compromised "by default" then ... there would be many problems.

If you have any more info or opinions then please do share.

I'm no expert on Linux security but what I've seen when provisioning a VPS from anybody is a system with the base OS installed and that's it. SSH on port 22. Root account active. Accounts not needing a private key to login. No firewall. Known vulnerabilities in base packages unpatched.

Lots of articles around the internet about hardening a Linux server, the ones I've tried take a bit more than 30 min to follow the steps, a lot longer if I'm trying to actually learn and understand what each thing is doing, why it's important, what the underlying vulnerability is, and how I might need to customize some settings for my particular use case.

As someone who also runs a Laravel site on DO (but doesn't use Forge so can't comment on whether it handles any additional security configurations) buying a cheap DO droplet is very much handling your own infrastructure, it comes with reasonable enough defaults for most people out of the box but if you're expecting any decent amount of traffic it definitely needs to be hardened a little more. Also other administrative tasks like adding swap space if you're like me and trying to get as much performance as possible from as little spend as possible.

a bash script that auto installs everything will do. It has to be maintained though. You also lock down and harden the server. Running a stable OS helps.

I've run a few debian servers for years with little issues. Set up auto-update (very easy) for security updates. There's really little to go wrong.

I'm sure you can find example setup scripts online (configure autoupdates, firewall, applications, etc.), should be a matter of running 'curl $URL' and then 'chmod +x $FILE' and 'bash $FILE'. I didn't need configuration management (I do use my provider's backup service which is important I guess).

Something like this: https://raw.githubusercontent.com/potts99/Linux-Post-Install...

(seen in https://www.reddit.com/r/selfhosted/comments/f18xi2/ubuntu_d... )

Totally, though I think in a fast paced/under-resourced environment incentives matter, and ephemeral cloud vms incentive admins to use configuration management, whereas it's easy to take a shortcut in the moment and quickly manually install something/edit config on a rarely-changing dedicated host.

Obviously the same can be said for long running VMs, and this can be solved by having a disciplined team, but I think it's generally more likely in an environment with a single long running dedicated machine.

This here is the trick. I like to do blue/green deployments. This workflow forces you to script (and implicitly test ) the full server+application deployment. With everything scripted, it just becomes a matter of deciding to rebuild a new machine every week/month/n-deploys which makes you comfortable. Plus, you get a hot spare for free.

Reply on news.ycombinator.com