Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #206014 > unrolled thread

Docker and Container Tools Podman/Buildah/Skopeo

Back to article view | Back to linux.debian.user

Contents

  Docker and Container Tools Podman/Buildah/Skopeo plataleas plataleas <plataleas@gmail.com> - 2019-03-05 14:30 +0100
    Re: Docker and Container Tools Podman/Buildah/Skopeo Reco <recoverym4n@enotuniq.net> - 2019-03-05 16:20 +0100
      Re: Docker and Container Tools Podman/Buildah/Skopeo <tomas@tuxteam.de> - 2019-03-05 17:10 +0100
        Re: Docker and Container Tools Podman/Buildah/Skopeo Reco <recoverym4n@enotuniq.net> - 2019-03-05 20:00 +0100
          Re: Docker and Container Tools Podman/Buildah/Skopeo <tomas@tuxteam.de> - 2019-03-06 10:40 +0100
          Re: Docker and Container Tools Podman/Buildah/Skopeo Dejan Jocic <jodejka@gmail.com> - 2019-03-06 12:20 +0100
            Re: Docker and Container Tools Podman/Buildah/Skopeo Reco <recoverym4n@enotuniq.net> - 2019-03-06 15:10 +0100
              Re: Docker and Container Tools Podman/Buildah/Skopeo Dejan Jocic <jodejka@gmail.com> - 2019-03-06 15:40 +0100
                Re: Docker and Container Tools Podman/Buildah/Skopeo Reco <recoverym4n@enotuniq.net> - 2019-03-06 16:50 +0100
      Re: Docker and Container Tools Podman/Buildah/Skopeo Reco <recoverym4n@enotuniq.net> - 2019-03-08 10:40 +0100
      Re: Docker and Container Tools Podman/Buildah/Skopeo Jonathan Dowland <jmtd@debian.org> - 2019-03-08 10:40 +0100
    Re: Docker and Container Tools Podman/Buildah/Skopeo Jonathan Dowland <jmtd@debian.org> - 2019-03-08 11:00 +0100

#206014 — Docker and Container Tools Podman/Buildah/Skopeo

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#206017

	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

[toc] | [prev] | [next] | [standalone]

#206018

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#206019

	Hi.

On Tue, Mar 05, 2019 at 05:07:00PM +0100, tomas@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

[toc] | [prev] | [next] | [standalone]

#206029

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 05, 2019 at 09:56:50PM +0300, Reco wrote:
> 	Hi.
> 
> On Tue, Mar 05, 2019 at 05:07:00PM +0100, tomas@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

[toc] | [prev] | [next] | [standalone]

#206031

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

[toc] | [prev] | [next] | [standalone]

#206033

	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

[toc] | [prev] | [next] | [standalone]

#206035

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

[toc] | [prev] | [next] | [standalone]

#206037

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

[toc] | [prev] | [next] | [standalone]

#206068

	Hi.

On Fri, Mar 08, 2019 at 09:34:03AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#206069

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.

[toc] | [prev] | [next] | [standalone]

#206070

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web