Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

docker.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#71

Post by taeric »

angersock wrote: post #69
taeric wrote: post #59

Earlier quoted context omitted.

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?

That is certainly a path I considered. However, having to setup either of those is not exactly trivial. And not something I care to do for a user application.

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#72

Post by sandGorgon »

markshuttle wrote: post #63
nickstinemates wrote: post #37

Earlier quoted context omitted.

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.

Thanks for answering. Flatpak is unavailable for Ubuntu official repositories (it has an unofficial ppa) while Snap is only installable on Fedora using a copr.

A new packaging format would have been great time for Linux to converge around the biggest usability+discoverability+ availability problem that the platform has. While developers need to release one binary for osx or Windows...they need to release atleast 4 for different Linux flavors.

Is there any chance that there could be convergence around the new static packaging that everyone is reinventing?

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#73

Post by sandGorgon »

dustinkirkland wrote: post #43
sandGorgon wrote: post #35

Earlier 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.

Actually, there's quite a bit of cross-distro compatibility around Snaps. Beyond Ubuntu, Snaps are known to work in Arch Linux, Debian, Gentoo, Fedora, openSUSE, Yocto, and OpenWRT. Snaps simply require a modern systemd and snapd daemons. With the appropriate SELinux profiles and an updated snapd, it's entirely feasible for the same docker.snap to run on both Ubuntu and Fedora (as well as others). You can learn more…

And the same thing is true for Flatpak...but are we really looking forward to another 20 years of multiple packaging formats for Linux ?

The push towards static packaging is a great time to unify. The problem is that snap is based on deb..not sure about Flatpak. So we again have a political split.

I really think this is the opportunity to unify Linux packaging - anything, I don't care..but let us please have one package format.

http://arstechnica.com/information-technology/2016/06/here-c...

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#74

Post by cheez »

taeric wrote: post #70
cheez wrote: post #68

Earlier quoted context omitted.

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 you…

Yep, this is a common problem. The solution is not perfect, but works correctly with respect to permissions:

https://medium.com/@ramangupta/why-docker-data-containers-ar...

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#75

Post by taeric »

cheez wrote: post #74
taeric wrote: post #70

Earlier quoted context omitted.

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 you…

Yep, this is a common problem. The solution is not perfect, but works correctly with respect to permissions: https://medium.com/@ramangupta/why-docker-data-containers-ar...

I'm not seeing anything there that addresses this.

To be clear, as a service deployment mechanism, this is fine. As an end user tool, this blows. Unless every container builds in support for LDAP or Kerberos, then each container is effectively a new computer on the network without auth setup in a meaningful way.

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#76

Post by mhall119 »

sandGorgon wrote: post #73
dustinkirkland wrote: post #43

Earlier quoted context omitted.

Actually, there's quite a bit of cross-distro compatibility around Snaps. Beyond Ubuntu, Snaps are known to work in Arch Linux, Debian, Gentoo, Fedora, openSUSE, Yocto, and OpenWRT. Snaps simply require a modern systemd and snapd daemons. With the appropriate SELinux profiles and an updated snapd, it's entirely feasible for the same docker.snap to run on both Ubuntu and Fedora (as well as others). You can learn more…

And the same thing is true for Flatpak...but are we really looking forward to another 20 years of multiple packaging formats for Linux ? The push towards static packaging is a great time to unify. The problem is that snap is based on deb..not sure about Flatpak. So we again have a political split. I really think this is the opportunity to unify Linux packaging - anything, I don't care..but let us please have one pack…

Snaps are descendant from deb, but they are now just squashfs images with some metadata

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#77

Post by cheez »

taeric wrote: post #75
cheez wrote: post #74

Earlier quoted context omitted.

Yep, this is a common problem. The solution is not perfect, but works correctly with respect to permissions: https://medium.com/@ramangupta/why-docker-data-containers-ar...

I'm not seeing anything there that addresses this. To be clear, as a service deployment mechanism, this is fine. As an end user tool, this blows. Unless every container builds in support for LDAP or Kerberos, then each container is effectively a new computer on the network without auth setup in a meaningful way.

What it's saying is that you have a container you use only to store the data, then share that container's volume with the target container. Finally, because it's on your hard drive, you can access it.

Basically, instead of host -> container, you do container -> container.

And yeah, the container is supposed to be effectively a new computer, but you can build images to create the auth environments you need and base everything off those.

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#78

Post by taeric »

cheez wrote: post #77
taeric wrote: post #75

Earlier quoted context omitted.

I'm not seeing anything there that addresses this. To be clear, as a service deployment mechanism, this is fine. As an end user tool, this blows. Unless every container builds in support for LDAP or Kerberos, then each container is effectively a new computer on the network without auth setup in a meaningful way.

What it's saying is that you have a container you use only to store the data, then share that container's volume with the target container. Finally, because it's on your hard drive, you can access it. Basically, instead of host -> container, you do container -> container. And yeah, the container is supposed to be effectively a new computer, but you can build images to create the auth environments you need and base ev…

But that doesn't work unless you do everything with public permissions. Seriously try it. Make a container that you share a volume with. Do something in that container on some data and see who owns it according to your computer.

The use case I have above is a real one. Somehow try to share your .ssh folder with a utility container sometime.

User namespaces somewhat help. But fall flat for the case of "still being you" on a container.

It can be comical even for the intended two containers choice. Unless both use the same uid:gid to write files, one container will not be able to read the other containers data.

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#79

Post by cheez »

taeric wrote: post #78
cheez wrote: post #77

Earlier quoted context omitted.

What it's saying is that you have a container you use only to store the data, then share that container's volume with the target container. Finally, because it's on your hard drive, you can access it. Basically, instead of host -> container, you do container -> container. And yeah, the container is supposed to be effectively a new computer, but you can build images to create the auth environments you need and base ev…

But that doesn't work unless you do everything with public permissions. Seriously try it. Make a container that you share a volume with. Do something in that container on some data and see who owns it according to your computer. The use case I have above is a real one. Somehow try to share your .ssh folder with a utility container sometime. User namespaces somewhat help. But fall flat for the case of "still being you…

So here is how I would think about your problem: am I doing this the way the tool wants me to do this? Does the tool even support this use case? If not, how should it be done? Is it impossible, or do I just not like the aesthetics of the solution?

If it's just the aesthetics of the solution, then you have a way forward. But if it is literally impossible to get data on and off a container, then you have a problem.

Re: Docker and Canonical Partner on Commercially-Supported Docker Engine for Ubuntu

#80

Post by orblivion »

taeric wrote: post #14

I really want to like docker for end user applications. However, until the problem of sanely sharing users into the container is solved, it is something that merely works well right up to the point you try to do something useful. I suppose this can be sidestepped by allowing root in all of your containers for the applications. I am curious if that actually provides security benefits, though.

What about the Snap thing that Ubuntu is working on? Unlike (afaik) Docker it's built for security (among other things), so it's sandboxed.

http://snapcraft.io/

Post reply on HN