nomad exec part 2: CLI

[notnoop]

Sequel to #5632 .

This PR adds the actual nomad exec CLI command, that's inspired by docker exec with some modification:

nomad alloc exec --job example-job /bin/bash

The command is primarily intended for interactive debugging so it makes the default more sensible for that case:

• Default to passing stdin to ultimate command - in docker exec terminology, --interactive is enabled by default.
  • I found docker terminology very confusing (since passing stdin isn't necessary interactive), so I used the long form --stdin instead, matching kubectl flag
• Default to setting up a psudo-terminal, a tty, if stdin is detected to be a tty. So when running inside an interactive session, -tty is enabled.

For explicitly negating the options, we use the golang flag way of disabling (e.g. --tty=false, --stdin=false).

I added this as a separate PR to separate the CLI UX review from internal plumbing of nomad exec.

[jippi]

@notnoop nice, this seems like a similar thing to nomad-helper attach ?

[notnoop]

@jippi indeed, they are functionally similar. By this being built-in, it can work without ssh access (only using the nomad API which can handle forwarding across federated regions) and other drivers besides docker. When targeting an exec task for example, the command will run inside the exec task chroot/container environment.

[jippi]

@notnoop thats great! :) Any plans to build in similar "interactive" flow as my tool have? we use it a ton internally, both on infra and dev side - and being guided through each selection of job, alloc and task is a pretty loved feature (opposite to a random alloc if omitted)

[42wim]

Looks more like the exec functionality of https://github.com/42wim/nomadctld ;)

Maybe make /bin/sh default command if not specified? That's what you probably need most of the time.

[endocrimes]

Good start, but I'd like to see command line argument handling cleaned up a little. I'd also like to see test cases for handling of -job and --task, for both happy and sad paths.

[endocrimes]

We could predict the job here?

[notnoop]

Not quite - this matches the pattern of nomad logs where --job is boolean flag about whether to interpret the first argument is an alloc or a job id. So --job itself doesn't take any arguments technically.

[endocrimes]

Ah - In which case the documentation for -job needs to be updated to show that it's parsed as a boolean flag

[nickethier]

I would say that alloc_exec.go could use some additional comments throughout especially in execImpl. Working with terminals/ttys has bit me in the past before. Otherwise the impl LGTM.

Only one question I had before hitting approve:
Is there an escape sequence similar to ~. to break the session when using a tty? I think something like that would be really useful over having to send a SIGTERM to the pid.

[nickethier]

If this default's to true then how do you unset it? -i false? I'm imagining the inverse since that's how docker works.

[notnoop]

Clarified - our CLI library is different from docker - it needs to be -i=false.

[nickethier]

comment on this func would be helpful

[notnoop]

done!

[notnoop]

Is there an escape sequence similar to ~. to break the session when using a tty? I think something like that would be really useful over having to send a SIGTERM to the pid.

This is an excellent suggestion. I'm going to follow up with adding it in a separate PR.

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.