5 ms·

Not really. This is more to replace kubelet if you want something with an even smaller footprint than k0s.

• INTPenis 4y ago
  Yeah I didn't really think before I typed that. If it requires you to install systemd files then it's not really equivalent. I don't understand why they made it so complicated, if you have a file format just let the user run it from their CWD.
  • bonzini 4y ago
    Because the idea is that this is a declarative configuration, not something that the user has to run. You first write the configuration, and then running it is just "systemctl start foo". Generators are the same mechanism by which systemd reads /etc/fstab; just like /etc/fstab entries are treated by systemd as "normal" mount units, systemd will treat .container files just like any other system service.
    • INTPenis 4y ago
      Yeah but they have invented the declarative file format, but they put it in /etc, why not put it in $HOME/.config/systemd instead? That would make it more on-par with docker compose. I'm hoping this is in the future of quadlet. Being able to run the files from CWD, using systemd units in $HOME, and not requiring root.
      • alexlarsson 4y ago
        For rootless use, put the files in ~/.config/containers/systemd/
        • bonzini 4y ago
          Alex, since you're here does quadlet support override files like systemd's /etc/systemd/system/foo.service.d directories? I couldn't find it in the documentation.
          • alexlarsson 4y ago
            The generator doesn't do that atm no. Seems like it would be useful though. On the other hand, I belive systemd would load override files for the generated .service file, although those can just override details on the systemd level, not the generated podman command.
            • bonzini 4y ago
              Yeah, my usecase was to override Network or Expose directives.
        • INTPenis 4y ago
          Thanks I just realized that. So really for a developer it would potentially be this simple; cp my-app.container $HOME/.config/containers/systemd && systemctl --user daemon-reload Just to compare with docker-compose again.
          • bongobingo1 4y ago
            You should be able to use `systemctl --user link` which is a bit nicer than copying. link PATH... Link a unit file that is not in the unit file search path into the unit file search path. This command expects an absolute path to a unit file. The effect of this may be undone with disable. The effect of this command is that a unit file is made available for commands such as start, even though it is not installed directly in the unit search path. The file system where the linked unit files are located must be accessible when systemd is started (e.g. anything underneath /home/ or /var/ is not allowed, unless those directories are located on the root file system).
          • config_yml 4y ago
            The cool thing is you can also create .kube file which points to a kubernetes pod definition yaml. This also generates a service definition which takes care of running a full pod with all your containers.
          • config_yml 4y ago
            Can you run your stuff on port 80/443 like this?
      • rhatdan 4y ago
        It works in the home directory. Just place the quadlet file in $HOME/.config/containers/systemd $ systemctl --user daemon-reload $ systemctl --user start QUADLETNAME.service If you want this to work at boot, you need to do loginctl enable-linger $USERNAME