Hacker News new | ask | show | jobs
by code_sloth 1922 days ago
> Do you really want to copy from a development computer to your production? ...

> Are you really sure that everything works exactly the same on different versions of GoLang? ...

He mentions he does have a build server which runs a 10 line shell script to download code and build the binary.

Builds happen on that server, and I assume it handles deploying the compiled binary (and systemd script?) to the target as well.

The build server would also have a "blessed" golang version. New guy code that uses new not-yet-blessed features would not compile.

> That VM with systemd died at 1am...

Your docker host died. All your containers die along with it. Docker alone cannot solve this category of issues anyway.

2 comments

But you add k8s now, so that three hosts can orchestrate three other hosts. Success!
The infrastructure layer is expanding, to meet the needs of the expanding infrastructure layer
Devops is the new self-justifying expanding bureaucracy of the tech world.
k8s isn't the only option, Nomad is a much better fit here.
Same thing is achievable with HA VMs.
And that would be much easier to implement and understand.

We seem to be obsessed with producing the most complex machines we can instead of creating simple, understandable machines.

Now you have 3 problems.

It's not solving "your system went down", it's adding more layers of system that can go down.

Except now your system can handle the inevitable server going down without taking the entire site offline. It DOES solve the problem of a single host failure causing an outage. Yes, there are other types of outages you can have, but it certainly does reduce the occurrence of outages significantly.

Are you really trying to suggest that people can't use Kubernetes to increase their reliability?

Yeah, I guess I am. It's adding whole layers of complexity and configuration to the system. I understand that those layers of complexity and configuration are designed to make the system more resilient, but it depends on everyone getting everything right all the time. The "screw-up surface" is huge.
Ever seen a large system that has it's own job server and scripts for orchestration/deployment? Application code that checks the status of it's peers and runtime env to determine what should run? All glued together with decades old perl and bash with no documentation.

I'll take "more configuration in yaml" over that.

that's not a 1:1 comparison though.

Leave your nice clean K8s deployment paradise to cruft up for decades, and will it be any better? I doubt it - there'll be old Dockerfiles and weird bits of yaml that shouldn't work but do, and upgrading a version of anything will break random things.

So yes, I think I would prefer the decades of crufty perl and bash to decades of crufty outdated yaml. At least the bash scripts have a hope of doing what they say they do, and are likely to still execute as intended.

Hum... No, Kubernetes is not a HA solution.

One can certainly create an HA cluster over some infrastructure set up by kubernetes, just as well as one can take a bunch of physical servers, set them up by hand, and create an HA cluster with them. K8s isn't adding anything to the availability.

> Docker alone cannot solve this category of issues anyway.

Docker does comes with an orchestrator out of the box, it's called Docker Swarm. You may not use it, but it's there and it's up to you to use it or not. It's extremely simple to setup, a single command on the manager and another one on the worker. It support healthcheck, replication, etc.... all super simples to setup too.

Sure doing all theses will takes, what 30 minutes? Instead of the 5 he took for his deployment, but it does solve that issue, natively, out of the box.

Oh and my docker image always have the "blessed" [insert environment here] version, thus everyone always use it while testing locally. If you need to update it, anyone can do it easily, without any knowledge of the build server environment, nor any special access to it.