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

51–60 of 70 posts

Re: Docker: The good parts

#51

Post by zrail »

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?

etcd[1] is a distributed key-value store with some interesting properties for making things like locking mechanisms. It's like zookeeper[2] except it uses the raft consensus algorithm[3][pdf] and is written in Go.

[1]: https://github.com/coreos/etcd

[2]: http://zookeeper.apache.org/

[3]: https://ramcloud.stanford.edu/wiki/download/attachments/1137...

Re: Docker: The good parts

#52

Post by ithkuil »

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 mention that the code is still not guaranteed to be the same because when the packages are built, two builds of the same package could be slightly different. The purpose of the binary packaging scheme is to use the built artifact. Repeatable builds are a secondary goal.

Re: Docker: The good parts

#53

Post by chrisweekly »

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.

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 unexpectedly change. Right? I'm genuinely interested in others' thoughts and experiences here.

Re: Docker: The good parts

#54

Post by nickstinemates »

king_magic wrote: post #43
1stop wrote: post #41

Earlier quoted context omitted.

Except that Douglas Crockford was talking about Javascript which (at the time that book was published, and perhaps even now) was viewed as a steaming pile of crap. So he wrote a book that highlighted "the good". Docker is a pretty modern piece of tech, that has very little wrong with it, and seems to work exactly as designed. So you are kind of shoe horning the reference...

While I think the bad parts of Javascript are far more bad than the bad parts of Docker, I think it's fair to call out the good parts of Docker in such a way that the reader walks away and starts thinking "well, okay, but I'm guessing there are some bad parts too - now what are they?". I'm a pretty smart person; I've poured over the Docker documentation, run through the interactive tutorial twice now, and I still don…

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.

Re: Docker: The good parts

#55

Post by iffycan »

We use docker for on-demand temporary PostgreSQL databases (for testing). Being able to get a clean db in 1 second is pretty neat. In addition to the docker stuff, there's another process that destroys containers over X minutes old.

Re: Docker: The good parts

#57

Post by king_magic »

nickstinemates wrote: post #54
king_magic wrote: post #43

Earlier quoted context omitted.

While I think the bad parts of Javascript are far more bad than the bad parts of Docker, I think it's fair to call out the good parts of Docker in such a way that the reader walks away and starts thinking "well, okay, but I'm guessing there are some bad parts too - now what are they?". I'm a pretty smart person; I've poured over the Docker documentation, run through the interactive tutorial twice now, and I still don…

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.

Re: Docker: The good parts

#58

Post by hdevalence »

chrisweekly wrote: post #53
viraptor wrote: post #44

Earlier quoted context omitted.

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.

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, you have to update every application.

In my experience (Linux on the desktop), bundling dependencies is an indicator of poor software quality, but I realize that the situation may be different on other systems.

In this case, I think that the solution is to use the distro's package manager to pin minor versions and rely on the distribution's updates for security fixes. Hosting your own repo is a bad idea, since it means you won't get any software updates. Software updates are really important -- they have security patches and bug fixes. If you're worried about the distro changing something from under your feet, you should pick something more stable. Debian or CentOS are good choices.

Re: Docker: The good parts

#59

Post by hootener »

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 for coursework can be a nightmare.

Docker solved this problem for me as a student, and I can imagine it being solved easily for others if professors would just latch on to it and provide DockerFiles for their students. Sure, OS X and Windows users may have the initial hassle of setting up VirtualBox or what not, but I think the trade off is worth it. And when the course is over, there's no longer a lot of development software sitting around your hard drive that you may never use again. Take any source you developed, the DockerFile you used, throw it all in a repo and then you can easily replicate the build environment if you need it later on.

As a developer, I use Docker to replicate "large scale" deployments on my own machine. Typically this is just a database container, a nodeJS server container, and a container for my web application code. However, as an exercise I've spun up a container with NGINX to act as load balancers for multiple running instances of my webapp container. It was simple, repeatable, and can be easily replicated on production servers.

Finally, onboarding of new developers becomes MUCH simpler with Docker. I developed bash scripts to quickly spin up containers for development and production workflows. So onboarding new developers to my codebase is fairly easy. I distribute the source code of the project, a repo that contains DockerFiles and bash scripts, and a small readme. Developers are typically up and running in less than an hour, regardless of their operating system of choice.

Re: Docker: The good parts

#60

Post by shrikrishna »

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.
Post reply on HN