Re: Docker and Container Tools Podman/Buildah/Skopeo
On Tue, Mar 05, 2019 at 02:26:24PM +0100, plataleas plataleas wrote: RedHat announced with RHEL8 that the docker container engine is replaced by a suite of tools in the Container Tools module including podman, buildah and skopeo. https://access.redhat.com/discussions/3697371 What does the Debian community think of this move? Does it make sense to prefer podman/buildah/skopeo over the docker engine on Debian systems as well? Some of those tools have some advantages over Docker: podman, for example, can allow a normal user to start containers, without requiring write access to a shared socket, or superuser privileges. It also operates without a persistent daemon running. Skopeo is more of a separate utility rather than replicating functionality of Docker, it's very useful though. None of the tools are packaged for Debian yet. I've had a preliminary look at podman, but it's too late now to get these into the next stable release. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Docker and Container Tools Podman/Buildah/Skopeo
Hi. On Fri, Mar 08, 2019 at 09:34:03AM +, Jonathan Dowland wrote: > On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote: > > s/RedHat/IBM/g > > > > fixed that for you. > > Not until the deal closes, because there's still a small chance it > won't (as in all deals). I'll take my chances :) > So really, you just broke it. Nah, merely anticipated. Reco
Re: Docker and Container Tools Podman/Buildah/Skopeo
On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote: s/RedHat/IBM/g fixed that for you. Not until the deal closes, because there's still a small chance it won't (as in all deals). So really, you just broke it. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Docker and Container Tools Podman/Buildah/Skopeo
On Wed, Mar 06, 2019 at 03:32:02PM +0100, Dejan Jocic wrote: > On 06-03-19, Reco wrote: > > Hi. > > > > On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote: > > > On 05-03-19, Reco wrote: > > > > > > > > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long > > > > list, although RedHat has longer one. > > > > > > > > Reco > > > > > > > > > Mir and Unity I can get, but why would you put LXD in that sentence about > > > NIH? > > > > Given the existence of LXC, why would anyone need LXD? > > You do realise that LXD is wrap around LXC, or rather libxlc, which > improves its functionality, while not taking anything from it? Yep. And I see nothing that needs to be improved with LXC, security issues left aside. LXC has sane configuration format already, and, which is more important, sane semantics, compared to [1]. It has features, including the arbitrary network configuration (not that kind of abomination in LXD, or $DEITY forbid, systemd-nspawn or runc), and arbitrary storage configuration. What's more important, it's easily extensible. > Some of that functionality is live snapshot migration, CRIU is lightyears ahead here. > bit improved security, LOL. [2] says: [LXD] Containers can be managed over the network in a transparent way through a REST API. Every time you add a web interface to a good thing you diminish its security. No exceptions. > improved/easier to manage networking, Nothing comes easy once you start writing your own DSL for the network configuration. Besides, if one has trouble with LXC network configuration, one should consider a job change IMO. > overall better management. You forgot YMMV, so I'm adding it here. > Also, while Canonical is not only supporter of LXC, it is practically > major supporter, as far as I know ( but could be wrong about it ). ... and that's exactly why they could focus on fixing real issues such as [3], [4], and [5] (last one is a shameless plug) instead of trying to write yet another Openstack clone. Reco [1] https://lxd.readthedocs.io/en/latest/configuration/ [2] https://linuxcontainers.org/ [3] https://seclists.org/oss-sec/2019/q1/125 [4] https://seclists.org/oss-sec/2019/q1/119 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906805
Re: Docker and Container Tools Podman/Buildah/Skopeo
On 06-03-19, Reco wrote: > Hi. > > On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote: > > On 05-03-19, Reco wrote: > > > > > > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long > > > list, although RedHat has longer one. > > > > > > Reco > > > > > > Mir and Unity I can get, but why would you put LXD in that sentence about > > NIH? > > Given the existence of LXC, why would anyone need LXD? > > Reco > You do realise that LXD is wrap around LXC, or rather libxlc, which improves its functionality, while not taking anything from it? Some of that functionality is live snapshot migration, bit improved security, improved/easier to manage networking, overall better management. Also, while Canonical is not only supporter of LXC, it is practically major supporter, as far as I know ( but could be wrong about it ).So, again, I don't really think that it belongs under NIH syndrome. Thanks for reply, Dejan
Re: Docker and Container Tools Podman/Buildah/Skopeo
Hi. On Wed, Mar 06, 2019 at 12:17:27PM +0100, Dejan Jocic wrote: > On 05-03-19, Reco wrote: > > > > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long > > list, although RedHat has longer one. > > > > Reco > > > Mir and Unity I can get, but why would you put LXD in that sentence about > NIH? Given the existence of LXC, why would anyone need LXD? Reco
Re: Docker and Container Tools Podman/Buildah/Skopeo
On 05-03-19, Reco wrote: > > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long > list, although RedHat has longer one. > > Reco Mir and Unity I can get, but why would you put LXD in that sentence about NIH? Dejan
Re: Docker and Container Tools Podman/Buildah/Skopeo
On Tue, Mar 05, 2019 at 09:56:50PM +0300, Reco wrote: > Hi. > > On Tue, Mar 05, 2019 at 05:07:00PM +0100, to...@tuxteam.de wrote: [...] > > You may dislike Redhat all you want [...] > Indeed. For instance, RedHat in its infinite wisdom blessed us with > pulseaudio [...] Still we'd be far worse off without well-maintained GCC, libc, binutils et al. We gotta be fair, I think. > > Actually more than can be said about Canonical [...] > Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long > list, although RedHat has longer one. Still, it's free software. We gotta acknowledge that, and work on keeping the alternatives viable we deem better. And we can make use of selected bits & pieces from those solutions... we have the permission, after all. > > As for the docker thingies... I get what they are supposed to do. But if > > I can convince someone else to to the dirty work... > > Hear, hear. You see, docker et al are targeted mainly at big corps: lots of machinery, save on capable sysadmins. IMHO it is a mixed blessing (even for them), because they end up integrating "whatever docker image lies around on my cloud provider's attic" into their core infrastructure, but hey: I'm not particularly sad when they fall flat on their faces for that. In a nutshell: IMHO critical, yes. Unfair, no. Cheers -- tomás signature.asc Description: Digital signature
Re: Docker and Container Tools Podman/Buildah/Skopeo
Hi. On Tue, Mar 05, 2019 at 05:07:00PM +0100, to...@tuxteam.de wrote: > On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote: > > Hi. > > > > On Tue, Mar 05, 2019 at 02:26:24PM +0100, plataleas plataleas wrote: > > > Hi all > > > > > > RedHat announced with RHEL8 that the docker container engine is replaced > > > by > > > > s/RedHat/IBM/g > > > > fixed that for you. > > > > > > > What does the Debian community think of this move? > > > > Mixed, but I speak only for myself. > > On one hand, RedHat is known for its Not-Invented-Here syndrome. > > Endless re-implementation of known tools can hardly do anyone any good. > > Also, vendor lock-in and all that. > > You may dislike Redhat all you want (and hey, I've my beefs with them > too) but they do pay part of the bills (sometimes a significant part!) > for many things that are dear to our hearts. For example gcc, the GNU > C library and many friends (binutils, etc.) through their acquisition > of Cygnus Support (these days called Sourceware) in the 2000s; further > to the Linux kernel (through many kernel people on RH's paylist -- use > your own search engine this time ;-) and many, many more things. Indeed. For instance, RedHat in its infinite wisdom blessed us with pulseaudio (#worksinfedora), systemd (#notabug), GNOME 3 (#itsmodern), Network Manager (aka Notwork Mangler), Flatpack (#designedforshovelware) and many other Finely Designed Programs™. > Actually more than can be said about Canonical, for example (the latter > have at least given back to Debian by having Debian Developers on > payroll, so...) Canonical's famous for their NIH too. Mir, Unity, LXD - it's a long list, although RedHat has longer one. > As for the docker thingies... I get what they are supposed to do. But if > I can convince someone else to to the dirty work... Hear, hear. Reco
Re: Docker and Container Tools Podman/Buildah/Skopeo
On Tue, Mar 05, 2019 at 06:10:40PM +0300, Reco wrote: > Hi. > > On Tue, Mar 05, 2019 at 02:26:24PM +0100, plataleas plataleas wrote: > > Hi all > > > > RedHat announced with RHEL8 that the docker container engine is replaced by > > s/RedHat/IBM/g > > fixed that for you. > > > > What does the Debian community think of this move? > > Mixed, but I speak only for myself. > On one hand, RedHat is known for its Not-Invented-Here syndrome. > Endless re-implementation of known tools can hardly do anyone any good. > Also, vendor lock-in and all that. You may dislike Redhat all you want (and hey, I've my beefs with them too) but they do pay part of the bills (sometimes a significant part!) for many things that are dear to our hearts. For example gcc, the GNU C library and many friends (binutils, etc.) through their acquisition of Cygnus Support (these days called Sourceware) in the 2000s; further to the Linux kernel (through many kernel people on RH's paylist -- use your own search engine this time ;-) and many, many more things. Actually more than can be said about Canonical, for example (the latter have at least given back to Debian by having Debian Developers on payroll, so...) As for the docker thingies... I get what they are supposed to do. But if I can convince someone else to to the dirty work... Cheers [1] https://sourceware.org/news.html -- tomás signature.asc Description: Digital signature
Re: Docker and Container Tools Podman/Buildah/Skopeo
Hi. On Tue, Mar 05, 2019 at 02:26:24PM +0100, plataleas plataleas wrote: > Hi all > > RedHat announced with RHEL8 that the docker container engine is replaced by s/RedHat/IBM/g fixed that for you. > What does the Debian community think of this move? Mixed, but I speak only for myself. On one hand, RedHat is known for its Not-Invented-Here syndrome. Endless re-implementation of known tools can hardly do anyone any good. Also, vendor lock-in and all that. On the other hand, "Docker Community"/"Docker Enterprise" - [1]? That's the road that no sensible program should take. > Does it make sense to prefer podman/buildah/skopeo over the docker > engine on Debian systems as well? I'd suggest runc if you're looking for a viable alternative right now. Reco [1] https://www.docker.com/products
Docker and Container Tools Podman/Buildah/Skopeo
Hi all RedHat announced with RHEL8 that the docker container engine is replaced by a suite of tools in the Container Tools module including podman, buildah and skopeo. https://access.redhat.com/discussions/3697371 What does the Debian community think of this move? Does it make sense to prefer podman/buildah/skopeo over the docker engine on Debian systems as well? Thanks for your thoughts! martin
