We have a whole lot of web apps and services at work - most of them are not internet-facing as they are internal 'admin' type tools. At the mome...
For further actions, you may consider blocking this person and/or reporting abuse
What you've described is feasible however I would look at using multiple replicas to prevent container creation and downtime. With either solution, you have no need to failover.
Honestly, Kubernetes is complex, but it's also the future. Learning it now will only serve you later and once you have the hang of it, it's actually awesome. Swarm is great, but you're 100% correct, it's lost the war. Good luck!
Hi,
Yeah - I'd be going with replicas for the applications and using rolling deployments with them to make the fallover work more nicely - at least for the apps I care about (there are quite a few metrics/stats things that really don't matter much so I might not bother with those).
I hear what you say about kubernetes - and it's one of my worries about going with Swarm. I'd really like the simplicity of swarm with the community of kubernetes ;-) Part of my worry with k8s is the pace of development - not of the features themselves so much - but that almost every document & tutorial about it seems to be out of date the moment it's written. One tutorial will say to use X-method for ingress, the next tutorial explains that X-method is so last week and we should all now be using method-Y ;-) For my underlying architecture I quite like it not to move so fast - years of looking after Solaris and AIX boxes will do that to you I guess ;-)
Nothing's set in stone yet - so I'm keeping my options open w/regards k8s vs. swarm. But as you say - I'm painfully aware that k8s seems to have won out and I don't want to be sitting in a year re-building it all ;-)
Thanks again for your reply :-)