Nomad job service to install/uninstall an application

Nomad
1

Dear nomad community,

I am learning nomad and wanted to ask about a particular use case and see if this would be a “good” nomad use:

job "enroot-deliver" {
  datacenters = ["default"]
  type        = "service"

  group "enroot" {

    # Each task should be scheduled on a different node.
    constraint {
      operator = "distinct_hosts"
      value    = "true"
    }

    restart {
      mode     = "fail"
      attempts = 0
    }

    reschedule {
      attempts = "0"
    }

    task "enroot-deliver" {
      lifecycle {
        hook    = "prestart"
        sidecar = false
      }
      driver = "raw_exec"
      user   = "root"
      config {
        command = "bash"
        args    = ["-c", "zypper install --no-confirm --no-recommends myapp"]
      }
    }

    task "enroot-delivered" {
      driver = "exec"
      # runs as nobody
      config {
        command = "sleep"
        args    = ["inf"]
      }
    }

    task "enroot-remove" {
      lifecycle {
        hook    = "poststop"
        sidecar = false
      }
      driver = "raw_exec"
      user   = "root"
      config {
        command = "bash"
        args    = ["-c", "zypper remove --no-confirm myapp"]
      }
    }
  }
}

The whole point is to use the lifecycle to install/uninstall the application when the job starts/finishes

To me, this would be a very nice use case but on the other hand, I feel this is against Nomad’s original design.

So my question is.
Would this be a valid use case for nomad service jobs?
if not then, how would you recommend doing this use case?

thank you very much

2

Hi @masuberu although Nomad doesn’t prescribe a particular usage pattern, I can make some observations about this one.

Having a task install / uninstall a package on setup/teardown via the system package manager is questionable. What if the package was meant to be installed for some other reason than just this service using it? I see you have host uniqueness constraint, but is that only necessary to avoid conflicting over managing the system package manager? These lifecycle hooks require raw_exec and running as root, neither of which are ideal especially in a production environment.

I think it is much more common to use the artifact stanza to have tasks download such packages automatically, into the sandbox Nomad creates for each task. The setup/teardown are then handled automatically, you don’t risk conflicts with the system package manager, and you don’t need lifiecycle tasks running as root with raw_exec.

Of course you’d need to host the application yourself to be downloadable as an artifact, such as with an internal file server.

3

Hi Seth,

thank you for your response, how would you recommend installing the rpms then? the reason I ask is because zypper should still require root privileges even if using the Isolated Fork/Exec Driver?