Puck(github.com)
github.com
Puck
https://github.com/steveiliop56/puck
9 comments
[deleted]
So I made this little tool called puck, its a simple cli that checks for updates in your servers. Right now its in alpha stage but I am working on it actively to get it to stable. Now you will say can't this be done with ansible? Yes it can, but I am planning to add more features like notifications via discord/ntfy, a web UI etc . that will make it stand a chance again Ansible. What do you think? Would you use something like this?
Adding notifications to an Ansible playbook is just adding a task with the discord module or uri in the case of nfty.
I do agree and lean towards using golang to have an easy binary but there's a lot of work already in this space for managing instances. I have a similar ansible task running on AWX to check instance updates but have had a backlog task to actually move it to Prometheus so the notifications and information are sitting in Grafana.
I do agree and lean towards using golang to have an easy binary but there's a lot of work already in this space for managing instances. I have a similar ansible task running on AWX to check instance updates but have had a backlog task to actually move it to Prometheus so the notifications and information are sitting in Grafana.
Even if I'm probably in the target audience, I wouldn't use it:
- It's a compiled language and not in the upstream repos of my dist, meaning something that needs to be built separately (yeah no I'm not downloading any prebuilt binaries thank you). While not without tradeoffs, rewriting it in shell script or maybe Python (sticking to libs available in apt repos) would make it a much easier sell and reduce the number of considerations before introducing it.
- A package on a machine is either auto-updated via unattended-upgrades or done manually via [rebuilding an image/running a playbook/whatever] which I already need a process for anyway. One more way to do the same thing is just more operational complexity.
That being said, I could see the value in a multi-distribution (ie apt/rpm/apk/pacman) utility which will trigger an event and call a command (send a notification) when there are available but unapplied updates for known bugs or CVEs. Would need to be runnable on offline server (possible meaning a split in two parts?) and without need for overly demanding centralized coordination like opening ports on every server or introducnig RPC. Puck currently looks like it wants to take a more centralized and active role than what I'd be after, though.
Your approach my still be valuable to others even if it's not my cup, though! Hope you enjoy making it and that it's useful for yourself already :)
(BTW, the name doesn't suck; no need to be apologetic (:)
- It's a compiled language and not in the upstream repos of my dist, meaning something that needs to be built separately (yeah no I'm not downloading any prebuilt binaries thank you). While not without tradeoffs, rewriting it in shell script or maybe Python (sticking to libs available in apt repos) would make it a much easier sell and reduce the number of considerations before introducing it.
- A package on a machine is either auto-updated via unattended-upgrades or done manually via [rebuilding an image/running a playbook/whatever] which I already need a process for anyway. One more way to do the same thing is just more operational complexity.
That being said, I could see the value in a multi-distribution (ie apt/rpm/apk/pacman) utility which will trigger an event and call a command (send a notification) when there are available but unapplied updates for known bugs or CVEs. Would need to be runnable on offline server (possible meaning a split in two parts?) and without need for overly demanding centralized coordination like opening ports on every server or introducnig RPC. Puck currently looks like it wants to take a more centralized and active role than what I'd be after, though.
Your approach my still be valuable to others even if it's not my cup, though! Hope you enjoy making it and that it's useful for yourself already :)
(BTW, the name doesn't suck; no need to be apologetic (:)
Python vs GoLang is a whole thing, but being unable to compile a go binary is a skill issue on your end, my friend. It's not a problem for this software unless you want to edit the code and don't know GoLang, except that's also a skill issue.
The fact that this tool is unnecessary due to other tools existing is a fair point though.
The fact that this tool is unnecessary due to other tools existing is a fair point though.
It's not a skill issue. I write, build, debug, and deploy golang regularly as appropriate. It's my language of choice at times.
> unless you want to edit the code and don't know GoLang, except that's also a skill issue.
How about editing the code live in a production environment currently lacking a debugger, internet, or compiler when it doesn't behave 100% according to expectations? Even if you have the debugger and compiler available and are comfortable using them, it's a world of difference in convenience.
> The fact that this tool is unnecessary due to other tools existing is a fair point though.
I never said that and do not believe that. Many options for the same thing can be great, let a thousand update helpers bloom I say. I guess we disagree on everything today :p
> unless you want to edit the code and don't know GoLang, except that's also a skill issue.
How about editing the code live in a production environment currently lacking a debugger, internet, or compiler when it doesn't behave 100% according to expectations? Even if you have the debugger and compiler available and are comfortable using them, it's a world of difference in convenience.
> The fact that this tool is unnecessary due to other tools existing is a fair point though.
I never said that and do not believe that. Many options for the same thing can be great, let a thousand update helpers bloom I say. I guess we disagree on everything today :p
Salt already does this on pretty much all distros and also the consumer-tier OS (mac, Windows).
Reminds me of apt-dater, which allows for a lot more versatility.
Minor nit: 10MB really isn’t that “small” for a CLI. I’d looked at your go.mod and seems like the most of dependency bloat might be coming from cobra or viper as it has in-tree plugins. You can check out an alternative like https://github.com/knadh/koanf which would decrease the binary size, I’m sure.