> is docker even useful for most projects or is it just a preparation for solving imaginary scaling issues that most won't even reach?

I use docker for a small server at work, where I know there will only ever be one container per image.

Where docker is incredibly useful is with non-free software which works on Linux. Usually, they rely on a specific version of Debian or Ubuntu. Yes, this can be achieved with VMs, but that requires running 5 or 6 kernels. So for us it's a huge resource win over VMs.

For me, Docker sits between chroot and full-blown VMs. If you drop privileges you actually do have some security advantages over chroots and separate processes – although I don't think Docker emphasises this enough. The way Docker is used and the way it is documented seem to have a disconnect.

> I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine.

If it doesn't solve any problems you have I personally wouldn't bother – you can always "dockerize" after, which should be a relatively straightforward process. At this stage it's just a distraction. Good luck.

Docker doesn't have anything to do with scaling. All it does is to bundle shared libs, executables, etc. of your app in a container image. If the world could agree on a common Linux userland (same builds, features and names/locations of common userland libs and language runtimes), then Docker wouldn't exist. So you could say Docker just solves a problem of our own making - that of too many Linux distros. Of course, now that those libs are contained in the image, and often invisibly so, the problem of updating those dependencies for eg. security updates is unsolved. That is, the entire reason why these dependencies are provided as shared libs in the first place - that of removing vulnerabilities without having to rebuild entire apps - is lost.

The other thing that Docker does is run in a namespaced environment such that apps don't have access to the local file systems on your host by default. This is also a problem that's been solved since the dawn of Unix by eg. using file permissions (though admittedly not every scenario is served well). Docker apps don't have access to the host's access control infrastructure (/etc/password, pam, etc.) though, so Dockerized apps need to invent their own ad-hoc auth.

The only problem that Docker is really solving is that you can pack more apps on a single host compared to full-blown VMs. Basically, Docker is infrastructure for cloud providers to sell you lots of pods cheaply (for them, that is). Since many images are based off Debian (pull in deps via apt on first start), it could also be argued that Docker is acting as GPL circumvention device of sorts.

+1 tannhaeuser. I live in a more heterogeneous environment than what docker can provide, and it seems to me that the ground docker covers is like you said, application packaging. This is frustrating since in a lot of cases, "applications" are only being provided as docker images. What the heck can I do with a docker image on something that doesn't provide docker? How do I have assurance that when teams pull docker images in from the wild, that they're actively maintained and not full of 0-day vulnerabilities? I've switched to pkgsrc and highly recommend it for solarish (and solaris), *bsd, centos, debian, mingw+windows, osx and whatever else one would feel like building binaries and dependencies for. The key to me is separating the operating system package manager, and the application dependencies such that when operations runs their mandatory apt/pkg/yum/dnf/whatever updates it doesn't break application dependencies. And on the flip side when applications want to screw with things that aren't in apt/yum/etc those custom needs can be met. This approach also doesn't preclude using the respective os container mechanism (zones/containerd/vmware/hyperv/chroot/etc). We package custom internal packages in our own internal pkgsrc repo, along side of the main repository that provides north of 10,000 packages.

More people should become hip to pkgsrc.

So only to get on the the same page as you and not to be a smartass- you're saying Docker is like an AppImage without access to host files (I didn't get the last part about GPL circumvention) whose purpose is to provide non-emulated VMs?

If all I use is Debian on my server with a file that always installs the required packages and I don't need isolation between services, should I care about docker as an "end-developer"?

Difficult to tell. I'd probably stay within a plain dev environment as long as possible. Just keep in mind you can't rely on host auth within Docker if you ever wanted to use it. Besides, it's never wrong to learn something new, and Docker isn't difficult to pickup.

Often times you want to run a newer version of a package but it has new dependency requirements that conflict with other packages. Most solutions around this involve tweaking the package, or using a chroot. A container lets you avoid this problem as each container has it's own rootfs and can be a different OS and can run different versions of software however you want without worrying about conflicts.

It's somewhat similar to static linking, but at a higher level.

It depends on what you deploy to. If it’s AWS or Azure web-app type stuff, then maybe not, but if it’s your own infrastructure in anyway then fuck yes.

Ten years ago we build things in C#, used MSSQL and deployed to IIS. All Microsoft tech, all pretty straightforward, except it wasn’t. We never kept track of the “it works in dev, but it explodes in prod and I don’t know why” hours, but I wish we did. Because it’s in the thousands, and those thousands of hours is exactly why we use docker.

We also use docker because it lets us build things that our IT crew isn’t certified in running infrastructure for (and the lovely security issues that brings to the table) but we mainly do it because it works.

Docker might not have a monopoly on that, but they have enough of a brand that the word “docker” is to containers what “google” is to search. At least in my circles.

I use Docker for development stuff too. I (and team members) have spent countless hours battling with setting up things like RabbitMQ, and I only wish I'd done it sooner - being able to instantly spin up a working, consistent development environment is amazing.

I know you can do this with VMs too, with tools like Vagrant, but containers start in a couple of seconds - great for integration tests.

> We also use docker because it lets us build things that our IT crew isn’t certified in running infrastructure for (and the lovely security issues that brings to the table) but we mainly do it because it works.

It is amazing how many technologies get traction simply because "It lets us bypass IT."

In our case it’s the compromise between developers and a operations department which has 5 technicians to support the infrastructure of a municipality with 7000 employees and around 300 IT-systems.

To manage our IT had to make certain infrastructure decisions and build their competency around those. This clashes with a lot of modern development, but we manage with docker and an increasing Azure presence. It’s not optimal, but sometimes it’s just necessary. Don’t get me wrong, we’re trying to improve and build Devops that isn’t handing off a container, but it’s a challenge in sectors where digitisation and IT aren’t priorities despite being an inherent part of any business process in 2019.

There is a real danger in there of course, but we have strategic choices for our development platforms as well. They just need to move a little faster than IT.

What are some docker alternatives? And how does Docker on windows work? I know it uses Hyper-V underneath but does MS include a base linux kernel image?

Docker on Windows is interesting. For windows containers, it can do both process based isolation (similar to Docker on Linux) and Hyper-V based isolation, which uses a very cut down VM as a base. Compared to Linux containers the base images are large, but there are only a few commonly used base images, so once you've got them it's not too horrible due to the overlay filesystem in use.

For Linux containers there is LCoW, which uses a Linuxkit VM to host the containers.

There is also some chance that in the future Linux containers will run natively on Windows without a VM, via WSL. This is very hacky at the moment but there have been reports of people being able to run Docker engine in WSL with no VM.

I always thought WSL was only meant to be a dev-tool. Do you have any links where there is a mention of a plan for them to be prod? (I know that's not what you're mentioning but wondering if that's how you guessed...)

So it's mainly in GH issue comments things like https://github.com/Microsoft/WSL/issues/2291#issuecomment-38... show that people have got it working.

Whether MS ever use that tech. for production linux containers remains to be seen. It sounds kind of cool and might be good enough for dev/test but I imagine sorting out all the wrinkles to make it prod. ready could be tricky...

Docker is immensely useful when starting projects that use web services because it lets developer download and run instances of any service on demand with a single CLI command, and lets any teammember do the same with your work.

Then with docker-compose you are able to instantiate custom deployments of your projects, including dbms and gateways and messa buses and IAM services, with a single command (docker-compose up).

So yes, it's very useful.

However, the point of the article is that Docker is no longer the only option, and although right now it's the default go-to container tool, there is nothing but inertia keeping the world using Docker.

I don't even think Docker is useful for production, but it's indispensable as a development tool since I don't want to sully my Linux install with a bunch of databases and dependencies I'll inevitably forget about.

Clearly, you haven't had outages during app deployments because somebody forgot to update the accompanying packages from the OS.

It makes it trivial to package, build, and configure your host machine as a VM exactly how is supposed to be setup. Drastically reduces the amount of "well this works great locally" BS.

Then it's trivially fast to pull and run the image on any machine with Docker or K8s installed.

Docker is not a tech for scaling, its a tech for repeatable environemnts (prod dev). Its very useful for this. Container orchestration is for scaling (k8s). Docker is very useful when you have more team members with different computers.

I've found it really useful on embedded systems (e.g. Raspberry Pi). It takes a long time to install anything complicated, and you occasionally need to make kludges. Having a Dockerfile means (a) I can remember what I did to make everything work, and in what order (b) using a hub, I can easily duplicate the environment to another Pi without waiting overnight for all the applications to build.

Yes, you can clone the SD card, but I think it's cleaner to use a version-controlled Dockerfile. Otherwise you always need some master SD card to clone from (and keep track of a multi-GB image file), and you have to faff with resizing images if the new card is smaller.

A fresh system install is then: flash Raspbian, update system, setup some init scripts, install docker, pull the image and clone the latest version of the code from github.

This is also the approach embraced by Balena, who (conveniently) provide Docker base images for a bunch of common embedded systems.

Another reasonably big user-base is machine learning.

What stuff are you putting on your Pi through docker? Just getting started and interested to hear how others leverage it.

It's for a drone-based sytsem. Python, OpenCV, ROS are the main parts, plus some machine vision camera SDKs. I've also put in some optimised machine learning libraries which are a bit finnicky to setup. ROS is an absolute mule to get right and I like having it in a closed off place so it can't mess around with the rest of the system. I have the actual ROS workspace in a shared volume so they're persistent if I fiddle with the Dockerfile.

None of it really requires docker, but it's nice to have the whole environment encapsulated, and having a record of what I had to do to get some of these things to install is invaluable.

I have a shell script which launches the container (I just run a new one) every time the Pi boots.

Think about this: Wouldn't it be nice if installing apps on your desktop was as simple as just a folder? And everything lived in that folder instead of sprawling out into the OS everywhere? Copy that folder to run more, or replace it to update, or delete it to remove everything.

That's what Docker does. It lets you wraps everything into a single isolated package (a container) that can run whatever you want without affecting anything else on the system, and then cleans up perfectly. You can connect it to networks and disks but There were APIs for most of these things already in Linux but Docker brought it all together into a simple interface.

The other big innovation is the Docker registry that makes images easily available over HTTP. No more complicated downloads or package systems, instead you could just point to a simple host/image:label address and download whatever you need. That simplicity and flexibility is what made it take off.

As others are saying, Docker is a tool for repeatable environments.

I have an application with a long, tedious setup process involving dozens of apt dependencies that I don’t maintain. In the past, I’ve had issues with things not updating properly, inconsistencies between versions, spontaneous breakages... Using Docker, I built an image that contains all the dependencies that are unrelated to my code or configuration, then another image relies on this and contains all of my stuff. My deployment process only needs to be concerned with updating this second image and all of the frightening dependencies are guaranteed to be consistent and reliable. This second image is deployed to each box. All of the production systems are identical and if I need a new production box, I can have it ready to go in minutes and be confident that it will work and behave reliably.

> [...] I built an image that contains all the dependencies [...]

How, may I ask? I've been looking for a good way to do this for a long time; nowadays I'm using a checklist and AMIs on AWS.

Ansible is too damn slow, does not know how config files work and clutters the terminal/my home directory/my known_hosts.

Dockerfile is a badly written shell script using && instead of errexit.

I'm not sure if mine is a good way of doing it but it's working for me. I took the relevant portion of my own badly written shell script, moved it into its own Dockerfile that has its own CI project and its own private repo on Quay, and I rebuild/republish as needed. The remainder of my original shell script went into the Dockerfile for the project that holds my code. The first line of this Dockerfile just starts with my base image.

    FROM quay.io/my-acct/my-image:latest

The point of the && in a Dockerfile is because every single RUN directive adds another layer to the final image. Less layers = slimmer images = faster and lighter deploys.

Yes. Also, the only thing that survives between RUN directives is the disk image so && saves state:

start-daemon && configure-daemon-while-running && stop-daemon

The point is, I've seen far more && than RUN directives so the decision was backwards.

It makes deployment really easy so long as you have the infrastructure to deploy to. I have most experience with Amazon ECS but you could also manage it with Kubernetes on AWS, Azure or GCP.

My company now deploys every app that can run on Linux as a Docker container, regardless of whether it needs a single instance or 50.

It's not as though it doesn't introduce its own problems for example - you might patch software on the host but you still need to patch it on the container and it can be difficult to get an inventory of that, say there's a zero-day found in nginx. You still require organisational discipline, that never goes away.

Even if you don't use Docker in production, I think it's still very useful tool for local development, combined with docker-compose.

When I'm working on one service, I often depend on a few other services too. I usually need a storage layer, perhaps API calls to related services, it may even to talk some Amazon services like S3 or SQS. Having a simple way to spin up every dependency locally, even AWS (lots of great AWS API compatible images out there) is really useful if only for local development.

I use it a lot for ML work. Nvidia-docker makes it easy to setup CUDA and partition access to GPUs (if you have more than one). Docker makes it easy to setup tensorflow, Keras, python, etc. which I find to be a royal pain otherwise.

Anytime a potential new hire submits their sample project in a docker container and I can stand it up and everything 'just works' I am happy. No need to mess with any dependencies and it should work as they intended it.

The Docker CLI will be around for a long time. This post is just FUD.

There isn't another runtime that is as easy to use as Docker.

Part of the article calls out how the alternatives (like CRI-O) are shipping docker compatible CLIs, so that users can keep going `docker build` but with a completely different runtime.

CRI-O isn't comparable to Docker for developers, it's a replacement for Docker when used as part of a Kubernetes cluster.

The thing is that whilst various operations are shipping bits of the functionality that Docker provides in various different tools, for developers working with containers none of them (that I've seen) have an easy to use, cross-platform setup.

The post was primarily about the company. The CLI can be around for decades, but that doesn't necessarily mean Docker the company can profit from it.