Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm a node.js developer. I understand the benefit of using docker for deployments or CI testing, but I have yet to be convinced of the benefits of using it for development on my local machine.

I install node, postgres, and redis natively and it all works fine. What benefits does docker provide to my workflow?



>I install node, postgres, and redis natively and it all works fine. What benefits does docker provide to my workflow?

Isn't it obvious?

With docker (or vagrant, or at least a VM etc) you can have the SAME environment as the deployment one. If you run OS X or Windows your direct local installs with differ in numerous ways to your deployment. And same if you run Linux but not the same distro or the same release.

And that's just the start.

Who said you'd be working in only one deployment/app at the time? If you need two different environments -- it could be even while working on version 2.0 of the same web app with new technologies--, e.g. one with Node 4 and one with Node 5, or a different postgres version, etc, you suddenly have to juggle all of these in your desktop OS.

Now you need to add custom ways to switch between them (e.g. can't have 2 postgres running on the same port at the same time), some will be incompatible to install together etc.

Without a vm/docker you also don't have snapshots (stored versions of the whole system installed, configured, and "frozen")...


Having dev servers set up the same as production makes sure that none of the little gotchas pop up that can cause problems. You can more readily guarantee that the version of every part of the stack is the same, and that the configurations are the same. One of the things this lets you do is work deeper in the stack without nearly as many concerns. You can test config tweaks, hand-rolled builds, etc, with knowing that a rollback is just an rm -rf and untar away, or a finalized config change is expressed as a single diff.


I run a docker-compose file and never, ever have to install node/postgres/redis myself, nor make sure I'm using the right version or have the right configuration files.

I pass the repo, with the Dockerfile and docker-compose.yml over to another developer and they do the same thing. They don't spend hours getting node/postgres/redis/whatever set up then fight environment issues to match what my, or staging, or our production environment are.


You might need different node/postgres versions for different projects.


Or indeed for testing the same project against different versions or in different environments.


installing them natively is clunky, they are managed in all different ways depending on how you install them. They need to started and stopped manually. You also are turning your machine into a "snowflake" with unique combinations of os and service versions.

With docker, you can make a dockerfile for your project and make it painless and consistent to run anywhere. You can also create a docker-compose file if you need other services like redis. It really is the holy-grail once it clicks.


Do you put your applications in production yourself, or do you have an operations team which takes care of it for you?

If you develop everything using Docker, running the containers on another (Linux) computer is much easier as everything is already prepared and ready to bundle up and deploy.

If you develop on Linux and deploy to Linux, don't you feel you will catch kernel and other OS-specific issues much faster? i.e. Before they become a problem in production?


Wait, not even another kind of VM? Have you ever had to work with a team that has an unreliable environment? And had to walk them through debugging an error message for installing one of them, or wanted to add something with further dependencies?

(Not to say Docker's immune from that; the sudden deprecation of docker-compose for docker-machine was a nasty surprise.)


>the sudden deprecation of docker-compose for docker-machine was a nasty surprise.

I think you meant the deprecation of Boot2Docker?


Sorry, you're right -- got them flipped.


Disclaimer: I work at Docker.

Yes, we screwed up on the b2d->machine transition. Sorry for making that experience unnecessarily confusing. We've learned a lot from that mistake and are working hard to avoid repeating it.


when you have 15 of those things start to make sense. I used vagrant in school just so that I wouldn't have any lasting tweaks of db's and weird things you end up doing. Also, with a provisioning script, I can get my projects running to this day. My snobol, smalltalk and scheme projects all can be run by just running vagrant up. I don't have to make sure that my current machine has all of the dependencies.

When we developed an angular and java site, I set up vagrant to configure tomcat, node, java, and all of the plugins required to get tomcat and maven to be nice together. Did it once, and then everyone else with a unixy platform were able to not spend time on dealing with that. Now that the class is over, all of that is removed from my machine but I can always just crank it back up in the time it takes to install all of those dependencies.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: