undefined | Better HN

0 pointsuser59944619y ago0 comments

Author from the original article here.

>>> * Docker encourages fully disposable infrastructure => I'd consider that incorrect and/or misleading

Docker is meant to manage disposable (i.e. stateless) applications. They are expected to be killed/stopped/restarted at any time, no persistent state, no data.

An application is either disposable OR not disposable by its design, docker doesn't change that. (For instance, don't try to dockerize databases).

Docker gives you a quick, nice and easy way to package your applications with dependencies (as Docker image) AND deploy them. [This is valuable]

It's especially great for development and test environments because you can run many containers (i.e. applications) on a dev/test machine, without dependency/deployment hell. [This is very valuable]

>>> * Docker containers can be more secure then traditional environments => No. Just No.

Docker has nothing to do with security.

>>> * Docker provides for idempotent environments agnostic of hardware concerns etc

Docker gets to ignore the hardware. You do not.

You get to buy, setup and manage servers. Maintain a full environment that can run docker.

It can be an undertaking full of dangers, as told by this article and mine :D

>>> * Container management software (Kubernetes, etc.) makes Docker much more powerful/useful and is only going to get better

Docker allows to package and deploy an application. It doesn't do anything about infrastructure at all (i.e. machines, load balancers, DNS, discovery), which you still have to manage and it's a HARD problem.

The orchestration systems is supposed to help you manage all of that. As a result, it will be able to automatically kill/restart/move/add containers across a cluster and make the necessary [physical or virtual] infrastructure changes.

Container + Orchestration will be a [r]evolution to manage entire giant fleets of hosts and applications. [This will be infinitely valuable (allowing me to automate the work of 10 people, all freeing all my time to enjoy unlimited free drinks and foods)]

IMO: In the current state of affairs. Having docker without orchestration is like having cars without roads.

0 comments

12 comments · 5 top-level

jfoutz9y ago· 3 in thread

>>> * Docker encourages fully disposable infrastructure

I just want to tack on the upgrade rollback situation. A container looks a lot like a process from the host os point of view. You can bring up the new release and leave the old release running on the same machine without much difference in load. The load just shifts to the new container. With a VM approach, you kind of need both vm's for the whole upgrade window.

Depending on your orchestration, blue/green deployment is pretty straightforward.

user5994461OP9y ago

There can't be two containers running that listen on the same port. The rolling upgrade will need to kill the first container to start the new one.

I may suppose that you talk about [CPU] load, because you are running computations/processing applications and not webservices.

fapjacks9y ago

Well, this is a problem that's been solved [0]. I've been using nginx-proxy for a couple of years now, in production, without any issues.

[0] https://github.com/jwilder/nginx-proxy

lobster_johnson9y ago

Don't use static ports. Pick a random one and update the load balancer (Haproxy, Traefik, Nginx) to point to the new one. If the rollout fails, you can always roll back by pointing back the old one.

FWIW, Kubernetes solves this out of the box.

adimitrov9y ago· 2 in thread

> For instance, don't try to dockerize databases

Host volume mappings. Problem solved.

I've been using them for over a year, with all kinds of different databases, postgres, mysql, mongodb, in dev, ci, and production, never had a problem. It gives you a nice separation of what is and what isn't part of the application state, and makes backups a breeze.

fapjacks9y ago

Right. This "don't Dockerize databases" thing is truly just bizarre. It almost in a way seems intentionally antagonistic to make Docker seem less capable than it is. After all, who wants to use something that only works for some applications? And the fact of the matter is that Docker is just a fancy way to run a process. Bind-mounted host directory volumes are one of the most fundamental features available for Docker. The truth of the matter is that Docker can be a complex beast. And what ends up happening is that often people only understand a small part of Docker features they're using. And then they complain about problems with Docker when what they really need to do is go read the documentation. Not all problems with Docker are like this, of course, but the vast majority of complaints that I see (and I see a lot of them from being part of the open source community for over three years now) come from people that don't fully understand the features of Docker they're trying to use. Getting Docker going is dead simple, and people fall into the trap of thinking that's all there is, when Docker is a damn deep technical subject.

mbesto9y ago

Is this what you're referring to?

https://docs.docker.com/engine/tutorials/dockervolumes/

1 more reply

closeparen9y ago· 2 in thread

>Having docker without orchestration is like having cars without roads.

Docker's stated purpose is to be the "shipping container" abstraction for server-side code.

Shipping containers are not much more exciting than any other kind of box (VM, jail, whatever) in isolation. Things get more interesting when every port has container-optimized cranes and there are thousands of container ships competing for your business.

digi_owl9y ago

Thinking about it i seem to recall that for a while all the hoopla was about VMs that could migrate between hardware to both better utilize existing hardware resources, and allow for more uptime.

But then a while later all the buzz was containerization, with Docker as the poster boy. This, i suspect, in that rather than have the overhead of a VM and such, you could spin up a container instance over there, take it down over here, and achieve much the same result. This in particular if the content of your VM or container was talking to a storage backend anyways.

XorNot9y ago

In my context it's because big data became a thing. Nobody wants to pay the virtualization IO overheads anymore.

That said, I've found myself swinging back towards preferring VMs - with docker-like infrastructure made available. The runv project (https://github.com/hyperhq/runv/) is an interesting and functional take on Docker-with-VMs since I spend way too much time wanting to do privileged things in containers.

scoot9y ago

> don't try to dockerize databases

Why ever not? There no less reason to do so in a container - and all the usual benefits still apply.

startling9y ago

> No. Just No. > Docker has nothing to do with security.

Docker can totally reduce the risk of in-container services being exploited. It has sane defaults, and makes it easy to distribute other restrictions with the application (seccomp profile, apparmor settings, etc).

j / k navigate · click thread line to collapse

0 comments

12 comments · 5 top-level

jfoutz9y ago· 3 in thread

>>> * Docker encourages fully disposable infrastructure

Depending on your orchestration, blue/green deployment is pretty straightforward.

user5994461OP9y ago

There can't be two containers running that listen on the same port. The rolling upgrade will need to kill the first container to start the new one.

I may suppose that you talk about [CPU] load, because you are running computations/processing applications and not webservices.

fapjacks9y ago

Well, this is a problem that's been solved [0]. I've been using nginx-proxy for a couple of years now, in production, without any issues.

[0] https://github.com/jwilder/nginx-proxy

lobster_johnson9y ago

Don't use static ports. Pick a random one and update the load balancer (Haproxy, Traefik, Nginx) to point to the new one. If the rollout fails, you can always roll back by pointing back the old one.

FWIW, Kubernetes solves this out of the box.

adimitrov9y ago· 2 in thread

> For instance, don't try to dockerize databases

Host volume mappings. Problem solved.

fapjacks9y ago

mbesto9y ago

Is this what you're referring to?

https://docs.docker.com/engine/tutorials/dockervolumes/

1 more reply

closeparen9y ago· 2 in thread

>Having docker without orchestration is like having cars without roads.

Docker's stated purpose is to be the "shipping container" abstraction for server-side code.

digi_owl9y ago

Thinking about it i seem to recall that for a while all the hoopla was about VMs that could migrate between hardware to both better utilize existing hardware resources, and allow for more uptime.

XorNot9y ago

In my context it's because big data became a thing. Nobody wants to pay the virtualization IO overheads anymore.

scoot9y ago

> don't try to dockerize databases

Why ever not? There no less reason to do so in a container - and all the usual benefits still apply.

startling9y ago

> No. Just No. > Docker has nothing to do with security.

j / k navigate · click thread line to collapse