[Info-vax] Containers - (was: Installing and using GNV - some feedback and questions)

[John E. Malmberg]

On 10/31/2016 8:34 AM, Stephen Hoffman wrote:
> On 2016-10-30 17:02:46 +0000, David Froble said:
>
>> I see some issues, and possibilities.
>>
>> If a user is to only be allowed in the container / application /
>> whatever assigned to him, then logging into the base OS seems to be
>> giving the user more than would be appropriate?
>
> Potentially.   And it's not just the users, the applications in the
> containers shouldn't be accessing other containers.   There'll also be
> requirements for accessing and protecting shared data.

It depends on the type of container.  Some containers are jails and some 
are not.

There are trusted containers and un-trusted containers.  Older 
containers typically were "trusted".

As security enforcement of containers has been added to be the default 
for new OS versions, some containers break on upgrade.

My container below runs on Ubuntu 14.04, but not Ubuntu 16, because 
Ubuntu 16 requires a trusted container to explicitly request the 
privileges needed.  Unfortunately Ubuntu 16 does not contain the libvirt 
library that can request those privileges.

>> Should users logged into the base OS be allowed to access all
>> containers? Perhaps a login to the container might be appropriate?
>
> Following the sandbox or jail model, containers get their own instance
> of the OS interfaces (to isolate those applications), and users can
> access those containers using user access controls.

>> With one OS, the issue of multiple OS licenses seems to go away?

Generally the containers are usually all Linux or the same non-linux OS 
as the host.

With Linux, it can then depend on the Linux distro and the type of 
container.  As I generally am using Linux distros that do not require 
license fees or paid contracts, I have not looked into that issue.

> There's a case for less overhead than virtualization — containers are
> virtualization at the OS level, rather than the hardware level — and
> there are less OS software licenses.
>
>> Being able to boot from a container doesn't seem to be very useful.
>
> It gets all the dependencies into one package.

It is usually not a true boot, more like the creation of a process tree.

>> If only that container is to be run, then why use a container?  Yes, I
>> understand testing a new OS version, and such, but that's what test
>> systems are for, not production systems.
>
> Repeatability, scheduling and failover, among other reasons.   Gives an
> easy way to turn it off and turn it back on again, from a known-good copy.

A container can appear externally to your system as a standalone system.

https://sourceforge.net/p/vms-ports/wiki/SimH-VAX%20in%20a%20Container/

I can move this container from one Linux system to another.  And this 
container will show up on many standard system management packages as a 
somewhat supported system because it is controlled by libvirt.

>> It seems to me that containers may be useful in some scenarios, but
>> not so much otherwise.  I've loaded the Python containers, and yes, it
>> was simple, and "contained".  But for production, it adds another
>> layer of complexity.
>
> There's no universal answer.
>
>> A good capability to have, and already to some extent available, but,
>> not to be used just because it's available.
>
> My fondness for bundles is around the ease of installation, management,
> upgrades and cleanup, and around the enforced isolation among the
> installed bundles.

Regards,
-John
wb8tyw at qsl.net_work