20 ms·

Dissatisfied with Docker

226 points by khuey 7y ago

chucky_z 7y ago
I am currently on this train. Having used rkt in the past, I went to revisit it recently only to find this: https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-project/ https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-pr... I am so extremely disappointed in the CNCF as rkt (at the time, at least) seemed to be more "production ready" than Docker. Are there any real alternatives? Is the answer "find something else that uses containerd in a more friendly way?" Is the answer "try to use podman/buildah, which are weird in their own way?"
- roca 7y ago
  Podman looks interesting at a quick glance, though not supporting docker-compose makes migrating nontrivial for us.
  - devmunchies 7y ago
    and my attempt to get it run on mac were fruitless. I would have to do it in a Vagrant VM like 5 years ago.
  - 3131s 7y ago
    It was discussed recently in the podman Github issues that this functionality will be covered by the separately maintained podman-compose, which was recently transferred here: https://github.com/containers/podman-compose https://github.com/containers/podman-compose
- l_t 7y ago
  Maybe containerd [0] is an alternative? It's being used in k3s instead of Docker. [0]: https://containerd.io/ https://containerd.io/ edit: I didn't notice that you mentioned this in your comment, my bad. Can you explain why it doesn't work for you? I'm new to the Docker-alternative scene and thought it looked pretty good at first glance.
  - chucky_z 7y ago
    Docker uses containerd. Here's an image straight from a blog post from last year: https://i1.wp.com/blog.docker.com/wp-content/uploads/2018/09/docker-engine-blog.jpg?resize=631%2C522&ssl=1 https://i1.wp.com/blog.docker.com/wp-content/uploads/2018/09... https://blog.docker.com/2018/09/join-the-beta-for-docker-engine-18-09/ https://blog.docker.com/2018/09/join-the-beta-for-docker-eng...
    - xyzzy_plugh 7y ago
      It does and it doesn't. The interface is pretty different. Using containerd directly as a binary is pretty rough around the edges, but docker uses it as a library. In particular the CRI implementation works, but leaves a lot to be desired. Their release cycle is also pretty lengthy, such that each minor release has a ton of changes, resulting in a lot of work to integrate into your infra.
- angry_octet 7y ago
  Wasn't that because RedHat bought CoreOS, and RH is all k8s? And then no one was pushing rkt along with commercial support, so it died? Agree the rkt was cool. I just don't know if RH is becoming more like MSFT or more like Oracle.
  - bionsystem 7y ago
    More like IBM it seems :)
- dharmab 7y ago
  We're implementing CRI-O so we can use Docker and Kata Containers side by side for different workloads. We're hoping if things go well we can fully migrate off Docker after a few years of transition, but it's in early stages.
syrusakbary 7y ago
The article is completely on point. Because of all the reasons exposed there (and a few more) I started Wasmer, a new container system based on WebAssembly - https://wasmer.io/ https://wasmer.io/ Here are some advantages of Wasmer vs Docker: * Much faster startup time * Smaller containers * OS independent containers (they can run in Linux, macOS and Windows) * Chipset independent containers (so they can run anywhere: x86_64, Aarch64/ARM, RISC-V)
- scanr 7y ago
  Wasmer looks interesting. I couldn’t read much as I get an “unexpected error” as soon as I start scrolling. It does say that it’s not optimised for mobile.
  - syrusakbary 7y ago
    Thanks for reporting it! We will investigate and try to fix it ASAP :) PS: if you could provide your device info (os and browser) it would be awesome
    - jackalo 7y ago
      The black terminal next to the “Try It Now” remains blank while the cursor box zooms around it. No visible text is seen. iPhone XS Max, iOS 13 GM, Safari.
    - yoz 7y ago
      Also seeing it on an iPhone 8, iOS 12.4. The site is completely unusable/unreadable.
- anaphor 7y ago
  One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of Least Authority). I know this is possible with Docker, but it's not really done much in practice because of various difficulties. I wonder how difficult it would be to do that with your tool?
alpb 7y ago
Nearly all points (daemon-less runtimes, daemon-less builds) the author has mentioned has been addressed by open source ecosystem in smaller standalone projects that are available. Docker provides a nice high-level layer for the end user on the developer machine. Its CLI is efficient, so are the builds when they're local, with a cache. I still use it on my dev machine despite being aware of the alternatives. Anyone security-aware company using containers in production most likely go with non-Docker approaches. Some notable examples include runc, Podman, Buildah, img, ko, Bazel/distroless.
- solipsism 7y ago
  Distroless is not non-Docker, it's very much Docker.
  - alpb 7y ago
    Please explain. You can build images using Bazel with distroless as the base image. Similarly I think Jib/ko use distroless images without needing a docker engine.
    - solipsism 7y ago
      The thing you build is a Docker image.
      - alpb 7y ago
        Technically an OCI image, and there’s nothing relevant that is mentioned in the original article in your argument, and you can run the resulting image without docker so I think at this point your argument sounds like random blabber, sorry.
      - pavon 7y ago
        It is an OCI image[1], which is supported by multiple runtimes, including docker. [1]https://www.opencontainers.org/ https://www.opencontainers.org/
zests 7y ago
I'm newer to the Docker scene but haven't really found any of the complaints in this article realized in my work. Faster speed would be nice but I don't really mind it now. I see a lot of complaints about the docker daemon and root privileges on HN and I've tried to understand where they are coming from but I can't get anywhere. For instance, I understand the reasoning behind "if there is no need for a daemon there shouldn't be a daemon" but I don't really understand what the actual/realized/tangible benefits of not having a daemon would be.
- roca 7y ago
  We have observed the daemon getting into a bad state and stopping responding to container create requests, wedging our production system. I guess this kind of bug could happen with a non-daemon approach if there's shared state, but it seems less likely. Not using any components with root privileges obviously makes things more secure. Another benefit of not requiring a daemon or privileges is that then it should be easy to manage fully independent sets of containers. In particular a container should be able to manage its own nested containers in a straightforward way. This is painful in Docker.
- wokwokwok 7y ago
  It would be faster. I also don’t really care if a container take 2 seconds or 100ms to start... but building docker images is painfully slow. I’ve also ended up (numerous times) with the “docker daemon is borked” situation, which requires a restart to fix... and you can imagine how that sucks on a prod or multi tenant systems.
  - roca 7y ago
    One reason we care about containers taking seconds to start is that our CI tests have to start and stop a lot of containers, and it all adds up. And running them in parallel wouldn't help because they would just bottleneck on the global docker daemon... or break entirely by interfering with each other, unless we run multiple Docker-in-Docker setups, which would be even more painful and add its own overhead.
  - krferriter 7y ago
deleted 7y ago
[deleted]
aledalgrande 7y ago
These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster. https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...
- thosakwe 7y ago
  I have no idea how, but Docker for Mac was taking up a whopping 65GB of space in one of the cache folders in ~/Library, although I had uninstalled it months ago. I wish I had taken a screenshot, but I was honestly dumbfounded. I had used it maybe once, ever. EDIT: It turns out I’m not making this up/an edge case, at least 940 people have run into this too: https://github.com/docker/for-mac/issues/371 https://github.com/docker/for-mac/issues/371
  - etimberg 7y ago
    I have that problem too. Solution seemed to be to set up an alias to clean out old images, volumes, etc and run that every so often
    - mirimir 7y ago
      Not just in MacOS. Over time, Docker can eat all your storage.
      - jdnenej 7y ago
        Because it keeps around all of the images you use as well as the containers after they are stopped so you can resume them. there is a command that auto automatically removes all unused images and containers you can use.
        mirimir 7y ago
        True. But there are situations where things get ~corrupted, and it becomes ~impossible to recover without basically nuking everything. But then, I was running containers with resource limits and long-term storage. So I could have thousands of lightweight "VMs" per physical server.
atarian 7y ago
I just want to be able to save a container binary to a USB drive and then run it from a different computer without having to install anything.
- lytedev 7y ago
  There are a number of ways to get this kind of functionality. Can you expound on "different computer"?
  - juandazapata 7y ago
    What part of "different computer" is confusing to you?
    - fwip 7y ago
      How different, for one. Are they running the same OS? The same architecture? Do they have any software installed?
- TheChaplain 7y ago
  I believe that already exist and is called "AppImage".
- astockwell 7y ago
  The first time I emailed a buddy a Go cross-compiled binary and he opened and it ran no problem (opsec aside), our worlds changed.
  - atarian 7y ago
    This is exactly how I'd like containers to be as well.
- m_sahaf 7y ago
  You're looking for binctr: https://github.com/genuinetools/binctr https://github.com/genuinetools/binctr
est 7y ago
All I want is a process that can be frozen and copied to multiple servers. start/stop is merely a state change.
- lytedev 7y ago
  This is interesting... May I ask why this is an important feature to you?
  - est 7y ago
    If you think about it most "Service", web or rpc, can be scaled in this way.
- blacksqr 7y ago
  DMTCP (Distributed MultiThreaded Checkpointing) http://dmtcp.sourceforge.net/ http://dmtcp.sourceforge.net/
- ethagnawl 7y ago
  This sounds a lot like the Smalltalk VM.
- ehotinger 7y ago
  That's quite an oversimplification of the problem, copying stack/heap/etc. Anyways, check out CRIU as a starting point.
  - e12e 7y ago
    (and note that lxd/lxc allows migration based on it. Not sure about copying - I suspect you run into similar issues as fork - who owns the open file handles and other resources?)
- soraminazuki 7y ago
  You’d be much better off using a VM if you want snapshots. Process snapshots requires that you can: 1. extract all kernel state related to the target process 2. replicate the state on another machine Both of these are extremely complicated problems. The first problem is difficult because it’s nearly impossible to isolate all relevant state in the kernel. Process state is closely intertwined with the entire kernel state, making it all too easy to produce an incomplete snapshot that can break the system in all sorts of ways. Worse, things would get more complicated if multiple processes are involved. The second problem is just as hard if you consider external dependencies or different kernel versions. It might simply be impossible to recreate the process even if you did succeed in creating the perfect snapshot. Process snapshots are simply not worth the trouble.
CruzeDon 7y ago
It's absolute trash
djsumdog 7y ago
These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro and it would be easier to check for outdated packages and security issues in containers. The cgroups and Linux specific hooks keep Docker from being implemented natively anywhere else. The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. I did a similar writeup about the things I hate about container orchestration systems: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...
- krferriter 7y ago
  We were using Docker-in-Docker in our cluster to run user-defined containers, and something about it resulted in the outer container disk usage blowing up to like 20GiB per container. I think something due to the overlay filesystem driver. We were under a time constraint so we just grew all the host root filesystems, but it was pretty inconvenient and not inexpensive to do so. I have to assume this also had a drastic negative impact on storage I/O performance in the inner container as well.
  - geggam 7y ago
    Docker in Docker feels like a root kit generator to me
- imiric 7y ago
  > The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Docker much easier to manage, avoids the security issues of sharing the Unix socket, and works remotely of course. [1]: https://docs.docker.com/engine/security/https/ https://docs.docker.com/engine/security/https/
devmunchies 7y ago
Do BSD jails solve these problems? The little i know of them, they are good at containerization but don't solve the distribution problem that docker containers do.
nickjj 7y ago
I've been using Docker since 2015ish and the container start up / stop speed is really the only thing that bugs me. Everything else is fine for day to day usage IMO (on Windows and Linux at least) and very much worth the trade offs, but having to wait multiple seconds for your app to start is tedious since it plays such a heavy role in both development and even in production. Each second your app is not running is downtime, assuming you're not load balanced. I opened an issue for this almost a year ago but not too much has come from it other than identifying there was maybe a regression in recent'ish versions: https://github.com/moby/moby/issues/38077 https://github.com/moby/moby/issues/38077 We're talking multiple seconds in Docker vs ~150ms as a regular process to start up a typical web app process like gunicorn in a decently sized Flask app (many thousands of lines of code, lots of dependencies -- a real world app).
- croo 7y ago
  Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(
  - xorcist 7y ago
    Starting the process probably isn't what's taking so long though.
    - oblio 7y ago
      You'd be surprised. Big Java enterprise apps deployed to Tomcat or God-forbid! IBM/Oracle app servers can take 2-3-5 minutes just to be fully operational. I've had deployment health checkers timeout after 2 minutes because the servers just wouldn't be up. It seems insane, but that's how life looks for thousands of developers.
      - nickjj 7y ago
        > It seems insane, but that's how life looks for thousands of developers. True, but there's tens of thousands of developers not using big Java enterprise apps where having Docker add 4-5-6+ seconds of startup time has a huge negative impact. gunicorn (Python) apps tend to start in hundreds of milliseconds (even pretty big ones). puma (Ruby) apps tend to start in seconds or tens of seconds (it can get higher for massive apps). cowboy (Elixir) apps tend to start in low seconds (this includes booting up the BEAM VM). Just the above 3 examples cover the Flask, Django, Rails and Phoenix ecosystem. That's a lot of developers.
aloknnikhil 7y ago
> In fact, a global system daemon should not be needed. Either users should be able to run their own daemons or container management should avoid having a daemon at all, by storing container state in a shared database. Absolutely love Podman. You can even define registries to work with docker hub, easily. https://podman.io https://podman.io
- nikisweeting 7y ago
  Yeah but no docker-compose support :/ dealbreaker for us. Theres an alpha podman-compose project but we couldn't get it running.
  - likeclockwork 7y ago
    You really don't need it since podman has pods of containers that communicate with each other. You can export and playback the pods as kubernetes yaml.. but I just use a bash script + an environment file to configure, create and launch pods. What else is docker-compose really doing for you?
    - nikisweeting 7y ago
      Our entire company runs on like ~20 docker-compose files. It's a super elegant way to describe collections of containers without the management overhead of Kubernetes. We've had nothing but good experiences with compose, and lots of headaches with Docker swarm and K8s.
  - dharmab 7y ago
    Both Podman and CRI-O support Pods, which can fill the same use case as docker-compose
    - nikisweeting 7y ago
      Which require kubernetes, which requires a full-time team member just to manage. Docker-compose has been a lifesaver for low-complexity declarative service management on our self-hosted systems.
ses1984 7y ago
There are two kinds of software: software no one uses, and software people complain about.
- notyourday 7y ago
  There's also software that was created to solve a specific problem that got misappropriated to do something else There used to be an ISP called pilot.net. It was a crappy ISP but to solve its ISP billing problem it wrote a billing system for telcos. There was a company that tried competing with AWS selling hosting based on hyperthreads of CPUs. It wrote its own provisioning system because it did not want to pay for Virtuozzo. The company's name used to be dotCloud.
  - otabdeveloper4 7y ago
    > There's also software that was created to solve a specific problem that got misappropriated to do something else Docker is a classic case. Docker must be the craziest, most over-engineered solution for packaging developer artifacts in the Universe.
    - majewsky 7y ago
      In the same way that Dropbox is the most over-engineered solution for file sharing, when all you need is an SVN-backed directory with curltmpfs. ;)
  - oblio 7y ago
    What's the link between pilot.net and dotCloud? Did dotCloud use the billing system from pilot.net?
- draw_down 7y ago
  Mmm, very clever.
  - deleted 7y ago
    [deleted]
bob1029 7y ago
What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your application runtime environment up and then getting the application running as a persistent service with reasonable defaults. Most cloud vendors let you put something like that in your VM startup configuration. All you would need from this point is to ensure that any sort of desired management functions are built into the app itself. Perhaps having a central management service it communicates with across the public internet would be a good place to start. You don't need a lot of tooling to make a huge impact here. If you own the codebase behind it, and have a fundamental understanding of your deployment techniques, you can easily pivot and embrace radical new approaches. If you are stuck on Docker, this doesn't seem as optimistic from where I am standing.
- roca 7y ago
  Off the top of my head: two things in our (OP) case: 1) Memory overhead 2) Slow access to filesystem storage shared between containers
- lacampbell 7y ago
  This is what I ended up doing. Don't laugh, but I spent about two weekends furiously learning docker for a side project, only to replace it with a shell script of about 100 lines. I'm sure containers have valid use cases for larger teams, but for one person I didn't see the point at all - especially as I use the same OS for dev and production.
  - samvher 7y ago
    Docker is not only about having reproducible environments. I mostly work as a single developer and I use Docker all the time, mainly because I like the isolation properties and because it's super easy to launch certain services (e.g. set up a postgres database). In the past really often I would have issues with conflicting dependencies, that's all gone now. The fact that your shell script did the job for you is obviously a good thing, but maybe that just means that in this particular situation Docker didn't have much to offer for you.
broknbottle 7y ago
switch to podman? https://podman.io/ https://podman.io/
- nikisweeting 7y ago
  No docker-compose suppport.
  - ptman 7y ago
    https://github.com/containers/podman-compose https://github.com/containers/podman-compose
    - nikisweeting 7y ago
      I know, but have you actually tried using it though? It's not going to be a viable production-grade docker-compose replacement for quite a while unless they get some serious funding or open-source attention.
- k__ 7y ago
  I saw it can be used as a drop-in replacement. Does podman have better startup performance than docker? Using a docker to debug and it is a bit of a pain.
neckardt 7y ago
I'm surprised nobody is mentioning LXC[1]. I'm by no means a containers expert, but they claim to be more secure since they default to running as non-root. Unlike docker, I had no trouble installing LXC with apt, while with docker I often got an outdated version. I'm now using LXC for all of my basic container applications (self hosting a wiki and a few other sites). [1]: https://linuxcontainers.org/ https://linuxcontainers.org/
- judge2020 7y ago
  Docker isn't up to date on the official Ubuntu (and debian too?) repos for some odd reason. A better way is either snap (snapcraft) or adding docker's own apt repository.
  - FreeHugs 7y ago
    Aren't those images provided by Ubuntu and Debian? Then it would not be under the control of Docker which versions are provided. docker.io provides Debian 10 as far as I can tell.
  - e12e 7y ago
    Docker (the daemon and tooling) is generally upstream-supplied (ie: docker provides apt repos etc). Not uncommon for rapidly moving upstream. I wouldn't recommend running distro-supplied docker in general (and neither do docker). Curated apt repos is nicer than snaps, IMNHO.
  - fiatjaf 7y ago
    snap never works.
- dbleyl 7y ago
  lxc is awesome, wondering the same thing. Also has some niches in the kubernetes space. Using lxc for development DBs and private servers.
- dvfjsdhgfv 7y ago
  Because LXC has no marketing money like Docker. For me it's just one of these cool tools I use every day without giving it a second thought.
notyourday 7y ago
Have you heard of this amazing thing called "a VM"? It is like docker but when you pee at the wall it always splashes back right at you so you quickly learn that you never want to pee at the wall.
jbergknoff 7y ago
It's interesting to see the complaint about containers starting too slowly. I haven't seen much discussion about it before this article and this comment thread, but it's one of my biggest pain points with Docker. I know we can save some time by skipping some namespaces (e.g. `--net host`) but I've still never been able to get satisfyingly fast container execution in that way. (e.g. `time echo` -> 0.000s, `time docker run --rm alpine echo` -> 1.3s; come to think of it, this is even slower than it used to be) Still, Docker is the best method that I've seen for distributing software, especially cross-platform. Not just for shipping a containerized web app to production, but also running dev tools (e.g. linters, compilers) and other desktop and CLI applications. I know some people run lots of stuff in containers (https://github.com/jessfraz/dockerfiles https://github.com/jessfraz/dockerfiles, probably the most prolific), but I think this is a largely underappreciated facet of Docker. My team at work is heavily Mac while I'm on Linux. The dev workflows are identical on my machine, on their machines, and in Jenkins. Nobody has to have a snowflake setup, installing this or that version of Python, we're all just `docker run`ning the same image. It's great. Unfortunately, Docker for Mac's IO performance is abysmal. If past performance is any indication of future results, that's never going to change. I'm constantly on the lookout for other ways to share tools cross-platform that don't involve Docker. Things like podman and binctr are exciting, and I've played with them, but I don't see them filling this niche.
anordal 7y ago
... then I suppose Selfdock is for you. * Does not give or require root. * Fast: Does not write to disk. * Fast: Does not allocate memory. * No daemon. https://github.com/anordal/selfdock https://github.com/anordal/selfdock
- aequitas 7y ago
  > Give up the idea of data volume containers. Given that volumes are the way to go, no other filesystems in the container need to, or should be, writable. Interesting philosophy, it will pose some issues when replicating a Docker 'build' like system though. But that could be separated from the 'run' system with cached layers. edit: Btw, Docker also seems to support this: https://nickjanetakis.com/blog/docker-tip-55-creating-read-only-containers https://nickjanetakis.com/blog/docker-tip-55-creating-read-o.... Also allowing explicit creation of writable tmpfs mountpoints.
- k__ 7y ago
  I read podman can be simply aliased to docker and it works. Is this the case for selfdock too?
KaiserPro 7y ago
A few things that I would add to that list: o No primitives to deal with secrets. o Terrible disk handling (aufs was just horrid, overlay2 I think misses the point. device mapper is just, silly) o poor speed when downloading and uncompressing images. Of all of them, the most serious is the lack of secrets handling. Basically you have to use environment variables. Yes, you can use docker compose and stuff appears, but thats only useful if you use compose/swarm. In this day and age, to have secrets as a very distant afterthought is pretty unforgivable.
- antocv 7y ago
  What do you consider a secret? What other system do you recommend which has the feature you want? I cant see how one would inject data into a process without ptracing/gdb-attaching to it, messing with its internal memory, or just use environment variables or argument list. If you put it on a file somewhere, you still have to tell the process where the file is by an argument or env and also manage that "volume" and uid space of that file and process. Kubernetes secrets have nothing to do with containers - it anyway usually exposes the secret as env var or volume and file.
  - heyoni 7y ago
    I smell potential for a fun tutorial with that last part!
  - KaiserPro 7y ago
    A secret is anything that you don't want to be public. normally API keys, or some other similar token. Its not even a case of stopping people attaching a debugger, there is simply not standard mechanism. Some sort of secret store should be a primitive in any container/VM/unikernel built since 2012. The "recommended" way is to map a volume in to a container. But thats rubbish, there is no standard place to put it, and crucially no API to fill the volume full of secrets. How do I map the specific volume to a container? you can't its manual. what would be nice is either a tagged value store, so you can specify a tag when you build a container, so that you have a way to signal which secrets your container wants. Or a lump of the container that you can encrypt, that has a key value store in it. There are lots of documents telling you that you _shouldn't_ embed secrets in your container, but there are not many howtos that don't involve the engineering equivalent of gaffer tape and wet string. Most of this has now been solved by better[] orchestration systems. [] not great though.
tigroferoce 7y ago
Beside technical considerations, the main point of Docker, to me, is its diffusion. Just like the actual physical containers it gets inspiration from, you can find Docker almost everywhere. It has become a Lingua Franca for devops, even in enterprise environments, and it will be very difficult to get rid of it.
peterwwillis 7y ago
Containers Without Docker: https://dzone.com/articles/containers-with-out-docker https://dzone.com/articles/containers-with-out-docker Dockerless: https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-replace-docker-with-and-why https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-r... https://dzone.com/articles/dockerless-part-1-which-tools-to-replace-docker-wi https://dzone.com/articles/dockerless-part-1-which-tools-to-... What's funny is, Docker is only actually useful because of how many features it has, all its supported platforms, all its bloat. You won't ever be totally satisfied with any alternative because it takes so long to make something like Docker, and someone will always need that one extra feature.
mschuster91 7y ago
> In fact, a global system daemon should not be needed. You will need a daemon running as root to bind to ports below 1024. In addition, in many cases you want a bind-mount onto your filesystem that also supports arbitrary UID/GID on files, which means you will need a root daemon. The problem is of course that anyone having access to the docker daemon can simply say "bind host / to container /mnt" and then can hijack /etc/sudoers for a privilege escalation on the host. It's mutually exclusive to have usable containers and a system that is secure against privilege escalation by the users at least and (in case of docker-in-docker implemented by bind-mounting the Docker socket in the container) by anyone accessing the container and achieving RCE there.
rotten 7y ago
I'd like it to be more like git. Yes Docker has "push" and "pull", but I want branches, and automatic attach when I do a checkout, and rollback when I screw it up. As a developer I'd like to be able to check out a docker image, work _in_ it, and merge it to master when I'm done. When my code is deployed, I'll know _exactly_ what is running. Managing secrets and environments (so the container knows when it is in production instead of running on a developer's laptop) is important to get this to work well. It feels like it is half way there already. I'm looking forward to when it is as straightforward as git for a developer to use. I'm not too worried about start up time - the biggest drawback to slow startup time is when you are running very sensitive autoscaling that is tearing down and spinning up new nodes very quickly. If you have that problem you may want to rethink your node size, hysteresis, and scaling thresholds.
bokieie 7y ago
We tried to use LXC directly and realized that Docker simply does it all for us, and better.

226 points by khuey 7y ago

I am currently on this train. Having used rkt in the past, I went to revisit it recently only to find this: https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-project/ https://www.cncf.io/blog/2019/08/16/cncf-archives-the-rkt-pr... I am so extremely disappointed in the CNCF as rkt (at the time, at least) seemed to be more "production ready" than Docker. Are there any real alternatives? Is the answer "find something else that uses containerd in a more friendly way?" Is the answer "try to use podman/buildah, which are weird in their own way?"

roca 7y ago
Podman looks interesting at a quick glance, though not supporting docker-compose makes migrating nontrivial for us.
- devmunchies 7y ago
  and my attempt to get it run on mac were fruitless. I would have to do it in a Vagrant VM like 5 years ago.
- 3131s 7y ago
  It was discussed recently in the podman Github issues that this functionality will be covered by the separately maintained podman-compose, which was recently transferred here: https://github.com/containers/podman-compose https://github.com/containers/podman-compose
l_t 7y ago
Maybe containerd [0] is an alternative? It's being used in k3s instead of Docker. [0]: https://containerd.io/ https://containerd.io/ edit: I didn't notice that you mentioned this in your comment, my bad. Can you explain why it doesn't work for you? I'm new to the Docker-alternative scene and thought it looked pretty good at first glance.
- chucky_z 7y ago
  Docker uses containerd. Here's an image straight from a blog post from last year: https://i1.wp.com/blog.docker.com/wp-content/uploads/2018/09/docker-engine-blog.jpg?resize=631%2C522&ssl=1 https://i1.wp.com/blog.docker.com/wp-content/uploads/2018/09... https://blog.docker.com/2018/09/join-the-beta-for-docker-engine-18-09/ https://blog.docker.com/2018/09/join-the-beta-for-docker-eng...
  - xyzzy_plugh 7y ago
    It does and it doesn't. The interface is pretty different. Using containerd directly as a binary is pretty rough around the edges, but docker uses it as a library. In particular the CRI implementation works, but leaves a lot to be desired. Their release cycle is also pretty lengthy, such that each minor release has a ton of changes, resulting in a lot of work to integrate into your infra.
angry_octet 7y ago
Wasn't that because RedHat bought CoreOS, and RH is all k8s? And then no one was pushing rkt along with commercial support, so it died? Agree the rkt was cool. I just don't know if RH is becoming more like MSFT or more like Oracle.
- bionsystem 7y ago
  More like IBM it seems :)
dharmab 7y ago
We're implementing CRI-O so we can use Docker and Kata Containers side by side for different workloads. We're hoping if things go well we can fully migrate off Docker after a few years of transition, but it's in early stages.

syrusakbary 7y ago

The article is completely on point. Because of all the reasons exposed there (and a few more) I started Wasmer, a new container system based on WebAssembly - https://wasmer.io/ https://wasmer.io/ Here are some advantages of Wasmer vs Docker: * Much faster startup time * Smaller containers * OS independent containers (they can run in Linux, macOS and Windows) * Chipset independent containers (so they can run anywhere: x86_64, Aarch64/ARM, RISC-V)

scanr 7y ago
Wasmer looks interesting. I couldn’t read much as I get an “unexpected error” as soon as I start scrolling. It does say that it’s not optimised for mobile.
- syrusakbary 7y ago
  Thanks for reporting it! We will investigate and try to fix it ASAP :) PS: if you could provide your device info (os and browser) it would be awesome
  - jackalo 7y ago
    The black terminal next to the “Try It Now” remains blank while the cursor box zooms around it. No visible text is seen. iPhone XS Max, iOS 13 GM, Safari.
  - yoz 7y ago
    Also seeing it on an iPhone 8, iOS 12.4. The site is completely unusable/unreadable.
anaphor 7y ago
One thing I also find sorely lacking in Docker is the ability to run your containers with the appropriate seccomp privileges (in order to enforce Principle of Least Authority). I know this is possible with Docker, but it's not really done much in practice because of various difficulties. I wonder how difficult it would be to do that with your tool?

alpb 7y ago

Nearly all points (daemon-less runtimes, daemon-less builds) the author has mentioned has been addressed by open source ecosystem in smaller standalone projects that are available. Docker provides a nice high-level layer for the end user on the developer machine. Its CLI is efficient, so are the builds when they're local, with a cache. I still use it on my dev machine despite being aware of the alternatives. Anyone security-aware company using containers in production most likely go with non-Docker approaches. Some notable examples include runc, Podman, Buildah, img, ko, Bazel/distroless.

solipsism 7y ago
Distroless is not non-Docker, it's very much Docker.
- alpb 7y ago
  Please explain. You can build images using Bazel with distroless as the base image. Similarly I think Jib/ko use distroless images without needing a docker engine.
  - solipsism 7y ago
    The thing you build is a Docker image.
    - alpb 7y ago
      Technically an OCI image, and there’s nothing relevant that is mentioned in the original article in your argument, and you can run the resulting image without docker so I think at this point your argument sounds like random blabber, sorry.
    - pavon 7y ago
      It is an OCI image[1], which is supported by multiple runtimes, including docker. [1]https://www.opencontainers.org/ https://www.opencontainers.org/

zests 7y ago

I'm newer to the Docker scene but haven't really found any of the complaints in this article realized in my work. Faster speed would be nice but I don't really mind it now. I see a lot of complaints about the docker daemon and root privileges on HN and I've tried to understand where they are coming from but I can't get anywhere. For instance, I understand the reasoning behind "if there is no need for a daemon there shouldn't be a daemon" but I don't really understand what the actual/realized/tangible benefits of not having a daemon would be.

roca 7y ago
We have observed the daemon getting into a bad state and stopping responding to container create requests, wedging our production system. I guess this kind of bug could happen with a non-daemon approach if there's shared state, but it seems less likely. Not using any components with root privileges obviously makes things more secure. Another benefit of not requiring a daemon or privileges is that then it should be easy to manage fully independent sets of containers. In particular a container should be able to manage its own nested containers in a straightforward way. This is painful in Docker.
wokwokwok 7y ago
It would be faster. I also don’t really care if a container take 2 seconds or 100ms to start... but building docker images is painfully slow. I’ve also ended up (numerous times) with the “docker daemon is borked” situation, which requires a restart to fix... and you can imagine how that sucks on a prod or multi tenant systems.
- roca 7y ago
  One reason we care about containers taking seconds to start is that our CI tests have to start and stop a lot of containers, and it all adds up. And running them in parallel wouldn't help because they would just bottleneck on the global docker daemon... or break entirely by interfering with each other, unless we run multiple Docker-in-Docker setups, which would be even more painful and add its own overhead.
- krferriter 7y ago

deleted 7y ago

[deleted]

aledalgrande 7y ago

These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster. https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...

thosakwe 7y ago
I have no idea how, but Docker for Mac was taking up a whopping 65GB of space in one of the cache folders in ~/Library, although I had uninstalled it months ago. I wish I had taken a screenshot, but I was honestly dumbfounded. I had used it maybe once, ever. EDIT: It turns out I’m not making this up/an edge case, at least 940 people have run into this too: https://github.com/docker/for-mac/issues/371 https://github.com/docker/for-mac/issues/371
- etimberg 7y ago
  I have that problem too. Solution seemed to be to set up an alias to clean out old images, volumes, etc and run that every so often
  - mirimir 7y ago
    Not just in MacOS. Over time, Docker can eat all your storage.
    - jdnenej 7y ago
      Because it keeps around all of the images you use as well as the containers after they are stopped so you can resume them. there is a command that auto automatically removes all unused images and containers you can use.
      - mirimir 7y ago
        True. But there are situations where things get ~corrupted, and it becomes ~impossible to recover without basically nuking everything. But then, I was running containers with resource limits and long-term storage. So I could have thousands of lightweight "VMs" per physical server.

atarian 7y ago

I just want to be able to save a container binary to a USB drive and then run it from a different computer without having to install anything.

lytedev 7y ago
There are a number of ways to get this kind of functionality. Can you expound on "different computer"?
- juandazapata 7y ago
  What part of "different computer" is confusing to you?
  - fwip 7y ago
    How different, for one. Are they running the same OS? The same architecture? Do they have any software installed?
TheChaplain 7y ago
I believe that already exist and is called "AppImage".
astockwell 7y ago
The first time I emailed a buddy a Go cross-compiled binary and he opened and it ran no problem (opsec aside), our worlds changed.
- atarian 7y ago
  This is exactly how I'd like containers to be as well.
m_sahaf 7y ago
You're looking for binctr: https://github.com/genuinetools/binctr https://github.com/genuinetools/binctr

est 7y ago

All I want is a process that can be frozen and copied to multiple servers. start/stop is merely a state change.

lytedev 7y ago
This is interesting... May I ask why this is an important feature to you?
- est 7y ago
  If you think about it most "Service", web or rpc, can be scaled in this way.
blacksqr 7y ago
DMTCP (Distributed MultiThreaded Checkpointing) http://dmtcp.sourceforge.net/ http://dmtcp.sourceforge.net/
ethagnawl 7y ago
This sounds a lot like the Smalltalk VM.
ehotinger 7y ago
That's quite an oversimplification of the problem, copying stack/heap/etc. Anyways, check out CRIU as a starting point.
- e12e 7y ago
  (and note that lxd/lxc allows migration based on it. Not sure about copying - I suspect you run into similar issues as fork - who owns the open file handles and other resources?)
soraminazuki 7y ago
You’d be much better off using a VM if you want snapshots. Process snapshots requires that you can: 1. extract all kernel state related to the target process 2. replicate the state on another machine Both of these are extremely complicated problems. The first problem is difficult because it’s nearly impossible to isolate all relevant state in the kernel. Process state is closely intertwined with the entire kernel state, making it all too easy to produce an incomplete snapshot that can break the system in all sorts of ways. Worse, things would get more complicated if multiple processes are involved. The second problem is just as hard if you consider external dependencies or different kernel versions. It might simply be impossible to recreate the process even if you did succeed in creating the perfect snapshot. Process snapshots are simply not worth the trouble.

CruzeDon 7y ago

It's absolute trash

djsumdog 7y ago

These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro and it would be easier to check for outdated packages and security issues in containers. The cgroups and Linux specific hooks keep Docker from being implemented natively anywhere else. The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. I did a similar writeup about the things I hate about container orchestration systems: https://penguindreams.org/blog/my-love-hate-relationship-with-docker-and-container-orchestration-systems/ https://penguindreams.org/blog/my-love-hate-relationship-wit...

krferriter 7y ago
We were using Docker-in-Docker in our cluster to run user-defined containers, and something about it resulted in the outer container disk usage blowing up to like 20GiB per container. I think something due to the overlay filesystem driver. We were under a time constraint so we just grew all the host root filesystems, but it was pretty inconvenient and not inexpensive to do so. I have to assume this also had a drastic negative impact on storage I/O performance in the inner container as well.
- geggam 7y ago
  Docker in Docker feels like a root kit generator to me
imiric 7y ago
> The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Docker much easier to manage, avoids the security issues of sharing the Unix socket, and works remotely of course. [1]: https://docs.docker.com/engine/security/https/ https://docs.docker.com/engine/security/https/

devmunchies 7y ago

Do BSD jails solve these problems? The little i know of them, they are good at containerization but don't solve the distribution problem that docker containers do.

nickjj 7y ago

I've been using Docker since 2015ish and the container start up / stop speed is really the only thing that bugs me. Everything else is fine for day to day usage IMO (on Windows and Linux at least) and very much worth the trade offs, but having to wait multiple seconds for your app to start is tedious since it plays such a heavy role in both development and even in production. Each second your app is not running is downtime, assuming you're not load balanced. I opened an issue for this almost a year ago but not too much has come from it other than identifying there was maybe a regression in recent'ish versions: https://github.com/moby/moby/issues/38077 https://github.com/moby/moby/issues/38077 We're talking multiple seconds in Docker vs ~150ms as a regular process to start up a typical web app process like gunicorn in a decently sized Flask app (many thousands of lines of code, lots of dependencies -- a real world app).

croo 7y ago
Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(
- xorcist 7y ago
  Starting the process probably isn't what's taking so long though.
  - oblio 7y ago
    You'd be surprised. Big Java enterprise apps deployed to Tomcat or God-forbid! IBM/Oracle app servers can take 2-3-5 minutes just to be fully operational. I've had deployment health checkers timeout after 2 minutes because the servers just wouldn't be up. It seems insane, but that's how life looks for thousands of developers.
    - nickjj 7y ago
      > It seems insane, but that's how life looks for thousands of developers. True, but there's tens of thousands of developers not using big Java enterprise apps where having Docker add 4-5-6+ seconds of startup time has a huge negative impact. gunicorn (Python) apps tend to start in hundreds of milliseconds (even pretty big ones). puma (Ruby) apps tend to start in seconds or tens of seconds (it can get higher for massive apps). cowboy (Elixir) apps tend to start in low seconds (this includes booting up the BEAM VM). Just the above 3 examples cover the Flask, Django, Rails and Phoenix ecosystem. That's a lot of developers.

aloknnikhil 7y ago

> In fact, a global system daemon should not be needed. Either users should be able to run their own daemons or container management should avoid having a daemon at all, by storing container state in a shared database. Absolutely love Podman. You can even define registries to work with docker hub, easily. https://podman.io https://podman.io

nikisweeting 7y ago
Yeah but no docker-compose support :/ dealbreaker for us. Theres an alpha podman-compose project but we couldn't get it running.
- likeclockwork 7y ago
  You really don't need it since podman has pods of containers that communicate with each other. You can export and playback the pods as kubernetes yaml.. but I just use a bash script + an environment file to configure, create and launch pods. What else is docker-compose really doing for you?
  - nikisweeting 7y ago
    Our entire company runs on like ~20 docker-compose files. It's a super elegant way to describe collections of containers without the management overhead of Kubernetes. We've had nothing but good experiences with compose, and lots of headaches with Docker swarm and K8s.
- dharmab 7y ago
  Both Podman and CRI-O support Pods, which can fill the same use case as docker-compose
  - nikisweeting 7y ago
    Which require kubernetes, which requires a full-time team member just to manage. Docker-compose has been a lifesaver for low-complexity declarative service management on our self-hosted systems.

ses1984 7y ago

There are two kinds of software: software no one uses, and software people complain about.

notyourday 7y ago
There's also software that was created to solve a specific problem that got misappropriated to do something else There used to be an ISP called pilot.net. It was a crappy ISP but to solve its ISP billing problem it wrote a billing system for telcos. There was a company that tried competing with AWS selling hosting based on hyperthreads of CPUs. It wrote its own provisioning system because it did not want to pay for Virtuozzo. The company's name used to be dotCloud.
- otabdeveloper4 7y ago
  > There's also software that was created to solve a specific problem that got misappropriated to do something else Docker is a classic case. Docker must be the craziest, most over-engineered solution for packaging developer artifacts in the Universe.
  - majewsky 7y ago
    In the same way that Dropbox is the most over-engineered solution for file sharing, when all you need is an SVN-backed directory with curltmpfs. ;)
- oblio 7y ago
  What's the link between pilot.net and dotCloud? Did dotCloud use the billing system from pilot.net?
draw_down 7y ago
Mmm, very clever.
- deleted 7y ago
  [deleted]

bob1029 7y ago

What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your application runtime environment up and then getting the application running as a persistent service with reasonable defaults. Most cloud vendors let you put something like that in your VM startup configuration. All you would need from this point is to ensure that any sort of desired management functions are built into the app itself. Perhaps having a central management service it communicates with across the public internet would be a good place to start. You don't need a lot of tooling to make a huge impact here. If you own the codebase behind it, and have a fundamental understanding of your deployment techniques, you can easily pivot and embrace radical new approaches. If you are stuck on Docker, this doesn't seem as optimistic from where I am standing.

roca 7y ago
Off the top of my head: two things in our (OP) case: 1) Memory overhead 2) Slow access to filesystem storage shared between containers
lacampbell 7y ago
This is what I ended up doing. Don't laugh, but I spent about two weekends furiously learning docker for a side project, only to replace it with a shell script of about 100 lines. I'm sure containers have valid use cases for larger teams, but for one person I didn't see the point at all - especially as I use the same OS for dev and production.
- samvher 7y ago
  Docker is not only about having reproducible environments. I mostly work as a single developer and I use Docker all the time, mainly because I like the isolation properties and because it's super easy to launch certain services (e.g. set up a postgres database). In the past really often I would have issues with conflicting dependencies, that's all gone now. The fact that your shell script did the job for you is obviously a good thing, but maybe that just means that in this particular situation Docker didn't have much to offer for you.

broknbottle 7y ago

switch to podman? https://podman.io/ https://podman.io/

nikisweeting 7y ago
No docker-compose suppport.
- ptman 7y ago
  https://github.com/containers/podman-compose https://github.com/containers/podman-compose
  - nikisweeting 7y ago
    I know, but have you actually tried using it though? It's not going to be a viable production-grade docker-compose replacement for quite a while unless they get some serious funding or open-source attention.
k__ 7y ago
I saw it can be used as a drop-in replacement. Does podman have better startup performance than docker? Using a docker to debug and it is a bit of a pain.

neckardt 7y ago

I'm surprised nobody is mentioning LXC[1]. I'm by no means a containers expert, but they claim to be more secure since they default to running as non-root. Unlike docker, I had no trouble installing LXC with apt, while with docker I often got an outdated version. I'm now using LXC for all of my basic container applications (self hosting a wiki and a few other sites). [1]: https://linuxcontainers.org/ https://linuxcontainers.org/

judge2020 7y ago
Docker isn't up to date on the official Ubuntu (and debian too?) repos for some odd reason. A better way is either snap (snapcraft) or adding docker's own apt repository.
- FreeHugs 7y ago
  Aren't those images provided by Ubuntu and Debian? Then it would not be under the control of Docker which versions are provided. docker.io provides Debian 10 as far as I can tell.
- e12e 7y ago
  Docker (the daemon and tooling) is generally upstream-supplied (ie: docker provides apt repos etc). Not uncommon for rapidly moving upstream. I wouldn't recommend running distro-supplied docker in general (and neither do docker). Curated apt repos is nicer than snaps, IMNHO.
- fiatjaf 7y ago
  snap never works.
dbleyl 7y ago
lxc is awesome, wondering the same thing. Also has some niches in the kubernetes space. Using lxc for development DBs and private servers.
dvfjsdhgfv 7y ago
Because LXC has no marketing money like Docker. For me it's just one of these cool tools I use every day without giving it a second thought.

notyourday 7y ago

Have you heard of this amazing thing called "a VM"? It is like docker but when you pee at the wall it always splashes back right at you so you quickly learn that you never want to pee at the wall.

jbergknoff 7y ago

It's interesting to see the complaint about containers starting too slowly. I haven't seen much discussion about it before this article and this comment thread, but it's one of my biggest pain points with Docker. I know we can save some time by skipping some namespaces (e.g. `--net host`) but I've still never been able to get satisfyingly fast container execution in that way. (e.g. `time echo` -> 0.000s, `time docker run --rm alpine echo` -> 1.3s; come to think of it, this is even slower than it used to be) Still, Docker is the best method that I've seen for distributing software, especially cross-platform. Not just for shipping a containerized web app to production, but also running dev tools (e.g. linters, compilers) and other desktop and CLI applications. I know some people run lots of stuff in containers (https://github.com/jessfraz/dockerfiles https://github.com/jessfraz/dockerfiles, probably the most prolific), but I think this is a largely underappreciated facet of Docker. My team at work is heavily Mac while I'm on Linux. The dev workflows are identical on my machine, on their machines, and in Jenkins. Nobody has to have a snowflake setup, installing this or that version of Python, we're all just `docker run`ning the same image. It's great. Unfortunately, Docker for Mac's IO performance is abysmal. If past performance is any indication of future results, that's never going to change. I'm constantly on the lookout for other ways to share tools cross-platform that don't involve Docker. Things like podman and binctr are exciting, and I've played with them, but I don't see them filling this niche.

anordal 7y ago

... then I suppose Selfdock is for you. * Does not give or require root. * Fast: Does not write to disk. * Fast: Does not allocate memory. * No daemon. https://github.com/anordal/selfdock https://github.com/anordal/selfdock

aequitas 7y ago
> Give up the idea of data volume containers. Given that volumes are the way to go, no other filesystems in the container need to, or should be, writable. Interesting philosophy, it will pose some issues when replicating a Docker 'build' like system though. But that could be separated from the 'run' system with cached layers. edit: Btw, Docker also seems to support this: https://nickjanetakis.com/blog/docker-tip-55-creating-read-only-containers https://nickjanetakis.com/blog/docker-tip-55-creating-read-o.... Also allowing explicit creation of writable tmpfs mountpoints.
k__ 7y ago
I read podman can be simply aliased to docker and it works. Is this the case for selfdock too?

KaiserPro 7y ago

A few things that I would add to that list: o No primitives to deal with secrets. o Terrible disk handling (aufs was just horrid, overlay2 I think misses the point. device mapper is just, silly) o poor speed when downloading and uncompressing images. Of all of them, the most serious is the lack of secrets handling. Basically you have to use environment variables. Yes, you can use docker compose and stuff appears, but thats only useful if you use compose/swarm. In this day and age, to have secrets as a very distant afterthought is pretty unforgivable.

antocv 7y ago
What do you consider a secret? What other system do you recommend which has the feature you want? I cant see how one would inject data into a process without ptracing/gdb-attaching to it, messing with its internal memory, or just use environment variables or argument list. If you put it on a file somewhere, you still have to tell the process where the file is by an argument or env and also manage that "volume" and uid space of that file and process. Kubernetes secrets have nothing to do with containers - it anyway usually exposes the secret as env var or volume and file.
- heyoni 7y ago
  I smell potential for a fun tutorial with that last part!
- KaiserPro 7y ago
  A secret is anything that you don't want to be public. normally API keys, or some other similar token. Its not even a case of stopping people attaching a debugger, there is simply not standard mechanism. Some sort of secret store should be a primitive in any container/VM/unikernel built since 2012. The "recommended" way is to map a volume in to a container. But thats rubbish, there is no standard place to put it, and crucially no API to fill the volume full of secrets. How do I map the specific volume to a container? you can't its manual. what would be nice is either a tagged value store, so you can specify a tag when you build a container, so that you have a way to signal which secrets your container wants. Or a lump of the container that you can encrypt, that has a key value store in it. There are lots of documents telling you that you _shouldn't_ embed secrets in your container, but there are not many howtos that don't involve the engineering equivalent of gaffer tape and wet string. Most of this has now been solved by better[] orchestration systems. [] not great though.

tigroferoce 7y ago

Beside technical considerations, the main point of Docker, to me, is its diffusion. Just like the actual physical containers it gets inspiration from, you can find Docker almost everywhere. It has become a Lingua Franca for devops, even in enterprise environments, and it will be very difficult to get rid of it.

peterwwillis 7y ago

Containers Without Docker: https://dzone.com/articles/containers-with-out-docker https://dzone.com/articles/containers-with-out-docker Dockerless: https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-replace-docker-with-and-why https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-r... https://dzone.com/articles/dockerless-part-1-which-tools-to-replace-docker-wi https://dzone.com/articles/dockerless-part-1-which-tools-to-... What's funny is, Docker is only actually useful because of how many features it has, all its supported platforms, all its bloat. You won't ever be totally satisfied with any alternative because it takes so long to make something like Docker, and someone will always need that one extra feature.

mschuster91 7y ago

> In fact, a global system daemon should not be needed. You will need a daemon running as root to bind to ports below 1024. In addition, in many cases you want a bind-mount onto your filesystem that also supports arbitrary UID/GID on files, which means you will need a root daemon. The problem is of course that anyone having access to the docker daemon can simply say "bind host / to container /mnt" and then can hijack /etc/sudoers for a privilege escalation on the host. It's mutually exclusive to have usable containers and a system that is secure against privilege escalation by the users at least and (in case of docker-in-docker implemented by bind-mounting the Docker socket in the container) by anyone accessing the container and achieving RCE there.

rotten 7y ago

I'd like it to be more like git. Yes Docker has "push" and "pull", but I want branches, and automatic attach when I do a checkout, and rollback when I screw it up. As a developer I'd like to be able to check out a docker image, work _in_ it, and merge it to master when I'm done. When my code is deployed, I'll know _exactly_ what is running. Managing secrets and environments (so the container knows when it is in production instead of running on a developer's laptop) is important to get this to work well. It feels like it is half way there already. I'm looking forward to when it is as straightforward as git for a developer to use. I'm not too worried about start up time - the biggest drawback to slow startup time is when you are running very sensitive autoscaling that is tearing down and spinning up new nodes very quickly. If you have that problem you may want to rethink your node size, hysteresis, and scaling thresholds.

bokieie 7y ago

We tried to use LXC directly and realized that Docker simply does it all for us, and better.