Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As someone who's already using the dedicated server for a ton of things, I have been really grateful. But now, I have a new question, are they going to do this to their dedicated servers as well?


This change only affects VPS services in the US, and for what it's worth, Hetzner does not offer dedicated servers in the US.


I am very ignorant here, so my apologies, but...

When someone runs a dedicated server these days, does this mean a one-off linux install? Or is this more likely to be a docker install so that it's portable?


It's an actual entire machine given to you. I remember there were a few options for me from Ubuntu, Debian to Red Hat to choose from, but all of them would also have preconfigured system users and some level of administration done by the provider.

But other than that, it's an actual bare metal machine and I installed Ubuntu on it and threw in a giant heap of services that have been running on it for more than a year now.


If you could rewind the clock, would you have started setting it up any differently, like in a container?

I am just curious what your options would be now if you wanted to migrate. Would you just copy your bash history to a local text file for reference, and then repeat the steps on a new server?


No, I wouldn't have started differently and I like the performance and the dedicated hardware I get for the money I spend. I have a custom backup solution that will upload daily backups of all my data to remote drives and I should be able to restore the setup on another machine without much problem.


Generally even in containerized deployments, you run one container per service/process. You wouldn't run everything you’d run on one box in one container.

I definitely recommend using docker compose or similar even in a one node deployment versus just installing and running things on the host linux system like it’s still 1998. Having a single directory to back up and a single file defining all of the services that can easily be redeployed is very convenient.


The performance impact seems completely unjustified for most of the things people do with a personal machine however.


What is the performance impact? Going one page into Google results, I found this paper. Is there a better reference?

> At light workload levels, the native host performs better than Docker. However, as the workload increases, both Docker and the native host show similar performance, with the difference getting smaller

https://www.researchgate.net/publication/376557310_Comparati...


> What is the performance impact?

DNAT, layered file system access, likely duplication of libraries if you don't pay much attention to your containers.


The performance impact is approximately zero.


Replying here as your other question is at max thread depth:

A non virtualized Linux install isn't more locked in than a docker install, as for a bare metal server you are choosing your own OS. I have done the docker thing on a bare metal server, but that's because I wanted to run multiple services on it and isolate them operationally.


> A non virtualized Linux install isn't more locked in than a docker install

Again, sorry for my ignorance here, but if not virtualized, how does one move hosting providers otherwise? My experience is limited to either running all the bash commands in an install readme, or installing a docker image.

So there must be something in-between, to recreate a linux install elsewhere?

> Replying here as your other question is at max thread depth:

btw, you can click on the time of the post, and reply there when there is no reply link in the main thread.


Using dedicated servers doesn't mean you're not using virtualization - it just means you're the one managing it. You control the hypervisor and the vms running on top of it. Because of that, you're actually less tied to a specific hosting provider since you're not reliant on their APIs to set up and manage your infrastructure.

Even if you're not using virtualization there are still plenty of ways to migrate your servers.

One of the most common approaches (which was the thing before docker took over) is managing servers with an IaC approach using tools like chef, puppet, ansible, saltstack etc.

With IaC you define your entire infrastructure in configuration files and deploy those configs to your host. It's a bit like docker swarm but for managing physical and/or virtual servers instead of containers.

Another popular option, often paired with IaC, is to create your own pre-configured *nix images tailored to your needs. For example, you might have specific images set up for your load balancers, db servers, file hosts, or other roles in your stack.

I've worked at a company where we handled migrations using dd. Technically that's also an option. Wouldn't recommend it tho.


>So there must be something in-between, to recreate a linux install elsewhere?

There's a class of tools like chef, ansible, puppet.

Or you can just package your services into debs and run a Debian repo to install them from, same as the base OS

Possibly there's something closer to dockerfiles out there by now as well

>btw, you can click on the time of the post, and reply there when there is no reply link in the main thread.

Cool, thanks!

Makes me puzzled about the point of concealing the reply links, I guess it just adds a bit of friction?


It's a fire extinguisher feature; for when the thread has too many, too fast replies.


If the server hoster supports it (Hetzner apparently does), you can enable KVM and install a previously prepared image. If the server hoster & hardware supports it, you can login remotely to the server management interface (like HP iLO) and install an image this way.

If you don't have above options or simply don't want to do it this way, you can also bootstrap via SSH. But instead of manually typing in shell commands, you will automate it in some way with custom scripts and/or tools like Ansible.


You can use a configuration manager like Puppet.

https://en.m.wikipedia.org/wiki/Puppet_(software)


Talos Linux, Flatcar Container linux...


Isn't a Docker image an OS image and a bunch of shell commands?


Imagine you'd set up your own server at home.

You'd buy a computer, plug an install USB drive in, and install ubuntu.

Then you'd connect to it via SSH, configure it, maybe install docker and set up your docker containers, etc.

A dedicated server is very similar.

The server is sitting in a datacenter at hetzner, and you usually install an OS with a button in the management UI, sure.

But everything afterwards is the same. You just connect via SSH, install docker or k8s and your services, maybe an nginx, etc.

You also have an option to request KVM access. That allows you to control the server as if you had connected a keyboard and monitor to it. You can even enter the BIOS to diagnose issues, if you'd like.

Personally I've got an install script that automates everything and sets up kubernetes and automated encrypted backups. Then I just deploy everything else with k8s.


For Hetzner you rent actual physical servers. There is nothing virtualized there, it's real hardware without abstractions.


Thanks, I guess what I meant to ask is that is it normal for people to virtualize their own dedicated server these days by default?

Would this be a best practice to avoid hosting vendor lock-in?


There's no lock-in possible. It's a bare metal Linux machine, you do whatever you want with it; you can replace it with the PC under you desk if you want.

If you want to run k3s, k8s or docker, you can, but personally I find those too complicated. NixOS is much easier to deal with, and achieves the same result.


Sure, I use CapRover on mine.


Yeah, it's a one-off install. In my case, I did Proxmox[1] for a while with VM's and LXC's, with some of my VM's and unprivileged LXC's running Docker (compose) too because it made the installation of said software easier. It's great, but I'm moving over to switch to Debian with Incus[2] instead of Proxmox. Just for fun mostly.

[1] https://www.proxmox.com/en/ [2] https://linuxcontainers.org/incus/introduction/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: