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.
containerd is just a building block. You'll actually be looking for a Kubernetes tutorial, which the internet is sprawling with.
choco install kubernetes-cli
minikube start
(You'll need Hyper-V, however.)
I'm not aware of many k8s distro's running anything other than Docker by default, at the moment
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.
I am looking for features similar to Norton Ghost bust faster than waiting for installers every time I build.
- 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...
What are they using instead? cri-o? rkt?
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.
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.
Is there another way to define what the container should look like?
There are also tools like jib which can build containers without docker: https://github.com/GoogleContainerTools/jib
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)
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.
That's on top of the security auditing nightmare if you ever decide to use stuff from Docker Hub.
This is how Erlang releases have worked for 20 years
http://erlang.org/doc/design_principles/release_handling.htm...
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?
As a tool for building containers its cumbersome, has bizarre and frustrating limitations and has issues that haven’t been addressed in years. You can’t use semver for tags, it eats up all your disk space and you have to manually GC it, etc… Multi-build support is basically useless and invariably you end up writing convoluted bash scripts to get the thing to work.
Caching is terrible pretty much across the board. How many petabytes of data are wasted every day re-syncing apt-get?
As a runtime engine its basically dead for production use. If you ever try to use it you’ll quickly discover that it has tons of problems. It locks up, orphans processes, stops responding to commands, forgets about containers, etc. And its not safe to run arbitrary containers. You’d be surprised by how many companies using Kubernetes gave up using docker a long time ago.
Please save yourself a lot of heartache and just use containerd.
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.
As a company Docker is a failure. All their cloud stuff is clunky, poorly thought out and at this point largely irrelevent. I'll be surprised if it will last 5 years. Kubernetes won. Those cute, cuddly characters and the Docker name are basically all they have going for them, and all these things, the Moby rename, the requiring login to download, etc... are the death throes of a dying company. Docker is the next jQuery.
People don't realize just how easy all this stuff will be to replace. Google already did it. Like 5 times. (gVisor, jib, kaniko, ...) It was probably some intern's side project.
Microsoft should just get it over with and acquire the company. It would be the perfect cherry on top to their Github cake.