Live data from Hacker News

Docker: The good parts

blog.shrikrishnaholla.in

21–30 of 70 posts

Re: Docker: The good parts

#21
post #20

Earlier quoted context omitted.

Irony is that I chose this theme purely for the typography.

I guess it looks better on your machine. This is how it looks like on Linux for me: http://i.imgur.com/JRHzYp7.png Extremely annoying to read.

Similar on android

Re: Docker: The good parts

#22
post #2

Sandboxed applications that take care of all of the dependencies is a no-brainer for me. Amazingly I see quite a lot of focus on separating out all of an applications dependencies into separate containers and then linking them. I feel like in most circumstances that is not taking advantage of Docker. Unless you have quite a huge amount of time invested in learning Puppet/Chef or whatever, have nothing to do except pl…

By "linking them" what do you mean exactly? Building container hierarchies using "FROM"? Exposing services through ports? Exposing resources through volumes? If your application is simple, then sure, you can get away with almost any deployment and provisioning approach and it'll work "well enough". But these linking capabilities and products like Chef exist for more complex scenarios, and it would do you well to inve…

By linking them I meant using Docker's links feature. http://docs.docker.io/en/latest/use/working_with_links_names...

I have seen people discussing using that link feature where it seemed like they were just setting up a database or something for a single application and then linking that database container. Which seemed like it would be easier to set up the database in the container if possible.

I wasn't saying you can't use Puppet or Chef, just commenting on that particular case with using links for things like database dependencies for a single application.

The use case you describe obviously is not something you would try to manage with Docker alone.

From what you are saying it sounds like you have a good solution.

One thing that I remembered when you mentioned "requirement to run 100s of applications" was this new devops tool called Salt (saltstack.com). I actually don't know much about it but it sounded a little bit like what you are talking about. What do you think of Salt compared to Chef?

Re: Docker: The good parts

#23
post #20

Earlier quoted context omitted.

Irony is that I chose this theme purely for the typography.

I guess it looks better on your machine. This is how it looks like on Linux for me: http://i.imgur.com/JRHzYp7.png Extremely annoying to read.

That looks really bad. I use Linux as well, but hadn't checked the rendering in Firefox. Have to change it. Pity, it looked good in Chrome

Re: Docker: The good parts

#25
post #22

Earlier quoted context omitted.

By "linking them" what do you mean exactly? Building container hierarchies using "FROM"? Exposing services through ports? Exposing resources through volumes? If your application is simple, then sure, you can get away with almost any deployment and provisioning approach and it'll work "well enough". But these linking capabilities and products like Chef exist for more complex scenarios, and it would do you well to inve…

By linking them I meant using Docker's links feature. http://docs.docker.io/en/latest/use/working_with_links_names... I have seen people discussing using that link feature where it seemed like they were just setting up a database or something for a single application and then linking that database container. Which seemed like it would be easier to set up the database in the container if possible. I wasn't saying you…

For example:

https://botbot.me/freenode/docker/msg/5836039/

Re: Docker: The good parts

#26
I've been using Docker as a sandbox for an online contest judge. I'm working to add in SELinux into the Docker container as well. So far, its been working great for me.

I'm not sold on using Docker for development though. I haven't attempted to setup multiple Vagrant machines so maybe that's why I'm not seeing the value, but setting up single dev machines through Vagrant is just so simple and straight forward.

Re: Docker: The good parts

#27
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…

This is solvable by using a more deterministic system like Nix as the base build box.

Re: Docker: The good parts

#28

Docker and LXC looks interesting. What is your experience of the performance overheads of using containers?

In that sense, we found that all container-based systems have a near-native performance of CPU, memory, disk and network. The main differences between them lies in the resource management implementation, resulting in poor isolation and security. [1]

[1] http://marceloneves.org/papers/pdp2013-containers.pdf

Re: Docker: The good parts

#29
post #20

Earlier quoted context omitted.

Irony is that I chose this theme purely for the typography.

I guess it looks better on your machine. This is how it looks like on Linux for me: http://i.imgur.com/JRHzYp7.png Extremely annoying to read.

And again in Chrome on Win 8.

Re: Docker: The good parts

#30
post #20

Earlier quoted context omitted.

I guess it looks better on your machine. This is how it looks like on Linux for me: http://i.imgur.com/JRHzYp7.png Extremely annoying to read.

Similar on android

Looks OK to me on android - http://i.imgur.com/JqV9bK0.jpg
Post reply on HN