11 ms·

Docker 1.5: IPv6 support, read-only containers, stats, and more

212 points by mohamedbassem 12y ago

ubercow 12y ago
>Specify the Dockerfile to use in build oh man it's finally here. I'm excited.
- greatabel 12y ago
  I feel the same way: first time I used docker when I found I can't specify file to use, I feel inconceivable.
- girvo 12y ago
  Finally! I can finally use one Dockerfile for Fig development, but another for staging and pushing it to Octohost, and then a final one for kicking up to AWS/CoreOS for deployment! They all use the same code, they just have subtly different configurations and trade-offs. This is going to make that so much easier!
minimaxir 12y ago
I've been doing research into Docker, because the ideas of making a dashboard to easily manage entire apps quickly and easily is very compelling for building and managing rapid prototypes. With the addition of a stats API and parametric Docker builds, this appears to be a realistic use case. I still haven't found a good answer to whether you can embed Docker images within a parent administrative Docker image, though, in order to achieve ultimate portability. Who Contains the Containers?
- Zikes 12y ago
  I think that's what CoreOS[1] is intended for. [1] https://coreos.com/ https://coreos.com/
  - minimaxir 12y ago
    CoreOS manages the backend for Containers efficiently, but it would be helpful to have a dashboard UI for diagnostics/admin for each child contained.
    - Zikes 12y ago
      You might want to look at Google's Kubernetes, then. http://kubernetes.io/ http://kubernetes.io/
    - flurdy 12y ago
      You might want to look into Panamax and Shipyard for nice UI on top of Docker management. http://panamax.io/ http://panamax.io/ http://shipyard-project.com/ http://shipyard-project.com/
      - minimaxir 12y ago
        Those examples are more of what I had in mind. Clearly my research was insufficient. :p thanks!
- mikehearn 12y ago
  This may be what you're looking for: http://blog.docker.com/2013/09/docker-can-now-run-within-docker/ http://blog.docker.com/2013/09/docker-can-now-run-within-doc...
- hammerdr 12y ago
  Not entirely sure what you're asking, but you should probably look into "schedulers" and other tools built on top of such ecosystems. Here are a few to get you started: Docker ecosystem: swarm and/or compose Mesos ecosystem: Chronos, Aurora, Marathon CoreOS ecosystem: fleet Hashicorp: Terraform Amazon Container Service: works with the above, will likely build their own simple one in the near future This is less about embedding images and about managing/"scheduling" them Edit: Zikes mentioned Kubernetes, as well.
  - Gigablah 12y ago
    Terraform is the odd one out; it's an "infrastructure as code" tool, like Amazon CloudFormation but with pluggable providers.
  - jacques_chester 12y ago
    There's also Lattice: https://github.com/pivotal-cf-experimental/lattice https://github.com/pivotal-cf-experimental/lattice Which is extracted the next generation runtime of Cloud Foundry, known as Diego.
ykumar6 12y ago
Read only flags? Streaming stats? Docker's API gets more and more powerful everyday! Very excited about this release
carrja99 12y ago
Oh yeah, being able to specify dockerfiles is golden. We actually use Makefiles to copy docker files from different directories for building, then copying them back. What a hassle it has been.
- toomuchtodo 12y ago
  Couldn't you use symlinks that you create/unlink at build time?
  - nbaksalyar 12y ago
    Docker explicitly forbids usage of symlinks. But there was a workaround: tar the entire directory and then build your container from the archive, like `tar cfh * | docker build -`. Hopefully that wouldn't be needed now.
- vacri 12y ago
  I ended up having to call container with nginx using a custom config file for each different environment. I've been waiting for this as well...
- echidna 12y ago
  You could always use the "wrapper script pattern", e.g. http://blog.james-carr.org/2013/09/04/parameterized-docker-containers/ http://blog.james-carr.org/2013/09/04/parameterized-docker-c... or implement a ready-to-go solution like Tiller (https://github.com/markround/tiller https://github.com/markround/tiller) if you don't mind the overhead of ruby in your containers.
mikehearn 12y ago
Named Dockerfiles support is a nice addition. I usually split up my projects with one (or more) container running the app, and a separate container running Grunt to compile all the front-end libraries. It was a minor annoyance to separate these into different directories simply because a Dockerfile could only be named... Dockerfile.
anders 12y ago
Wish they'd enable IPv6 by default
- justincormack 12y ago
  Yes, I dont see why they shouldnt get link local addresses. It is also slightly odd that if there are existing router advertisements they dont get used, rather you have to do manual config.
  - shykes 12y ago
    We really wanted to, but there was a specific reason not to. I will ask our resident ipv6 expert to provide more details.
  - tianon 12y ago
    It does have linked local addresses by default. It's the more complicated setup of actually routing IPv6 addresses outside our current host that's not enabled by default. https://docs.docker.com/articles/networking/#ipv6 https://docs.docker.com/articles/networking/#ipv6 has more of the details (and the discussion at https://github.com/docker/docker/pull/8947#discussion_r22534269 https://github.com/docker/docker/pull/8947#discussion_r22534... is also useful) Basically, we can't use existing router advertisements (as I understand it) because you also have to tell your current IPv6 router that the entire prefix you use for Docker needs to go to this one host as opposed to just the one IPv6 address that host would auto-assign itself via RA. Since there's manual outside-Docker setup involved, we can't really automate this bit. If there's a nice clean way to do so, we're definitely open to a PR (I'd love to have something simpler myself)! :)
    - justincormack 12y ago
      That is not very clear from the docs then which say "By default, the Docker server configures the container network for IPv4 only. You can enable IPv4/IPv6 dualstack support by running the Docker daemon with the --ipv6 flag" - that doesnt sound like link local addresses by default... Will have to take a look, I guess there are lots of potential setups. If you have a /64 per host it should be ok anyway, if you have a /64 for the network it might not be.
muaddirac 12y ago
> Open Image Spec I'm wondering if this will eventually merge with the ACI that Rocket implements.
- efuquen 12y ago
  That seems unlikely, based off the bad blood developing between CoreOS and Docker. See the links below: https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643
  - Alupis 12y ago
    Wow, those are some pretty hostile words coming from Shykes. > Coming up with a new "standard", then criticizing the established open-source project for failing to implement it, is a common tactic > One last fact, which you might find funny: one of these alternative implementations of Docker's image distribution system is developed by CoreOS, the very same vendor which is propping up this so-called standard > Do you know how many complaints I received, since Docker was created, that I didn't "comply" with this or that self-proclaimed standard? Dozens > But [CoreOS] never did, because as competing commercial vendors their interest is to weaken and fragment the Docker standard, not contribute to it. ~~ > based off the bad blood developing between CoreOS and Docker You know, I think this is really 1-way... I have not see anything along these levels of hostility coming from the CoreOS camp.
    - jontro 12y ago
      Looks like spam accounts / repeated behaviour which reported these bugs. Even though Shykes isnt the best pr guy in the world.
      - Alupis 12y ago
        I'd hardly call 2 issue tickets "spam accounts"... and the first one definitely isn't -- there's years of activity.
Scaevolus 12y ago
You can rename containers now! `docker rename OLD_NAME NEW_NAME` Uou can have a container named `service_prod`, deploy a new version as `service_staging`, then shuffle them with renames if the staging version is effective.
ademarre 12y ago
> Open Image Spec ... As we continue to grow the contributor community to the Docker project, we wanted to encourage more work in the area around how Docker constructs images and their layers. As a start, we have documented how Docker currently builds and formats images and their configuration. Our hope is that these details allow contributors to better understand this critical facet of Docker as well as help contribute to future efforts to improve the image format. The v1 image specification can be found here: https://github.com/docker/docker/blob/master/image/spec/v1.md https://github.com/docker/docker/blob/master/image/spec/v1.m... This is a great start, and I hope this doesn't sound negative, but this likely wouldn't be here if CoreOS hadn't shaken things up the way they did with ACI/Rocket.
- zimbatm 12y ago
  Got the same impression. Now what is needed is to split the docker daemon into little parts with least privileges. An example of that, yesterday while trying to see if I could implement `docker build` using available commands, I found out that the docker daemon is shelling out to git on the server side if a remote url is given. It seems risky since the server is running with a lot of privileges that aren't needed for that task. https://github.com/docker/docker/blob/master/builder/job.go#L79 https://github.com/docker/docker/blob/master/builder/job.go#...
  - jlhawn 12y ago
    > trying to see if I could implement `docker build` using available commands This should be possible soon! The only command missing is a symmetric `docker cp`. I've got most of the implementation ready to be reviewed in a pull request [1] (closed now, but I will reopen it soon). [1] https://github.com/docker/docker/pull/10198#issuecomment-73336761 https://github.com/docker/docker/pull/10198#issuecomment-733...
  - shykes 12y ago
    The split into smaller binaries is something I'm very open to. We just want to make sure the user experience doesn't get sacrificed. Here's a recent discussion thread on the subject: https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ-Y https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ...
nicois 12y ago
It's really annoying how long it's taking to add fuse support to containers. If I want to act on remote filesystems I have to use something like rsync.
- ewindisch 12y ago
  It seems pretty close to working. One of the few (or only) issues remaining is this one: https://github.com/docker/docker/issues/10184 https://github.com/docker/docker/issues/10184 Basically, docker had to add device support, which it now has, but fuse is explicitly forbidden in libcontainer (https://github.com/docker/libcontainer/blob/164cd807a16e63ed539cddda55ce3bbc32e1791e/devices/defaults.go#L146 https://github.com/docker/libcontainer/blob/164cd807a16e63ed...) A patch to libcontainer or possibly Docker itself should resolve this (volunteers always welcome!)
guhcampos 12y ago
Docker Issue #1988 is still an issue. While it is still an issue, and still neglected (or more likely arbitrarily ignored for profit) Docker will be a red flag for any real corporate uses.
- shykes 12y ago
  I agree it's still an issue. Enterprise sysadmins should be allowed to block access to external registries, including Docker Hub. There is nothing contentious about it, and it has nothing to do with profit. If you send a properly implemented patch for it, the maintainers will merge it.
  - justinsb 12y ago
    That's great news. What do you consider a "properly implemented patch"? I would think the most bulletproof & simplest patch would simply allow the default index (index.docker.io) to be reconfigured to something else in docker.conf. Would you support a patch that did that? Edit: And perhaps https://registry-1.docker.io/v2/ https://registry-1.docker.io/v2/ as well?
    - shykes 12y ago
      I think the best way is to allow a "whitelist mode" where only an explicitly specified list of URLs are allowed to be reached. Everything else would be blocked by default. This should give ops the peace of mind they need. Note that this is an ACL change, and not a namespace change. That is important because we want image names to have the same meaning everywhere, regardless of site-specific configuration. So for example, "docker pull ubuntu" should always mean "install ubuntu from the official docker library". This is crucial to the developer experience and to respect the principle of separation of concern between dev and ops. However, if ops chooses to block access to the standard library then "docker pull ubuntu" will fail with "access blocked by your administrator", which is totally acceptable. What we don't want is the operation silently substituting a site-specific image, without the knowledge of the end user, thereby breaking their build in a thousand invisible ways. I hope this helps. Does this mean I should look forward to a patch from you? :)
sshykes 12y ago
In other news, the issues list [0] just keeps growing by the day, apparently with few or no devs committed to ensuring show-stopping kernel interoperability bugs [1] get resolved in a timely manner. I want to love you docker, but the experience of using your products is often sooo painful! [0] https://github.com/docker/docker/issues https://github.com/docker/docker/issues [1] https://github.com/docker/docker/issues/4036 https://github.com/docker/docker/issues/4036 Karma-wise I'm sure there will be hell to pay for my impolite outburst.. Sorry for the offense! Just calling it like I see it.
- shykes 12y ago
  You are right that devicemapper (basically lvm snapshots for storage, used as an alternative to aufs/btrfs on many distros including Red Hat) has been a source of headaches for us. It is relatively obscure (we knew we were in trouble when googling libdevmapper error messages returned our own source code as the first result) and frankly not pleasant to work with. But, the good news is that we have made progress recently. In fact the 1.5 release includes several improvements to devicemapper. And as of last week, Red Hat has volunteered a dedicated engineer to escalate devicemapper problems. So, fingers crossed things will be even better in the next release :) Another alternative is to switch storage drivers: aufs and btrfs are popular options.
  - sshykes 12y ago
    Thanks for following up Solomon! I'm glad you are at least aware of what is going on with this.
- jacques_chester 12y ago
  Wider exposure means more issues logged, including dupes and wish lists.
- omni 12y ago
  GitHub has a really great Pulse feature which gives you a quick look at the flow of PRs and issues in and out of a project: https://github.com/docker/docker/pulse/monthly https://github.com/docker/docker/pulse/monthly Docker has actually been closing issues much more quickly than they come in. Yes, there is a backlog, but that's to be expected from a new project getting a lot of usage. They definitely do not seem to be slouching, though.
general_failure 12y ago
Does anyone know the status of User namespace support? I would think this is a blocker for any paas to use docker.
- shykes 12y ago
  User namespaces recently got merged into libcontainer (which is used as the default backend for sandboxing in Docker). There is 1 technical question left to resolve to enable it by default: how to abstract away the concept of UID mapping, and how does it impact sharing of volumes between containers? There is an ongoing technical discussion, I am optimistic that we will find a solid solution soon but don't want to make any promises we can't keep.
  - SEJeff 12y ago
    In addition to user namespaces, and the obvious sVirt / SELinux bits Dan W from Redhat has been contributing, what features / enhancements are necessary for docker to be considered mostly secure? For reference I run all of my apps as different containers with different users on my own server. I then have iptables rules to block any outbound internet connections for containers that shouldn't. It was hilarious to see when someone hacked my wordpress install running in a container and managed to write out a perl daemon using a rexec bug in wp. But when it tried to contact its C&C server, iptables dropped it and ossec notified me. In a perfect world, I'd do something similar, but root inside the container would map to != uid 0 on the host. I'm just curious if there is anything else you consider necessary to deem docker more "secure" than it currently is.
- deleted 12y ago
  [deleted]
damm 12y ago
IPv6 is really a 1.0 feature. I know how to build and i know it does go test; but it makes me a little :( that there's no public CI listed in github.com/docker/docker.
- TheDong 12y ago
  They link to their jenkins with the little "build passing" badge near the bottom: https://github.com/docker/docker#contributing-to-docker https://github.com/docker/docker#contributing-to-docker https://jenkins.dockerproject.com/job/Docker%20Master/ https://jenkins.dockerproject.com/job/Docker%20Master/ They used to use drone.io, but they recently removed it: https://github.com/docker/docker/pull/10519 https://github.com/docker/docker/pull/10519 I like the creative branch naming.. "jfrazelle:burn-in-a-fire-drone" :)
michaelsbradley 12y ago
I was a little disappointed to see 1.5 released without a fix for the "tty bug" in `docker exec`, and without mention of the same known bug/limitation in the documentation: https://github.com/docker/docker/issues/8755 https://github.com/docker/docker/issues/8755 Hopefully it will get fixed soon. Other than that, I'm excited to kick the tires of v1.5 -- thanks Docker team!

212 points by mohamedbassem 12y ago

ubercow 12y ago

>Specify the Dockerfile to use in build oh man it's finally here. I'm excited.

greatabel 12y ago
I feel the same way: first time I used docker when I found I can't specify file to use, I feel inconceivable.
girvo 12y ago
Finally! I can finally use one Dockerfile for Fig development, but another for staging and pushing it to Octohost, and then a final one for kicking up to AWS/CoreOS for deployment! They all use the same code, they just have subtly different configurations and trade-offs. This is going to make that so much easier!

minimaxir 12y ago

I've been doing research into Docker, because the ideas of making a dashboard to easily manage entire apps quickly and easily is very compelling for building and managing rapid prototypes. With the addition of a stats API and parametric Docker builds, this appears to be a realistic use case. I still haven't found a good answer to whether you can embed Docker images within a parent administrative Docker image, though, in order to achieve ultimate portability. Who Contains the Containers?

Zikes 12y ago
I think that's what CoreOS[1] is intended for. [1] https://coreos.com/ https://coreos.com/
- minimaxir 12y ago
  CoreOS manages the backend for Containers efficiently, but it would be helpful to have a dashboard UI for diagnostics/admin for each child contained.
  - Zikes 12y ago
    You might want to look at Google's Kubernetes, then. http://kubernetes.io/ http://kubernetes.io/
  - flurdy 12y ago
    You might want to look into Panamax and Shipyard for nice UI on top of Docker management. http://panamax.io/ http://panamax.io/ http://shipyard-project.com/ http://shipyard-project.com/
    - minimaxir 12y ago
      Those examples are more of what I had in mind. Clearly my research was insufficient. :p thanks!
mikehearn 12y ago
This may be what you're looking for: http://blog.docker.com/2013/09/docker-can-now-run-within-docker/ http://blog.docker.com/2013/09/docker-can-now-run-within-doc...
hammerdr 12y ago
Not entirely sure what you're asking, but you should probably look into "schedulers" and other tools built on top of such ecosystems. Here are a few to get you started: Docker ecosystem: swarm and/or compose Mesos ecosystem: Chronos, Aurora, Marathon CoreOS ecosystem: fleet Hashicorp: Terraform Amazon Container Service: works with the above, will likely build their own simple one in the near future This is less about embedding images and about managing/"scheduling" them Edit: Zikes mentioned Kubernetes, as well.
- Gigablah 12y ago
  Terraform is the odd one out; it's an "infrastructure as code" tool, like Amazon CloudFormation but with pluggable providers.
- jacques_chester 12y ago
  There's also Lattice: https://github.com/pivotal-cf-experimental/lattice https://github.com/pivotal-cf-experimental/lattice Which is extracted the next generation runtime of Cloud Foundry, known as Diego.

ykumar6 12y ago

Read only flags? Streaming stats? Docker's API gets more and more powerful everyday! Very excited about this release

carrja99 12y ago

Oh yeah, being able to specify dockerfiles is golden. We actually use Makefiles to copy docker files from different directories for building, then copying them back. What a hassle it has been.

toomuchtodo 12y ago
Couldn't you use symlinks that you create/unlink at build time?
- nbaksalyar 12y ago
  Docker explicitly forbids usage of symlinks. But there was a workaround: tar the entire directory and then build your container from the archive, like `tar cfh * | docker build -`. Hopefully that wouldn't be needed now.
vacri 12y ago
I ended up having to call container with nginx using a custom config file for each different environment. I've been waiting for this as well...
echidna 12y ago
You could always use the "wrapper script pattern", e.g. http://blog.james-carr.org/2013/09/04/parameterized-docker-containers/ http://blog.james-carr.org/2013/09/04/parameterized-docker-c... or implement a ready-to-go solution like Tiller (https://github.com/markround/tiller https://github.com/markround/tiller) if you don't mind the overhead of ruby in your containers.

mikehearn 12y ago

Named Dockerfiles support is a nice addition. I usually split up my projects with one (or more) container running the app, and a separate container running Grunt to compile all the front-end libraries. It was a minor annoyance to separate these into different directories simply because a Dockerfile could only be named... Dockerfile.

anders 12y ago

Wish they'd enable IPv6 by default

justincormack 12y ago
Yes, I dont see why they shouldnt get link local addresses. It is also slightly odd that if there are existing router advertisements they dont get used, rather you have to do manual config.
- shykes 12y ago
  We really wanted to, but there was a specific reason not to. I will ask our resident ipv6 expert to provide more details.
- tianon 12y ago
  It does have linked local addresses by default. It's the more complicated setup of actually routing IPv6 addresses outside our current host that's not enabled by default. https://docs.docker.com/articles/networking/#ipv6 https://docs.docker.com/articles/networking/#ipv6 has more of the details (and the discussion at https://github.com/docker/docker/pull/8947#discussion_r22534269 https://github.com/docker/docker/pull/8947#discussion_r22534... is also useful) Basically, we can't use existing router advertisements (as I understand it) because you also have to tell your current IPv6 router that the entire prefix you use for Docker needs to go to this one host as opposed to just the one IPv6 address that host would auto-assign itself via RA. Since there's manual outside-Docker setup involved, we can't really automate this bit. If there's a nice clean way to do so, we're definitely open to a PR (I'd love to have something simpler myself)! :)
  - justincormack 12y ago
    That is not very clear from the docs then which say "By default, the Docker server configures the container network for IPv4 only. You can enable IPv4/IPv6 dualstack support by running the Docker daemon with the --ipv6 flag" - that doesnt sound like link local addresses by default... Will have to take a look, I guess there are lots of potential setups. If you have a /64 per host it should be ok anyway, if you have a /64 for the network it might not be.

muaddirac 12y ago

> Open Image Spec I'm wondering if this will eventually merge with the ACI that Rocket implements.

efuquen 12y ago
That seems unlikely, based off the bad blood developing between CoreOS and Docker. See the links below: https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/9538 https://github.com/docker/docker/issues/10643 https://github.com/docker/docker/issues/10643
- Alupis 12y ago
  Wow, those are some pretty hostile words coming from Shykes. > Coming up with a new "standard", then criticizing the established open-source project for failing to implement it, is a common tactic > One last fact, which you might find funny: one of these alternative implementations of Docker's image distribution system is developed by CoreOS, the very same vendor which is propping up this so-called standard > Do you know how many complaints I received, since Docker was created, that I didn't "comply" with this or that self-proclaimed standard? Dozens > But [CoreOS] never did, because as competing commercial vendors their interest is to weaken and fragment the Docker standard, not contribute to it. ~~ > based off the bad blood developing between CoreOS and Docker You know, I think this is really 1-way... I have not see anything along these levels of hostility coming from the CoreOS camp.
  - jontro 12y ago
    Looks like spam accounts / repeated behaviour which reported these bugs. Even though Shykes isnt the best pr guy in the world.
    - Alupis 12y ago
      I'd hardly call 2 issue tickets "spam accounts"... and the first one definitely isn't -- there's years of activity.

Scaevolus 12y ago

You can rename containers now! `docker rename OLD_NAME NEW_NAME` Uou can have a container named `service_prod`, deploy a new version as `service_staging`, then shuffle them with renames if the staging version is effective.

ademarre 12y ago

> Open Image Spec ... As we continue to grow the contributor community to the Docker project, we wanted to encourage more work in the area around how Docker constructs images and their layers. As a start, we have documented how Docker currently builds and formats images and their configuration. Our hope is that these details allow contributors to better understand this critical facet of Docker as well as help contribute to future efforts to improve the image format. The v1 image specification can be found here: https://github.com/docker/docker/blob/master/image/spec/v1.md https://github.com/docker/docker/blob/master/image/spec/v1.m... This is a great start, and I hope this doesn't sound negative, but this likely wouldn't be here if CoreOS hadn't shaken things up the way they did with ACI/Rocket.

zimbatm 12y ago
Got the same impression. Now what is needed is to split the docker daemon into little parts with least privileges. An example of that, yesterday while trying to see if I could implement `docker build` using available commands, I found out that the docker daemon is shelling out to git on the server side if a remote url is given. It seems risky since the server is running with a lot of privileges that aren't needed for that task. https://github.com/docker/docker/blob/master/builder/job.go#L79 https://github.com/docker/docker/blob/master/builder/job.go#...
- jlhawn 12y ago
  > trying to see if I could implement `docker build` using available commands This should be possible soon! The only command missing is a symmetric `docker cp`. I've got most of the implementation ready to be reviewed in a pull request [1] (closed now, but I will reopen it soon). [1] https://github.com/docker/docker/pull/10198#issuecomment-73336761 https://github.com/docker/docker/pull/10198#issuecomment-733...
- shykes 12y ago
  The split into smaller binaries is something I'm very open to. We just want to make sure the user experience doesn't get sacrificed. Here's a recent discussion thread on the subject: https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ-Y https://groups.google.com/forum/#!topic/docker-dev/mzpAga_XZ...

nicois 12y ago

It's really annoying how long it's taking to add fuse support to containers. If I want to act on remote filesystems I have to use something like rsync.

ewindisch 12y ago
It seems pretty close to working. One of the few (or only) issues remaining is this one: https://github.com/docker/docker/issues/10184 https://github.com/docker/docker/issues/10184 Basically, docker had to add device support, which it now has, but fuse is explicitly forbidden in libcontainer (https://github.com/docker/libcontainer/blob/164cd807a16e63ed539cddda55ce3bbc32e1791e/devices/defaults.go#L146 https://github.com/docker/libcontainer/blob/164cd807a16e63ed...) A patch to libcontainer or possibly Docker itself should resolve this (volunteers always welcome!)

guhcampos 12y ago

Docker Issue #1988 is still an issue. While it is still an issue, and still neglected (or more likely arbitrarily ignored for profit) Docker will be a red flag for any real corporate uses.

shykes 12y ago
I agree it's still an issue. Enterprise sysadmins should be allowed to block access to external registries, including Docker Hub. There is nothing contentious about it, and it has nothing to do with profit. If you send a properly implemented patch for it, the maintainers will merge it.
- justinsb 12y ago
  That's great news. What do you consider a "properly implemented patch"? I would think the most bulletproof & simplest patch would simply allow the default index (index.docker.io) to be reconfigured to something else in docker.conf. Would you support a patch that did that? Edit: And perhaps https://registry-1.docker.io/v2/ https://registry-1.docker.io/v2/ as well?
  - shykes 12y ago
    I think the best way is to allow a "whitelist mode" where only an explicitly specified list of URLs are allowed to be reached. Everything else would be blocked by default. This should give ops the peace of mind they need. Note that this is an ACL change, and not a namespace change. That is important because we want image names to have the same meaning everywhere, regardless of site-specific configuration. So for example, "docker pull ubuntu" should always mean "install ubuntu from the official docker library". This is crucial to the developer experience and to respect the principle of separation of concern between dev and ops. However, if ops chooses to block access to the standard library then "docker pull ubuntu" will fail with "access blocked by your administrator", which is totally acceptable. What we don't want is the operation silently substituting a site-specific image, without the knowledge of the end user, thereby breaking their build in a thousand invisible ways. I hope this helps. Does this mean I should look forward to a patch from you? :)

sshykes 12y ago

In other news, the issues list [0] just keeps growing by the day, apparently with few or no devs committed to ensuring show-stopping kernel interoperability bugs [1] get resolved in a timely manner. I want to love you docker, but the experience of using your products is often sooo painful! [0] https://github.com/docker/docker/issues https://github.com/docker/docker/issues [1] https://github.com/docker/docker/issues/4036 https://github.com/docker/docker/issues/4036 Karma-wise I'm sure there will be hell to pay for my impolite outburst.. Sorry for the offense! Just calling it like I see it.

shykes 12y ago
You are right that devicemapper (basically lvm snapshots for storage, used as an alternative to aufs/btrfs on many distros including Red Hat) has been a source of headaches for us. It is relatively obscure (we knew we were in trouble when googling libdevmapper error messages returned our own source code as the first result) and frankly not pleasant to work with. But, the good news is that we have made progress recently. In fact the 1.5 release includes several improvements to devicemapper. And as of last week, Red Hat has volunteered a dedicated engineer to escalate devicemapper problems. So, fingers crossed things will be even better in the next release :) Another alternative is to switch storage drivers: aufs and btrfs are popular options.
- sshykes 12y ago
  Thanks for following up Solomon! I'm glad you are at least aware of what is going on with this.
jacques_chester 12y ago
Wider exposure means more issues logged, including dupes and wish lists.
omni 12y ago
GitHub has a really great Pulse feature which gives you a quick look at the flow of PRs and issues in and out of a project: https://github.com/docker/docker/pulse/monthly https://github.com/docker/docker/pulse/monthly Docker has actually been closing issues much more quickly than they come in. Yes, there is a backlog, but that's to be expected from a new project getting a lot of usage. They definitely do not seem to be slouching, though.

general_failure 12y ago

Does anyone know the status of User namespace support? I would think this is a blocker for any paas to use docker.

shykes 12y ago
User namespaces recently got merged into libcontainer (which is used as the default backend for sandboxing in Docker). There is 1 technical question left to resolve to enable it by default: how to abstract away the concept of UID mapping, and how does it impact sharing of volumes between containers? There is an ongoing technical discussion, I am optimistic that we will find a solid solution soon but don't want to make any promises we can't keep.
- SEJeff 12y ago
  In addition to user namespaces, and the obvious sVirt / SELinux bits Dan W from Redhat has been contributing, what features / enhancements are necessary for docker to be considered mostly secure? For reference I run all of my apps as different containers with different users on my own server. I then have iptables rules to block any outbound internet connections for containers that shouldn't. It was hilarious to see when someone hacked my wordpress install running in a container and managed to write out a perl daemon using a rexec bug in wp. But when it tried to contact its C&C server, iptables dropped it and ossec notified me. In a perfect world, I'd do something similar, but root inside the container would map to != uid 0 on the host. I'm just curious if there is anything else you consider necessary to deem docker more "secure" than it currently is.
deleted 12y ago
[deleted]

damm 12y ago

IPv6 is really a 1.0 feature. I know how to build and i know it does go test; but it makes me a little :( that there's no public CI listed in github.com/docker/docker.

TheDong 12y ago
They link to their jenkins with the little "build passing" badge near the bottom: https://github.com/docker/docker#contributing-to-docker https://github.com/docker/docker#contributing-to-docker https://jenkins.dockerproject.com/job/Docker%20Master/ https://jenkins.dockerproject.com/job/Docker%20Master/ They used to use drone.io, but they recently removed it: https://github.com/docker/docker/pull/10519 https://github.com/docker/docker/pull/10519 I like the creative branch naming.. "jfrazelle:burn-in-a-fire-drone" :)

michaelsbradley 12y ago

I was a little disappointed to see 1.5 released without a fix for the "tty bug" in `docker exec`, and without mention of the same known bug/limitation in the documentation: https://github.com/docker/docker/issues/8755 https://github.com/docker/docker/issues/8755 Hopefully it will get fixed soon. Other than that, I'm excited to kick the tires of v1.5 -- thanks Docker team!