61–70 of 76 posts
Any update on when the OS X version will be available? I'm only seeing version 1.1.2 here: https://github.com/boot2docker/osx-installer/releases
Use the Vagrant env, boot2docker is a mess IMO.
Writable `/etc/hosts`, `/etc/resolv.conf` is huge - no more local dns hacks.
Yeah that one was super-high on the request list, there were 3 competing patches before we finally got it right.
Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.
Earlier quoted context omitted.
Yeah that one was super-high on the request list, there were 3 competing patches before we finally got it right.
Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host? Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.
Earlier quoted context omitted.
Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host? Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.
I think it is supported. The feature we are discussing allows the container to change its own resolv/host files, from the inside. I'm pretty sure that works from build also. But it's possible that I missed one of the patches (a sign of healthy autonomy and trust between maintainers).
"Note, however, that changes to these files are not saved during a docker build and so will not be preserved in the resulting image. The changes will only “stick” in a running container."
If I do RUN echo "127.0.0.1 somehost" >> /etc/hosts or COPY container_hosts /etc/hosts, according to the announcement wording, this will not persist in my image.
If this is incorrect, could you clarify what isn't saved during docker build? If this is correct, why is docker build unable to retain these changes?
This is excellent news. The lack of a container restart policy was the main reason why I was spending a bunch of time learning CoreOS and fleet. Trying to get CoreOS installed on VPS providers is a huge pain[0], and fleet and etcd are technically not labelled as production-ready (only CoreOS used as a base OS is)[1], so I'm really glad I can go back to vanilla Docker. [0]: http://serverfault.com/a/620513/85897 [1]: h…
> I was wasting a bunch of time learning CoreOS I'm pretty sure CoreOS and Docker are different solutions to different problems. So... one is not really inter-changeable with another, and thus you were not "wasting" your time. So, perhaps you didn't understand the problem you were trying to solve? Docker is about application environment isolation/portability (not! virtualization! -- there is no security provided here…
Actually there is plenty of security[1]. It may not be "as secure" as a traditional virtualization platform, but that doesn't mean Docker/containers don't have plenty of capabilities (ha!) to offer in terms of security.
You need to understand what they offer, but the old "Docker isn't secure" thing is not more truthful than "Docker is a security solution". Security is a continuum, and Docker has some very interesting security uses.
I've already linked to [1], but I'd encourage all to read it.
[1] http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applica...
Earlier quoted context omitted.
Docker currently uses LXC. Isn't it reasonable to suggest porting it to other jail-solutions?
Well, simplifying here, but Docker is more-or-less a fancy wrapper for LXC. FreeBSD Jails do a lot more than just make applications portable -- they provide security and isolation between applications (like a super chroot). Jails can be used to safely provide application hosting for various clients while Docker should only be used for your applications (jails prevent clients from messing with the host system nor each…
Indeed, dotcloud (ie, Docker before it was Docker) were using LXC as a security measure to isolate clients inside their PAAS (see pg 8 of [2])
It has long been speculated that it would be possible to port the Docker API to other container mechanisms.
Personally I don't think this should be a priority - I'd much prefer Docker put all their resources behind building the best experience possible on a single platform.
Nevertheless, asking about it is a valid question.
[1] http://en.wikipedia.org/wiki/LXC#Alternatives "LXC is similar to other OS-level virtualization technologies on Linux such as OpenVZ and Linux-VServer, as well as those on other operating systems such as FreeBSD jails, AIX Workload Partitions and Solaris Containers."
[2] http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applica...
I'm not sure about how I feel about this (edit - restart policies). It's cool, but seems to ignore what the OTP part of erlang development learned. They've already gone to "X number of restarts = failure" but with no time involved. There's also no hierarchy, which is where you really start to get the benefits. While great, I worry that this is a part-solution that will delay the implementation of a proper one.
Earlier quoted context omitted.
Docker != Jails (not in any way, shape, nor form). Please stop trying to make Docker into everything it's not.
Docker currently uses LXC. Isn't it reasonable to suggest porting it to other jail-solutions?
Earlier quoted context omitted.
I think it is supported. The feature we are discussing allows the container to change its own resolv/host files, from the inside. I'm pretty sure that works from build also. But it's possible that I missed one of the patches (a sign of healthy autonomy and trust between maintainers).
Hm...this sounds like a bit of a disconnect from the 1.2 announcement post, which says: "Note, however, that changes to these files are not saved during a docker build and so will not be preserved in the resulting image. The changes will only “stick” in a running container." If I do RUN echo "127.0.0.1 somehost" >> /etc/hosts or COPY container_hosts /etc/hosts, according to the announcement wording, this will not per…
Now, in its current implementation "docker build" commits an intermediary image after each build step. These intermediary images are used by the build cache, to speed up successive builds. These intermediary images are created in exactly the same way as every other image - which means the same rules apply for /etc/resolv.conf and /etc/hosts. An unfortunate side effect is that changes to these files are not shared between build steps.
We can solve this in a future version (or even a hotfix if necessary). A relatively quick stopgap would be for "docker build" to copy these files across build steps. The long-term solution is to no longer commit a full-blown intermediary image at each build step, but instead to use a snapshotting facility more tailored to the needs of the build caching system. While we're at it we can make sure it preserves /etc/hosts and /etc/resolv.conf.
Sorry for the inconvenience, I hope the explanation helps.