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

31–40 of 70 posts

Re: Docker: The good parts

#31

Post by phaker »

shrikrishna wrote: post #23
aw3c2 wrote: 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.

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

This looks like the font file you're using lacks some rendering hints (all points that touch the median line should be annotated as such, it looks like they aren't).

Another version of the same font or the same font from another source may work. Webfont sites often try to tweak the hinting tables, they're trying to make the fonts look better but it breaks stuff all the time.

Re: Docker: The good parts

#32

Post by lucian1900 »

aw3c2 wrote: post #20
shrikrishna wrote: post #15

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.

It's nowhere near that bad, but it doesn't exactly look great on Chrome OS X.

Re: Docker: The good parts

#33

Post by mateuszf »

tel wrote: post #27
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…

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

Or using a package manager which allows to specify exact versions of the artifacts, like npm or maven.

Re: Docker: The good parts

#34

Post by mateuszf »

ilaksh wrote: post #22
ryanjshaw wrote: post #17

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…

One advantage that I see is for example possibility to upgrade applications server and leave db running. You can then switch to new app-server using nginx making this process transaction like (complete successfully or fail completely).

Re: Docker: The good parts

#35

Post by icebraining »

shrikrishna wrote: post #23
aw3c2 wrote: 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.

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

It's weird, it looks good on my machine, using FF25 on Ubuntu.

Re: Docker: The good parts

#36

Post by binocarlos »

ilaksh wrote: post #4
shrikrishna wrote: post #3

Earlier quoted context omitted.

I have never used Puppet/Chef,so can't speak for them, but part of the reason why sandboxing in Docker isn't overkill is that it uses a layered file system that shares as much as can be shared; so, although the containers are isolated in user space, they still share the same base. This is one of the reasons for its high performance

Not sure I understand what you are saying. I know that Docker uses AUFS. I'm not saying sandboxing in Docker is overkill. I'm saying that using separate containers for application dependencies rather than running them all in the same container is often making things more complicated than necessary. Obviously some people have good reasons to use links, like they need to run lots of databases on different servers or so…

I've settled on running 5 or 6 containers rather than one big one with 5 or 6 processes because:

I can host some containers on other physical hosts - I don't need to keep thinking (what if I fill up the biggest droplet on Digital Ocean) - If one of the services dies or needed kicking - 5/6 of the stack is unaffected - Orchestration is really only a matter of network endpoints getting written to environment variables - not too taxing

Running everything is one container also has it's advantages - like being able to push the whole stack as one image.

Re: Docker: The good parts

#38

Post by espennilsen »

el_tone wrote: post #29
aw3c2 wrote: 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.

And again in Chrome on Win 8.

This how it looks for me. http://i.imgur.com/9wNxAZM.png

Chrome Version 32.0.1700.72 m on Windows 8.1

Re: Docker: The good parts

#39

Post by 1stop »

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…

If run in the same machine, I think it will install the same version every time... won't docker cache the change and just play it back?

Re: Docker: The good parts

#40

Post by lifty »

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…

Spot on. Once an image has been built its safe to say that it can be moved around and ran even after a lot of time has passed. The build process is another story; even though you have the steps(the logic) for creating the image(the result), you still need to control the package sources(the input data) to get an image that works correctly. I think the build process maintains its "run anywhere" property, but it doesn't maintain its "run anytime" property.
Post reply on HN