I have been using docker as an application sandbox for a while now. It seems like a breeze! Instead of concentrating on setting up and resolving dependencies, I can concentrate on the development. That is the best take away for me from docker!
Docker: The good parts
11–20 of 70 posts
Re: Docker: The good parts
#12Your Google Analytics is showing: http://imgur.com/D8vWM3k
:)
Re: Docker: The good parts
#13Your Google Analytics is showing: http://imgur.com/D8vWM3k :)
Thanks! Fixing it
Re: Docker: The good parts
#14Complete off topic nitpick, but reading this font made my head hurt. I didn't manage to read till the bottom, even though I'm interested. Could I suggest a font that has the same x-height for each character?
Re: Docker: The good parts
#15Complete off topic nitpick, but reading this font made my head hurt. I didn't manage to read till the bottom, even though I'm interested. Could I suggest a font that has the same x-height for each character?
Irony is that I chose this theme purely for the typography.
Re: Docker: The good parts
#16It 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 "config line" >> /etc/config.conf
I'm aware that this file is to generate a "run anywhere" image, but I worry people might be treating it as a huge step on from installation scripts when it's very similar. The image part afterwards, however, is a huge step onwards.
Re: Docker: The good parts
#17Sandboxed 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 investigate the rationale behind them before being so dismissive.
I currently have a requirement to run 100s of applications provided by mutually untrusted 3rd parties, and co-ordinate startup/shutdown (for backup) and RPC access to these applications.
I need to be able to start an arbitrary combination of these applications on a node, depending on load (I cannot foresee the bandwidth/CPU requirements of each application without running it, and it will change unpredictably over time, sometimes to the point where a 1Gb/s link will be saturated by a single application for a few hours, and then change again to a trickle).
Sometimes I need to start multiple copies of this infrastructure for independent services that I may need to bring up/down independently.
In my scenario, using Docker alone to deploy the whole caboodle is not a maintainable solution. Using Docker to package the untrusted applications and selectively expose just the volumes for backup and a single port to just the host control process (keeping applications from talking to one another), and Chef to deploy/undeploy applications to nodes in arbitrary and constantly varying configurations that automatically rewire themselves is very maintainable.
The way I use these tools:
- Chef/Puppet/etc. = infrastructure deployment and configuration management
- Docker = application deployment and confinement
This separation is useful because the operations people can do their job, and the developers can do theirs, without stepping on each others toes and with minimal co-ordination. If you do everything in Docker, the ops team has a nightmare managing change in complex applications; if you do everything in Chef, your developers suddenly have to become Chefs, which is overkill and will waste time co-coordinating with the ops people.
My example above is childs play compared to what some organisations need to deploy and manage.
Re: Docker: The good parts
#18It 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.
Re: Docker: The good parts
#19cute headline :) ( at least I think so as a node JavaScript developer ) . all fun aside, I love docker ( and previously vagrant ) as an on demand mobile back end for native iOS and android Dev. it works isolate, disconnected , and can be deployed when I need to stage for reviews . its great !
This is likely very naive. But can you elaborate on how you use it for this?
Am just starting to explore Docker.
Re: Docker: The good parts
#20Complete off topic nitpick, but reading this font made my head hurt. I didn't manage to read till the bottom, even though I'm interested. Could I suggest a font that has the same x-height for each character?
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.