First podlet experimentation

[frotinybo]

Hi,

I am a new and enthusiastic user of podlet/quadlet.
Thanks to the authors/contributors of those very valuable pieces of podman ecosystem.

Here below is my "lesson learnt" from my first experimentation.

Context:

I wanted to experiment the invidious software (https://github.com/iv-org/invidious) using containers. The project holds a compose.yml file made of two containers : an application + a backend database. The first step consisting in having the complete application locally running with a podman-compose command was quite straigh forward. The next needs were:

• To start automatically the application at system startup.
• Invidious suffers from memory leaks. it is recommended to restart periodically the application.
  I found very elegant to use the quadlet capabilities. This is also where podlet entered into the scene in order to perform the translation "compose file" -> "quadlet files".

Those are the issues I went through (background data : invidious project compose.yml file):

• To revisit the declaration of complex variables, arrays, etc.
  I am sure the tool will improve on the subject but as setting up variable,array... in a compose file can be quite tricky (complex and multiple possible syntax), quadlet files may be not directly crunched by systemd because of an unsupported or invalid syntax resulting from a too straight forward podlet translation.
  → temporary workaround : to reformat quadlet files after generation.

• To explicit private network
  When defining multiple containers (services) in a compose file without specifying any network, docker-compose automatically (and behind the scene) creates an internal podman network on which the containers listed in the compose file can intercommunicate. This trick is lost in the translation : podlet does not generate any .network file in this case -> quadlet does not handle any network -> containers can't communicate internally.
  → solution : to declare a network common to the two containers in my compose file. (Note : could be a feature of the podlet tool to explicit such network ? ie automatic creation of a .network file + attachment of the containers to this network in the quadlet files). I also tried the "podlet -pod" way to try to facilitate intercontainer communication but gave up as this needed more adaptation of the compose file.

• To explicit host name
  The invidious initial compose file does not contain a hostname information for the database container. However, the application container references a "invidious-db" host hosting the database service. When using podman-compose such "invidious-db" data is present in the DNS of the private network and does point to the IP of the database host (I suspect that the name of the services are aliased by docker-compose ?). This is no more the case when the two containers are launched through quadlet.
  → solution : to declare a hostname for the database container in my compose file.

In conclusion:

I am now very happy to have my application fully supported in a quite powerful and standard way : usage of containers managed through systemd. Going from docker-compose to quadlet/systemd has been significantly simplified thanks to podlet. However, such step may require attention :

• Maturity. quadlet/podlet are quite new tools in the podman ecosystem.
• Podman-compose uses/hides some behaviors that can be lost in a quadlet context.

Thinking of a seamless and automatic transition for non trivial compose.yml files may be optimistic still (but I have no doubt this will happen). Nevertheless, using quadlet is a good approach to anchor containers in systems for situation where K8s is overkilling and podlet will facilitate the transition.