131–140 of 290 posts
Earlier quoted context omitted.
Can we please stop sounding the trumpet of "progress"? Containers have been around for nearly a couple of decades (possibly more if you extend the definition), since IBM i had LPARs. There's nothing fast-moving or technologically novel about, especially, Linux containers.
Yeah, but the layered images and copy on write nature of Docker has not and IMHO, that is what is novel about this new wave of containers.
Earlier quoted context omitted.
docker-compose comes to save the day when it comes to how to connect containers. Your Dockerfile will specify which underlying OS is used. Preserve state of your database with data volumes.
docker-compose is no magic, it only maps a YAML file to docker's command arguments. While I think docker-compose is useful in some cases, I strongly advise to not use it at first so you understand how docker actually works. Once you understand how docker works, using the YAML file can become useful to lighten your load.
[1] https://github.com/glowdigitalmedia/glowmachine-docker/blob/...
Earlier quoted context omitted.
Docker solves a problem that most people don't have. It's not a PaaS, rather, it's (some of) the building blocks to create your own PaaS. Most folks don't need that. Most folks want to put files on a server and start a process. For those folks, Docker in the raw ends up being a whole lot of confusing & unnecessary scaffolding.
There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked . The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time.…
I still reckon that the main reason VMware ESX is as successful as it is comes down to the lack of isolation and sheer deployment hell that windows has been for years. The same can be said for python or ruby on a Linux machine for example. Docker removes some of that pain like ESX does.
Maybe because Docker isn't really needed ? I mean if your app needs the entire fucking OS to provide isolation from other apps, then you are clearly doing it wrong.
Don't underestimate the amount of people doing things wrong. Docker could be much more successful in the Windows world, the ability to package very precise versions of databases, libraries, weird obsolete application into one image that can be deployed easily would be extremely helpful in many companies. It would be the wrong solution, but an easy work-around for broken upgrade paths.
Having containers able to package weird obsolete (unpatched) applications, specific (out-of-date) versions of libraries, and poorly-written homespun code is a recipe for exploits. The out-of-date version of the library (e.g. Java 7) likely has exploits out in the wild that have been patched in more recent versions. The weird obsolete application (e.g. DTS) likely not only has exploits patched in the active codepath, but has multiple bugs and integration issues. The homespun code likely reimplements something done better in another application or library, and introduces more bugs and vulnerabilities to the network.
Sorry for going off on this, but being able to repackage unsupportable applications would be a nightmare in places I've worked before.
Earlier quoted context omitted.
If the goal is to simplify deployment process, why not use something like Capistrano or Fabric? You can run 'Cap deploy '
Because, as mentioned, I already deploy in one line: git push deploy/uat and I didn't have to write a single deployment script to achieve it. Plus, by using Dokku I get the benefits of containerised apps.
While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…
(1) Testing.
(2) Build environments -- it's helpful to build distribution Linux binaries in older Linux versions like CentOS 6 so that they'll work on a wider range of production systems.
(3) Installing and running "big ball of mud" applications that want to drag in forty libraries, three different databases, memcached, and require a custom Apache configuration (and only Apache, thank you very much).
#3 is really the killer app.
This has led me to conclude that Docker is a stopgap anesthetic solution to a deeper source of pain: the Rube Goldberg Machine development anti-pattern.
More specifically, Docker is a far better solution than the abomination known as the "omnibus package," namely the gigantic RPM or DEB file that barfs thousands of libraries and other crap all over your system (that may conflict with what you have).
Well written software that minimizes dependencies and sprawl and abides by good development and deployment practices doesn't need Docker the way big lumps of finely woven angel hair spaghetti do.
Docker might still be nice for perfect reproducibility, ability to manage deployments like git repos, and other neat features, but it's less of a requirement. It becomes maybe a nice-to-have, not a must-have.
But... if my software is not a sprawling mess that demands that I mangle and pollute the entire system to install it, why not just coordinate development and deployment with 'git'? Release: git tag. Deploy: git pull X, git checkout tag, restart.
Finally, Docker has a bit of systemd disease. It tries to do too much in one package/binary. This made the rounds around HN a while back:
https://github.com/p8952/bocker
It demonstrates that at least some of Docker's core functionality does not require a monster application but can be achieved by using modern filesystems and Linux features more directly.
So honestly I am a bit "meh" about Docker right now. But hey it's the hype. Reading devops stuff these days makes me wonder if "Docker docker docker docker docker docker docker" is a grammatically correct sentence like "Buffalo buffalo buffalo buffalo buffalo buffalo."
Just my personal opinion but Docker still reflects the developer-centric culture that inspired it and by that I mean security is still getting more mature but isn't quite there yet. For instance there's still work being done to add native PAM and by extension Kerberos support, and the daemon runs as root, thus requiring extra caution about who may run docker commands. If you're (for example) in an enterprise where de…
In summary from a person in that scenario:
1. Not known of and too short of time horizon - People still run Windows XP in the real world. Changes where the rubber meets the road (IT and DevOps) take years of hard evidence, infrastructure cost, justifications, etc. to catch on. It does not behove these groups to be an early adopter.
2. Not flexible enough yet - I have a ton of use for this if I could run it more like a VM but faster and easier to deploy. I devop with a product that uses its own kernel... I tried to talk Dev in to compiling a kernel with Docker for a use case I have - you can guess where that went.
Docker is great, but I can only use it with my devs in its current state and for myself in specific cases.
Earlier quoted context omitted.
DevOps/infra guy here rolling out Docker startup-wide at the moment. You and minimaxir are both correct. With regards to docker/lxc/container security, you're right. Some of the biggest players haven't solved the lxc/docker/container security issues yet; its a really hard problem to solve. Breaking out of container will always be easier than breaking out of deeper levels of virtualization (Xen/KVM).
> Breaking out of container will always be easier than breaking out of deeper levels of virtualization (Xen/KVM). I agree it's not easy to get right, but it doesn't seem necessary that containers will always be leaky. Solaris/Illumos Zones are an OS-level virtualization approach that's pretty airtight, for example.
When you have a local server, that supports KVM and Zones, you choose KVM as the cleaner abstraction. While surrounded by neat tech, Zones are actually a bit of a pain and not all that portable between systems IME. OTOH I can `zfs send/recv` over SSH, drop a short bit of JSON in, and have my KVM instance reliably moved to another SmartOS box 100% of the time, no worries.
So unless you're really worried about that last 5% or whatever of overhead, what's the point of Docker? It's not actually very portable at all it seems (on my Mac I'd have to run it inside VirtualBox). I don't have much experience with it, but my guess is that similar to Zones, you're at the mercy of the host system as far as common dependencies like OpenSSL or gcc go.
It seems like a solution to a problem I'm having trouble even imagining. A slightly lower overhead, less secure, less portable lightweight "VM" with slightly less overhead. I guess if you're a PaaS and you could increase margins by 5% overnight by switching to Docker that might make sense?
As someone who's set up Solaris 10, OpenBSD, FreeBSD, SmartOS, Debian, Redhat, Ubuntu, KVM, Xen, etc etc etc, I just have a real hard time figuring out Docker's value proposition. It seems like the Solaris world went from Zones to KVM, and some people are attempting to do just the opposite. Which I just can't think of a good excuse for.
Earlier quoted context omitted.
Docker solves a problem that most people don't have. It's not a PaaS, rather, it's (some of) the building blocks to create your own PaaS. Most folks don't need that. Most folks want to put files on a server and start a process. For those folks, Docker in the raw ends up being a whole lot of confusing & unnecessary scaffolding.
There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked . The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time.…
I get that when I use the same OS and built-in package manager?
I would virtualize the environment using something like VirtualBox for my dev and EC2/DigitalOcean/etc on prod.
> and dependency isolation
If you're going to scale something, you're going to split everything out on different virtualized servers anyway, so you'll get your isolation that way.
Basically, current mainstream practice is to virtualize on the OS level, where as Docker is pushing to have things virtualized on the process level.
I personally don't see the advantage ... just more complexity in your stack. I never have to mess with the current virtualization structure, I don't even see it. It looks just like a "server", even though it's not. Isn't that better?
The security question (it's possible to break out of containers) isn't solved, and the workaround (use VMs) eliminates many of the advantages of containers and adds a massive burden.