5 ms·
If you want something stable I'd stay away from containers and use well-tested technologies like VMs and configuration management. In my experience many of the
by tveita 11y ago
If you want something stable I'd stay away from containers and use well-tested technologies like VMs and configuration management.
In my experience many of the tools in the container ecosystem are in the early adopter phase, promising a lot of convenience for some use cases, but too buggy and feature incomplete to really deliver yet. Not to mention the breaking changes and occasional migration to a new tool.
- vacri 11y agoWe were using docker up to about a year ago, and ripped it out for just this reason - we didn't have the time available to keep coding the workarounds. Great if you have the time, not so great if you don't.
- endymi0n 11y agoWe were too deep in already unfortunately, but 1.10 introduced a whole new barrage of bugs and regressions, wasting hours and days working around it. If they don't devote some time getting the basics right and getting the core stable, we need to really consider alternatives. I'm already scared what 1.11 will break.
- cpuguy83 11y agoPlease make sure to report any issues so they can be fixed.
- crdoconnor 11y agoStuff like this is what makes me wary of any technology that's been hyped.
- yomism 11y agoI too had a production deploy using Docker and but droped it because of changes like this and some instability. Started using Ansible (ok, maybe comparing oranges to apples here) and its better for my use case.
- tachion 11y agoOr simply use containers technology that's been around for a decade and is battle tested and stable, like FreeBSD Jails - https://www.freebsd.org/doc/handbook/jails.html https://www.freebsd.org/doc/handbook/jails.html Linux is not the only OS around, and Docker is not the only container technology available, that's important thing to remember.
- endymi0n 11y agoThing is, on top of being stable, it should be useful. If you're using containers just for your own code - fine. If you mix and match other repos and ecosystems like we and many others do, good luck with FreeBSD. 60% of the time, interesting repos already have a Dockerfile and if they don't, it's usually pretty easy to write one. With FreeBSD containers, I'd have to do all the wiring myself - if and only if it even compiles and works out of the box on a non-Linux system.
- tachion 11y agoWell, sure, but how is that different from writing workarounds for all these Docker quirks? At least you end up with self-baked solution based on stable technology, instead of self-baked solution for unstable technology. And when it comes to software, its hard to find one that doesnt work on FreeBSD (there's over 24k of precompiled packages available!), not to mention FreeBSD's Linuxulator, that is Linux kernel emulation, built in, so that sentence may be considered spreading a FUD.
- deleted 11y ago[deleted]
- musha68k 11y agoYou are mostly right but devops people should still play around with the newest tools to form their own opinions. It's complicated. I wouldn't stop considering containers per-se (SmartOS zones/FreeBSD jails are fine!) but the whole tooling surrounding the management of Linux containers and corresponding images is still in the "cambrian" phase. Security issues and the general over-selling of the technology (Docker and CoreOS especially are almost too good at marketing their products..) shouldn't discourage you to play around with "those toys" though. Even for certain production scenarios there is a bunch of setups which work fine already (RedHat's OpenShift platform comes to mind).