71–80 of 111 posts
Compare this with vagrant
You don't have docker style provisioning/overlays, but that may be an advantage, especially if you already have provisioning scripts compatible with vagrant.
To oversimplify: vagrant is for development, docker for deployment. But that's oversimplified, there's lots of overlap.
Earlier quoted context omitted.
Because almost no one around here uses FreeBSD it seems.
Some of us do, when appropriate. Docker took a technology known to many that setup/admin/manage machines, added some fluff, made things simpler, and marketed the idea. In a crowd that might spend more time thinking about nodejs and callbacks vs promises or how easily one can tip a rails app up on heroku, existing systems tools for things like jails/virtualization may either be over looked or not a concern. For every…
And I think that's the crux of it--do you think anyone would use Heroku if its container environment were FreeBSD-based? I'm guessing not; nobody develops on FreeBSD, so they'd have to test on a separate FreeBSD VM before deploying.
I recently wrote an article that covers some of this ground: http://www.sitepoint.com/docker-for-rubyists/ The basic idea behind Docker is that you don't have to create another operating system in order to just separate your processes from each other. This leads to containers being much more lightweight than virtual machines but also significantly less powerful (i.e. powerful as in ability to do something, not in ter…
Any chance you can elaborate on: "(i.e. powerful as in ability to do something, not in terms of performance)" Do you mean smaller units of functionality which perform at good levels? For example, I wouldn't want to deploy a large, monolithic service this way?
I've been having trouble figuring out the value-add of using Docker over Ubuntu's built-in LXC functionality [1]. [1] https://help.ubuntu.com/12.04/serverguide/lxc.html
Right now, the only thing that supports Docker container format is Linux's dockerd implementation, which happens to use LXC+AUFS. Later on, Docker containers could be deployed "baked" into Xen images, or (if all the code inside them is architecture-neutral) deployed onto a FreeBSD dockerd that uses jails, etc.
Docker is about the tools to construct and manage containers, not the specific technology behind the deploy-target; the deploy-target is effectively commoditized by having a common container format!
Earlier quoted context omitted.
Some of us do, when appropriate. Docker took a technology known to many that setup/admin/manage machines, added some fluff, made things simpler, and marketed the idea. In a crowd that might spend more time thinking about nodejs and callbacks vs promises or how easily one can tip a rails app up on heroku, existing systems tools for things like jails/virtualization may either be over looked or not a concern. For every…
"added some fluff, made things simpler, and marketed the idea" Well what on earth do you need a pre-assembled computer for? You just take some circuit boards and a soldering iron, then assemble everything over the weekend and you have a perfectly good computer. I don't understand why this Apple I thing is so popular, it's nothing special. Far as I can tell, every successful piece of tech out there can be reduced to "…
Holy cow, the unit test case is fantastic.
Part of Team Foundation Server for quite some time now. With Team Foundation Server you can set up a build that ramps up Hyper-V instances with build results. Sure it is all Microsoft stuff, but the concept is nothing new.
Earlier quoted context omitted.
Containers are not virtual. Containers aren't emulating anything or translating anything. They let your partition out system and network resources as you see fit (or to protect users from abusing each other) without running kernels within kernels and other performance killing hokum.
Containers are not virtual. They belong to a category of virtualization known as 'container-based virtualization' which implements virtualized perspectives of the system within the host kernel, effectively dividing the system in to multiple systems (from the perspective of the affected processes). That is unquestionably virtualization. I believe a statement closer to what you were looking to express was containers ar…
Earlier quoted context omitted.
Part of Team Foundation Server for quite some time now. With Team Foundation Server you can set up a build that ramps up Hyper-V instances with build results. Sure it is all Microsoft stuff, but the concept is nothing new.
but aren't Hyper-V instances way more heavyweight?
The hypervisor takes the OS role, and what you see as main OS is actually a guest OS as well, that has control privileges over the other virtualized instances.
I never used this type of CI build, so I cannot speak much about the real resource usage.
I recently wrote an article that covers some of this ground: http://www.sitepoint.com/docker-for-rubyists/ The basic idea behind Docker is that you don't have to create another operating system in order to just separate your processes from each other. This leads to containers being much more lightweight than virtual machines but also significantly less powerful (i.e. powerful as in ability to do something, not in ter…
Any chance you can elaborate on: "(i.e. powerful as in ability to do something, not in terms of performance)" Do you mean smaller units of functionality which perform at good levels? For example, I wouldn't want to deploy a large, monolithic service this way?
I've been having trouble figuring out the value-add of using Docker over Ubuntu's built-in LXC functionality [1]. [1] https://help.ubuntu.com/12.04/serverguide/lxc.html
OTOH, docker lets me go *docker run ....." and have all of that done for me. That's where the value-add is for me.