41–50 of 159 posts
I think thats the best way I can summarise what Docker _is_.
I'm stunned that nobody has brought up the idea of 'immutable architecture' -- the idea that you create an image and deploy it, and then there is no change of state after it's deployed. If you want a change to that environment, you create a new image and deploy that instead. Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
You get most of the benefits of immutable builds anyhow by having scripts which can reliably set up servers from scratch on the fly.
For me, it is the ultimate in the idea in Continuous Delivery of "build once." I can be very confident that the docker image I build in the first stage of my pipeline will operate correctly in production. This is because that identical image was used for unit tests, to integration and functional testing, to the staging environment and finally production. There is no difference than configuration. This is the core tha…
How do you handle different configurations then? Especially if you need to provide N values (or structured data). Also, how do you manage your containers in production?
Lots of people write their own scripts to do this; I wrote Tiller (http://github.com/markround/tiller) to standardise this usage pattern. While I have written a plugin to support storing values in a Zookeeper cluster, I tend to prefer to keep things in YAML files inside the container - at least, for small environments that don't change often. It just reduces a dependency on an external service, but I can see how useful it would be in larger, dynamic environments.
I'm stunned that nobody has brought up the idea of 'immutable architecture' -- the idea that you create an image and deploy it, and then there is no change of state after it's deployed. If you want a change to that environment, you create a new image and deploy that instead. Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
You shut down a VM and instruct the hypervisor system to take a "snapshot" which locks the original VHD file and creates a new one. When writes happen, they're performed on the new VHD, and reads have to use both the main and the snapshot VHD. And you can create a chain of snapshots, each pointing to the previous snapshot, for versioning. Or you can have several VM snapshots use the same master VHD, like for CI or data deduplication.
To roll back, it's usually as simple as shutting down the VM and removing the snapshot file.
I'm stunned that nobody has brought up the idea of 'immutable architecture' -- the idea that you create an image and deploy it, and then there is no change of state after it's deployed. If you want a change to that environment, you create a new image and deploy that instead. Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
I'm stunned that nobody has brought up the idea of 'immutable architecture' -- the idea that you create an image and deploy it, and then there is no change of state after it's deployed. If you want a change to that environment, you create a new image and deploy that instead. Docker gives you the ability to version your architecture and 'roll back' to a previous version of a container.
This means that you have to roll out a (potentially huge) new blob each time you want to make even small config changes. You get most of the benefits of immutable builds anyhow by having scripts which can reliably set up servers from scratch on the fly.
Earlier quoted context omitted.
The problem is Vagrant + Ansible violates the rule of "build once." I don't care about the isolation for isolation sake, I care about it for the artifact sake.
How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint. What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually…