La partie « So, what is a "Portable Service"? » commence par :
A portable service is ultimately just an OS tree, either inside of a directory, or inside a raw disk image containing a Linux file system. This tree is called the "image". It can be "attached" or "detached" from the system. When "attached", specific systemd units from the image are made available on the host system, then behaving pretty much exactly like locally installed system services. When "detached", these units are removed again from the host, leaving no artifacts around (except maybe messages they might have logged).
La partie suivante, « Where’s the difference to a "Container"? » a ce second paragraphe :
"Portable services" do not provide a fully isolated environment to the payload, like containers mostly intend to. Instead, they are more like regular system services, can be controlled with the same tools, are exposed the same way in all infrastructure, and so on. The main difference is that they use a different root directory than the rest of the system. Hence, the intent is not to run code in a different, isolated environment from the host — like most containers would — but to run it in the same environment, but with stricter access controls on what the service can see and do.
De mon point de vue, pour l'instant, c'est toujours plus de complexité et un point de plus pour systemd qui veut tout faire...
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: use case
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien systemd portable services: parce que les conteneurs, c'est trop mainstream. Évalué à 3.
La partie « So, what is a "Portable Service"? » commence par :
La partie suivante, « Where’s the difference to a "Container"? » a ce second paragraphe :
De mon point de vue, pour l'instant, c'est toujours plus de complexité et un point de plus pour systemd qui veut tout faire...
"It is seldom that liberty of any kind is lost all at once." ― David Hume