A Slack Workflow example for DevOps

original by slack, modified by Michael Bladowski

In case you are running a Pro or Enterprise Plan in Slack, this might be interesting for you. Slack has something called Workflows.

They can be used for nearly everything. With this posting, I want to show a very basic and simple example of how to make use of these Workflows and
their Feature of receiving Webhooks.

Let´s say you are a Team of DevOps managing multiple Servers.
When someone, you, or someone on your team stops a Service, it would be good to know:

• when this happened
• if a person did that on purpose
• when the service is running again

So let´s say someone on a server is doing:

systemctl stop cron

If you want to see a message in one of your channels like this:

this is an example in german

So in this (german) example, everybody in your channel will get a Notification that says:

Hey, the Cron-Daemon on Server XYZ has been stopped! (don´t forget to start it, whenever your work is finished)”

and when you do:

systemctl start cron

you want to see:

this is an example in german

a message that says:

Hey, the Cron-Daemon on Server XYZ is back and running again!

Okay, let’s explain how easy this is:

• create a Workflow that says “service XYZ is down”
• select “Webhook”

creating a slack workflow

Just press “Next” — but it´s up to you to provide “Parameters” you can later use in your channel message.

Press “Add Step” because the first part is only the “Trigger” that starts this Workflow. But right now, the Workflow is empty. So we have to add the main part: Sending a Message to the Server:

We choose: “Send a message”

Here we actually create the message that gets triggered by our Webhook:

If you are done, just repeat all steps again, but in the 2nd round, you create the message that says: “The Service is online and running again” (something like that).

Important: Don´t search for the Webhook-URLs, you won´t get them until your workflows are published. Once they are, you are able to get them here:

So let´s summarize where we are:

• we have created one workflow that gets started by calling a webhook URL from SLACK saying a Service is DOWN
• we have created a second workflow that gets started by calling a webhook URL from SLACK saying a Service is UP again

So we have two Webhook-URLs like:

https://hooks.slack.com/workflows/ABCDEF/ABCDEF/12323123/ihhiofweqhofi

I could say: Now, trigger these URLs from wherever you want and have fun.

But I want to show a specific example that one or another DevOp might like.

Let´s say we are working with Linux servers and services are started and stopped via the already-mentioned call systemctl start/stop service

Let’s say we have an Ubuntu server. Every service (usually) has a file called:

/lib/systemd/system/{service}.service

so when we talk about "cron" we should see a file called:

/lib/systemd/system/cron.service

This file might look like this:

[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target

[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

If you call “man systemd.service” you will see what´s possible here.
It´s pretty cool what you can do here, these Service-Configs are very
flexible and powerful.

There a two simple Keys we need:

• ExecStartPost
• ExecStopPost

As you can guess:

ExecStartPost: run the command “after” the Service has been started
ExecStopPost: run the command “after” the Service has been stopped

So below [Service] we add:

ExecStartPost=-curl -s -I "https://hooks.slack.com/workflows/ABCDEFGH/SG7837GUGU/463989938774395593/weopijqfopjweop" > /dev/null
ExecStopPost=-curl -s -I "https://hooks.slack.com/workflows/ABCDEFGH/SG7837GUGU/463989105651380516/wiopqejfopjqwepofj" > /dev/null

Note: the “-” before “curl” says: ignore the exit code and always return 0.
(it’s up to you how you call this and how you handle output and errors)

After modifying your file, don´t forget to: systemctl daemon-reload

With these two lines added to your service config, you let your team know when a Service got stopped and started again.

Setting this up takes only 5 minutes and you get a pretty good feeling of how powerful these Workflows are and how you can use them in your daily business.

As said, the possibilities are endless and I am sure if you never used Slack Workflows before, this won´t be your last ;-) Just imagine what´s possible if you bring Zapier into this game ☺

That´s it. As always: I hope you learned something.
Feel free to clap and follow me on Medium, Twitter, or Mastodon. 👋

Cheers,
Micha