[TriLUG] docker vs podman

[Sean Korb via TriLUG]

These are all features we need in HPC especially multiuser
environments.  I've been using Singularity for a couple of years to
package workload up and run on clusters, and udocker before that to
run in user space without root privileges.  It's been tricky sometimes
but Singularity had a pretty vigorous user community and became fully
featured and fully OCI compliant quickly.  I'm always on the watch for
new technologies though.  User communities are fickle and can migrate
in an instant.  Almost all our builds are docker base images though so
good design and documented provenance are all attractive features.

sean

On 8/20/20, Hrivnak, Michael via TriLUG <trilug at trilug.org> wrote:
> 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.
> --
> This message was sent to: Sean Korb <spkorb at gmail.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web	:
> https://www.trilug.org/mailman/options/trilug/spkorb%40gmail.com
> Welcome to TriLUG: https://trilug.org/welcome


-- 
Sean Korb spkorb at gmail.com http://spkorb.org (est 1994)
"Computers are useless.  They can only give you answers." -P. Picasso