Does anyone know if this means anything significant in regards to LXD?
Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
61–70 of 80 posts
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#62Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#63Earlier quoted context omitted.
i had a quick question - do you see a convergence of Flatpak and snap at some point ? because it seems that RedHat and Fedora are beginning another divergence on static packaging.
I think it's better for someone from the Canonical/Snap team to comment on that. I'll ask them to comment.
Snaps are just a package format, an alternative to .deb which puts control of updates in the hands of the upstream. They enable an upstream to deliver a set of stable releases across versions of Ubuntu and other distros. In this case, it means Docker Inc can offer 1.x, 2.x, 3.x of Docker and provide security and feature updates directly.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#64Does anyone know if this means anything significant in regards to LXD?
Docker and LXD don't compete. Docker is great for running clustered processes - cloud-native apps - where Docker gives you hyperelasticity. CS Docker Engine provides more coordination facilities for those cloud-native apps.
LXD is more like KVM in that gives you "guests" that feel like a full OS. You can run existing apps in there in exactly the same way you would run them in a VM.
So these are two counterparts in the container continuum, and it's useful to understand them both so you use the right thing at the right time.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#65Earlier quoted context omitted.
What do you mean by sanely sharing users in the container?
An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You…
You're not doing things the "Docker" way. If you've got data you want to pull out, use a mounted volume and get it out that way.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#66Earlier quoted context omitted.
An example is easiest. I have my machine setup to provide who I am to machines I ssh to. Now, launch a container that you want to pull data from a machine that you have ssh access to. First, you'll find that the user used to setup the container was not you. So you can't even just map in your .ssh dir. So you'll try modifying the image to work with specified user at start up. Only, again, it wasn't setup that way. You…
You're not doing things the "Docker" way. If you've got data you want to pull out, use a mounted volume and get it out that way.
This doesn't really change anything. I want to put data in and then take derived data out. All while maintaining access protections to my user on the host system.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#67Does anyone know if this means anything significant in regards to LXD?
Docker and LXD don't compete. Docker is great for running clustered processes - cloud-native apps - where Docker gives you hyperelasticity. CS Docker Engine provides more coordination facilities for those cloud-native apps. LXD is more like KVM in that gives you "guests" that feel like a full OS. You can run existing apps in there in exactly the same way you would run them in a VM. So these are two counterparts in th…
I'm well aware of LXC, I do understand them both. And LCX is not more like KVM. KVM is full virtualization, it emulates hardware, and nothing like LXC.
LXC is based on cgroups and kernel namespaces - the exact same things that enable Docker-based containers. LXD and Docker engine are competing "container"-based virtualization engines.
LXC can can be run as app-based containers just like Docker. This is what lxc-execute does. You don't have to run init as pid 1 in LXC.
By the way "Cloud-native" is little more than a marketing term.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#68Earlier quoted context omitted.
You're not doing things the "Docker" way. If you've got data you want to pull out, use a mounted volume and get it out that way.
This doesn't really change anything. I want to put data in and then take derived data out. All while maintaining access protections to my user on the host system.
That's what mounts let you do. I'm not sure why you don't agree.
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#69Earlier quoted context omitted.
I see. This is an interesting problem, and I would think one that a lot of people are experiencing. Seems like an area of opportunity to make docker images a lot more flexible.
Apologies for the slow response on this post. I would love to think of ways to fix this. I think most uses of docker today involve deploying applications that you do want completely sandboxed. And for those, this works rather well. Hopefully this doesn't keep you from trying it. (Indeed, you may have a nice solution to this that escaped me.)
Unless I grossly misread your problem--which I may have!--it seems like you're trying to handle authentication and accounts on the docker instance.
What's wrong with using ye olde Kerberos and LDAP to accomplish this exactly?
Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu
#70Earlier quoted context omitted.
This doesn't really change anything. I want to put data in and then take derived data out. All while maintaining access protections to my user on the host system.
That's what mounts let you do. I'm not sure why you don't agree.
That is what they do nominally. But for existing data, it falls flat. Hard.
Again, an example is easiest. (Will also shed light on if I am actually doing something wrong. Entirely in the realm of plausible.)
So, you have a file share with your data, scoped to user "cheez". You can ssh to machine "remote" and see this data. You can copy this data over to your machine, call it "local" and it will still be scoped to your user, "cheez". This is great, as you don't have to worry about someone else accidentally getting access to it.
However, you decide to use "container A" to run some analysis on this data. The folks that setup "container A" did so using the username "container". You mount your data on a volume to "/my/data". You check, and the container can now see it, but user "container" does not have permission to do anything with it.
You have plenty of options at this point. You can give public permissions to see the data in the directory. You can launch ssh from in the container and copy the data in. (Note that this way will have the data in the container as belonging to "container" which will make similar concerns on egress.)
You can also run the container as "root" which will clearly have permission. However, recognize the concerns with this approach, as this also gives you permission to see any other file in that directory that "cheez" wouldn't normally have permission to see.
You can also recreate the container such that "cheez" is the user that is created in the container. This sounds great, but redoing the entire setup of the image has a few problems. Not to mention the security implications this has, since you could also recreate the image with the user of your boss and circumvent some other security measures of your machine.
Now, if your container doesn't set anything up in userspace (defined as "not root") until launch of the container, much of this concern goes away. Not all of it, I believe, but most. However, anything that you want to run "in the container" using your identity from "out of the container" seems to fall into this trap. It is subtle, but gets in the way of a lot of use cases.