To tell all the cool kids you are using it. (Ok, I know there are real use cases for Docker, but I see a lot of hype as well. People telling my mathematician friend that she needs to use docker at the start of her project - it is likely to be a one off graph she needs to produce for a research paper).
Ask HN: Why use Docker and what are the business cases for using it?
51–60 of 137 posts
Re: Ask HN: Why use Docker and what are the business cases for using it?
#52Re: Ask HN: Why use Docker and what are the business cases for using it?
#53We have a shitload of servers running CentOS for historical reasons. We can't change the distribution because all the services running on this servers are tight to the quirks and special cases of this distribution. So we need to live with CentOS. Some of our newer services need a up to date version of glibc and a lot of other dependencies CentOS can't provide. So we use docker to boot up Ubuntu 14.04 containers and r…
>running CentOS for historical reasons Is CentOS not the state-of-the-art Linux distro to run for servers (besides RHEL for support)?
Re: Ask HN: Why use Docker and what are the business cases for using it?
#54Re: Ask HN: Why use Docker and what are the business cases for using it?
#55(disclosure: I do work for Codeship :P ) There are a lot of really great reasons to use Docker, or any container technology for CI. First off containers give you a standard interface to a reproducable build. This means you can run something in a container and expect it to behave the same way as something a co-worker runs on their workstation, or something run in the staging or production environments. For CI this is…
If anyone is interested in joining our beta, just drop me an email: brendan at codeship.com.
Re: Ask HN: Why use Docker and what are the business cases for using it?
#56Do people use Docker in conjunction with Vagrant now? Or is Docker used as a replacement for Vagrant for a homogenous development environment?
Re: Ask HN: Why use Docker and what are the business cases for using it?
#57I shed a single tear when I realized I could just fire up flask + nginx + uwsgi within seconds after installing docker.
For a business perspective, it's a little tricky. I guess it can help if you need to offer an onsite version of your SaaS app and the enterprise client had strict rules about being on site.
What would really make docker kickass is if they had a way to encrypt all the source code somehow and protect it.
Re: Ask HN: Why use Docker and what are the business cases for using it?
#58I'm saying this because I know docker solves a lot of pain on the devops side, but on the "software" side it's been painful all the time I've touched it. I.e. practically speaking, it makes releasing much slower, sometimes I'm forced to do a hard reset on the container rather than just reload nginx, etc.
My suggestion is to go with what's simpler for your stack. If you're struggling with having to manage and deploy new configured/secure ec2 instances every day, then it might be worth looking into docker.
Re: Ask HN: Why use Docker and what are the business cases for using it?
#59If Docker was fixing this only, I would still use it. There is nothing better than a single binary deployment that is byte to byte the same as it was running on a dev laptop and a QA env.
Re: Ask HN: Why use Docker and what are the business cases for using it?
#60My apologies if I'm hijacking the original poster. Does Docker handle multi-environment configuration management? For example: qa, stage and live have the same config files, but different values. Currently we're using Ansible and we set variables for a specific environment, then we feed those variables into config files based on where we're deploying to (config files are not duplicated, only variables that feed into…
One way I've seen many people tackle this problem is to have the Dockerfile/image built in a more generic way, then the end of the Dockerfile kicks off an Ansible playbook (or some other lite CM tool) that will configure everything for the proper environment (e.g. change configuration and kick off a service, something along those lines). Some will even go as far as using a CM tool to do the entire internal Dockerfile…
This pattern is maybe even more helpful than harmful, for making your dev environment more closely match production, when your final deploy target is not a docker container.
(You are obviously going to want to see those build scripts running in test, if not earlier; certainly once, before they should kick off in a production environment.) You could do more individual steps in the docker file, just like you could store your token credentials and database handles in the git repository. Neither way is "completely wrong" but there is a trade-off.