Watchtower HTTP API based updates

[victorcmoura]

This pull request implements the changes proposed in #429.

API Features + ToDo List:

• /v1/update endpoint to trigger image updating process
• --http-api flag to set up HTTP API mode
• --http-api-port flag to customize the listening port (Container will always listen to 8080)
• authentication token set by ENV variable
• Expose port 8080 in the Dockerfile
• Docs on how to use the API

Required changes:

• Lock to prevent concurrent updates
• API has a package of its own
• validates if the authentication token has been set, makes fatal exit if not

Suggestions are welcomed!

[zoispag]

This is useful. Will also solve an issue I have with a container getting updated, while the UI tests are running!! Great 👍🏼
I think it is a good idea to Expose port 8080 from the Dockerfile, so that an update can be triggered by another running container, without necessarily need to bind a port to the host machine.

[zoispag]

Auth should be added.
Maybe a simple header auth, a bearer token probably, that can be provided as an ENV variable to watchtower.

[victorcmoura]

@zoispag Just added the suggestions to the feature list. Thank you =)

[victorcmoura]

Even though this API presents a huge potential, I believe we've reached a minimal working version that can be improved by future PR's. Let me know if there should be something else implemented by now.

[dinuta]

Hi guys, great idea. I just wonder if you can add a rollback endpoint which should do a rollback in case the new image has issues (Yes it's possible )

I think here about 2 possible endpoints.

• /v1/rollback - which will rollback all images under the watchtower instance
• /v1/rollback
  Http header: Rollback-Image the specific image to rollback.
  Example:
  Rollback-Image: alpine-latest

[simskij]

Even though this API presents a huge potential, I believe we've reached a minimal working version that can be improved by future PR's. Let me know if there should be something else implemented by now.

Thank you, Victor, for your excellent work! I'll have a look as soon as I can.

[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.

[simskij]

So sorry for allowing this to fall between the cracks. Hope to get to it as soon as possible! Still feels like a great extension of watchtower in my opinion!

[simskij]

Hi guys, great idea. I just wonder if you can add a rollback endpoint which should do a rollback in case the new image has issues (Yes it's possible )

I think here about 2 possible endpoints.

• /v1/rollback - which will rollback all images under the watchtower instance
• /v1/rollback
  Http header: Rollback-Image the specific image to rollback.
  Example:
  Rollback-Image: alpine-latest

Hi!

I know this is a popular request but as we only track by hash on a tag, I really don’t see a feasible way of accomplishing this without having to add some kind of persisted memory to watchtower, which I’m kind of hesitant to do.

If you have any suggestion on how this solution would work, feel free to open an issue for it and submit as much details as possible.

With that said, at least to me, those endpoints are not within the scope of this particular pull request.

Thanks for understanding! 🙏🏻

[simskij]

Some minor things, but other than that, I'd say this is pretty much good to go. Great work, @victorcmoura! I really appreciate you taking the time to push this change through. 🙏🏼

If you don't feel up for splitting out the API parts to a separate package at this point, just let me know and I'll add it to do the todo list. It's not critical, just something I think would be nice at some point down the line.

[victorcmoura]

@simskij, just pushed the requested changes. xD

[simskij]

That is awesome! Merging. Thanks again, @victorcmoura!

[simskij]

@all-contributors add @victorcmoura for code and docs

[allcontributors]

@simskij

I've put up a pull request to add @victorcmoura! 🎉