Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What is the actual purpose of Docker?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: Ask HN: What is the actual purpose of Docker?

#31

Post by akshaykarle »

Docker is mainly an app packaging mechanism of sorts. Just like you would build a jars, wars or rpms, etc. you create docker images for your applications. The advantage you get is that you can package all your dependencies in the container thereby making your application independent and using the tools provided by docker in combination with swarm, compose, etc. it makes deployment of your apps and scaling easier.

OpenVZ, LXC, solaris zones and bsd jails on the other hand or mainly run complete OS and the focus is quite different from packaging your applications and deployments.

You can also have a look at this blog which explains the differences more in detail: http://blog.risingstack.com/operating-system-containers-vs-a...

Re: Ask HN: What is the actual purpose of Docker?

#33

Post by zwischenzug »

Some key points:

- Docker is nothing new - it's a packaging of pre-existing technologies (cgroups, namespaces, AUFS) into a single place

- Docker has traction, ecosystem, community and support from big vendors

- Docker is _very_ fast and lightweight compared to VMs in terms of provisioning, memory usage, cpu usage and disk space

- Docker abstracts applications, not machines, which is good enough for many purposes

Some of these make a big difference in some contexts. I went to a talk where someone argued that Docker was 'just a packaging tool'. A sound argument, but packaging is a big deal!

Another common saw is "I can do this with a VM". Well, yes you can, but try spinning up 100 vms in a minute and see how your MacBook Air performs.

Re: Ask HN: What is the actual purpose of Docker?

#34

Post by 3pt14159 »

zwischenzug wrote: post #33

Some key points: - Docker is nothing new - it's a packaging of pre-existing technologies (cgroups, namespaces, AUFS) into a single place - Docker has traction, ecosystem, community and support from big vendors - Docker is _very_ fast and lightweight compared to VMs in terms of provisioning, memory usage, cpu usage and disk space - Docker abstracts applications, not machines, which is good enough for many purposes Som…

What is important to note is that the ideal use case for Docker is not actually speed - it's about quickly responding to increased load. If you need to vary the number of, say, web servers from 5 to 100 over the day, then Docker is good because you can start them up very quickly.

The down side about docker is that it takes longer to set up your docker in the first place, it is harder to keep secure, and it runs slower than a traditionally deployed application, but compared to VM deployed applications the performance is usually better.

Re: Ask HN: What is the actual purpose of Docker?

#35

Post by jebblue »

grhmc wrote: post #7

For me, it is the ultimate in the idea in Continuous Delivery of "build once." I can be very confident that the docker image I build in the first stage of my pipeline will operate correctly in production. This is because that identical image was used for unit tests, to integration and functional testing, to the staging environment and finally production. There is no difference than configuration. This is the core tha…

>> I don't even mind Java anymore because the CLASSPATHs

Agree and add that Python's paths (forget what they're called) (as well as Java CLASSPATHS) have been a problem for me on occasion too which means Docker would probably help with all these types of path issues.

Re: Ask HN: What is the actual purpose of Docker?

#37

Post by jdoss »

justincormack wrote: post #8

OpenVZ is not upstream in the kernel; the container stuff that got merged is what Docker uses. Docker has much wider adoption than OpenVZ does now.

> Docker has much wider adoption than OpenVZ does now.

I don't think your statement is true at this point in time. OpenVZ is used by a ton of companies in the hosting industry and by large companies such as Groupon and smaller ones like TravisCI [1]. I would't make a statement that that Docker has a wider adoption than OpenVZ at this point in time. Maybe in five years, yes it may have a wider adoption than OpenVZ. OpenVZ and commercial VZ have been doing full OS containers since the early 2000s and it has the production track record to do very well in many server applications. I wouldn't hesitate to use it over Docker in production for my future projects.

[1]: http://changelog.travis-ci.com/post/45177235333/builds-now-r...

Re: Ask HN: What is the actual purpose of Docker?

#38

Post by grhmc »

caw wrote: post #30
grhmc wrote: post #23

Earlier quoted context omitted.

The problem is Vagrant + Ansible violates the rule of "build once." I don't care about the isolation for isolation sake, I care about it for the artifact sake.

How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint. What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually…

> How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file?

Unless you're snapshotting that vagrant box and then deploying that to all your servers somehow, you are building multiple times.

> What is this rule to only build once?

I'd recommend reading the book Continuous Delivery. It is a fantastically helpful read.

I prefer not to update my machines, but that is because I follow immutable deployments. But, even if I did update my machines, it is far cleaner (and easier to roll back!) to deploy an asset which has all its dependencies in the box. than to push out code and maybe have to upgrade or install new packages. The gemfile.lock and friends make this a bit less of a problem, but you also get to lock things like libxml version or ffmpeg or...

> In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once.

Totally true, and we don't do this. We build a machine image and do a rolling-deploy replacing existing servers with the new machine image.

> The physical servers need to get updated and managed post-install.

One of the reasons I try not to work with hardware. Physical hardware is hard, and avoiding it makes my life much simpler. I love it.

Re: Ask HN: What is the actual purpose of Docker?

#39

Post by crdoconnor »

grhmc wrote: post #29
crdoconnor wrote: post #28

Earlier quoted context omitted.

I don't care so much for this rule. It sounds like a figleaf covering for broken build scripts. I care about tracking down issues before they reach production. Meaning that I want an environment that mirrors production as closely as possible. Meaning heavyweight not lightweight virtualization.

Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. It also doesn't "cover up" broken build scripts. Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts. Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other co…

>Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization.

Well, it gets you a step closer to accurately mimicking production.

>It also doesn't "cover up" broken build scripts.

That seems to be what that 'build once' rule is for. If your building process isn't risky, why the need to prohibit running it twice?

Re: Ask HN: What is the actual purpose of Docker?

#40

Post by grhmc »

grhmc wrote: post #29
crdoconnor wrote: post #28

Earlier quoted context omitted.

I don't care so much for this rule. It sounds like a figleaf covering for broken build scripts. I care about tracking down issues before they reach production. Meaning that I want an environment that mirrors production as closely as possible. Meaning heavyweight not lightweight virtualization.

Agreed about preventing issues getting to production, but that doesn't exclusively mean heavyweight virtualization. It also doesn't "cover up" broken build scripts. Our build scripts get tested a dozen times a day and cannot tolerate half-assed broken build scripts. Our deployment pipeline (after verifying the image is good enough to be deployed) packs the docker image into a machine image along with several other co…

It is far easier and less risky to only run it once and use that artifact than to make sure every environment it could possibly build in is identical. Keeping all your environments perfectly identical is more likely to either: 1. introduce subtle differences you aren't even aware of, or 2. introduce DLL-hell at datacenter scale.
Post reply on HN