7 ms·
Docker 1.3 is out
- _mikz 12y agoWhat happened to the "release every first week of a month"?
- micah_chatt 12y agoI'm guessing that would be a second dot release (1.3.1) monthly. If you look at the github milestones, it appears a dot release is scheduled for every 3 months. https://github.com/docker/docker/milestones https://github.com/docker/docker/milestones
- _mikz 12y agofrom http://blog.docker.com/2014/02/docker-0-8-quality-new-builder-features-btrfs-storage-osx-support/ http://blog.docker.com/2014/02/docker-0-8-quality-new-builde... "One release per month. Every first week of the month, we release a new version of Docker. For example, in the first week of March we will release 0.9." looking at https://github.com/docker/docker/blob/master/CHANGELOG.md https://github.com/docker/docker/blob/master/CHANGELOG.md it does not fit very well
- micah_chatt 12y agoCheck out https://github.com/docker/docker/releases https://github.com/docker/docker/releases EDIT: Its slightly off, but still about one a month
- shykes 12y agoWe moved the cadence to every other month, because packagers complained we were shipping too fast :)
- hackerboos 12y ago"You need more waterfall in your agile."
- ewindisch 12y agoThis includes critical security updates for boot2docker to resolve a RCE vulnerability. Docker itself containers a lower priority security update. Users, especially those of boot2docker, are highly encouraged to upgrade. https://groups.google.com/forum/#!topic/docker-announce/aQoVmQlcE0A https://groups.google.com/forum/#!topic/docker-announce/aQoV...
- McKayDavis 12y agoThank you for pointing this out! For those wanting to avoid upgrading to a new boot2docker release you can patch the vulnerability with the following command from the boot2docker shell: sudo sed -i "s/DOCKER_TLS:=''/DOCKER_TLS:=auto/g" /etc/init.d/docker && sudo /etc/init.d/docker restart This will enable TLS by default and restart the docker daemon. Note that this will also kill all of your running containers.
- deleted 12y ago[deleted]
- perlpimp 12y agohope 1.3 will be soon in the homebrew, we're migrating tomorrow to docker and all of our office is OSX. that is regarding new standard folder sharing feature.
- whiteacid 12y agoLooks like it's almost there https://github.com/Homebrew/homebrew/pull/33225 https://github.com/Homebrew/homebrew/pull/33225
- teacup50 12y agoYour entire office is OS X and you're migrating to a Linux-only non-portable technology stack that requires a VM to run on your desktop? Is this really cheaper and more effective than cleaning up your code base so that it doesn't require complete ownership of the host environment in order to run?
- yazaddaruvala 12y ago...maybe I'm confused... Is your premise that they will only run their application/service internally? Normally what I've seen is, develop on OSX and then push to Heroku (Linux) / <infrastructure provider of choice, running a Linux VM>. Why then wouldn't the natural progression be, develop in boot2docker and push to <docker PASS of preference>?
- teacup50 12y agoWhy would you want to "develop in boot2docker" ?
- nell 12y agoDeveloping an app in boot2docker is questionable. But almost always the module or service that you work on relies on other services and datastores. boot2docker can help you pull down an entire stack to your workstation and not rely on connecting to an external network. You can essentially work on Airplane mode.
- general_failure 12y agoWhat is the status of user namespaces? Is this not one of the core security problems with docker?
- ewindisch 12y agoUser namespaces will come. Patches are in progress and you can refer to github for the status of that effort. I'd hesitate before calling it a "security problem" with Docker. It's a highly-requested security feature. The absence of it makes containers less secure, but does not make them vulnerable. There are use-cases for Docker without user namespaces, but user namespaces will make Docker better and will make containers more secure. We do distinguish between the security of the Docker engine and the pieces of our ecosystem and the security of containers themselves. We seek to improve both. Vulnerabilities such as the one fixed today in boot2docker 1.3 whereby either web browsers or containers may control the Docker daemon and perform remote code execution are serious issues in Docker itself and/or its ecosystem of products. Resolving such vulnerabilities is not, for me, less important than adding user namespaces.
- general_failure 12y agoTotally agree. Do you have a link to the patch in progress? I would love to test them out.
- wmf 12y agoI dug into all the bug trackers to find the current status and it looks like user namespaces can be enabled once Go 1.4 is released in December.
- valarauca1 12y agoStill SSL problems. I remember reporting them last announcement, even emailing back and forth with docker... still not fixed. I sent another email.
- ewindisch 12y agoThank you. We will be updating the blog to support higher versions of TLS as well as to evaluate its cipher suite. It has taken longer than it should, and for that we apologize. It has not been forgotten or abandoned and will be resolved as promptly as possible. Our other sites, including the Docker website and the Docker Hub already have relatively aggressive cipher suites and have disabled SSLv3, protecting it from POODLE.
- ahmett 12y agoDocker Remote API v1.15 is also out. But without a WHATSNEW section... https://docs.docker.com/reference/api/docker_remote_api/#full-documentation https://docs.docker.com/reference/api/docker_remote_api/#ful...
- calebm 12y agoHas anyone been able to get Mac host drive sharing working with boot2docker 1.3? I have not yet.
- bfirsh 12y agoHave you tried running "boot2docker upgrade" to get the latest image? If you're still having trouble email me at benf@docker.com
- deleted 12y ago[deleted]
- calebm 12y agoActually, maybe I'm not on 1.3... I did do a "boot2docker upgrade", but when I do "boot2docker version", I'm still getting 1.2.0: (py)cmbpr:~ caleb$ boot2docker upgrade Downloading boot2docker ISO image... Latest release is v1.3.0 Success: downloaded https://github.com/boot2docker/boot2docker/releases/download/v1.3.0/boot2docker.iso https://github.com/boot2docker/boot2docker/releases/download... to /Users/caleb/.boot2docker/boot2docker.iso Waiting for VM and Docker daemon to start... .............................. Started. Writing /Users/caleb/.docker/boot2docker-vm/ca.pem: Writing /Users/caleb/.docker/boot2docker-vm/cert.pem: Writing /Users/caleb/.docker/boot2docker-vm/key.pem: To connect the Docker client to the Docker daemon, please set: export DOCKER_HOST=tcp://192.168.59.103:2376 export DOCKER_CERT_PATH=/Users/caleb/.docker/boot2docker-vm (py)cmbpr:~ caleb$ boot2docker version Client version: v1.2.0 Git commit: a551732 (py)cmbpr:~ caleb$
- smegel 12y ago> our recommended approach of “one app per container.” Instead, we’re responding to users who’ve told us they sometimes need helper processes Isn't it quite normal for an "app" to consist of multiple processes? Maybe a web server, app server, database system, message queue, object store, cron jobs and the like.
- shykes 12y agoYes, but often you are better off isolating these processes from each other, and only allow communication over the network. Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.
- pbiggar 12y agoIt seems like phrasing it as "one service per container" (with service being in the SOA sense), might be better. Certainly, I think of an SOA app being composed of multiple services, and I'm pretty sure the thing you're suggesting that the thing you want one of in the container is what I'm calling a service.
- smegel 12y agoSure, if I was designing a production grade system I probably would isolate a lot of the services. But I thought the whole idea of Docker was I could download something like a "Wordpress image" from the Docker marketplace, and it would just work in a self-contained way. Unless there is some higher level tool to download multiple Docker images for different apps and configure them together to provide a service of some kind.
- shykes 12y agoYou're right, ideally you could get the best of both worlds: 1) multi-container stack that mimics the production setting, and 2) something you can 'docker pull' and 'docker run' as a single unit. For now you need 3d-party tools to define their own multi-container constructs, like Fig or Kubernetes. Eventually Docker needs to implement a multi-container construct of its own, to avoid fragmentation (interoperable containers are not as useful if they're bundled in non-interoperable wrappers). Luckily, the authors of Fig work at Docker and we're working closely with the authors of Kubernetes. So if you use either of those tools, you will probably be familiar with the native Docker version :)
- shykes 12y agoNoteworthy features: * Feature preview of digitally signed images * Process injection with `docker exec` * More flexible container lifecycle with `docker create` * Shared directories on Mac OS X thanks to boot2docker * Fine-grained security options
- polvi 12y agoAs far as I can tell, the current implementation of signed images hardcodes the Docker, Inc cert-- effectively locking in users to only Docker, Inc's trusted images. https://github.com/docker/docker/blob/master/trust/trusts.go#L38 https://github.com/docker/docker/blob/master/trust/trusts.go... Ideally docker users could sign their own images and provide their own keys to do signature validations. What is the timeline on this work? With out this, "digitally signed images" means "locked into Docker, Inc- otherwise no security", and is very misleading. A very basic implementation would be to read certs out of a directory on the filesystem and is how all other package managers handle this. Edit: I missed the part in the post that even if the signature fails, the container still runs. The signatures do nothing. Got it. Preview.
- shykes 12y agoAbsolutely, the full implementation will allow each user to sign with their own keys, and provide user-configurable trust rules ("allow images only signed by this key"). The Docker CA will be used as a default convenience to provide a common namespace if you want it, but users who want to use their own custom PKI will have all the flags to do that, and there will be an "escape hatch" to opt out of the entire trust infrastructure altogether. The only reason we're starting with verification-only, and only for images produced by the official library maintainers, is because the other side of the tools (signing) are not yet ready to be merged in Docker. By releasing a subset now, we can start getting some feedback and ironing out the quirks, while the contributors finish their work on the signing tools, using the library maintainers as guinea pigs. Hope this helps. PS. to state the obvious, all of this is taking place in the open on #docker-dev in Freenode. It is being designed by key contributors from multiple companies, and you are welcome to join the fun.
- 12y ago