Why is Docker hard?
Le but inavoué de ces changements vise à faciliter la modernisation. L'introduction de nouveaux équipements pour conteneurs nécessite, selon Devlin, une réevaluation complète du niveau des effectifs, l'abolition du salaire à la tâche et l'abandon du travail protégé.
-- Le syndicalisme docker depuis 1945 (Michel Pigenet)
Abstract
This document compiles every argument against Docker adoption in 2020.
Multiple sides and categories of concerns are taken into accounts
Containers require a new way of thinking
category: container technology
Containers are very complex and create unique challenges
- Containers abstract a whole system, it's not a "small abstraction" (like a software library)
- Immutability: you cannot update a container like a regular application
- Ephemeral: everything can be overwritten and nothing is persisted
- New security paradigms: no strict isolation between containers or between container and host!
But that's a necessary tradeoff for scalability and agility.
sources:
Containers require a new way of debugging
category: container technology
- No SSH on docker containers
- Use
docker volumes
anddocker logs
- Use sidecar pattern to ship logs
- Nsenter can be used a last resort to debug Linux Namespaces
Containers are not VMs! We cannot use the same debugging methods as VMs
sources:
- JPetazzo - Docker SSH considered evil (2014)
- Microsoft Azure - Sidecar Pattern (2017)
- StackOverflow - Why I can not simply ssh to docker container? (2019)
Benefits vs Virtual Machines are unclear
category: container technology
Arguments against Docker:
- People are used to the standard way: VM images (AMI, vApp, Packer, KVM etc) + a provisioning tool (Ansible, Chef). And it works.
- Docker needs many new specific tools to be used properly in production: Registry, Orchestrator (K8s), applcation package management (Helm), Operators (Flux, database rollback etc).
- People advocating Docker are often fanatic and offer only "docker == magic" arguments
- Docker is by definition less secure because all containers share the same kernel: VM are better!!!
Arguments against VMs:
- testability: a container is testable
- vm are slow: a VM is too coarse-grained and restarting a VM is a big deal (boot time, provisioning time...)
- containers are lightweight and you can run more containers per rack
- VMs cannot scale as fast and wide as containers
- a "best of two worlds approach": use VMs which run Docker. (better isolation, and lets the user use Docker for fast development)
sources:
- HackerNews - Is it just me or why does Docker suck so much? (2014)
- Smashcompany - Flaws of Docker, Kubernetes and their ecosystem (2019)
Creating good images is hard
category: docker specifics
Copy-pasting simplistic Dockerfiles from the web creates broken images:
- no python version pining
- no dependencies pining
- bad layer caching usage
- running as root
Building production-ready / best practices Docker images is hard. You must learn Docker best practices and think instead of copy-pasting.
source: Pythonspeed - Dockerizing Python is Hard (2020)
You must be root to use Docker
category: docker specifics
many solutions do exist:
- the standard way: adding the current user to the
docker
group and restart Docker - Rootless Docker
- use other container technologies
Docker is dying
category: docker specifics
Is Moby a fork/replacement for Docker?
Before 2017:
- Docker was a monolithic app with many responsibilities: build, runtime...
- Docker is a company selling enterprise editions but the open source community maintains the open source project
Now:
It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-source product into Docker, solves that problem.
- The monolith has been broken into multiple open source projects (build =
buildkit
, runtime =containerd
) - Moby = all the open source projects
- Docker = the product, using moby components
Docker Swarm lost to Kubernetes
- Docker supports Kubernetes orchestration since 2017 (Docker 1.12)
- Cloud providers: KaaS and proprietary
Docker vs other container types
rkt, lxd, ... Docker now faces many challengers
CRI : Container Runtime Interface. Created by the OCI (Open Container Initiative)
The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation
-- OCI website
- Kubernetes supports any OCI container
- Docker containers (== moby containerd) implements CRI
Docker Containers are now just one type of OCI containers The community is looking to improve container security by creating new paradigms like MicroVMs or Unikernels. The container technology is now under the OCI/Linux Foundation governance, which is BETTER than a standalone company.
RHEL doesn't ship Docker anymore
Instead of Docker: Podman, Buildah, Skopeo.
These tools are OCI-compatible, not only Docker-Compatible. They offer many improvements (ex: Podman has no daemon running on the host!) over Docker
Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Simply put:
alias docker=podman
.
sources:
- Servethehome - Kubernetes Wins (2017)
- Technodrone - Goodbye Docker and thanks for all the fish (2019)
Command-line only is hard
category: misc technical
Docker/K8S GUIs
for Windows / MacOS / Linux:
Rancher, Portainer, Kitematic, DockStation
I have trouble memorizing commands
Google it, tab completion, cheatsheets
I know the theory but cannot put it in practice
Tutorials can harm the way you learn:
- you never have to setup the real environment and only address the "passing" case.
- You aren't trained to troubleshoot in a tutorial.
- You aren't trained to ask good questions.
- Tutorials are really easy and give the illusion of mastery.
In general, excessive guidance carn harm the way you learn:
- tutorial hints,
- copy/paste full code snippets,
- learning programming syntax but not programming concepts
Solutions:
- Setup your work environment (don't work in artifical environments like play-with-docker)
- Program from scratch: without any tutorial/instruction! You can look at other people's code, but not allowed to copy/paste from them.
- Learn to ask for help
- Code more
sources:
- Reddit - Why is learning the command line important? (2016)
- Programmingforbeginnersbook - When you know the basics (2020)
Docker is not the developers job
category: company & culture
When the company culture doesn't evolve but they still want to adopt Devops, the following reactions can occur:
Loss of productivity
category: company & culture
- Developers don't want to be part of infrastructure/ops team. Too much responsibilities and not enough time.
- Manager view: If the developers begin to do infra/ops work, the developer productivity/velocity will go down.
- Every developer need to be availabe for ops: interruptions, participating in post-mortems, performance monitoring...
The switch to devops must change expectations and metrics!
- Individual productivity is less important than flow of work in/out of operations
- Commits / LoC metrics are replaced by MTTR, Change lead time, deploys per hour
- Managers and developers must see the big picture ie working to deliver a product
source: Dzone - Devops kills developer productivity too (2014)
Developer burnout
category: company & culture
It is no surprise that developers are now more likely to crumble under stress -- especially because they know that they are directly affecting the end-user experience. With the ability to create rapid changes and innovate quickly comes the acceptance of great responsibility that can increase stress levels and cause severe damages when not carefully managed.
Docker steals Ops jobs
category: company & culture
Traditional sysadmins can fear that devops tools like Docker will automate them out of their job.
- Everything as code is a developer skillset, not a ops/sysadmin skillset.
- Docker trivialized what was a real job into sharing random precompiled binaries: security issues. Nobody can build Haddop from scratch.
sources: