swarm-cronjob VS kine

Anything from simple crontab entry to something like this: https://crazymax.dev/swarm-cronjob/

So, I found a really nice little tool that solves a problem I have in a really nice way. Specifically, cron jobs on Docker Swarm. This project: https://github.com/crazy-max/swarm-cronjob It uses labels on your services to schedule jobs. Thus it needs access to the docker api, and all the security concerns that go along with it...

As i said, if it's not exposed to the outside world and doesn't work with untrusted data, that claim is not entirely valid.

Imagine something like this getting abandoned, or someone running a year old version of it: https://github.com/crazy-max/swarm-cronjob/blob/master/READM...

Its only job is to run containers on a particular schedule, no more no less. There are very few attack vectors for something like that, considering that it doesn't talk to the outside world, nor processes any user input data.

Then again, it's not my job to pass judgement on situations like that, merely acknowledge that they exist and therefore the consequences of those suddenly breaking cannot be ignored.

I also found swarm-cronjob and ofelia both seems promising. BUT , I really like the idea of an interface to watch log files etc.

-- Kine (Kine is not etcd)

Looking at [1], is there any reason why this couldn’t run in something like DynamoDB? I feel like the operations required would fit

https://github.com/k3s-io/kine/blob/master/pkg/drivers/gener...

I don't like some of the decisions that k3s makes which is why I stay away from it, but it's a great project. I'm not using kine yet, but I fantasize about using it exclusively every time I deal with etcd-induced slowness/random CPU spikes on my group of controller nodes. k0s supports kine too of course but I just haven't switched it on yet.

Well in some situations you can also get away with CRDTs or Gossip (SWIM), but yeah in the general sense Paxos (Raft is a Paxos-family algo). There are lots of paxos family algos to choose from[0].

> I’m also currently building a distributed search engine using etcd for the service registry, broker peer announcements, and worker queue and it’s been a good experience so far.

As a random stranger on the internet, please build an abstraction layer around etcd. Even if there's only one implementation, I've found that so many distributed projects that just never reach the scale that etcd is built for would benefit from the option of writing their own drivers (you don't need a full plugin system just a regular abstraction layer).

One example is Kine[0] for k8s -- if k8s had a built in option for writing/reading from something like Postgres from the beginning it would have been a better project for it, IMO.

If you do build a plugin system though, you can pass off the work of maintaining the other implementations!

[0]: https://vadosware.io/post/paxosmon-gotta-concensus-them-all

[1]: https://github.com/k3s-io/kine

I could spent >0s looking into this, but I've been curious how kline implements Etcd's Watch API. For the matter, I don't have much idea in general how kline handles data. Kline would be a great candidate for a blog post or introductory technical article on.

I do quickly see one issue- evidently watches presently use polling. The issue requests use of postgres triggers: https://github.com/k3s-io/kine/issues/20

check out https://github.com/k3s-io/kine

Not to be mistaken for high-availability Dqlite[1], which is one of the options one can run the k3s kubernetes distribution on (instead of etcd), via the Kine etcd shim[2]. Ultimately though the K3s team replaced Dqlite with an embedded etcd to get high-availability[3].

[1] https://dqlite.io/

[2] https://github.com/k3s-io/kine

[3] https://rancher.com/docs/k3s/latest/en/installation/ha-embed...