On Thu, Jun 14, 2018 at 7:22 PM, Michael Thomas <mike@mtcc.com> wrote:
So I have to ask, why is it advantageous to put this in a container rather than just run it directly > on the container's host?
There is no real reason not to run it in a container, and all the advantages of running ALL applications in standardized containers (whether the choice be the likes of vSphere,XEN,KVM,Virtuozzo, LXC, or Docker). Assuming the host runs containers: running one app. outside the container (BGP) would put the other applications at risk, since there could be a security vulnerability in the BGP implementation allowing runaway resource usage or remote code exploitation, or in theory, the install process for that app could "spoil" the host or introduce incompatibilities or divergence from expected host configuration. One of the major purposes of containers is to mitigate such problems. For example the BGP application could be exploited but the container boundary prevents access to sensitive data of other apps. sharing the hardware; the application installer running in a container cannot introduce conflicts or impact operating settings of the host platform. Also, the common model of virtualizing the compute resource calls for treating hosts as a shared compute farm --- no one host is special: any container can run equally on other hosts in the same pod, and you hardly ever even check which host a particular container has been scheduled to run on. Users of the resource are presented an interface for running their application: containers. No other option is offered... there is no such thing as "run my program (or run this container) directly on host X" option. ---- no host runs directly any programs or services which have configurations different from any other host, and also every host config is about identical other than hostname & ip address; Simply put: being able to run a program outside a container would violate the service model for datacenter compute services that is most commonly used these days. Running the BGP application in a container on a shared storage system managed by a host cluster would also make it easier to start the service up on a different host when the first host fails or requires maintenance. On the other hand, running directly on a host, suggests that individual hosts need to be backed up again, and some sort of manual restore of local files from the lost host will be required to copy the non-containerized application to a new host.
Mike -- -JH