Update Notification over Slack Channel or Email

[matthiasbaldi]

Would it be possible and useful to implement a possibility to notify updated services over Slack or Email.
I think to a process like this:
shepherd recognised a new image > triggers the update > if it was successful, send the notification.

@djmaze What do you think about features like this?

I found no docs or issues about this topic. Was it discussed already?

Thank you.

[djmaze]

This has not been discussed yet. I like the idea of being notified of updates. That said, I guess the needs are quite different for every user. This should probably be made a plugin functionality using separate scripts and / or containers.

I am open to ideas / PRs!

[unixfox]

Most of the program similar to shepherd use apprise for the notifications because it supports quite a lot of services: /~https://github.com/caronc/apprise

[djmaze]

Interesting. That would just need the notification URL as an environment variable.

On the downside, we would need to add python to this image.

[pascalandy]

There is a container for this: /~https://github.com/variadico/noti
I use it for more than 2 years now. It notify me when a backup is completed. This is how it looks like:

docker run --rm \
--name noti \
-e NOTI_MESSAGE="$NOTI_MESSAGE" \
-e SLACK_CHANNEL="$SLACK_CHANNEL" \
-e SLACK_TOKEN_CRON="$SLACK_TOKEN_CRON" \
"$IMG_noti" \
sh -c \
'NOTI_SLACK_TOKEN="$SLACK_TOKEN_CRON" \
NOTI_SLACK_CHANNEL="$SLACK_CHANNEL" \
noti -k -m "$NOTI_MESSAGE"';

[pascalandy]

Here is my dockerfile:

### ### ### ### ### ### ### ### ### ### ### ### ### ###
# stage build

FROM golang:alpine as stage

LABEL com.ghost.version="3.1.0"                                \
      com.baseimage.version="golang-alpine"               \
      maintainer="FirePress.org Pascal Andy https://firepress.org/en/contact/"

RUN apk add --no-cache git ca-certificates

RUN go get -u github.com/variadico/noti/cmd/noti

WORKDIR /go

RUN cd /bin && \
  echo; pwd; echo; ls -AlhF; echo; du -sh *; echo; du -sh;


### ### ### ### ### ### ### ### ### ### ### ### ### ###
# --- final stage
# it won't have go's libraries
# I bypassed notify-osd even if the system complains about installing it

FROM alpine:3.9

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

WORKDIR $GOPATH

RUN mkdir -p /go && \
	mkdir -p "$GOPATH/src" "$GOPATH/bin" && \
	chmod -R 777 "$GOPATH" && \
	\
	set -ex && \
  apk add --update --no-cache tini ca-certificates && \
	rm -rf /var/cache/apk/* /tmp/*

COPY --from=stage /go/bin /go/bin

ENTRYPOINT ["/sbin/tini", "--"]

# by Pascal Andy | https://pascalandy.com/
#

[pascalandy]

The Dockerfile can be more optimized but it's good enough :)

[djmaze]

Reflecting on this, I would still like this to be in a separate image. The noti / apprise image should possibly listen on a tcp/udp port in a separate docker network. So shepherd just needs to make a simple connection using netcat or similar in order to trigger the notification.

[pascalandy]

That's how I see it as well.

[iamrenejr]

Would it be a good idea if the code in this repo had its own way to call the various notifications? Like if provided a slack token, it would call the slack APIs itself instead of notifying a separate service after it's done what it's supposed to do.

Essentially they're just post-action curl commands that get conditionally executed if the matching parameter was provided for it (eg, curl slack API if slack token was provided, curl Discord API if Discord token was provided, etc).

[djmaze]

@iamrenejr I do not think so. Notification APIs are a moving target, and that code would also inflate the size and complexity of this image. People probably also want the option of email notifications, which would also be more difficult to implement.

I prefer microservices if possible :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[unixfox]

Still an issue.

[caronc]

Hi, I stumbled across this issue and just wanted to share a recent project I created that may or may not help you out. It's effectively an API wrapper/gateway to Apprise. It's still a work in progress though but the API part is finished.

[unixfox]

Good idea to avoid having to bundle apprise into shepherd but relying on an external REST API if the user choose to enable notifications.

[djmaze]

@caronc Thanks, looks interesting. But I'd rather prefer a stateless API service where notification endpoints can be configured statically.

[caronc]

@djmaze No problem; I just thought I'd chime in based on your comment in Aug:

I prefer microservices if possible :)

As per this reference:

I'd rather prefer a stateless API service where notification endpoints can be configured statically.

The current API is 100% stateless. It even has a small webpage for a user to browse/change their configuration. It's a key/value store of configuration. Once written it persists. Future calls need only send the message body and reference the key containing the configuration. You can either post the configuration yourself statically (once at the start), and/or allow the user to configure. The key doesn't have to be apprise like in the screenshot. It can be shepard, etc. You can write/read save as many configs as you want.

I realize you're still shopping for an idea to put in place, so no pressure, just food for thought! 🙂

[djmaze]

Well, as you described, the configuration in your server is stateful. A configuration can be added via the API, but it then it has to be persisted in order to survive a restart of the API server. So the API server needs a persistent volume. Which can be difficult to achieve in a multi-node swarm.

I imagine the API server endpoint(s) to be configured via a static YAML file (or similar) instead. So there is no need to persist anything.

[matthiasbaldi]

Why you don't think about configuration over Swarm-Secrets or ENV variables?
Then you don't have to manage the state yourself in the app or in the cluster.
Managing cluster storage can be pretty complicated, that's true.

[djmaze]

@matthiasbaldi Yes, that's what I meant.

[caronc]

Well, as you described, the configuration in your server is stateful.

You got me there now that I think about it 😳.

Whether you use Apprise or not; your feedback has been very constructive (so thank you for that!!). I only just wrote this API on Saturday and published it Sunday (yesterday). Would there be value in the extending the /api/notify/key call to also accept /api/notify to which the payload would have to include a list of the Apprise URLs? That would provide a stateless solution anyway. You (or anyone looking for a stateless solution) would only need to post to a single URL

P.S. Sorry for hijacking this thread; but good feedback is hard to come by 😉 ... that and improving a modular version of Apprise is my goal.

[djmaze]

@caronc That would be better, but IMHO for even better separation of concerns the notification url(s) should be preconfigured on the api server side.

[djmaze]

So I went ahead and built the solution I have been talking about :)

[caronc]

Nicely done! Apprise by default uses space and/or comma as a delimiter to separate URLs from one another... Thus you don't even need the for-loop when calling the add() function in your app.py. Apprise uses a regex with a slightly more complicated logic to ensure the URLs are being correctly delimited from one another (and not breaking in the middle of the ones that have spaces in them).

Otherwise, awesome job man! :)

[djmaze]

Apprise by default uses space and/or comma as a delimiter to separate URLs from one another... Thus you don't even need the for-loop when calling the add() function in your app.py

Thanks, updated.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[unixfox]

Still want to have it implemented.

[alexanderadam]

Watchtower will use 📣 shoutrrr in the future. So maybe it might be useful for shepherd as well.

Or, what would probably even be better: maybe joining forces would make sense as people using watchtower would love to use it for Docker swarm as well and having more maintainers is usually a good thing, isn't it?

[djmaze]

@alexanderadam shoutrrr does not nearly support as much notification types as apprise, AFAICS not even email. So, when having to choose, I would rather use my simple microservice approach with apprise. (Btw, your link to shoutrrr is wrong.)

Concerning watchtower, I had a look at it again. I believe it brings much overhead concerning user interface as well as code complexity, e.g. for managing and cleaning up containers. The approach of updating swarm services can be much simpler. That is why it fits in this small shell script.

To me it looks like we would have to bend watchtower a lot in order for it to support both use cases. From the standpoint of a swarm-only user, this brings much more complexity (including possible problems) and almost no benefits.

[alexanderadam]

@djmaze thank you for your insights, your fast response and, of course, thank you for shepherd! 🙏

PS: I corrected the link now 😉

[iangregsondev]

So I went ahead and built the solution I have been talking about :)

How can we use this Shepherd?

[bf8392]

Hi =) I would also be interseted on how to imp,ement an apprise notification with the curl of the api =) I also think it's the perfect approach as apprise supports over 50! Notification channels =)

[djmaze]

The PR just merged now allows a simple way of doing this. If this is still not clear, I could add an example using docker compose.

[unixfox]

An example is always welcome :).

[djmaze]

I added an example compose config now.