Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
shykes
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
68 ms
·
781.
▲
by
shykes
13y ago
Check out boot2docker: http://github.com/steeve/boot2docker It's a 25MB vm which boots a working docker installation in 5 seconds. I use it on my mac with virtualbox, and connect to it from the native docker clien
782.
▲
by
shykes
13y ago
+1 To use docker on my mac I have replaced Vagrant with boot2docker ( http://github.com/steeve/boot2docker ). I didn't need all the moving parts anyway - the VM is always the same, the application-specific bits are
783.
▲
by
shykes
13y ago
Hi everyone, I see a lot of comments and questions on the state of packaging for Docker in various distros. Recently we started working closely with maintainers of major distros, and making sure we made their life as easy as possible, while
784.
▲
by
shykes
13y ago
Hi there, you can find a high-level roadmap here: https://github.com/dotcloud/docker/blob/master/hack/ROADMAP.... We ship on average one major release per month, and one minir release per week. Each
785.
▲
by
shykes
13y ago
Here's the pull request for switching to 1.2 stable in Docker: https://github.com/dotcloud/docker/pull/2978
786.
▲
by
shykes
13y ago
We explain how to setup a dev and build environment here: http://docs.docker.io/en/latest/contributing/devenvironment/ I guess we could reference that it the install docs.
787.
▲
by
shykes
13y ago
You're right, the arch docs need some updating. Pushing that to the queue. Thanks!
788.
▲
by
shykes
13y ago
This, by the way, is the reason we artificially prevent docker from running on multiple archs. If half of the containers you download end up not running on your arch, and there's no elegant way for you to manage that by filtering your
789.
▲
by
shykes
13y ago
It wouldn't be the craziest thing people do with docker: http://blog.bittorrent.com/2013/10/22/sync-hacks-deploy-bitt... http://blog.docker.io/2013/07/docker-desktop-your-deskto
790.
▲
by
shykes
13y ago
You can assign permanent names to containers. We're designing the naming syatem to make it completely OK to keep persistent containers. They're just named directories, docker will never remove them on its own. For example a common
791.
▲
by
shykes
13y ago
This is just totally wrong. Any decent container configuration (including the default docker configuration) will agressively drop capabilities, preventing you from doing this, and any other script-kiddie attack. See my other comment in this
792.
▲
by
shykes
13y ago
To my knowledge there are currently no known exploits. It's more a matter of risk management: newer codebases are less secure because we had less time to find bugs and spread best practices. That problem is amplified for larger codebas
793.
▲
by
shykes
13y ago
btrfs will probably compare favorably to lvm.. But it's just an educated guess at this point.
794.
▲
by
shykes
13y ago
You can use the ADD build instruction in the Dockerfile to upload any part of your source repo into the container. Then more RUN instructions to manipulate that, for example compile the code etc. Here are 2 examples: https://gith
795.
▲
by
shykes
13y ago
That's a good point, thanks. Note: the author and HN poster are 2 different people, but evidently we both check comments :)
796.
▲
by
shykes
13y ago
Quick update: until we figure out what broke the build on our ReadTheDocs.org setup, we switched the default branch to master. So if you visit http://docs.docker.io you will get the bleeding edge build of the documentation, whic
797.
▲
by
shykes
13y ago
There is a slight performance overhead with lvm, but nothing dramatic. The other advantage of the AUFS driver is that it is more proven. If you have a way to get aufs on your system (and I believe debian does), my pragmatic ops advice would
798.
▲
by
shykes
13y ago
The 42 limit comes from the aufs code itself. My guess is that it's because of stack depth: if you stack these kernel data structures too many levels deep, you might trigger an overflow somewhere. The hardcoded limit is probably a prag
799.
▲
by
shykes
13y ago
Documentation is definitely part of the process :) Apparently the documentation service triggered an incorrect build overnight. Until we fix that you can browse the latest version of the docs from the master branch: http://docs.d
800.
▲
by
shykes
13y ago
I have not tried personally, but I think it should be possible. People already do crazy things with Docker :) For example: http://resin.io/docker-on-raspberry-pi/
801.
▲
by
shykes
13y ago
Yes, it's idiomatic, but typically you will use shared filesystem access rather than shared memory. By default nothing is shared, and you can specify exceptions using shared directories called "volumes": http://doc
802.
▲
by
shykes
13y ago
The easiest way is to add a Dockerfile to your source repository, and use 'docker build' to create a container image from it. Documentation link: http://docs.docker.io/en/master/use/builder/
803.
▲
by
shykes
13y ago
It is definitely designed to be easier in several ways. One way is that it defines a format for portable container images, and an infrastructure for moving images around machines and sharing them with others. See http://www.docke
804.
▲
by
shykes
13y ago
No, docker sets up its own partition in a loop-mounted sparse file. There is a slight performance tradeoff, but in production you should assume the copy-on-write layer is too slow anyway and use volumes for your performance-critical directo
805.
▲
by
shykes
13y ago
Yes, Docker should be able to help you. It is definitely not just for large companies. Docker can help you streamline your development and deployment process across all the machines, from the development laptop to the production server. The
806.
▲
by
shykes
13y ago
For process isolation, the overhead is approximately zero. It adds a few milliseconds to initial execution time, then CPU and memory consumption of your process should be undistinguishable from a no-container scenario. For disk IO, as long
807.
▲
by
shykes
13y ago
It's both. Everyone using docker benefits from the "software distribution" feature. Some people using docker also benefit from the security and isolation features - it depends on your needs and the security profile of your
808.
▲
by
shykes
13y ago
The 42 layer limit is still there... But not for long! There is a fix underway to remove the limitation from all drivers, including aufs. Instead of lifting the limit for some drivers first (which would mean some images on the index could o
809.
▲
by
shykes
13y ago
Not yet, but that's coming very soon. We've been artificially limiting the number of architectures supported to limit the headache of managing cross-arch container images. We're reaching the point where that will no longer be
810.
▲
by
shykes
13y ago
A few details on the "standard linux support" part. To remove the hard dependency on the AUFS patches, we moved it to an optional storage driver, and shipped a second driver which uses thin LVM snapshots (via libdevmapper) for cop
More ›