<div dir="ltr"><div><p class="gmail-p1" style="color:rgb(0,0,0)">Hi,</p><p class="gmail-p2" style="color:rgb(0,0,0)">Regarding orchestration, we’ve done quite a bit of research and previously explored Nomad as one possible path. Another toolset we recently came across is<span class="gmail-Apple-converted-space"> </span><a href="https://fly.io/">Fly.io</a>. Fly works with Docker images, but instead of running them directly, it extracts the root filesystem from the image and adds its own init system along with some infrastructure-related processes. The final image is then booted inside Firecracker microVMs.<br></p><p class="gmail-p2" style="color:rgb(0,0,0)">The newer generation of Fly machines, along with their updated init process, now supports PID namespaces. So, in theory, if we package a GPT root filesystem into a Docker image and set the entrypoint to:<br></p></div><div>CMD ["unshare", "--pid", "--fork", "--mount-proc", "/lib/systemd/systemd"]<br></div><div><span style="color:rgb(0,0,0)">—it should be able to boot on Fly, as suggested by their documentation.</span><br></div><div><p class="gmail-p2" style="color:rgb(0,0,0)">This approach seems somewhat similar to what<span class="gmail-Apple-converted-space"> </span><span class="gmail-s1">systemd-nspawn</span><span class="gmail-Apple-converted-space"> </span>does (perhaps a bit less), but I’d really appreciate any feedback on potential pitfalls or considerations with this setup.<br></p><p class="gmail-p2" style="color:rgb(0,0,0)">Thanks for your time,<br></p><p class="gmail-p1" style="color:rgb(0,0,0)">Umut</p></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 18, 2025 at 6:22 PM Umut Tezduyar Lindskog <<a href="mailto:umut@tezduyar.com">umut@tezduyar.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello, <div><br></div><div>If multiple instances of the systemd-nspawn are started of the same image, do the processes in the images have COW? For example, do PID 1 in both instances share the same text section? I couldn't put all the pieces together and prove it. I could see that the inode numbers in both instances are pointing to the same one (using smaps) but the PSS values didn't reflect this.</div><div><br></div><div>Somehow unrelated question. Are there mainstream tools that can do nspawn orchestration? I stumbled on Nomad in many occasions. My use case is to start instances of the same image with systemd-nspawn on a cloud cluster, specifically aws. At some point the instance is shut down and resources are reused. </div><div><br></div><div>Thank you for your time</div><div>Umut</div></div>
</blockquote></div>