6 ms·

I dont understand containers. First you go to through great pain sharing and reusing libraries. Then you make a copy of all the libraries and the rest of the sy

• bognition 9y ago
  Its about creating and maintaining a clean environment. Conceptually they aren't that different than a VM just much lighter weight.
  • chrisper 9y ago
    Well, we need to differentiate between application containers (Docker) and Linux containers (old:openVZ, new:LXD/LXC). Then there are application containers which are even more "limited," like Flatpack. I'd argue that only Linux containers are like VMs.
    • imhoguy 9y ago
      Docker was LXC wrapper in the past. Now it just handles cgroup stuff itself. You can run full system in the Docker but purists regard this as antipattern.
      • chrisper 9y ago
        I'd prefer LXD / LXC anyway. Sadly, LXD porting to Debian is a slow process.
  • dozzie 9y ago
    Except that it's not clean environment. Make it a properly built DEB or RPM package, and then we're starting (but just starting) to talk about clean. Note also that binary packages help with repeatable deployment that uses Docker, deployment tools (e.g. Ansible or Salt), configuration management tools (CFEngine, Puppet), even manual -- and mix of all these. Docker images only help with Docker deployment.
• femto113 9y ago
  What you're missing is that if two containers have the same base they will share all of those resources (both on disk and in RAM). Thus while each container is a complete system you can still fit many more containers on a given host than you could VMs (which don't share anything with each other).
  • xorcist 9y ago
    VMs are irrelevant because containers are not VMs.
    • wpietri 9y ago
      Seems relevant to me. People have been using VMs for situations where they can now use containers.
  • rwmj 9y ago
    Hmm, well sometimes that is true. Because containers don't encourage stable APIs, another scenario is that each container has slightly differing versions of each library because of unnecessary API changes (or in the positive case, because they extensively test the program with a particular library version).
    • SomeStupidPoint 9y ago
      Containers are how we managed to have something like five or six versions of Python in our production environment.
      • rwmj 9y ago
        I can see two different versions being necessary (Python 2.x and 3.x), but is it really necessary to have versions other than the latest of each?
      • subway 9y ago
        How do you apply security updates to 'five or six versions of Python' without losing your mind?
• gaius 9y ago
  An interview question I asked recently: what are the advantages of Docker over an application deployed as a statically linked binary?
  • dopamean 9y ago
    What kind of answers do you expect/would like to hear?
    • gaius 9y ago
      I intend it to be a starting point for a conversation, someone who really understands it will be able to convince the skeptic that I play, someone who is just typing the commands because it's trendy won't. Also it helps if they know what a statically linked binary is.
      • fapjacks 9y ago
        It is obvious from your comments that nobody will convince you of any merit Docker has. You are not "playing a skeptic".
        • gaius 9y ago
          I like containers as a concept, and I like the Docker commands for building them and running them locally. I am less convinced by Docker Swarm as a Prod-grade runtime environment, and skeptical that Docker the company can build a viable business out of something that will rapidly become a commodity, I expect the file format will long outlive the company that created it. But those are nothing to do with the question really, which can be answered purely technically.
          • eatmyshorts 9y ago
            Curious--how do you feel about Mesosphere and Kubernetes vs. Docker Swarm?
• moondev 9y ago
  Immutable infrastructure. And there should be no pain involved if the ci/cd pipeline is automated correctly.
• mmgutz 9y ago
  I had trouble understanding the benefits of it as well. A container is a snapshot of a specific version of an application/daemon and the OS it runs on all bundled into a deployable/runnable image. You create a container for every version of an app. Deploying or rolling back is almost as simple as deploying an image on any host that runs Docker.
  • chrisper 9y ago
    There is also the fact that things stay inside a container (more or less). You want to remove mysql? No problem, just discard the container. Compare that to removing mysql and all its config files etc. from all over the place.
    • sigjuice 9y ago
      The underlying problem is things like mysql that scatter things all over the place. Docker only encourages such sloppiness, IMHO.
      • Godel_unicode 9y ago
        While it might be true that MYSQL being a bad roommate is the core problem, does that matter? As an admin you don't get to ignore the pager because the outage is Oracle's fault.
• lllr_finger 9y ago
  Immutability, and consequently determinism, are wonderful traits to embrace when you're managing deployments across environments and regions for dozens or hundreds of services.
  • eatmyshorts 9y ago
    And with testing...
• k__ 9y ago
  Docker users have essentially given up. Nix[0] genuinely tries to solve the problem. [0] https://nixos.org https://nixos.org
• peterwwillis 9y ago
  It's basically leaning on shitty software engineering to produce increased reliability in release engineering/operations. The old model was a system would be running, and a lot of software components within that system would depend on each other, creating a web of dependencies. If one of the dependencies had a problem, it could bring down the whole system [in theory]. The new model is "simpler" in that every software component has its own independent operating environment, with [supposedly] no dependency on the others. In this way, if one dependency fails, it can do so independent of the system at large - the failed piece is simply replaced by a different, identical piece. In addition, the component environments don't store state or anything else that would be necessary in order to replace it. We basically bloat up our RAM and waste CPU and disk space in order to be able to understand and support the system in a more abstract way, in the service of better availability, and also, better scalability. How is this different from simply running a bunch of chroot'ed services on a system without containers? It really isn't. But you get more control over the software by adding things like namespaces and control groups, and by everyone using the same containers, more uniformity. By dealing with the annoyance of abstractions and bloat, we get more human-friendly interoperability.
• eatmyshorts 9y ago
  Others have discussed how docker uses a layered approach, and how two containers that share a base system will share most of the filesystem and memory. The real power of containers comes with container orchestration (i.e. Kubernetes, Mesosphere, and OpenShift). By leveraging containers, container orchestration systems can provide high availability, scalability, and zero-downtime rollouts and rollbacks, among many other things. These things were hard before containers & container orchestration. By allowing containers to be moved between nodes in a cluster, one generally achieve higher hardware utilization than with VMs alone (which is in itself a big improvement upon software on bare-metal hardware). All of this also leads to easier/better continuous deployment, as well. This, in turn, leads to easier testing, and greatly simplifies provisioning of hardware for new projects. So, the benefits are: - Cheaper than VMs (through better hardware utilization) - More reliable, through HA load balancers - More scalable, through scalability load balancers - Better testing, through CI/CD enabled by containers - Faster application delivery by simplifying provisioning
  • peterwwillis 9y ago
    Except: - Nobody ever used VMs the way containers are - A HA load balancer is not a container-specific concept - There is no such thing as a 'scalability load balancer' - You don't need a container to do CI/CD - It's not faster, it's slower, and it's not simpler, it's more complex
    • _seemethere 9y ago
      How is it slower to use containers than traditional machines? Provisioning for a container is basically just downloading an image and running it. Sounds like you haven't really used containers at all.
    • eatmyshorts 9y ago
      - Nobody ever used VMs the way containers are? Many people are using VMs to get better utilization of hardware by running multiple distinct apps on the same hardware. Containers do this, too. Container orchestration makes it really easy, allowing for even better hardware utilization than with VMs. You say that "nobody ever used VMs the way container are", yet I've got multiple clients that deployed to Kubernetes in large part because of this very point. - I never said an HA load balancer is a container-specific concept. I said that "these things were hard before containers". I stand by that statement. Containers and container orchestration make HA proxies really, really simple. - A scalability load balancer is a load balancer in front of a service that monitors load and scales up, or down, the number of instances behind that load balancer. Again, container orchestration makes this really easy. - No you don't need a container to do CI/CD. But containers make it much, much easier. - It is faster. I can provision an entire cluster of machines in about 5 minutes on AWS or GKE. If I have an existing cluster to publish to, it's even easier--it's one line in my continuous integration config file. Container orchestration has a learning curve (I'm assuming this is why you say "it's more complex"?), but it is tremendously easier and faster to provision hardware for a project with containers and container orchestration when compared to provision actual hardware, or even provisioning VMs.