November 5, 20169 yr Have our leading dockers experts encountered these issues? https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ Sounds depressing. via Tapatalk
November 5, 20169 yr I'll address some of the concerns: 1) At the time it wasn’t possible to run a container [in the background] and there wasn’t any command to see what was running, debug or ssh into the container. A: unRAID was always able to run docker containers in the background, and within two months of it's inclusion on the beta branch of unRAID, the docker manager was fully functional, even if it was a plugin then. So no command line issues here. 2) There are all kind of subtle regressions between Docker versions. It’s constantly breaking unpredictable stuff in unexpected ways. A: Even this being true, the guys from LT, specially Jonathan and Eric, test everything before they ship a new version of Docker for us, so no major issues happen with us. 3) The docker journey begins with a clean up script. It is an initiation rite every organization has to go through. A: The majority of image layers are expunged from the datastore when we remove/update our containers. This is not a serious issue for us, and if someone need, Squid's User Scripts plugin has a special tool to clean the mess. 4) There are endless issues related to the interactions between the kernel, the distribution, docker and the filesystem. A: This is true, BTRFS and Docker have their problems sometimes, but no major flaw here. 5) Linux 3.x: Unstable storage drivers A: unRAID currently uses 4.x kernel builds, so we are on the edge of the development. 6) As a long standing goal, the AUFS filesystem was finally dropped in kernel version 4. A: unRAID always used BTRFS, so this doesn't affect us. 7) The transition to the registry v2 was not seamless. We had to fix our setup, our builds and our deploy scripts. A: Yep, this is somewhat true. Some of functionality of Docker Manager was affected by v2 registry migration, but wasn't serious neither evolved in major code rewrite. There were another reasons, but the majority was due to improper use of Docker, it seems.
November 5, 20169 yr It does read as though the author of the article has an issue with docker..... It seems like that, yes... But he is right when he says you can't delete unused/old/stale portions inside the docker image. Periodically deleting the .img and installing everything again is a 'hack'. Networking is much more difficult that it should be. Come on, why isn't it easy to give a docker a 'public'/fixed (for the local LAN) IP ? Pipework is also a 'hack'.
November 5, 20169 yr It does read as though the author of the article has an issue with docker..... It seems like that, yes... But he is right when he says you can't delete unused/old/stale portions inside the docker image. Periodically deleting the .img and installing everything again is a 'hack'. Networking is much more difficult that it should be. Come on, why isn't it easy to give a docker a 'public'/fixed (for the local LAN) IP ? Pipework is also a 'hack'. Not arguing with those points at all. But it's the best we got at this current time and it's a hell of a lot better than when we were on V5 and relying on plugins for everything. Yeah there are limitations, there always are with anything we use. Just a matter of making the best of what we have....
Archived
This topic is now archived and is closed to further replies.