Development: docker (and podman)

[falkmielke]

Description

This tutorial summarizes initial steps in creating docker images.
Matter of fact, it is just an assembly of components and tutorials which I found helpful for applying docker in an INBO-environment.

Task list

• My tutorial or article is placed in a subfolder of tutorials/content
• The filename of my tutorial or article is index.md. In case of an Rmarkdown tutorial I have knitted my index.Rmd to index.md (both files are pushed to the repo).
• I have included tags in the YAML header (see the tags listed in the tutorials website side bar for tags that have been used before)
• I have added categories to the YAML header and my category tags are from the list of category tags
• I have put images to the static folder.

[falkmielke]

Site tested and ready for review. Thank you in advance!

[florisvdh]

Thanks for this guided tour! We can discuss some things live further. Some of my comments are an example and apply to more places.

Some questions.

Images are stored in different places between Docker and Podman:

$ podman images
REPOSITORY                TAG         IMAGE ID      CREATED      SIZE
docker.io/library/alpine  latest      b0c9d60fc5e3  4 weeks ago  8.13 MB
$ 
$ docker images
REPOSITORY                     TAG       IMAGE ID       CREATED         SIZE
test-mne                       latest    b711361627aa   2 days ago      5.47GB
nginx                          latest    97662d24417b   4 days ago      192MB
rocker/tidyverse               latest    0a2c0d551856   3 weeks ago     2.73GB
alpine                         latest    a606584aa9aa   7 months ago    7.8MB
geopython/geopython-workshop   latest    ed98940df343   20 months ago   1.05GB
ubuntu                         latest    99284ca6cea0   20 months ago   77.8MB
hello-world                    latest    d2c94e258dcb   21 months ago   13.3kB

Is it possible to let Podman run a container I installed or built with Docker in this setting?

Also, I'm hesitant to log into RStudio Server as root (Podman case): how should we look at this? What are the permissions of the rstudio user (Docker case)?

[florisvdh]

The qmd file does not seem to be on par with index.md ? I don't see md_document as an output format here (cf other tutorials). If you are editing the index.md file directly, then you can drop the qmd file.

[falkmielke]

Using a qmd is still experimental; I much prefer the format, but it does not fully match the tutorial workflow. Currently, I quarto render --to hugo-md and apply the conversion steps found in notes_qmd.txt.
The yaml header, specifically, does not translate well despite preserve_yaml: true. I synced them now, but it is crucial to always review it.

[florisvdh]

Is there a reason why the figures are not in a subdirectory of the tutorial directory? (Cf other tutorials)

[falkmielke]

Yes!
On all the other tutorials I saw, the images are generated by running the Rmd main file.
It makes nostalgic sense to keep them with the tutorial, but in fact they are subject to version control and change upon every re-render.

The images for this tutorial are screenshots, i.e. static images. In a hugo context, these are best stored in the static folder.

Both is possible. I would follow the opinion of the website maintainers (@damianooldoni ?)

[florisvdh]

without storing the bloated container

The technique is equally relevant when running the container locally (hence storing it), hence not limited to remote hosts.

[falkmielke]

Good addition, thank you (I added it to the text).

[florisvdh]

Please don't use (subtly) offensive or provocative language in tutorials. It's not a personal blog 😉, it's an organisation's website, so as an author you also give a face to the organisation. You can point at disadvantages, but do it neutrally, short and don't involve the personal rants. Rather focus on the positive and supportive vibes for things you do want to teach.

Example (a more subtle one):

Suggested change

	To store files locally, i.e. on the host machine, without storing the bloated container, you will have to map a virtual path on the container to a local drive on your computer.
	To store files locally, i.e. on the host machine, without storing the container, you will have to map a virtual path on the container to a local drive on your computer.

And in another sentence (or place) you could add e.g. 'Images can take up considerable storage space. You better take control of this by ...'

[falkmielke]

Agreed; my apologies. In part the reason is that I started this as personal notes. Nevertheless I should have re-read with the organization's perspective in mind.

Still, I am a bit confused.
I removed the "rants" elsewhere, and will re-read carefully again tomorrow.
However, on the "suggested change" line, I do not understand why you suggest a change.
You removed "bloated", but in the IT context (see here, "business english"/"IT"), this is quite common and I find it useful.

I much appreciate if you point out the exact words you suggest to change, I don't take change suggestions personally, so the more, the better. ❤️

[florisvdh]

Thanks for your response. As I encounter the word in IT context, 'bloated' is mostly used in a blaming sense, so that is how it appears to me here; an INBO tutorial should not usually do that. But it will be easier to discuss that live.

At https://en.wikipedia.org/wiki/Software_bloat I find:

The term is not applied consistently; it is often used as a pejorative by end users, including to describe undesired user interface changes even if those changes had little or no effect on the hardware requirements

[florisvdh]

I believe 'users' is more appropriate than 'Linux people' or 'Windows people'; the latter seem to label individuals which we should not do.

Suggested change

	(Linux people will be familiar with the concept of "mounting" and "linking" storage locations.)
	(Linux users will be familiar with the concept of "mounting" and "linking" storage locations.)

[falkmielke]

Agreed and adjusted.

[florisvdh]

Don't post that here please.

[falkmielke]

No problem, I have removed it.
But I honestly don't know why this might be considered inappropriate.
Whales really do not carry containers.

The intermezzo comment was meant as a general invitation to keep users thinking about what they read and see.
And personally, I find it dull to read texts and books which never break the flow to make you hesitate to re-think what you know.

Again, no problem, this is personal taste versus organizational exposition, and I am very glad for your critical reading!

[florisvdh]

Thanks for removing it.

Yes, of course whales don't carry containers, but the reader tries to grasp why you say that. Since this humour seems to revolve around blaming (the second line!), I didn't consider it appropriate. Especially when you consider disadvantages of a technology, I recommend to stick to that (keep it technical and neutral) instead of blaming developers or organisations. We don't offend.

[florisvdh]

Not the same as this (which I followed):

https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

$ dpkg -l | grep docker
ii  docker-buildx-plugin                             0.20.0-1~ubuntu.22.04~jammy                        amd64        Docker Buildx cli plugin.
ii  docker-ce                                        5:27.5.1-1~ubuntu.22.04~jammy                      amd64        Docker: the open-source application container engine
ii  docker-ce-cli                                    5:27.5.1-1~ubuntu.22.04~jammy                      amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras                        5:27.5.1-1~ubuntu.22.04~jammy                      amd64        Rootless support for Docker.
ii  docker-compose-plugin                            2.32.4-1~ubuntu.22.04~jammy                        amd64        Docker Compose (V2) plugin for the Docker CLI.

[florisvdh]

Different from https://docs.docker.com/engine/install/linux-postinstall/#configure-docker-to-start-on-boot-with-systemd ?

[falkmielke]

Indeed! Starting processes on system boot is not the best idea; people loose track easily, I tend to not do that.
Autostart is optional. I will look up what containerd does, did not even notice it got installed.

[florisvdh]

One can also manage this post-hoc, using docker rmi (or docker system prune to do a large cleanup). This prevents re-downloading images afterwards if you need the container again. I would not use --rm by default, unless the aim is really to give it a single shot and then quit.

[florisvdh]

The requirements below seem to be met out of the box in an Ubuntu environment. Then am I right that the 'out of the box' statement here does not hold?

[falkmielke]

Thank you for the extra observation; I will make the text "box-independent".

[falkmielke]

Thanks for this guided tour! We can discuss some things live further. Some of my comments are an example and apply to more places.

Thank you for the thorough review! I will go through your comments and adjust.

Some questions.

Images are stored in different places between Docker and Podman:
[...]

Is it possible to let Podman run a container I installed or built with Docker in this setting?

I have not looked this up, but the chance is low. Pods work technically different from docker containers, and once you build or pull one, it is converted into a container of the respective system.
What you can do is

• Use the same dockerfiles
• mount the same volumes

so you can transfer the recipe's, not the outcome.
Generally, I think it is good practice to treat containers as volatile to keep them hostmachine-independent.

Also, I'm hesitant to log into RStudio Server as root (Podman case): how should we look at this? What are the permissions of the rstudio user (Docker case)?

The difference, as I understand it, is that a container with the unprivileged container user in the Docker case still requires privileged execution on the host system. To me, this brings the risk of privilege escalation in case of breakout to the root.
I do not know why RStudio requires a "root" user within the container; yet if that would escape, it would be far less dangerous. I think we could alternatively get a base-r container, non-root, but just terminal login.

I will double-check and try.