3 ms·
Oh, hai there. I haven't gone 'whole hog' on Docker yet and subsequently tried to push for rolling it out in production for my team. I don't know how incorrect
by OhSoHumble 10y ago
Oh, hai there. I haven't gone 'whole hog' on Docker yet and subsequently tried to push for rolling it out in production for my team.
I don't know how incorrect I am, but it seems like the Docker project is more interested in features rather than stability. Except, like you said, I don't have any specific examples to back that up. Maybe it's just community hive mind thought bleeding onto my decision making abilities?
The most concrete failing I've experienced was the deprecation of the boot2docker project in favor of docker machine. When I started using docker machine, stuff just... broke... and it left a bad taste in my mouth. In fact, using docker on either a mac or windows is just awful for me. My anecdotal experience is that it breaks in small ways that then that can really disrupt my productivity. I'm in the process of picking up docker again and it led me to install Arch on my work laptop just so I can have native containers.
Right now my use case is using containers to test Chef cookbooks and it works... alright. Not as well as virtual machines, but alright. How docker handles init bothers me a little bit but it's nothing the maintainers of the testing suites for Chef couldn't handle through yaml configuration options.
Oh, I guess while you're here... one thing I've been wrestling over is the usage of dockerfiles. I have no problem with containers but to me, it looks like using a configuration management system to bake container images seems to grant so much more flexibility and testing capabilities that I can't really see dockerfiles as anything other than an intermediate step. Is this a valid viewpoint?
- gerdesj 10y ago"but it seems like the Docker project is more interested in features rather than stability." I think that is a fair dig but I think they are still exploring the limits of what it can do. They are following the path of release often and make changes and show your working really well - you get to see the code and can contribute yourself. The thing is that you have to take all that into account when you are using their product. You need to take an Engineering approach to "production". Use Docker in the way that works for you. You state that you ended up using Arch instead of Windows or Mac - so fine, you have constructed a tool chain that works for you and welcome aboard! You see, Windows and Mac also do odd things every now and then but you don't get to see the workings. You are clearly not daft - you use Arch. I run Arch (my wife's laptop), Gentoo (my laptop and a fair few mail proxies and Icinga instances and other things), a lot of Ubuntus and a slack handful of Kalis and a sprinkling of Debians, Centos and others. You need to use engineering principles when going to production. Also you have to look at the price you paid to use Docker - it's a purely social one but one that is extremely important and may not involve money but cost you a fortune anyway. You need to decide if you want to pay that cost. You are clearly someone who understands the open source methodology but I would suggest that you look a little deeper into the dev -> prod thing. There is no reason why dev = Docker => prod = Docker. That's something that only you can decide after careful testing. Cheers Jon