> I mean I see a lot of folks doing hyper-scaling with containers, indeed you can get a lot of containers on a host and they are blindingly fast. But that doesn't excite me as much as people using it to automate their dev-test-build pipeline.<p>This is it exactly. When I can develop locally using my favorite editor and my favorite OS, but then deploy -- still locally, mind -- to what is more or less the production environment... This has huge benefits for avoiding the "works on my box" problems that arise as code makes its way to prod.
I'm using Docker as different than most people intended: To grade student programming assignments on different physical machines. And I can distribute the docker images to students, so they stop complaining "But it works on my machine". So it is a different usage of packaging and shipping code.
I'm just start to play with Docker, it seems like a nice way to build out contained systems that you don't want to change much ... but feels like it could lead to problems when it comes time to do updates to software inside the container. It feels like Docker offloads alot of responsibility for security updates from the ops to people in development. Or am I missing something ...
> Docker is operating system level virtualization. Unlike hypervisor virtualization, where virtual machines run on physical hardware via an intermediation layer ("the hypervisor"), containers instead run user space on top of an operating system's kernel. That makes them very lightweight and very fast.<p>This is one of the best explanations of Docker I've read. (Altho I suppose it requires knowing what Hypervisor is, if just at a topical level...perhaps the same for a "kernel")
Docker is great because it allows you to avoid simulating an entire virtual machine.<p>Think how ridiculous it is that in many cases today we run an entire simulated computer, with a full general-purpose operating system, just to power a single application (e.g. web server, database, etc).
Docker to me makes things an order of magnitude (or two) easier than previously possible. In time these additional layers will be as central as virtualization itself was in arriving with VMware.
After having used many years of virtualization stacks (openvz, xen, vmware, kvm), I believe using docker on production is still quite tricky, if not very tricky.
Especially for larger apps, at the very moment it's like juggling eggshells.
It requires a great deal of orchestration as you gradually involve many docker instances and especially when the host is involved (volumes, links). So yeah , I wouldn't call it actual "containerizing" the app and it's more like containerizing "processes". I for one would love to see a day where openvz gets docker-like cli and having repository for creating/pushing/pulling images.
Every time I see a post like this, I see lots of folks are super exited, but I still fail to see benefits, perhaps is the nature of my/our architecture/setup.<p>So, let's say I have a fairly typical setup, 1 web app, 1 database. Normally I would have 2 VM instances to start with. When I need to scale I add more nodes for web and/or db... both are load balanced, of course.<p>How would docker help me? I guess I should google for docker use cases, but I thought I'll try my luck here too.<p>Test/dev environments are pretty close to production ones.<p>It seems there is a lot of hype, but I fail to see it through. I'm wondering if all this hype is artificial, time will tell of course.<p>Thanks.
Because Docker just makes more sense. Why should I run multiple versions of the whole OS for near-to-identical setups? That is just a waste of resources. Docker makes much more sense when you have multiple applications you want in separate instances on the same stack. There benefits far outweigh the disadvantages in my experience.
Containers are the new craze, because they're much lighter-weight and easier to deploy than full-system virtual machines. Docker is simply a convenient approach to container distribution and deployment, designed to package up an application as a self-contained invokable container.
It's nice to have logically independent code bases on separate environments just so that they don't step over each other toes with dependencies etc. and can be moved around easily.