Docker 0.8: Quality, new builder features, btrfs, OSX support
1–10 of 128 posts
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#2Glad to hear OS X has official support. I jumped into Docker for the first time last week and have a burning unresolved question for those using boot2docker.
What is your development workflow? I am working on a Rails app, so my instinct is to have a shared folder between OS X and boot2docker, but afaik this is not supported as boot2docker doesn't support VirtualBox guest extensions.
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#3Just to clarify on the OSX support: obviously we did not magically get Darwin to support linux containers. But we put together the easiest possible way to run Linux containers on a Mac without depending on another machine.
We do this by combining (1) docker in "client mode", which connects to (2) a super-lightweight linux VM using boot2docker.
The details are on http://docs.docker.io/en/latest/installation/mac/
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#4Glad to hear OS X has official support. I jumped into Docker for the first time last week and have a burning unresolved question for those using boot2docker. What is your development workflow? I am working on a Rails app, so my instinct is to have a shared folder between OS X and boot2docker, but afaik this is not supported as boot2docker doesn't support VirtualBox guest extensions.
Hi Matt, you are not alone :)
It turns out that shared folders are not a sustainable solution (independently of whether boot2docker supports them), so the best practices are converging towards this:
1) While developing, your dev environment (including the source code and method for fetching it) should live in a container. This container could be as simple as a shell box with git and ssh installed, where you keep a terminal open and run your unit tests etc.
2) To access your source code on your host machine (eg. for editing on your mac), export it from your container over a network filesystem: samba, nfs or 9p are popular examples. Then mount that from your mac. Samba can be natively mounted with "command-K". NFS and 9p require macfuse.
3) When building the final container for integration tests, staging and production, go through the full Dockerfile + 'docker build' process. 'docker build' on your mac will transparently upload the source over the docker remote API as needed.
There are several advantages to exporting the source from the container to the host, instead of the other way around:
- It's less infrastructure-specific. If you move from virtualbox to vmware, or get a Linux laptop and run docker straight on the metal, your storage/shared folders configuration doesn't change: all you need is a network connection to the container.
- Network filesystems are more reliable than shared folders + bind-mount. For example they can handle different permissions and ownership on both ends - a very common problem with shared folders is "oops the container creates files as root but I don't have root on my mac", or "apache complains that the permissions are all wrong because virtualbox shared folders threw up on me".
That said, we need to take that design insight and turn it into a polished user experience - hopefully in Docker 0.9 this will all be much more seamless!
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#5Awesome that OSX support is now official, but is there any benefit to using this process as opposed to using docker-osx? https://github.com/noplay/docker-osx
The official installation process seems more complicated, and I don't really see an advantage.
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#6It's not explicitly said, but are they following Semantic Versioning? http://semver.org/
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#7It's not explicitly said, but are they following Semantic Versioning? http://semver.org/
Not exactly. The article says the first number is for major lifecycle events, ie 1.0 means "production ready". They'll be releasing monthly and the second number will be the release increment. The third number will be for patches and fixes.
So to me that doesn't fit in with the Semantic Versioning contract. I think the product is too young yet to use a version scheme that assumes relative API stability.
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#8Glad to hear OS X has official support. I jumped into Docker for the first time last week and have a burning unresolved question for those using boot2docker. What is your development workflow? I am working on a Rails app, so my instinct is to have a shared folder between OS X and boot2docker, but afaik this is not supported as boot2docker doesn't support VirtualBox guest extensions.
You can use Docker + Makefiles (test, binary, etc) to really help you with this.
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#9It's not explicitly said, but are they following Semantic Versioning? http://semver.org/
Not exactly. The article says the first number is for major lifecycle events, ie 1.0 means "production ready". They'll be releasing monthly and the second number will be the release increment. The third number will be for patches and fixes. So to me that doesn't fit in with the Semantic Versioning contract. I think the product is too young yet to use a version scheme that assumes relative API stability.
Well, to be fair, this is why even with semver 0.x means "anything goes". It's only from 1.x onwards that major version increments should be used for backwards-incompatible changes.
Re: Docker 0.8: Quality, new builder features, btrfs, OSX support
#10It's not explicitly said, but are they following Semantic Versioning? http://semver.org/
Not exactly. The article says the first number is for major lifecycle events, ie 1.0 means "production ready". They'll be releasing monthly and the second number will be the release increment. The third number will be for patches and fixes. So to me that doesn't fit in with the Semantic Versioning contract. I think the product is too young yet to use a version scheme that assumes relative API stability.
Well, I would assume 0.x.x is by nature unstable, so I'm not sure how it doesn't fit. I read the article, but I'm still left wondering for clarification.