Note: This blog post’s been updated with
signal’s new usage in Wash 0.15.0.
Wash 0.13.0 includes a new
signal command that lets you send an arbitrary signal to a given entry. For example, you can use
signal to start a stopped container.
wash . ❯ meta docker/containers/wash_tutorial_redis_1 ... State: Dead: false Error: "" ExitCode: 0 FinishedAt: "2019-11-16T18:58:03.7284542Z" OOMKilled: false Paused: false Pid: 0 Restarting: false Running: false StartedAt: "2019-11-12T21:47:13.9406019Z" Status: exited wash . ❯ signal start docker/containers/wash_tutorial_redis_1 wash . ❯ meta docker/containers/wash_tutorial_redis_1 ... State: Dead: false Error: "" ExitCode: 0 FinishedAt: "2019-11-16T18:58:03.7284542Z" OOMKilled: false Paused: false Pid: 63392 Restarting: false Running: true StartedAt: "2019-11-16T18:58:49.6323676Z" Status: running
If the entry’s schema is known, then you can use the
docs command to view its supported signals/signal groups.
wash . ❯ docs docker/containers/wash_tutorial_redis_1 No description provided. SUPPORTED SIGNALS * start Starts the container. Equivalent to 'docker start <container>' * stop Stops the container. Equivalent to 'docker stop <container>' * pause Suspends all processes in the container. Equivalent to 'docker pause <container>' * resume Un-suspends all processes in the container. Equivalent to 'docker unpause <container>' * restart Restarts the container. Equivalent to 'docker restart <container>' SUPPORTED SIGNAL GROUPS * linux Consists of all the supported Linux signals like SIGHUP, SIGKILL. Equivalent to 'docker kill <container> --signal <signal>'
Note that signal groups consist of signals that fall under a specific category.
signal currently works with Docker containers, AWS EC2 instances, and GCP compute instances (try it out!).
For plugin authors: You can get
signal to work with other entries by implementing the
signal action (see here for external plugins, here for core plugins). Checkout the corresponding entry schema docs to see how you’d specify an entry’s supported signals. Note that the
signal action does not have to wait for the given signal operation to finish. It is enough to return once the signal’s been successfully received by the plugin’s API. We also don’t impose any restrictions on the sent signal’s name, so you are free to name your signals however way you want.
Note that we’re open to extending the
signal action’s power depending on user demand. Some things we’re considering are:
signalto take-in signal-specific API options. This would enable something like
signal stop docker/containers/wash_tutorial_redis_1to accept all of
docker stop’s options. In a more general sense, this lets
signaltake full advantage of the plugin’s API by allowing the user to pass-in API-specific options.
signalto return an (optional) result of the signaled operation. Combined with (1), this would enable
signalto be the “kitchen-sink” Wash action, where plugin authors can specify all vendor-specific operations that are not captured by any of the other Wash actions as signals (similar to an arbitrary method invocation).
Please let us know if any of these extensions would be useful by filing an appropriate issue!