5 ms·

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

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.
xorcist 7y ago
The most basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state is tricky. Requiring daemon access to build images is insane. Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.
- Smithalicious 7y ago
  Yeah Docker should get with the times and be assimilated into systemd like everything else
  - Nullabillity 7y ago
    Seems to be on its way! systemd-nspawn (the container subsystem) seems to have support for OCI images since march.[0] [0]: https://github.com/systemd/systemd/pull/9762/files https://github.com/systemd/systemd/pull/9762/files
  - oblio 7y ago
    You could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.
    - ahartmetz 7y ago
      I see them as souped-down virtual machines or the new vServers but with a decent interface. vServers (a bunch of hacks to separate users as if running different Linux instances) were pretty awful.
    - CameronNemo 7y ago
      I disagree. I would prefer to have a model where the supervisor needs no knowledge of the LSM profile, namespaces, seccomp profile, or cgroups applied to a service. Additionaly, I would prefer a non-init service supervisor.
- ahartmetz 7y ago
paulddraper 7y ago
> the most serious is the lack of secrets handling. Basically you have to use environment variables. That's how I always handle my secrets. (12 factor app) Am I missing a better way?
- fhgsfkcc 7y ago
  secrets don't belong in env vars, because many languages and/or frameworks will happily dump all your env vars to users in the event of misconfiguration or some errors.
  - paulddraper 7y ago
    I have literally never seen that happen. (Outside a core dump, which has a lot more than env var.) You have any examples in mind?
    - ygjb 7y ago
      It happens all the time, especially in security and quality assurance testing. It's less common in modern versions of tools and frameworks, but I routinely encounter these kinds of dumps when I am doing security testing work on anything enterprisey.
    - nikisweeting 7y ago
      Django error pages with DEBUG=True.
e12e 7y ago
I don't think you're wrong - but you might want to look at docker swarm over compose (even on single nodes) and: https://docs.docker.com/engine/swarm/secrets/ https://docs.docker.com/engine/swarm/secrets/ (as well as the sibling "config")

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.

xorcist 7y ago

The most basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state is tricky. Requiring daemon access to build images is insane. Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.

Smithalicious 7y ago
Yeah Docker should get with the times and be assimilated into systemd like everything else
- Nullabillity 7y ago
  Seems to be on its way! systemd-nspawn (the container subsystem) seems to have support for OCI images since march.[0] [0]: https://github.com/systemd/systemd/pull/9762/files https://github.com/systemd/systemd/pull/9762/files
- oblio 7y ago
  You could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.
  - ahartmetz 7y ago
    I see them as souped-down virtual machines or the new vServers but with a decent interface. vServers (a bunch of hacks to separate users as if running different Linux instances) were pretty awful.
  - CameronNemo 7y ago
    I disagree. I would prefer to have a model where the supervisor needs no knowledge of the LSM profile, namespaces, seccomp profile, or cgroups applied to a service. Additionaly, I would prefer a non-init service supervisor.
ahartmetz 7y ago

paulddraper 7y ago

> the most serious is the lack of secrets handling. Basically you have to use environment variables. That's how I always handle my secrets. (12 factor app) Am I missing a better way?

fhgsfkcc 7y ago
secrets don't belong in env vars, because many languages and/or frameworks will happily dump all your env vars to users in the event of misconfiguration or some errors.
- paulddraper 7y ago
  I have literally never seen that happen. (Outside a core dump, which has a lot more than env var.) You have any examples in mind?
  - ygjb 7y ago
    It happens all the time, especially in security and quality assurance testing. It's less common in modern versions of tools and frameworks, but I routinely encounter these kinds of dumps when I am doing security testing work on anything enterprisey.
  - nikisweeting 7y ago
    Django error pages with DEBUG=True.

e12e 7y ago

I don't think you're wrong - but you might want to look at docker swarm over compose (even on single nodes) and: https://docs.docker.com/engine/swarm/secrets/ https://docs.docker.com/engine/swarm/secrets/ (as well as the sibling "config")