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

Docker: The good parts

blog.shrikrishnaholla.in

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Docker: The good parts

#61

Post by hootener »

shrikrishna wrote: post #60
hootener wrote: post #59

Here are three instances where Docker made my life way easier: Docker as an educational tool can be pretty powerful. One of the most annoying parts of CS courses is the initial install/configure/dependency wrangling you have to do to install required applications in whatever courses you happen to be taking that semester. Since courses may have different and conflicting requirements, just preparing your machine to use…

I completely associate with what you said about using Docker as an educational tool. I have my projects littered around, and half of them might not even run anymore. Might be good to build a tar and archive them somewhere.

Sure. And if Docker was leveraged to create an easily reproduceable build environment, you'd have a fairly good chance of all that source running in that container again at a later date.

Re: Docker: The good parts

#62

Post by shykes »

IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

Hi, Docker author here.

This is a perfect example of how we're trying to design Docker: by looking for the right balance between evolution and revolution.

Evolution means it has to fit into your current way of working and thinking. Revolution means it has to make your life 10x better in some way. It's a very fine line to walk.

I think a lot of bleeding edge tools sacrifice evolution because it involves too many compromises - there's a kind of "if they don't get it, their application is not worthy of my tool" mentality, and as a result the majority of developers are left on the side of the road. I see several tools named in this thread which suffer from this problem, and as a result will never get a chance to solve the problem at a large scale.

In this example of build repeatability, "evolution" means we can't magically make every application build in a truly repeatable way overnight. However, we can frame the problem in such a way that lack of repeatability becomes more visible, and there's an easy and gradual path to making your own build repeatable.

Sure, you can litter your Dockerfile with "run apt-get install" lines, and that does partially improves build repeatability: first with a guaranteed starting point, second with build caching, which by default will avoid re-running the same command twice. Your build probably wasn't repeatable to begin with, and in the meantime you benefit from all the other cool aspects of Docker (repeatable runtime, etc), so it's already a net positive.

Later you can start removing side effects: for example by building your dependencies from source, straight from upstream. In that case your dependencies are built in a controlled environment, from a controlled source revision, and you can keep doing this all the way down. The end result is a full dependency graph at the commit granularity, comparable to nix for example - except it's not a requirement to start using docker :)

Re: Docker: The good parts

#63

Post by robszumski »

saintfiends wrote: post #46

This maybe slightly OT, but could someone explain what etcd does?. CoreOS hosts containers and an etcd instance run on host (master) and on each container. Is that it? Let's say I'm on on a VPS and I'm running multiple instances of CoreOS each hosting multiple containers. Can etcd be used in this case?

Yes, etcd can be used for a few different use-cases on CoreOS clusters. You can do service discovery by "announcing" each container to the cluster. With an etcd watch, any process on the cluster could be listening for changes to your service discovery keyspace, and take any action you specify (Reconfigure proxies, etc.)

Etcd also provides distributed locking for the cluster through a module. If you need to prevent an action from happening more than once, you can take a lock on a specific key to prevent others from processing that item.

Related to locking is the leader election module which offers an easy way to choose a new leader for a distributed service. Module docs are here: https://github.com/coreos/etcd/blob/master/Documentation/mod...

Re: Docker: The good parts

#64

Post by memracom »

heavenlyhash wrote: post #50
IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

I've been doing a lot of research lately into more deterministic dependency management and reproducible builds by leveraging hashes via git. You might be interested in MDM[1], which is a general-purpose dependency manager for binary blobs. Specifically for container images, you also might be interested in hroot[2] -- it separates the concept of the image and transport out from the containerization system. I agree who…

Why would you use apt-get with an upstream repository? Deployment 101 is to set up your own local repo mirror so that you control exactly what binary objects get deployed.

Re: Docker: The good parts

#65

Post by memracom »

viraptor wrote: post #44
pgeorgi wrote: post #37

Earlier quoted context omitted.

or apt-get...

For that to work you'd have to have your own repository with all the packages you install. Old specific versions will not be preserved in the upstream repos if a new package is released.

That is just basic common sense. It is easy to mirror upstream repos that you need. Don't allow your systems to have dependencies that are outside of your control.

Re: Docker: The good parts

#66

Post by nickstinemates »

king_magic wrote: post #57
nickstinemates wrote: post #54

Earlier quoted context omitted.

I'll be more than happy to work with you 1:1 to get clarity. Your medium of choice. That goes for anyone else reading this. I love answering questions and helping people. It's like pure bliss, so don't worry about being a bother.

That would be incredible - would you be willing to shoot me an email? rringham@letsgohomeapp.com I'd be happy to take whatever I learn and apply to my app and contribute it back to the community, maybe as a quick tutorial up on GitHub, or something along those lines.

Sure thing. And for anyone else interested, email nick @ docker . com or say hi to keeb on Freenode

Re: Docker: The good parts

#67

Post by IanCal »

ithkuil wrote: post #52
IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

The dependency issues are solved if you reuse a given docker image; as you said. Yes, the procedure of generating the image (Dockerfile) is basically a glorified installation script. But I don't understand why you use the properties of the image creation tool to refute runtime properties of docker images. EDIT: like if when discussing the properties of a perfect headache free binary package management system, you men…

> But I don't understand why you use the properties of the image creation tool to refute runtime properties of docker images.

I'm not, my concern is that the language used suggested that having a Dockerfile meant that if it builds for one person it would build for all when this isn't the case.

That's not a problem with docker, as it's not something docker is trying to (or claiming to) solve. I'm worried that some people might think it is, so thought I'd post here to clarify things.

Re: Docker: The good parts

#68

Post by IanCal »

shrikrishna wrote: post #18
IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

Dockerfiles are just "run anywhere", not "run any time". Maybe I should have made it clear. The creator still needs to maintain his Dockerfile. Maybe http://blog.docker.io/2013/11/introducing-trusted-builds/ will make things easier.

I think the level of detail you have worked fine for the writing style, my comment is somewhat nitpicky. Your statement is generally true, if they use the dockerfile they posted then it's extremely likely to work for you too.

It was mostly a clarification for people reading that the dockerfile doesn't guarantee repeatable builds.

Thanks for the post :)

Re: Docker: The good parts

#69

Post by IanCal »

shykes wrote: post #62
IanCal wrote: post #16

It is pretty cool, but I'm starting to see a lot of comments like this about the Dockerfile: > I don’t need to worry about the version of node, nor of the dependencies nor anything else. If it’s worked for them, it’ll work for me. As simple as that! This isn't true as far as I can tell, the Dockerfile will have a series of lines like this RUN apt-get install x RUN apt-get install y RUN apt-get install z RUN cat "conf…

Hi, Docker author here. This is a perfect example of how we're trying to design Docker: by looking for the right balance between evolution and revolution. Evolution means it has to fit into your current way of working and thinking. Revolution means it has to make your life 10x better in some way. It's a very fine line to walk. I think a lot of bleeding edge tools sacrifice evolution because it involves too many compr…

Hi, nice to speak to you.

I agree, this is the right way to go about it. Someone with a nicely repeatable build can go ahead and get that with docker too, someone without still that gets a nicely distributable image. Docker seems to have taken off quickly as there's a benefit very soon after you start using it, and very little to get in the way of you having something running.

There's an issue in that people see the claims of one part and think they apply to the whole (I don't think the poster thinks that, but people reading it might get that impression), but this is a problem of education, not a technical one.

Re: Docker: The good parts

#70

Post by chrisweekly »

hdevalence wrote: post #58
chrisweekly wrote: post #53

Earlier quoted context omitted.

Right, but that's not really a problem, is it? My understanding is that committing dependencies is strongly discouraged -- if you're writing libraries or modules intended for distribution and others' use. On the other hand if you're deploying a standalone app, locking down any specific dependencies' versions and committing them is actually considered a best practice, as it's the only way to be sure it won't unexpecte…

The problem is that you're now forcing all of your users to use the library you bundled. First, this bloats the system, since you now don't share dependencies between applications. Second, it makes the system more complicated because there are multiple library copies floating around the filesystem. Third, it means that when you really do need to change a library/dependency, you can't just update the libfoo package, y…

Ok, but here it seems like you're referring to "[my] users" as if they were consumers of the library -- that is, as if they were developers. That's still my first case in which I agree committing / bundling dependencies is a bad idea. I'm talking about the 2nd case, of locking down dependencies used to build an application whose "users" are not even aware of the presence of dependent libraries nor the structure nor configuration of the underlying software. In this second case, isn't [freezing/shrinkwrapping/committing/bundling] the dependencies generally considered the right thing to do?

Of course, updating the dependencies (whether for patches or more consequential updates) in subsequent releases is fine... but within a given release cycle, one otherwise runs the risk of unexpected inconsistency, between e.g. a developer build and a CI build done a short time later.

I think this discussion illustrates the problem and might be more articulate than I'm being: https://github.com/bower/bower/pull/538

Thanks @hdevalence -- and anyone else who cares to comment. :)

Post reply on HN