On Sat, 17 Aug 2019, Daniel Walsh wrote:

Just off the top of my head:

o    What are Containers

o    The container applications

o    Quick intro to Buildah

o    Deeper intro to Podman (Podman uses Buildah when it does `podman
build`).

... snip ...

  i'm going to follow up on my earlier post with a thought that might
provoke a reaction but, what the heck ... (i'm free associating here
so, be warned ...)

  i've designed and delivered a *bunch* of linux/linux-related
courses, and one of the things that seems to really, really, really
set the stage properly early on is to list the components to be
covered, and map those components *specifically* to the red hat/fedora
packages that provide them.

  it may sound weird but, in the relevant courses, students seem to
grasp the "big picture" more quickly if one not only lists the
concepts to be covered, but maps that to actual fedora (my OS of
choice) packages, along with what each package provides. let me give
an example.

  if i'm going to teach a course on containers on fedora (which is my
plan), it would be easy to just:

  $ sudo dnf group install --with-optional "container management"

and go from there. but my experience is that it's clearer if one
starts with the *minimal* set of packages to get started and, as the
class progresses, one by one, installs each additional package only
when necessary, while explaining what that new package brings to the
table.

  so, after displaying the various components of container technology,
i would start with only podman (and, sure, podman-docker) installed,
and cover what that allows one to do.

  once that's done, introduce and install "buildah", and work with
that. after that, skopeo, i guess, and so on, and so on. mapping each
feature to a separate package really drives home the idea that these
are different features that can be installed and worked with
separately.

  over the next day or two, i'm going to flesh this out and put it all
on a wiki page to make it clearer. i guess what i'm talking about here
is explaining the entire container "ecosystem", and mapping that to
the (fedora/RH) packages that support it.

  thoughts?

rday

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io

Robert,

Your approach sounds entirely reasonable to me.  As far as how/when to introduce Buildah, I'll leave that up to you.  I just wanted to make you aware that Podman vendors in Buildah and then calls the API's for the actual building of the containers when it does `podman build`.    The point that James brought up about the latest/greatest Buildah possibly not being the same as the one used by Podman is true.  However, just before we release a new Podman we create a new version of Buildah and do a fresh vendoring into Podman. 

If you want to figure out what version of Buildah your Podman is using, you can use this command:

# podman info | grep Buildah
  BuildahVersion: 1.9.0

One other small note in case it matters, Buildah and Podman use the --layers option differently.  By default Podman build does this 'podman build --layers=true' while by default Buildah does `buildah --layers=false`.  I bring this up only because with some Dockerfiles you will get different resulting images if you use one tool over the other due to the layers option being set differently.

Hope that helps,

t