[TriLUG] docker vs podman

[Hrivnak, Michael via TriLUG]

On Wed, Aug 19, 2020 at 5:51 PM Mauricio Tavares <raubvogel at gmail.com>
wrote:

> I should have not hit send so fast...
>
> On Wed, Aug 19, 2020 at 4:37 PM Mauricio Tavares <raubvogel at gmail.com>
> wrote:
> >
> > On Wed, Aug 19, 2020 at 3:39 PM Hrivnak, Michael <mhrivnak at hrivnak.org>
> wrote:
> > >
> > >
> > >
> > > On Wed, Aug 19, 2020 at 10:10 AM Mauricio Tavares via TriLUG <
> trilug at trilug.org> wrote:
> > >>
> > >> Pros:
> > >> 1. More secure (?) because it does not use a daemon and runs rootless
> > >
> > >
> > > Rootless is a big deal. Many people set up docker to let them run
> containers as their normal user and then forget that they've effectively
> enabled passwordless-sudo. Yes it enables you to "docker run foo" without
> sudo, but the docker daemon doing the work is running as root!
> https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user
> > >
> > > Podman will truly run your container without any root privileges
> necessary.
>
>       As I asked when I accidentally sent an incomplete reply, how
> does that affect PCI passthrough? Can I still do that? If so, are
> there extra abstraction layers being added?
>

You can use the --device option to pass a device from the host into the
container. There's no abstraction AFAIK. I think it just bind mounts the
device in.


>
> This also reminds me I need to put some time on LXC.
>
> > >
> > > An underappreciated perk of being daemonless is that your UID extends
> into containers, which makes it possible to identify you in the host
> system's audit log. When things go sideways, that can make a big difference.
> > >
>       That reminds me of some research I need to do to answer a little
> weeble bit of a question I have. Let me make myself a reminder so I
> will not forget about it.
>
> > > 8. Adheres to Open Container Initiative standards
>
>       Myth: Docker doesn’t support the OCI specifications work
> (
> https://www.docker.com/blog/demystifying-open-container-initiative-oci-specifications/
> ).
>

Docker has been an important contributor to OCI, and of course their work
on docker and the registry spec was the basis for the container standards
defined now by OCI.

Last I looked (which may have been a while), "docker build" still produces
images in the "docker v2 schema 2" format, not the OCI format. They're very
similar, but not the same. Most registry implementations support both.


> And besides, knowing people who use docker and jenkins together rather
> successfully, what is your definition of "any normal CI pipeline?"
>

A CI pipeline that doesn't require running a build tool as a service as
root.


>
> > > 9. You can use systemd on your host to run a container like any other
> service. You get the same look and feel while using familiar tooling
> (systemctl, journalctl, ...), but it's backed by a container.
> > >
>       Saying something is good because it integrates well with systemd
> is an interesting use of "good"
>

For those who use systemd to manage services, which is most people who use
a modern distro, it is good.


>
> > >>
> > >>
> > >> Cons:
> > >> 2. They would rather you use podman pods instead of docker compose,
> > >> but by then you are using kubernetes so why not just use kubernetes
> > >> and save the intermediate step?
> > >
> > >
> > > That's comparing an apple to an industrial-scale orange grove. Running
> a small number of related containers in a pod using podman is trivial and
> sometimes useful. Running k8s is anything but trivial. Don't get me wrong;
> I'm a big fan of k8s and its ability to solve problems at large scale. But
> if you just need to run a few containers together on a machine, podman or
> docker is the right tool for the job.
> > >
> > > However, it can be convenient to define a Pod in similar ways whether
> you're running it in k8s or with podman.
> > >
>       Per https://www.redhat.com/sysadmin/compose-podman-pods the
> config file for a pod is suprisingly close to that for a kubernetes
> pod. Running kubernetes can be simple or, to use your quote, anything
> but trivial *depending* on what you are trying to accomplish. I have
> coworkers running kubernetes off their OSX laptops. What is the
> difference between that and running podman to run a few pods?
>

Running minikube on a laptop for dev purposes is useful, if your purpose is
to develop on top of k8s. I've made extensive use of minikube on my laptop
so I can work on k8s controllers or work on automation that deploys
workloads on top of k8s.

But if your goal is just to run a production service on a machine (for
example a web server, application server, dns server, mail server, ...),
and your first step is "1. setup an entire k8s control plane on this
machine and only this machine", there's a good chance you're doing it
wrong. That's a great time to utilize the init system that's already on
that machine. Imagine running whatever processes you need the "normal" way
for that init system, but instead of making the command "httpd ..." or
whatever, make the command "podman run quay.io/mhrivnak/httpd". There's a
little more to it than that, but not much. You can enjoy the advantages of
containerized processes without needing to introduce an entire new process
orchestrator, especially a complex one that's intended for cluster use.


>
> If I want to go for resiliency (when I start thinking pods I want
> resiliency, and that means clustering), I can put one kubernetes
> cluster together about as quickly as a docker swarm. If you want to
> talk about large scale, there are blokes out there who can make a
> proper reliable and secure kubernetes cluster. And the online
> solutions; we had a talk on trilug
> (https://trilug.org/2020/02/06/Feb-13-my-homelab-away-from-home/) that
> including when moving to the cloud solution makes sense.
>

Pods are not just for clusters. Sometimes you just need to run two or more
processes side-by-side on a machine, and it's convenient to deliver them as
containers. A pod is a useful and familiar (to some) primitive for
stitching containers together and running them in a single location.