5 ms·

File server and plex, that’s about it. I have another server I’ll occasionally run a Kubernetes cluster on, otherwise I don’t really bother with self hosting -

File server and plex, that’s about it. I have another server I’ll occasionally run a Kubernetes cluster on, otherwise I don’t really bother with self hosting - I hate dev ops shit for a reason...

Marsymars 7y ago
> I hate dev ops shit for a reason... I've mostly fallen into it at my job because the alternative to me pushing dev services to SAAS offerings and maintaining the glue myself is a pile of poorly-maintained IT-provided Server 2008 R2 boxes.
shantly 7y ago
> I hate dev ops shit for a reason... I notice I was a lot more keen on hosting a bunch of crap myself before I knew how to do it "right", and before devops, orchestration ("you mean running scripts in remote shells?"), cloud, or containers or any of that were things. And yet it all worked just fine back then—time spent fixing problems from my naïve "apt-get install" or "emerge" set-up process wasn't actually that bad, compared with the up-front cost of doing it all "right" these days. A couple lightly-customized "pet" servers were fine, in practice. Hm.
- shostack 7y ago
  As a beginner programmer this is something I wonder about. Having worked with many amazing engineers, I have some sense of the effort that goes into "doing it right" and the fear of god put into me for the consequences of not doing it right. So then look at home projects and I wonder if I know enough to self host things, or host them on GCP in a manner that won't just invite getting hacked, running up a ridiculous bill, or leaking my private sensitive data out. Any guidance to offer?
  - shantly 7y ago
    1) Just pay a flat fee for a VPS, unless you're trying to learn how to use a "true" cloud provider. Their web interfaces usually make recovery from the worst failure modes ("I can't even ping the box...") trivial and they'll cut you off if usage goes too high (which is what you want if you're trying to avoid insane bills). They may also have DNS and such in one place, again in an easy pointy-clicky interface, which is nice. 2) A lot of what people do is chasing nines that you don't need (and a lot of the time they don't either, but "best practices" don't you know, and no-one wants to have not been following best practices, even if doing so was more expense and complexity than it was worth for the company & project, right?) so just forget about failover load balancers and rolling deploys and clustered databases and crap like that. All of that stuff can be ignored if you just accept that you may have trouble achieving more than three nines. 3) If it's just for you, consider forgetting any active monitoring too. That can really kill your nines of reliability, but if it's mostly just you using it, that may be fine, and you won't get alerts at 3:00AM because some router somewhere got misconfigured and your site was unreachable for two minutes for reasons beyond your control. Otherwise use the simplest thing that'll work. You can get your servers to email you resource warnings pretty easily. A ping test that messages you when it can't reach your service for the last X of Y minutes (do not make it send immediately the first time it fails, the public Internet is too unreliable for that to be a good idea) is probably the fanciest thing you need. Maybe you can find some free tier of a monitoring service to do that for you and forget about it, even. 4) If you can mostly restrict yourself to official packages from a major distro, and maybe a few static binaries, it's really easy to just write a bash script that builds your server from scratch with very high reliability. Maybe use docker if you're already comfortable with it but otherwise, frankly, avoid if you can and just use an official distro packages instead, as it'll complicate things a lot (now you have a virtual network to route to/from/among, probably need a reverse proxy, you may have a harder time tracking down logs, and so on). Test it locally in Vagrant or just plain ol' Virtual Box or whatever, then let it loose on a fresh VPS. If you change anything on the VPS, put it in the script and make sure it still works. If you're feeling very fancy learn Ansible, but you'll probably be fine without it. 5) For security, use an SSH key, not a password, and change your SSH port to something non-default (put that in your setup script) just to cut down on failed login noise, if you feel like it. You could add fail2ban but if you've changed the port and are using a key it's probably overkill. 6) Forget centralized logging or any of that crap. If you have a single digit count of VPSen then your logging's already centralized enough. If one becomes unreachable and can't be booted again and you can't find any way at all to read its disk, and that happens more than once, consider forwarding logs from just that one to another that's more reliable if you wanna troubleshoot it. You can do this with basic logging packages available on any Linux distro worth mentioning, no need to involve any SaaS crap. 7) Backups. The one ops-type thing you actually have to to do if your data's not throwaway junk is backups. Backups and strictly-used build-the-server-from-scratch + restore-from-backup scripts are kinda sorta all most places actually need, despite all the k8s and docker chatter and such. 8) Cloudflare exists, if you have any public-facing web services. [EDIT] mind none of this will help you get a job anymore since everyone wants a k8s wizard AWS-certified ninja whether they need 'em or not, so don't bother if your goal is to learn lucrative job-seeking skills, but it's entirely, completely fine for personal hosting and... hate to burst anyone's bubble... an awful lot of business hosting, too. Warning: if you learn how to run servers like this you may need to invest in some sort of eye clamp to prevent unwanted eye-rolling in server-ops-related meetings at work, depending on how silly the place you work is.

Marsymars 7y ago

> I hate dev ops shit for a reason... I've mostly fallen into it at my job because the alternative to me pushing dev services to SAAS offerings and maintaining the glue myself is a pile of poorly-maintained IT-provided Server 2008 R2 boxes.

shantly 7y ago

> I hate dev ops shit for a reason... I notice I was a lot more keen on hosting a bunch of crap myself before I knew how to do it "right", and before devops, orchestration ("you mean running scripts in remote shells?"), cloud, or containers or any of that were things. And yet it all worked just fine back then—time spent fixing problems from my naïve "apt-get install" or "emerge" set-up process wasn't actually that bad, compared with the up-front cost of doing it all "right" these days. A couple lightly-customized "pet" servers were fine, in practice. Hm.

shostack 7y ago
As a beginner programmer this is something I wonder about. Having worked with many amazing engineers, I have some sense of the effort that goes into "doing it right" and the fear of god put into me for the consequences of not doing it right. So then look at home projects and I wonder if I know enough to self host things, or host them on GCP in a manner that won't just invite getting hacked, running up a ridiculous bill, or leaking my private sensitive data out. Any guidance to offer?
- shantly 7y ago
  1) Just pay a flat fee for a VPS, unless you're trying to learn how to use a "true" cloud provider. Their web interfaces usually make recovery from the worst failure modes ("I can't even ping the box...") trivial and they'll cut you off if usage goes too high (which is what you want if you're trying to avoid insane bills). They may also have DNS and such in one place, again in an easy pointy-clicky interface, which is nice. 2) A lot of what people do is chasing nines that you don't need (and a lot of the time they don't either, but "best practices" don't you know, and no-one wants to have not been following best practices, even if doing so was more expense and complexity than it was worth for the company & project, right?) so just forget about failover load balancers and rolling deploys and clustered databases and crap like that. All of that stuff can be ignored if you just accept that you may have trouble achieving more than three nines. 3) If it's just for you, consider forgetting any active monitoring too. That can really kill your nines of reliability, but if it's mostly just you using it, that may be fine, and you won't get alerts at 3:00AM because some router somewhere got misconfigured and your site was unreachable for two minutes for reasons beyond your control. Otherwise use the simplest thing that'll work. You can get your servers to email you resource warnings pretty easily. A ping test that messages you when it can't reach your service for the last X of Y minutes (do not make it send immediately the first time it fails, the public Internet is too unreliable for that to be a good idea) is probably the fanciest thing you need. Maybe you can find some free tier of a monitoring service to do that for you and forget about it, even. 4) If you can mostly restrict yourself to official packages from a major distro, and maybe a few static binaries, it's really easy to just write a bash script that builds your server from scratch with very high reliability. Maybe use docker if you're already comfortable with it but otherwise, frankly, avoid if you can and just use an official distro packages instead, as it'll complicate things a lot (now you have a virtual network to route to/from/among, probably need a reverse proxy, you may have a harder time tracking down logs, and so on). Test it locally in Vagrant or just plain ol' Virtual Box or whatever, then let it loose on a fresh VPS. If you change anything on the VPS, put it in the script and make sure it still works. If you're feeling very fancy learn Ansible, but you'll probably be fine without it. 5) For security, use an SSH key, not a password, and change your SSH port to something non-default (put that in your setup script) just to cut down on failed login noise, if you feel like it. You could add fail2ban but if you've changed the port and are using a key it's probably overkill. 6) Forget centralized logging or any of that crap. If you have a single digit count of VPSen then your logging's already centralized enough. If one becomes unreachable and can't be booted again and you can't find any way at all to read its disk, and that happens more than once, consider forwarding logs from just that one to another that's more reliable if you wanna troubleshoot it. You can do this with basic logging packages available on any Linux distro worth mentioning, no need to involve any SaaS crap. 7) Backups. The one ops-type thing you actually have to to do if your data's not throwaway junk is backups. Backups and strictly-used build-the-server-from-scratch + restore-from-backup scripts are kinda sorta all most places actually need, despite all the k8s and docker chatter and such. 8) Cloudflare exists, if you have any public-facing web services. [EDIT] mind none of this will help you get a job anymore since everyone wants a k8s wizard AWS-certified ninja whether they need 'em or not, so don't bother if your goal is to learn lucrative job-seeking skills, but it's entirely, completely fine for personal hosting and... hate to burst anyone's bubble... an awful lot of business hosting, too. Warning: if you learn how to run servers like this you may need to invest in some sort of eye clamp to prevent unwanted eye-rolling in server-ops-related meetings at work, depending on how silly the place you work is.