25 ms·

Why Docker Is Not Yet Succeeding Widely in Production

• minimaxir 11y ago
  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 infrastructure form the ground up.
  • nailer 11y ago
    Even if you're building brand new infrastructure from scratch right now many issues (discussed elsewhere in these comments and the article) are still unsolved.
    • eropple 11y ago
      Yup. At my last gig we built out a Mesos cluster and were deploying Docker containers, but we couldn't answer "how do we practically secure this to the same level as independent virtual machines?" and, finding no good answer, we went back to auto-scaling groups and baked AMIs.
      • toomuchtodo 11y ago
        Yes, doing the same thing here as well. Still using docker to streamline deployments though, but one docker container/role per instance, no "orchestration" for containers (baked AMIs, ASGs).
        • eropple 11y ago
          I did that at one place, but I wasn't super satisfied with the process--having to download container images on spin-up was annoyingly slow and I didn't feel like we were getting better dev/prod consistency versus Vagrant and Packer.
          • toomuchtodo 11y ago
            We bake the container into the AMI, so no fetch is necessary at spin up (there is no cost to generate AMIs, only storage fees, so cost is not an issue). Packer is used to build the AMIs with the containers built-in, and Docker is used both in Prod (single container to each AMI) and Dev (Docker Compose to bring up entire dev env locally). Both used a shared docker registry.
            • eropple 11y ago
              Ahh, gotcha. That's a neat approach, though the double hit of Docker builds + AMI builds feels a little weird to me. Thanks for the insight.
              • Leon 11y ago
                I also do what the other poster does, but we take it a step further and make sure that the layers on the image have smaller and more variable layers near the last layer add. On instance startup we can do a docker pull and bring down only a few k of bytes for docker image updates. This way we can update the ami less often (which it takes longer anyway) and we don't worry too much about pushing updates to the container repo without having to batch ami builds for quicker turn around deployment.
                • toomuchtodo 11y ago
                  If you're in AWS, I wouldn't worry about how many bytes docker image updates take. Our registry is using S3 as its backend, and I can pull images under 100MB in a few seconds.
                  • Leon 11y ago
                    It's not always an option to host and manage a registry, some parts it's easier for the customers to rely on a registry service like quay, in which case it can make a difference for some images to think about layering. But you are right, s3 is fast and that's one of the reasons I'm glad Deis moved to support s3 out of the box.
      • dehora 11y ago
        I was wondering, what did you think of the production readiness of Mesos independent of Docker?
        • eropple 11y ago
          Seems reasonable, if you want to be running lots of things on the same boxes without isolation (I'm not comfortable with that, but you might be). If you're sharing those resources for stuff like Spark, ElasticSearch, etc. I think it makes sense as a work scheduler, but there are a lot of other options to consider too.
      • devonkim 11y ago
        It's quite possible but the most straightforward answer is somewhat ugly - install endpoint security in every container. For example, each container would need to have intrusion detection, iptables, etc. Other options would include having containers route traffic with a virtual LAN setup and you have a container whose function is to replace your usual network security appliances. And the irony is that shared services like that can be put into both control and data planes which is easy with hypervisors and software defined networking combined with storage fabric security. When it comes to security, you honestly should be securing things at every layer anyway, but in a lot of places I see people not bothering with iptables and delegating 80%+ of the security responsibilities to operations while application teams focus upon application security.
  • shawnee_ 11y ago
    Docker will likely be more prevalent in a few years with startups who have built their infrastructure form the ground up. The opposite seems likely ... Docker will fade and become deprecated as building infrastructure from the ground up locally to feed into the cloud becomes cheaper and cheaper still. AWS is not always so cost-effective when you truly dig in and crunch the numbers. My guess as to why Docker won't succeed widely in production is because it's a software-based solution trying to glue together slippery pieces that just don't want to be glued together. The core issue of security will never be solved by a Docker-like solution; that problem is best solved by integrated hardware. This very issue is being addressed in ClearLinux: http://sched.co/3YD5 http://sched.co/3YD5
    • toomuchtodo 11y ago
      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).
      • mjn 11y ago
        > 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.
        • ssmoot 11y ago
          I agree. But that's my biggest problem with Docker. Who runs SmartOS and uses Zones? Why? 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.
  • inopinatus 11y ago
    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.
    • dasil003 11y ago
      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. The problem is that it's not a well-defined problem that can be solved by thinking really hard and coming up with an elegant model—like, for example, version control—it's messy and the effort to make it work isn't worth it most of the time right now. That's no reason to write off Docker though. Pushing files to manually configured servers or VPSes is messy and leads to all kinds of long-term pain. You can add Chef / Puppet, but it turns into its own hairy mess. There's no easy solution, but from where I stand, the abstraction that Docker/LXC provide is one that has the most unfulfilled promise in front of it.
      • batou 11y ago
        Ansible, systemd and go is stealing my heart at the moment. Basically pick the tech that doesn't cause the problems to start with. 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.
        • tracker1 11y ago
          That's a bit of my point... If you're building relatively small independent services with Docker you can deploy service A with node 0.10 as it's tested environment and service B with iojs 2.4 on the same server, without them conflicting... when you need to update/enhance/upgrade service A you then can update the runtime. The same can be said for ruby, python and any number of other language environments where you have multiple services that were written at different times with differing base targets. I've seen plenty of instances where updating a host server to a new runtime breaks some service that also runs on a given server. With docker, you can run them all... given, you can do the same with virtualization, but that has a lot more overhead. It's about maximum utilization with minimal overhead... For many systems, you only need 2-3 servers for redundancy, but a lot can run on a single server (or very small cluster/set) I have to agree on ansible, systemd and go... I haven't done much with go, but the single executible is a really nice artifact that's very portable... and ansible is just nice. I haven't had the chance to work with systemd, but it's at least interesting.
  • KirinDave 11y ago
    > is that if it ain't broke, don't fix it. I hate being passive-aggressive so I'll be directly aggresive here: this mentality is a way to say, "I don't want to revisit the operational aspects of my system because I don't like to do that work. Find someone else." Like any aspect of your system, your ops and deploy components can rot. Pretending otherwise is outright ignoring a consistent lesson offered by those who came before and have failed over and over. Docker offers to take over as a project many aspects of the system subject to bit-rot and make an explicit and consistent container abstraction for software to compose. While it has many features we do need (I agree wholeheartedly that it'd be great to parallelize layer creation, less so about secret exposure since the environment & volume tooling already can do that), it has also replaced whole categories of software and devops tooling with simple and extensible metaphors.
    • feld 11y ago
      I disagree. It's all about "the evil you know". And then there's the part where Weave is slow, so you might as well stick to VMs or hardware... http://www.generictestdomain.net/docker/weave/networking/stupidity/2015/04/05/weave-is-kinda-slow/ http://www.generictestdomain.net/docker/weave/networking/stu...
      • KirinDave 11y ago
        On Weave, yeah. Not the best performance, and improving. Flannel is obviously better, and one of the reasons we're excited about rocket. That changes almost nothing for shops hoping to move to containerized architectures now. It's only for existing early adopters. The idea that docker introduces that much uncertainty is outright fear mongering. There is a huge amount of recalcitrance in the community to do anything meaningful in the space due to a proposed risk aversion. My personal opinion is that we're all pretending we didn't write incredibly delicate and brittle provisioning and monitoring code with very dated tools. Many people I know, and more than a few I respect, ultimately point to all their provisioning shell scripts as the ultimate reluctance to change things. "It will be really hard to migrate and test these! Generating them is a pain!" Of course, the elephant in the room is we all knew this going into it and we all know we SHOULDN'T have been doing things like generate shell script execution and using git to provision on production boxes and w/e other hacky shit we've done. Of course, what we have is not any one thing but all too often an amalgam of spare hours and quick fixes and patches laid over some existing provisioning system like salt, ansible (or just a whole shit ton of puppet work). Counter-intuitively, suddenly everyone has become a devops luddite when it comes to a genuinely novel approach even though container abstractions have already proven themselves at scale. People hem and haw and suggest that somehow it's not ready for production. Meanwhile major players in the space are already using them, even for core services, with excellent results. Lightweight containerization has been used to solve this for awhile now. Docker as a product and initiative is relatively new, but to suggest it was the first example of a container engine used in production ignores the actual history of lightweight containers.
  • api 11y ago
    I have mixed feelings about Docker. I've found three major use cases so far: (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 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."
    • davexunit 11y ago
      >Docker might still be nice for perfect reproducibility Docker actually doesn't help reproducibility at all, because the underlying reproducibility problems present in the distro and build systems are used are still present. See GNU Guix, Nix, and Debian's Reproducible Builds project for efforts to make build truly reproducible. I had a good laugh when I read "the Rube Goldberg Machine development anti-pattern". This describes the situation of "modern" web development perfectly. I'll add that such software typically requires 3 or more different package managers in order to get all of the necessary software. And yes, Omnibus is an abomination and Docker is much better. I think Docker is papering over issues with another abstraction layer. It's like static linking an entire operating system for each application. Rather than solving the problem with traditional package management, Docker masks the problem by allowing you to make a disk image per application. That's great and all, but now you have an application that can only reasonably be run from within a Linux container managed by Docker. Solving this problem at the systems level, which tools like GNU Guix do, allows even complex, big ball of mud software to run in any environment, whether that is unvirtualized "bare metal", a virtual machine, or a container.
  • brianwawok 11y ago
    New startup. Did not use docker. Happy with scripts and ansible.
  • joshmn 11y ago
    I have a client, pre-funding but has some revenue, who is hell-bent on using their Rackspace credit for their production environment. "But we have a sysadmin who works for yahoo" He tries to demo me what they have currently and the damn thing timed out during login. I laughed. The cost of these headaches is easily avoidable. Get off the ground and running first, pay the kind-of-premium Heroku bill, and when you're ready to really scale, make the switch. There are few exceptions to managing an infrastructure, such as RackSpace, a cluster of AWS nodes, your own metal, etc. versus something like Heroku.
• geerlingguy 11y ago
  Some of the points mentioned in the article are in my top hitlist (for decidedly smaller production infrastructure than Shopify): Image building, Logging, Secrets, and Filesystems. But really, the most painful aspect of using Docker in production, at least in environments where you need multiple physical servers (or VMs) is overall orchestration of the containers, and networking between them. Things are much better today than they were a year (or 6 months!) ago... but these are two parts of Docker configuration that take the longest to get right. For orchestration: there are currently at least a dozen different ways to manage containers on multiple servers, and a few seem to be gaining more steam, but it feels much like the JS frameworks era, where there's a new orchestration tool every week: flynn, deis, coreos, mesos, serf, fleet, kubernetes, atomic, machine/swarm/compose, openstack, etc. How does one keep up with all these? Not to mention all the other tooling in software like Ansible, Chef, etc. For networking: if you're running all your containers on one VM (as most developers do), it's not a big deal. But if you need containers on multiple servers, you not only have to deal with the servers' configuration, provisioning, and networking, but also the containers inside, and getting them to play nicely through the servers' networks. It's akin to running multiple VMs on one physical machine, but without using tools like VMWare or VirtualBox to manage the networking aspects. Networking is challenging, but at least we have a lot of experience with VMs, which are conceptually similar. Orchestration may take more time to nail down and standardize.
  • mbrock 11y ago
    On these points, what are you comparing Docker to? Using bridged networking, you have pretty much the exact same situation with Docker as without. And just because you're running processes with Docker doesn't mean you have to keep up with dozens of tools for automatic clustering and whatnot. If you want to just start your processes manually, or with Ansible or Makefiles or whatever, you can do that.
    • danesparza 11y ago
      Agreed -- "Logging, Secrets, and Filesystems" would be interesting problems to solve in any architecture. Docker might shine a clearer light on any inconsistencies -- but wouldn't make these any easier or harder.
• filereaper 11y ago
  I think Simon nailed it with the points under this heading "Reliance on edgy kernel features" Officially Docker is only supported on RHEL 7 and up, and most systems I've seen are still on RHEL6. I think its just a matter of time before Docker goes into Production, where I'm working we're seriously looking at "Dockerizing" lots of things, but OS support keeps popping up.
  • e40 11y ago
    This, a thousand times. I'm on CentOS 6 and have switched to docker for some services that don't easily run on that OS. However, I found out the hard way that docker isn't supported on CentOS 6, by having some crashes when building containers (due to bugs in devicemapper). Painful. I really wish RH had found the time to fix RHEL 6 and support docker. RHEL 7/CentOS 7 is a big step for many. RHEL 6 isn't even near EOL and many people (including myself) wanted to get more mileage out of CentOS 6.
  • Rapzid 11y ago
    Most systems I see run debian or a debian based distro(such as Ubuntu). By comparison to RHEL, they are all running with "edgy kernel features".
• rubiquity 11y ago
  I think the reason is because the tooling and the companies (CoreOS, Joyent, Weave, etc.) building all of the tools, are only focusing on grabbing Fortune 500 customers. Nobody is building Docker tools for the "Blue Collar Apps" of the world. And those companies might be completely justified because the benefits of Docker versus Amazon AMIs/RPMs/DEBs/etc. aren't that big enough to make us go crazy for Docker and switch everything over and fork over cash to these companies. If I have less than 50 (maybe even 100) EC2 instances for my applications there is no way in hell I am going to run 3 service discovery instances, a few container scheduler instances and so on and so forth.
  • bcantrill 11y ago
    Disclaimer: I'm the CTO at Joyent. For whatever it's worth, we completely agree with the sentiment (and I like your "blue collar apps" term) -- and we deliberately have designed Triton[1] for ease of use by virtualizing the notion of a Docker host. I think that the direction you are pointing to (namely, ease of management for very small deployments) is one that the industry needs to pay close attention to; the history of technology is littered with the corpses of overcomplicated systems that failed because they could not scale down to simpler use cases! [1] https://www.joyent.com/blog/triton-docker-and-the-best-of-all-worlds https://www.joyent.com/blog/triton-docker-and-the-best-of-al...
  • NeutronBoy 11y ago
    > Fortune 500 customers Fortune 500 technology customers. Fortune 500 companies who have hundreds of millions and decades of work invested in their infrastructure generally aren't going to jump on whatever the latest infrastructure trend is.
  • vacri 11y ago
    > If I have less than 50 (maybe even 100) EC2 instances for my applications there is no way in hell I am going to run 3 service discovery instances, a few container scheduler instances and so on and so forth. You could go "old school" and have some (virtual) servers do more than one thing :)
• scurvy 11y ago
  I still haven't been sold on Docker. Why would an otherwise competent company that runs things just fine, ditch it all and adopt Docker? Just because it's the shiny new thing? What do we actually gain here in production?
  • peteridah 11y ago
    containers provide a reasonable level of abstraction/isolation for applications, and have been used in production for some years now. Docker may be shiny, but containers not so much.
    • scurvy 11y ago
      But why the need for abstraction and isolation? If I'm a reasonably well run web shop that knows how to run their apps and balance out server load, what does Docker get me? Also, shout out to the fanboys for downvoting my question, which was just a question asking for thoughts and answers and didn't make any statement whatsoever.
      • mateuszf 11y ago
        Isolation - so you can run / snapshot / restore multiple applications not influencing each other on one machine. Abstractions so that you code doesn't have to worry about different os-es, cloud providers, etc.
      • scurvy 11y ago
        @mateuszf can you give actual examples of each? I can upgrade nginx on my servers without affecting memcache or MySQL or redis or....Why the need for isolation there?
        • oldmanjay 11y ago
          Docker is a tool to empower developers to better manage the applications that we currently leave to people who, and I'm trying to be charitable here, seem to think knowing how to type and be rigid in their opinions is some kind of qualification for managing systems. It has literally nothing to do with the ability to upgrade independent pieces on the sysadmin's schedule and everything to do with abstracting sysadmins clean out of the process. The entire profession has established itself as a roadblock to progress, so like good engineers do, we're busy coding the problem away. Basically.
• nailer 11y ago
  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.
  • amouat 11y ago
    > it's possible to break out of containers Prove it. I'm not saying it's impossible, but it's certainly not trivial. Also, take a look at what Joyent are doing with Triton.
    • jgrowl 11y ago
      I was going to mention Triton/SDC. It does solve the security issues though it does it by running SmartOS. SDC is pretty cool but docker really needs to be secure in its own right. It is also worth mentioning that since Joyent has implemented their own docker client, not all features are there yet. Last time I tried docker-compose didn't really work right yet. There is a full list of divergences on their github page. It has a lot of potential though.
      • lloydde 11y ago
        > since Joyent has implemented their own docker client Not our own docker client, our own Docker engine, https://github.com/joyent/sdc-docker https://github.com/joyent/sdc-docker , which was necessary for the whole DC to be the host. For a taste of the details see https://www.joyent.com/developers/videos/bryan-cantrill-virtualizing-the-docker-remote-api-with-triton https://www.joyent.com/developers/videos/bryan-cantrill-virt... . Your larger point is correct, we're still working hard every day to add increase the support particularly for the newer docker apis and extensions. Now, docker-compose 1.2 is working in the production datacenters with docker-compose 1.3 in the east-3b (beta) dc. https://www.joyent.com/developers/triton-faq https://www.joyent.com/developers/triton-faq https://github.com/joyent/sdc-docker/blob/master/docs/api/divergence.md https://github.com/joyent/sdc-docker/blob/master/docs/api/di...
    • nailer 11y ago
      I know that 'appeal to authority' is a bad argument technique but the Docker authors themselves have mentioned this repeatedly in the past. IIRC one of the holes was sysfs. Has something changed?
• nailer 11y ago
  The security question (it's possible to break out of contains) isn't solved, and the workaround (use VMs) eliminates many of the advantages of containers and adds a massive burden.
• zaargy 11y ago
  TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.
  • shepardrtc 11y ago
    Yes, exactly. I really can't recommend that my company use this right now because of the complexity. The Hello World image is easy, but after that, there's quite a bit involved. And my company is already happy enough with spinning up VMs.
  • huskyr 11y ago
    I have a feeling this is not just a problem with Docker. People tend to choose technologies not because they solve their problem, but because it's hip to be using the newest stuff, even if it's far too big and complicated for their simple usecase.
    • mseri 11y ago
      In this regard I think the remarks of McKinley's "Choose Boring Technology" [1,2] is quite relevant. [1]: http://mcfunley.com/choose-boring-technology-slides http://mcfunley.com/choose-boring-technology-slides [2]: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
      • therealmarv 11y ago
        Big thanks for this links. Actually this is really true for Docker and DevOps. There are proven concepts and known unknown but for Docker the unknown unknown part is really scary especially regarding security for production. Maybe for bigger companies this is no problem but for small dev teams this is very risky and time consuming. Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and easy with `sudo apt-get install fail2ban`. Now try to secure CoreOS against sshd attacks. There are guys out there who tried to run fail2ban in a container (without luck) and so far I've only found one hacky script which tries to do the same oO https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blob/master/tested/blackhole.cloud-init https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blo...
• mc_hammer 11y ago
  the comments nailed it here too ;d ill highlight the website is off by one... reading the website i have no idea how it works and what technical debt im adding to my teams stack by using it. "Build/Run/Ship", I'm doing that already. I have no idea if its using VMs or something else for containers. no idea if my hardware works on it. and no idea if the distros used for images are 1 year old or -nightly, so whos security issues am i inheriting?
• therealmarv 11y ago
  I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise: What underlying OS, how to connect this containers, how to preserve state of my database and logs (it's not trivial as the article proofs again). So overall Docker makes life not easier on this simple use-case, it makes life (of the sysadmin) more complicated.
  • pat2man 11y ago
    Kubernetes solves this by mounting external volumes (say NFS or iSCSI) on the host and then exposing them to one or more docker containers. This seems like a pretty ideal solution for any Docker user.
    • therealmarv 11y ago
      thanks I will definitely look more into Kubernetes.
    • rubiquity 11y ago
      Are you suggesting that a person with a total of 3 nodes use a system like Kubernetes which requires at a minimum (correct me if I'm wrong) 5 nodes just to function? If you really, really want to use Docker with a typical Nginx-App-DB setup just whip up the necessary shell commands to start/stop/log containers and throw that in Ansible or the like. edit: I guess you can cram all of the various Kubernetes master/etcd servers on a single node but whoops there goes reliability.
      • xkarga00 11y ago
        How did you come up with that number of nodes?
        • 11y ago
• shepardrtc 11y ago
  I think containers are the future, but I think this generation is still a bit early for widespread use. Once they get polished a bit and are made easier to use, then I think companies will begin adoption.
• stephengillie 11y ago
  I'm confused by this paragraph > Every major deployment of Docker ends up writing a garbage collector to remove old images from hosts. Various heuristics are used, such as removing images older than x days, and enforcing at most y images present on the host. ... More specifically, I'm confused by this sentence, from the above paragraph in TFA: > Most people discover their need by accident when their production boxes scream for space. When did Docker become a replacement for Ops or Devops which are aware of their servers, monitoring systems that let you know when you're getting close to the "Yellow Alert" warning, and some sort of plan for growth and expansion? Hardware isn't free, but it seems like some want Docker to make hardware free; delivering on the promise that full-OS VMs couldn't realize, which was trying to deliver on the promise that HT couldn't make happen. I'm sorry, but if you have 24 cores and 64GB of RAM, there's only so many ways to schedule and swap to maximize use of those resources. --- Copy on Write (COW) sounds like Thin Provisioning. Thin Provisioning is known for 2 things: 1. Slower performance than "Thick Provisioning" where the entire allocated space is zeroed on allocation, instead of on write. And 2. Ease of overallocation - you can take a 100GB disk and create 10 virtual disks of 100GB each; this is like reserve banking, and it's only a problem if someone actually wants to use the entire resource that you say they can access. I'm curious if they'll have an NTFS option. Actually, with Microsoft's recent open sourcing, I'd be interested to see NTFS open up a bit; maybe get an official Linux driver of some sort. Will there be other write methods? Perhaps one that's more similar Thick Provisioning? --- I'd hate to see VMs die. The flexibility and value they provide to the Microsoft world is unparalleled. I could see Dockers replacing Linux etc VMs -- no need to run CentOS(?) to host your LAMP stack when you can just have each letter in its own cluster of containers. Maybe if each Windows component was rerolled as a container image; we could have Domain Controller (DNS/AD/LDAP/Kerberos/ACL) containers, IIS containers, SQL containers, DFS containers that were backed by SAN or NAS, FTP containers, TFS containers, etc. And there would have to be RDP/VDI containers, where users could remotely connect, and work in the environment with a desktop and GUI tools, since that is such a core part of the Microsoft ecosystem. --- Looking at the Security and Image Layers and Transportation sections makes me realize how young this technology is. In a few more years, a few more iterations, and this could definitely replace numerous VM Appliances and Middleware devices. The time for Dockers and containers isn't quite today, but it's very close.
• technofiend 11y ago
  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 developers may never have root access under any circumstances, you end up with a chicken and egg scenario: if developers don't have the ability to test container creation (because doing so might grant them root access in a container), who does?
  • Smushman 11y ago
    This is why it is not yet adopted by DevOps and IT 'in the wild'. 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.
• icedchai 11y ago
  It's not succeeding because it's usually not necessary.
• benjaminwootton 11y ago
  "However, for many production users today, the pros do not outweigh the cons. Docker has done fantastically well at making containers appeal to developers for development, testing and CI environments—however, it has yet to disrupt production." I keep hearing about people putting Docker in dev and test environments and not production. This use case makes no sense to me as you would throw away the entire point of containers and have a wildly inconsistent path to production.
  • spinningarrow 11y ago
    Does anyone have any good links to using Docker for development? Even a simple `npm install` in a docker container fails on Windows because of the lack of support symlinks (adding --no-bin-links means npm's run scripts can't be used to their full and useful extent).
  • superuser2 11y ago
    Not necessarily. If you're in a microservice architecture, it can be very attractive to "docker run" all the services you're developing against on your development VM. Relying on Puppet (as with prod) means development VM setup/change time is measured in hours. My company's Puppet catalog takes 15 minutes to compile, 6 hours to run. Entire days of developer productivity are lost trying to get development VMs working. Docker would make that instantaneous. It's also very hard to manage and synchronize data (i.e. test fixtures) across all those services. With Docker you could have a consistent set of data in the actual images and revert to it at will.
  • jamesRaybould 11y ago
    We are looking at using Docker to help make our dev environments a little bit more sane. We deploy to Heroku so we use the Heroku docker image to give us (what is hopefully) as close to production environment in dev as possible. I have got docker working in a proof of concept project but the performance on OSX when using volumes, so you can actually dev on it, pretty terrible.
• amouat 11y ago
  For a forum like this, it should go without saying that many of these problems are really opportunities for successful businesses. Containers are only going to grow in uptake; companies like Weave and ClusterHQ have a very bright future if they can solve real pain points like the ones in this article.
• mariusmg 11y ago
  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.
  • LoSboccacc 11y ago
    eh, this is part of hiring the cheapest people to save the bottom line. it creates problems where there should be none.
  • mrweasel 11y ago
    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.
    • stephengillie 11y ago
      As a Windows admin, this sounds like a recipe for disaster. My networks are already getting crowded with Appliances and Appliance VMs that are provided to us as black boxes, and we have to depend on a 3rd party for security patches and a durable security implementation. 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.
    • acd 11y ago
      Docker is called App-V when it is runs on Windows instead of Linux. App-V virtualizes the registry, provides app portability. Unfortunately full App-V is only for Windows enterprise customers.
• davexunit 11y ago
  I like Linux containers, but Docker's image layering system and imperative Dockerfiles have got to go. A lot of pain points can be fixed by using declarative, functional package management and not relying on COW file system hacks to sort-of deduplicate files amongst many containers.
• joslin01 11y ago
  I wrote about my experience with deploying Docker & ECS here: https://news.ycombinator.com/item?id=9759639 https://news.ycombinator.com/item?id=9759639 I'm frustrated though because I keep pinging them about adding branch information to their (dockerhub) webhooks so I can actually deploy environments via branches.. It's crazy vital in my opinion and seems like it should be an easy fix, but 2 months later and still doesn't seem to be scheduled in. Nevertheless, I'm sure Docker has its technical shortcomings but really, I wouldn't say it's not succeeding.. it's just young. Adoption takes time.
  • ChuckMcM 11y ago
    I have seen similar issues with a other packages, where their popularity has outstripped the core teams ability to incorporate feedback. Basically the core team can't scale the feature set fast enough to meet demand. On the plus side over time they get to things, on the minus side if someone executes better they sometimes can take away the momentum/lead from the original package.
  • loki77 11y ago
    Just up front: I'm one of the folks developing Empire. That said, what we do is we have our CI system build our docker images, push them to dockerhub (private registry) if the tests all go great, and then we deploy using https://github.com/remind101/deploy https://github.com/remind101/deploy. We also tag all our images with the git SHA that they were created from, so we have immutable identifiers for each image, which has been useful. We just recently put direct github deployment support in Empire, so that's been really nice (before we had to use another service that pulled deployments and put them into Empire). Anyway, not quite the workflow you're talking about, but it's really worked well for us, so maybe it'd help you as well :)
• hangonhn 11y ago
  From my experience it is still buggy. For example, this bug: https://forums.docker.com/t/docker-export-intermediate-size-multiple-times-container-size/2537 https://forums.docker.com/t/docker-export-intermediate-size-... No one seems to know anything about it. Also, when we upgraded from 1.6.3 to 1.7, devicemapper started having issues. On top of the bugs, the limited networking support is very, well, limiting. I would be very hesitant about using it in production at the moment. That said, I can also see the potentials and it seems to be heading in the right direction. It's just not ready at this moment.
  • scjody 11y ago
    Yes indeed. I'll trust Docker in production when I can go 6 months without hitting any weird bugs like that, or having to wipe out `/var/lib/docker` and restart the daemon to get it out of some inexplicable state.
• peu4000 11y ago
  I'd really love to include docker in our puppet testing framework, so we can do actual meaningful tests without deploying to real environments. But, dealing with all of the problems of deploying docker to production doesn't look worth the time investment for a medium sized company IMO(we're at ~1700 vms)
  • omni 11y ago
    What does vms stand for?
    • Synroc 11y ago
      Virtual Machines
    • deleted 11y ago
      [deleted]
• altcognito 11y ago
  It is still early, and it took nearly half a decade to get companies to use cloud services and that has a well defined API for orchestrating resources. It will take similarly long for containers to have well tread paths for discovery, logging, failover, image building etc... etc..
  • omouse 11y ago
    it took nearly half a decade to get companies to use cloud services and that has a well defined API for orchestrating resources There's lots of stragglers; sometimes it's a struggle to get people to even consider AWS for development boxes.
• Moter8 11y ago
  Offtopic: http://i.imgur.com/E3UyqFO.png http://i.imgur.com/E3UyqFO.png Well, that was weird. A refresh fixed it. Chrome 44.
• JustSomeNobody 11y ago
  Can I Dockerize Windows?
  • ZenoArrow 11y ago
    The next release of Windows Server (Windows Server 2016) supports native use of Docker. http://www.tomsitpro.com/articles/windows-server-2016-containers,2-940.html http://www.tomsitpro.com/articles/windows-server-2016-contai...
• kitwalker12 11y ago
  I think the author missed orchestration. docker-swarm/docker-machine is still not production ready and kubernetes is too damn complicated to setup outside GCE
  • crb 11y ago
    Can you share your experiences with Kubernetes setup?
    • kitwalker12 11y ago
      It's pretty complicated with GCE itself. for GCE, I followed this http://kubernetes.io/v1.0/docs/getting-started-guides/gce.html http://kubernetes.io/v1.0/docs/getting-started-guides/gce.ht... guide. I eventually wanted to set it up in Rackspace where my company cloud lives. I used corekube(https://github.com/metral/corekube https://github.com/metral/corekube) heat templates to set it up but the way to add more minions to the cluster wasn't simple. On top of that there's this complicated networking I have to setup on rackspace, because k8s runs in its own flannel subnet which is actually overlayed on top of an isolated rackspace private subnet. To access the API externally I had to do some NAT manipulation to interface that private subnet to the rackspace public IP just to get the guestbook example working. Dunno how I'd have managed that with a more complex setup of multiple services.
      • mkulke 11y ago
        Corekube is somewhat complex template (and not supported by kubernetes currently). Just attempt to roll your own, it's actually not that hard. You can use the official coreos "getting started" cloud-config files as a starting point. Etcd & flannel are required, the rest is just wiring a set of binaries. Adding nodes is pretty straightforward, you just create a server with the proper cloud-config, they should auto-register at the master. A serious setup, however, involves using security groups/private networks and load balancers, also cinder is not supported as a volume backend yet.
        • kitwalker12 11y ago
• morgante 11y ago
  Where's the evidence that Docker isn't succeeding widely in production? In the past week alone I've talked to a dozen or so companies who are all using it in production.
• DyslexicAtheist 11y ago
  docker security issues[0] should really be listed as #1. The overhead/complexity of getting it secure (using SELinux) outweigh its benefits in production. [0] http://blog.valbonne-consulting.com/2015/04/14/as-a-goat-im-skeptical-of-dockers-hype/ http://blog.valbonne-consulting.com/2015/04/14/as-a-goat-im-...
  • mixmastamyk 11y ago
    I don't think its a good choice if security is a main concern. I wouldn't put multi-tenant apps on it either.
• saosebastiao 11y ago
  I'm pretty disillusioned with docker so far. Haven't put in too much time with it, but the little time I have put into it has produced nothing of value. I'm surprised we're still talking about it to be honest, with so much progress in unikernels like OSv, HalVM, Mirage, and Ling. In the two hours I've spent with OSv, I've gotten much lighter weight VMs that boot my large scala app extremely quickly (a few seconds, max), with less configuration and more predictable performance.
• crb002 11y ago
  I would venture to say that Packer/Mesos is far more important than Docker. You get automated full infrastructure builds from source or trusted binaries, and full cluster management. Docker is useful when you have many layers of apps turtled together as snowflake configurations.
• DannoHung 11y ago
  Hey, cool, trough of disillusionment! That means we're like a year away from it being boring and just working, right?
• gusfoo 11y ago
  > Configuration management software like Chef and Puppet is widespread, but feel too heavy handed for image building. I bet such systems will be phased out of existence in their current form within the next decade with containers. Hmm, I don't think so. My reason is that, in addition to the maturation and feature growth of containers, there will also be feature growth in Puppet et al.
• deleted 11y ago
  [deleted]
• krzrak 11y ago
  "it has yet to disrupt production" This overused buzzword in context of production looks ridiculous.
• markbnj 11y ago
  I agree with many of the points expressed, and as someone who has used docker in production I have run into many of these issues myself. At the same time, I value composability and I don't want docker to have a single monolithic approach to everything. Garbage collecting old images, fine, even though its not that hard to deal with the issue. Logging and distribution of secrets don't feel like docker-level concerns to me. There are good solutions for both.
• biturd 11y ago
  >Developing the public mental model of containers is integral to Docker’s success and they’re rightly terrified of damaging it. I guess you can all call me a moron or close to it, to this day, I don't know what a container is good for. I'm reading this now: https://www.docker.com/whatisdocker https://www.docker.com/whatisdocker Is this server level, user level, both? Something else? I saw a Hacker Con video and someone was basically containerizing all their apps so that the underlying OS basically did nothing but run the hardware and containers. Does this mean, one day, instead of monitoring my installs on Mac OS X to see what files were put where so when something breaks I can find those files? I could simply install to a container, my OS would not be touched, and I could delete the container and be back to a stable state? Can you even get OS X to run on a container? Would it be a good idea or even feasible to install PhotoShop in a container, or not even possible, as that app tosses stuff all over my OS. Or, is this more like a different way to do things, but it is still AWS and their AMI's or Digital Ocean or any of the others. I feel I am completely falling behind and have no idea why I would need one of these. Hell, if I made an iOS app, I have no idea if there are Apple servers you pay them to use for stuff, or if you deploy your own servers, or you use something like AWS, and how does that scale on demand, do you have to build that into your s=infrastructure, or is there a "auto scale as demand dictates" checkbox? Is AWS, Docker, all the rest, in the end, is this just like in the old days where I would have 42U of rack space, put in a DNS server, put in a few http servers, use this as round robin image load balancers, DB servers, backup DB servers, replication DB servers. And when I needed to grow for heavy demand for a day, that was an issue. I fail to see how you can scale based on demand when a database is involved. Databases scare me, one thing never talked about... We have git for code, what about databases. How does a dev team work that out? If you need a new field, drop some data, alter a table, add an index, etc. How do you get what you have on your local machine in test out to live? How is every little database change tracked and rolled back if need be. How do the DBA guys communicate with the coders to make sure a name change to a table gets updated in the code. Is there git for postgres and others? All this made sense to me 5 yeas ago when the cloud was called the internet and email, ftp, http, etc were all part of the "cloud" or as I call it "the internet". But now, things are confusing, wrapped up in terms like "cloud" that make no sense to me. I have been, as we all have been, using "the cloud" for over a decade, the first time I logged into a slip account and got on some gopher server or similar, that was cloud to me and I believe it still is. POP email is cloud, the internet is cloud. It is now just convoluted to the developer so end users understand something that really only developers need to understand. Am I making the same mistake with containers, and they are nothing special and have been around for ages like the cloud and it is just a buzzword now? Apple has sandboxing and something called containers in their OS, is this similar in principle? Auto makers don't burden their end users with engine shop talk, nor dumb it down for them into simple terms, but we seem to with tech. This should be it's own post but I just kinda got on a roll, sorry.
• emergentcypher 11y ago
  My application compiles to a jar that runs on a server and expects an accompanying config file. I've tried giving Docker a whirl a few times and I never fully understood what need I had that it was solving.
  • why-el 11y ago
    Is your application just a jar? In the yes case your conclusion is correct. Throw in a database, a cache server, couple of versioned libraries your jar file needs, and more developers, and suddenly a reproducible image with all this packaged will make a lot of sense.
    • regularfry 11y ago
      In that instance, docker doesn't buy you much over vagrant. Docker stands to win where you've got 15 different apps which all need to come up together so you can QA the combined set of services in a single VM on a tester's desktop.
    • emergentcypher 11y ago
      Our build process already includes the application's dependencies inside the jar, and packages it into an installable deb file that places the app, its config, and the init file in the right locations. I have a database and a cache server. They don't run on the same server as the application jar... they run on separate machines tuned to their purpose. Why would I want them packaged together? So my team doesn't have to run "apt-get install postgresql" on their dev machines? Or to maintain an exactly consistent dev environment?
      • mixmastamyk 11y ago
        How fast can you replace one of those servers when they go down? More info: http://martinfowler.com/bliki/SnowflakeServer.html http://martinfowler.com/bliki/SnowflakeServer.html
• dcosson 11y ago
  The security point here is something that confuses me about the current state of the ecosystem. The article mentions that "most vendors still run containers in virtual machines", presumably since if someone hacks an app in a container they might be able to break out of the container and access other apps running on that host. But clustering systems like Kubernetes, CoreOS, AWS Container Service, etc. seem to be all the rage these days and they seem fundamentally at odds with this. The cluster might schedule multiple containers on the same host at which point somebody who hacks one can hack all of them. How do you reconcile this? Do people running these clusters in production typically run tiers of separate clusters based on how sensitive the data they have access to is?
  • Leon 11y ago
    Once you've automated the entire process of bringing up a container cluster with monitoring, metrics, logging, etc then it becomes trivial to make as many as you want. The same is done with separate virtual networks for security concerns. It becomes as simple as asking what name the cluster should have. It also makes sense from managing resource concerns to some extent, such as a cluster with cheap instances for low priority applications but need HA support or a cluster with beefy instances in a subnet that has fewer hops should be used for edge tier applications.
• reidrac 11y ago
  So far my experience with Docker has been quite exciting, but I'm still to find a real good use case for it. Also moving around a 700MB+ image when you can deploy some Debian package (or even setup a virtualenv, I do mostly Python), sounds a waste of resources. Add to that that moving volumes around is still an issue and... well, Docker has a lot of potential, but I doesn't fit very well in any of the projects that I'm involved in.
• novaleaf 11y ago
  I run a tiny startup, and honestly don't see a benefit to using docker. Every service I deploy gets it's own VM (which is automatically provisioned/locked-down by a bash script), and they automatically update when a new revision is pushed to our production git branch. It seems that docker is more useful when you have physical hardware? and/or lots of under-utilized infrastructure?
  • boomzilla 11y ago
    Yes, and even when you run your own hardwares, it's still far easier to just KVM up your virts and "bash bootstrap.sh". For your developers, tell them to "vagrant up" with the same "bootstrap.sh". This setup and a Jenkins server for build artifacts solves all my devops needs.
• limaoscarjuliet 11y ago
  I work in a place which, in order to solve the dependency nightmares, had some highly paid people do magic tricks manually in order to save the day... every day. Every upgrade was hell. Yes, we have Director of Upgrades. Simple tools (rpm + yum + docker) allowed us to replace these people with a simple shell script. Literally. I agree with the article Docker is missing some things. Two that I would like to see: - Auto cleanup - Clean and easy proxying
• peterwwillis 11y ago
  Am I the only person noticing that these problems only exist because you're using containers, and that maybe by not using a container model you can simplify everything except running 10 different versions of an app at once? Maybe containers provide more headaches than they solve.
• Animats 11y ago
  Docker is part of the first generation of a good idea - containerization. The problem is that there's too much stuff in the box. Each application doesn't need its very own copy of everything. You get portability at the expense of maintaining your own distro. There will be a second generation of this, hopefully not so bulky.
• x5n1 11y ago
  This tutorial shows how to deploy a micro docker container with WordPress. Each microcontainer has its own instance of Nginx and PHP-FPM. An Nginx server as a proxy sits on the front end serving connections to one or more sites hosted in the containers. It uses Alpine Linux and persists all data on the host's file system. The logging is also available on the host system. The benefit of doing it this way is that each site sits in its own container, so if it is compromised, no harm comes to any other site or services running on the host system. It also does not link containers, instead opting to attach the database to the first IP address of the network Docker sets up, thereby avoiding the need for complicated service discovery. It also includes instructions on how to deploy Redis on the same box and use that with WordPress. Also includes instructions on how to do SSL for each site. It's being used in production. http://www.dockerwordpress.com/ http://www.dockerwordpress.com/
• iamleppert 11y ago
  I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll cry! Meanwhile you have 0 rows of data before you've paid them their first month's salary and have spent time on solving problems of scale you'll never have. Focus on your product, outsource the rest. And leave customized docker setups to mid-stage startups and big corps who already have these problems, or at least the money and people to toil on them. Not everything needs to be a container! And most companies are not and will never be Google!!
  • deleted 11y ago
    [deleted]
  • kosma 11y ago
    Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what happened; they kinda worked, but the farther we got, the more kludges piled on top of each other. In four months work we didn't even hit production - the most we got was a CI/QA service that was actually nothing more than a loose bunch of Python scripts. Between managing dev/test/prod differences, tracing missing logs, removing unused volumes, networking all that stuff together and trying to provide at least a decent level of security, I realized that I'm wasting everyone's time and money. Developers hated it because it filled their workflows with traps and obstacles. Admins hated it because of the lack of tooling. Business hated it because it caused unexplainable delays. The only thing we really accomplished was some compliance with the The Twelve-Factor App - something that could've been done in a week. Hardly a victory. My advice? Forget about Docker unless your primary business is building hosting systems. It will take years before Docker gets mature enough for production, and not without a ton of tooling on top of it and some major architectural changes. Until then, go back to the old UNIX ways of doing things... it worked perfectly since the Epoch and it will continue to work long after the 32-bit time_t rolls over. You'll be fine.
• AaronFriel 11y ago
  I thought the obvious reason was storage. I don't see it mentioned here, but storage is a huge pain point. How do you store your critical data "with Docker" is a labyrinthine set of steps. Docker's answer to storage so far has been "don't use Docker". That's their answer. Use volumes to map some other storage, but then you have to have some way of mapping storage to containers outside of Docker. Now you're really stuck. Containers are awesome, but unless your product doesn't do work, you'll need to store data at some point. And that's when the magic stops.
• siliconc0w 11y ago
  Just to oppose the pessimism here - we use docker in production and so far it has worked pretty well. We do run into the problems mentioned in article but they aren't insurmountable. We also built a tool around cluster/deploy management just like we had to do with chef. IMO any tool that does procedural run-time configuration like chef/ansible/puppet will generally be inferior to an image based infra management solution. (unless you're using said tools to build images - which is another ball of wax that will likely end up looking like a reimplemented docker) The problem with procedural run-time config is that unless you blow away the VM, build from scratch, and run a test suite you don't really have good assurances your infrastructure is in a good state. With images, you have a bit for bit copy of what was built and tested in CI or QA. This is, for us, worth the price of admission.
• cyansmoker 11y ago
  Regarding the author's point on reaping children, it is a well know issue. I wrote (and I'm sure I'm not alone) a replacement 'process 1' for that: https://github.com/Fusion/cfr_reaper https://github.com/Fusion/cfr_reaper
• ksec 11y ago
  I always think Docker is just another layer of complexity. Which most people dont need or shouldn't have
• oldmantaiter 11y ago
  Using Docker as a local development system (especially with boot2docker on OSX creating a bunch of containers with different major versions of OS (el6/el7 for example) and being able to develop/test multiple apps at the same time is the only benefit I can justify for Docker. But that's as far as I will take it, Docker is mainly used (from what I've seen) as a nice way to package something without having to write an actual package (RPM/deb) that will work across multiple platforms (for the most part). If you take the time to learn how to properly package your application, docker is unnecessary in almost every case.
• pjotrp 11y ago
  Docker for reproducible Science is an intermediate solution. While a Docker image can be moved and rerun (with some luck) the content of a Docker image is actually not transparent. Reproducibility implies being able to regenerate the full container including software version control and visibility of the full dependency chain all the way down to BLAS and glibc! You can't do that by using apt, rpm, Perl CPAN, rubygems, Python pip and the like. None of these package managers have been designed for true isolation of packages and full reproducibility. That is why today people go with Docker. The shortcomings of these package managers drive people to Docker. The technology for regenerating exact Docker containers exists in the form of GNU Guix and/or Nix packages. The fun fact is that when using GNU Guix, Docker itself is no longer required. Watch GNU Guix.