Hacker News Reader

> Please save yourself a lot of heartache and just use containerd.

Part of the appeal of Docker is the ease with which developers new to the concept of containers can pick it up. I cannot say the same for containerd. Try a search for containerd tutorials and compare what you find with docker tutorials.

> People don't realize just how easy all this stuff will be to replace.

Think carefully about why that is. If it were easy, it would have been understood. So, no - understanding the replaceability of the container components is not easy. That is why people have not realized it.

The issue with many docker's competitors is it appeals to docker experts. The abstraction and terminology itself is not straightforward.

A lot of hyperbole in your comment is unnecessary and/or undeserved. Of course I realize that this is HN where k8s, rkt and containerd are used largely by the visiting audience. But don't forget the dark matter developers.

> Try a search for containerd tutorials and compare what you find with docker tutorials.

containerd is just a building block. You'll actually be looking for a Kubernetes tutorial, which the internet is sprawling with.

Yeah, but how's the dev experience for Kubernetes, even with all those tutorial? How easy is it to install on Windows, for example?

choco install minikube

choco install kubernetes-cli

minikube start

(You'll need Hyper-V, however.)

If you have Docker for Windows, it includes K8S too, out of the box

although I've not seen much on K8s + containerd without Docker in terms of tutorials, it is a very new space, and (IIRC) cri-containerd is also pretty new.

I'm not aware of many k8s distro's running anything other than Docker by default, at the moment

IBM Cloud has 1.11+containerd in production (https://twitter.com/estesp/status/1029739247606145025), GKS has containerd as an "alpha" option during k8s cluster creation; Azure has stated direction to move to containerd for AKS (and their OSS deploy tool already supports containerd on cluster creation)

Cool, I guess I'm not surprised that IBM Cloud are leading the way there :) are you aware of any on-prem options shipping Containerd as a default so far?

I know our own on-prem (IBM Cloud Private) has containerd in testing and looking for a late year release where containerd is the primary engine. I'm not as up to speed on who else is offering on-prem K8s; but I do know minikube is also getting containerd integration as we speak.

Awesome, I had a play with getting containerd running without Docker a little while back and it all worked, just required a bit more effort than Docker :) It'll be interesting to see what happens as more k8s options adopt it

In my opinion docker is not a good fit for the problems its trying to solve.

On the developer side I'm trying to build a artifact of my application which can run on servers. I'm probably using windows or osx as my development environment, and I'm probably targeting linux. So docker is a tool I can use to create a container to achieve my goal.

But it doesn't do a good job of that. The dockerfile format can be very frustrating to work with. And all the terminology sets a very high barrier of entry for usage. Yes its all googleable, but sometimes I think the solution is harder to use than the problem it set out to solve.

Go, Java, .Net, even javascript with Node, all do a much better job of making it easy for developers to build cross-platform applications. Without the need to learn an arcane file format and clumsy cli tool.

As an example of that frustration, building a cross-platform Go app is as easy as setting an environment variable. No additional configuration is required and there are no additional tools you need to install. The binary that is produced has everything it needs to run and can be deployed without having to use specialized tools.

Whereas building a Go app in a container with Docker means you end up retrieving all the dependencies every time and you get no package caching for builds so they take 10 minutes. For any large project you will inevitably break out your docker files into separate steps with some sort of make file. You will then bang your head against a wall for days trying to get docker in docker to work for your CI build system.

Is that really the best we can do?

But docker is also about isolation, file formats, conventions for deployments, protocols, etc. And yes it's a step forward in many ways. Containers are great for allowing the ops side to focus on running an application instead of making sure its configured properly.

But on so many of these dimensions docker has had major problems. It's not really safe to run arbitrary containers, so the isolation is an illusion. Because of the way the tooling works the containers are way too big and contain way too many unnecessary dependencies - which end up being security liabilities because they aren't upgraded often enough.

But ultimately docker turned out to be way too low level. It's why something like Kubernetes exists. It's a much higher level way of describing how an application should work.

So docker is getting pressure from both sides and that's why I think its days are numbered. The formats and conventions will stick around, but once they start requiring people to pay for the local development tool, everyone will move on and we'll stop talking about docker at all anymore.

Thanks for the shout out. Is there a good tutorial you could recommend for containerd?

I am looking for features similar to Norton Ghost bust faster than waiting for installers every time I build.

Wow I'm so glad that I'm not the only one with this opinion. Every single time I've had to use docker I've had to slog through inane design decisions which seem to make everything harder than it needs to be. Everything is inconsistent and there are several commands which seem to essentially do the same thing but subtly do not, and so on .. It's like every design decision has just been made by a single developer who likes to come up with new and "smarter" ways to do things.

I wouldn't go so far to call it a mess but there is some truth to it. Naively, one might expect the following use cases:

- test-drive even the most complex deployments on your laptop

- spin up all the cool admin tools you ever wanted without wasting months of precious life time

- reproducible setups

- everything is always up to date

But as you say, caching is at best in a mediocre state. If you indeed want to run heavy-weight servers (like ELK), be ready to have a Terabyte space just for images unless you want to GC all the time when tweaking the configuration.

Also the laptop thing doesn't work unless you either have a very beefy machine or just work with very lightweight software. In reality Docker can be used for these use cases:

- Test-driving some heavy weight or complex server software

- CI to some degree

I'm starting to think good old Unix tools in combination with automation tools like Chef, Ansible, ... are the way to go - or even just plain .deb files...

> You’d be surprised by how many companies using Kubernetes gave up using docker a long time ago.

What are they using instead? cri-o? rkt?

At Datadog we are using containerd. We've heard of other companies using cri-o.

There's also a lot of mixed deployments of container vs native out there. It seems Kubernetes is popular but not many companies with a large number of servers are willing to bet the farm on it, so they may only run a subset of their services with it (stateless, or test environments)

You can use Docker, just be ready to account for the instability. With proper detection and strategies to evict bad nodes you can build a reliable platform out of it. (though for stateful things you may end up with a real mess on your hands)

Weve seen issues with cointainerd too, but at least so far it seems more stable.

Basically every piece of docker is being replaced. The runtime (containerd, crio), the tools to build containers (google has several), the server to host images (ecr, gcr, etc)... it's weird to call it docker when none of the components actually use docker anymore.

The gui and installer is nice for local development, so I guess it has that going for it.

+1 for containerd (+ cri-containerd, which is included by default now), it's served really wonderfully (meaning I didn't have to touch it much) as the base for k8s machines I've boostrapped recently -- I don't even install Docker anymore (as in literally docker the daemon is not installed or running, just runc + containerd).

The replacement of docker is a good thing IMO (though probably not a good thing for Docker the company) -- it's one of the main benefits of the kubernetes hypetrain, the development of C*I (Container <something> Interface) has been great for the ecosystem.

I personally find docker's CLI way more ergonomic however.

How do Dockerfiles work if you aren't using Docker?

Is there another way to define what the container should look like?

You can build the containers with Docker and ship them to a repository. The format is the same.

There are also tools like jib which can build containers without docker: https://github.com/GoogleContainerTools/jib

Wtf are you talking about? I've been running docker in production for 3 years (30+ microservice platform) with litterallly 0 of those problems. Caching works, hence why you need to clean your disk space. And multi stage builds are awesome for many circumstances. It sounds like you don't really understand how to use docker all that well.

You've never had docker do anything weird in production?

It didn't happen often, but we definitely had problems. We're running kubernetes clusters with several hundred nodes.

Caching is very crude. When building its based on lines in the dockerfile which means adding a dependency means redownloading everything. You also can't mount a directory for builds.

Multi stage builds are very limited in what they can do and often aren't powerful enough to implement efficient builds. You end up either having 20 minute builds or complex make files to work around the inefficient default workflow.

FWIW an intelligent caching mechanism should not require manual cleanup. Thankfully kubernetes does this for us in production... but the crazy 1 GB images you end up with for a moderately complex python app make it hard. (especially when people use :latest and then there are 12 versions of the app laying around)

On our CI server, I setup an apt-cache container, and have a 'base' image derived from bitnami/minideb that sets the container's apt proxy to apt-cache. There's also Squid for HTTP caching, Archiva for Java artifacts, and Devpi for Python ones. So, sure, changes will require re-downloads, but they're pretty fast since everything's local. For getting multi-stage builds to work nicely, I just use a Makefile, defining separate targets for 'builder' images and 'runtime ones', and COPY artifacts from the former into the latter to form the final application images.

> As a concept, containers never really lived up to their potential. "A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application." As long as that application runs in linux.

I like the concept of containers as a lightweight alternative to virtualization. I even use containers (FreeBSD Jails, specifically) for some particular use-cases where I need stronger isolation than separate UIDs, but don't need a full-blown VM. I don't mind this use-case at all.

I really dislike the reality of containers which seem to be "Our deployment procedure and dependencies are so insane so there is no hope of packaging this as an RPM or DEB, so here's an entire userland for you".

As an example of papering over a crazy deployment/dependencies nightmare: I remember seeing a project[0] which used four Docker containers to apply some machine learning based automation to Hue lights. Two of the containers are basically infrastructure pieces (RabbitMQ and Cassandra), one container was dedicated to the machine learning piece and one acts to tie the other three together.

I have no idea why this project needs to run four separate operating system instances to do this job. If I were building it I'd do it as one application, so no need for RabbitMQ, and I'd use an ORM to let the user choose which database is most suited. I'd have an SQLite database as a reasonable default. Maybe I'd have an option to publish stuff to some kind of message queue so that it could be consumed by other systems.

Don't get me wrong, I love the idea behind this project and want to try it out, but it really feels like the author went container-crazy because they could and didn't stop to think about whether they should.

[0] https://github.com/tlackemann/hubert

My fellow employed engineers have been moving towards Docker for over a year; slow progress because there's so many problems that Docker introduces whose solutions are convoluted at best.

That's on top of the security auditing nightmare if you ever decide to use stuff from Docker Hub.

> "As a concept, containers never really lived up to their potential. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application. As long as that application runs in linux."

This is how Erlang releases have worked for 20 years

http://erlang.org/doc/design_principles/release_handling.htm...

> Those cute, cuddly characters

I never really got how a shipping container on a whale makes for a good logo, unless it's just meant to be reflective of the apparent reliability:

> the "whale" your container is riding on may just fucking dive underwater for hours at a time, but hey containers are designed to be in the ocean.. Wait, they're not?