4 ms·

I have read a lot about Docker now. Here and elsewhere. I even have been to Docker talks in my town. Still I do not get what the usecase is. Everytime I ask th

• cleverjake 12y ago
  sysadmins who have to run services. the same way you separate you model from your view from your controller, you can separate your various services from one another.
• drinchev 12y ago
  Imagine you have 20 services that need to run with your website ( 5 database daemons, 5 nodejs apps, 5 ngnix instances, 2 dns servers, 2 mail smtpd daemons, 1 git repository ). Your infrastructure consists of 5+ virtual servers that host your services. Each virtual server might be database only or db + dns or web + dns or ... you got the point. What docker allows you to do is to isolate all those 20 services in separate containers that if any of them is being hacked your attacker will end up compromising only that service without any access to the main server. What docker allows you to do is to version control the configuration and the container for the different services in a way that if you need to reinstall a service ( redeploy your app ) it is less of a hassle and since it is containeraized you will not be compromising your other services while doing that. etc.
  • bildung 12y ago
    Maybe I misunderstood GP's question, but what you describe has been done with countless other solutions for years, why should I specifically use docker and not stay with kvm, or bsd jails, or...?
    • dmpk2k 12y ago
      At least in the case of KVM, it's a very heavy-weight solution. Hardware virtualisation takes more RAM, and the I/O is substantially lower. I think hardware virtualisation (e.g. KVM) should only be used when the use-case demands it (e.g. Windows, OS development, or legacy applications). As for why Docker? Dunno. While I think illumos zones are pretty awesome myself, having a standardised format is handy. Docker is also popularising the container mantra with Linux.
  • bithive123 12y ago
    To add to bildung's comment, what many of us are wondering is given all the existing tools and complexity, why add another integration point? In the scenario you're describing where you're provisioning virtual machines in a cloud, shuffling docker containers around on a fleet of VMs may not be the way to go. Many people would use some combination of disk images and configuration management to achieve the same ends.
  • davidw 12y ago
    So you have 20 containers each running their own version of the OS? Don't you have to spend a lot of time keeping all of those up to date with OS/library/app updates? It seems like the kind of thing that makes sense if you have a big deployment anyway, so you might as well hive stuff off, but makes much less sense if you're a "small" shop.
    • msie 12y ago
      No. The containers share the same OS.
      • xorcist 12y ago
        Can you make changes in the underlying OS image, and those changes are directly visible in the application images, without restarting said applications?
    • cgb_ 12y ago
      What happens is you'd rearchitect (if needed) your stack so that it scales across N-nodes (for each tier). Then docker build files & snapshotting features allow you to 'recompose' the image from a base OS, one step of which is to apply all patches. So when you are performing patching, you'd bring a container into service with the updated patches, send some traffic to it (possibly tightly controlled to minimise disruption), verify and then put into production. Iterate through your N-nodes per tier and you've patched. Every container after the first is rapidly started up (just the cost of a supervisor/init & the application process).
  • mrweasel 12y ago
    > What docker allows you to do is to isolate all those 20 services in separate containers that if any of them is being hacked your attacker will end up compromising only that service without any access to the main server. Have the Docker developers changed their stance that they don't promise that Docker can safely untrusted programs running as root? (https://news.ycombinator.com/item?id=7910117 https://news.ycombinator.com/item?id=7910117)
    • drinchev 12y ago
      Well most certainly container to host escalation is possible, but if you play your cards well enough it is highly unlikely. From the security section [1] : > Your average server (bare metal or virtual machine) needs to run a bunch of processes as root. Those typically include SSH, cron, syslogd; hardware management tools (e.g., load modules), network configuration tools (e.g., to handle DHCP, WPA, or VPNs), and much more. A container is very different, because almost all of those tasks are handled by the infrastructure around the container ... > This means that in most cases, containers will not need "real" root privileges at all. And therefore, containers can run with a reduced capability set; meaning that "root" within a container has much less privileges than the real "root". For instance, it is possible to ... > This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host ... [1] : https://docs.docker.com/articles/security/ https://docs.docker.com/articles/security/
      • mrweasel 12y ago
        Cool thanks. So while you still need to take the same steps to provide security as you would on a physical (or virtual host), Docker gives you the added benefit of a smaller attack surface.
  • tikums 12y ago
    > What docker allows you to do is to isolate all those 20 services in separate containers that if any of them is being hacked your attacker will end up compromising only that service without any access to the main server. Except that: containers share the same kernel. If a contained application is hijacked with a privilege escalation vulnerability, all running containers and the host are compromised. Also, several resources are not namespaced. Nothing with a shared kernel is going to be very secure. Malicious container can easily compromise a vulnerable host OS, and an already compromised host OS completely owns the container. This is no different from the failed experiments in sandboxing on PCs. Can your container share a Linux instance with containers from other customers in the cloud? Not with any confidence, no. Containers do not contain: http://opensource.com/business/14/7/docker-security-selinux http://opensource.com/business/14/7/docker-security-selinux
• deleted 12y ago
  [deleted]
• weavie 12y ago
  I have completely destroyed the Oracle installation on my windows machine.. just cannot get it to run anymore. So I quickly downloaded boot2docker and from there pulled in a prebuilt Docker oracle instance. In very little time I have a working oracle server on my machine again. Now if I manage to destroy that install, it won't matter - I can very quickly rebuild it again. Somehow at the same time I also messed up the Oracle .net drivers.. I am forced to use a specific version that the rest of my team doesn't use.. God knows how, but I have spent days trying to work out what has gone wrong. I am really looking forward to Microsoft implementing Docker for Windows. Then I will be able to develop each project in isolation and if something messes up like this again - it won't matter.
• stock_toaster 12y ago
  It seems to me the goal is separation of many apps on a single server for the sake of hygiene, security, and reproducibility (in theory), as well as shipping all dependencies for an app to run in one "thing". The problem I have with it is the level that it is done at. Using OS level virtualization (lxc) seems somewhat messy, because now you have to have a whole addition layer of proxies and indirection for any networked services. I am left wondering if sandboxing/Capsicum[1], along with something like Nix[2], would be much cleaner abstractions in the long run. [1]: http://www.cl.cam.ac.uk/research/security/capsicum/freebsd.html http://www.cl.cam.ac.uk/research/security/capsicum/freebsd.h... [2]: http://nixos.org/nix/ http://nixos.org/nix/
  • josteink 12y ago
    > The problem I have with it is the level that it is done at. Using OS level virtualization (lxc) seems somewhat messy, because now you have to have a whole addition layer of proxies and indirection for any networked services. Nonsense. You can have LXC containers work at directly at ethernet-level with each container having it's own regular network IP, just like a regular VM.[1] Just because the default is to create an internal network doesn't mean LXC is limited to this only. And then all the problems you mention go away. You get the hygenic benfits of a VM without the resource-related cost. [1] Simple example on setting this up on Debian: https://wiki.debian.org/LXC/SimpleBridge https://wiki.debian.org/LXC/SimpleBridge
• nmjohn 12y ago
  Here is how I'm using it personally: I have a handful of VPS's. Every once in a while I find a fantastic deal on one and add it to my "collection." Instead of trying to manage which VPS has what running on it - I use docker. Or rather I am migrating to it, still not 100% complete. It is quite powerful in this regard, allowing me to write small separate applications that run completely agnostic from their underlying hardware/virtualization. If I cancel a VPS, I just move the container over with a couple simple commands. So how is this useful? This morning I decided I wanted to have access to a HTTP-DNS tunnel. I launched iodine in a docker container and pushed it to one of my servers - if I need to move it to a different one, it's just a couple commands away from happening without having to reset or rebuild anything. I have a handful of web scrapers, RSS monitors, an IRC bouncer, etc running in docker containers that make management much easier than my previous solutions. Now as for a more "professional" use? I'm not as sold on it. If your server has room for multiple "things" running on it - you a.) need multiple smaller servers or b.) your application isn't large enough to even need docker to begin with. But of course this isn't applicable to everything and docker definitely has other benefits that depending on your software may or may not be useful.
• blackkettle 12y ago
  I use it [and like it] for two main purposes: 1.) Packaging and configuration development. I find it nice for this purpose because a.) it makes it easier to ensure that the work I do does not depend on some quirk of my local system configuration, which has evolved over a long period of time, b.) it is easy to tear things down and start over without consequences, c.) the versioning/layering can be useful for evolving base images 2.) Encapsulating research work and working environments. I can build a full, working environment for my research, with all source and compiled binaries, and be certain that everyone else who comes along will be able to use it and replicate/reproduce my work, or extend it with their own, without a need to hassle with configurations, compilers, etc. I can index the container with tags from a paper or conference so it can be readily found and used. I guess none of these things requires Docker [or any lxc system for that matter], but I have found it really useful and easy-to-use for these two purposes.
• vacri 12y ago
  Two use cases that I am aware of: 1) Devs get to use whatever environment they want, but the product they work with is guaranteed to be the product on the servers - no mismatched libs and a reduction in WORKSFORME. 2) For incorrigible hackers who like a finger in every pie. Want to work on project X that depends on a given package? Spin up the container. Want to shift to a different project that uses an incompatible version of that package? Spin up a different container. I'm not seeing it live up to the hype in my ops world - to me, it's just a package-management system with it's own baroque API and a custom init system. Then there's things like the python bindings using a different workflow to the CLI (the python bindings put config in 'start', the cli cannot do this). Cryptic cli responses. The 'docker ps' output that has crazy long whitespace and I have yet to see not wrap to become an unreadable mess on any of my terminals. Downloading a new image not only takes the 'latest' tag from the previous (fair enough), but it also steals the 'repository' name - so now the previous image has neither the tag (fine) or the repo name (!?!?!). I'm also yet to figure out how to get dockerhub to send an email that the build failed. And fun stuff like the benefit of adding yourself to the 'docker' group so you can run docker commands without having root... but you can forget about looking at the logs, no access there! Yesterday I learned that they also intend to remove usability features rather than add them, with the belief that 'third-party apps' will provide them. Because fragmentation is good when it comes to usability? The functionality is already there, and they want to remove it to 'keep the core small'... rather than perhaps move it into an 'extras' repo (that everyone will end up adding anyway, bar the die-hard minimalists). https://github.com/docker/docker/pull/5001 https://github.com/docker/docker/pull/5001 I'm finding that I'm fighting docker more than it's helping - I am yet to personally see the advantage to ops over a .deb package. Or an rpm, if that floats your boat. But then again, I'm already using largely single-purpose VMs. I guess you can store state in a docker image that's not as simple in a .deb, but then again docker linux images (based off distros) generally start at 100MB and grow quickly from there. And to make matters worse, my developers who went "ooh, shiny, we HAVE to use Docker!" and pushed the issue... aren't even using it themselves to develop our product. They grew bored of it quickly and reverted to their usual methods. I get puzzled stares when I run into the docker-corner-case-of-the-day. So much for item 1) for me... /rant
  • vacri 12y ago
• 23david 12y ago
  Docker allows developers to use standard linux command-line skills to assemble and package what are essentially chrooted/jailed applications. Once the application instructions are set in the Dockerfile, it can then be uploaded to a remote server so it can be easily passed around to other machines. In practice, the main use case for many companies is to use docker to package Ruby, Node or Python applications along with all of their module and OS library dependencies. This allows multiple applications to run on the same physical machine without conflicting with each other.
  • xorcist 12y ago
    Please tell me more about the conflicts. I have only occasionally had Python scripts broke because of dependencies, but not since the introduction of virtualenv.
    • groks 12y ago
      Docker is to the Linux OS as virtualenv is to Python.
      • xorcist 12y ago
        But Linux doesn't have this problem. Paths to loadable modules are given in the application configuration, and dynamic libraries have versioned file names. On top of that you can give a path to the dynamic linker. So that doesn't really make sense.