| > I like the approach of the program managing its own scheduling much better than cron. If you write your own scheduler, you have reinvented the wheel. Running a cron job is way more simpler and everybody is familiar with it. Nobody is familiar with your own custom scheduler. > You have an endpoint that is constantly available to scrape metrics from. I don't think you need metrics for this service at all. It has to "just work". > You can send it an RPC to say "hey, do the sync now". You don't need any of that. Keeping a service alive is unnecessary work, an RPC interface is overengineering. This is a very simple problem, don't overcomplicate it. > Someone could go into CloudFlare's web interface and mess up the configuration; with this design, the mistake is fixed within 30 seconds. My script have a --force switch, so you can do the same with it. Still, you shouldn't manage an IP manually when using a DDNS script. The cache is to "be nice" with CloudFlare (don't hit them unnecessarily) and your bandwidth.
ddclient also had this feature. > If you just apply the change periodically even though there is no diff, you get a nice alert that the API is broken before you need to change. That's a valid point, I agree, but I don't think it's a big problem. REST APIs endpoints should never change, you should have years before CloudFlare deprecate and enpoint, so I think in the breaking API-regard, is a non-issue. > Furthermore, this program properly maintains a global rate limit of API calls across all configurations. I did not even think about rate limits, because my script will hit CloudFlare API so rarely, it should never reach rate limits. Also, if it would be needed, it could be implemented with the cache, which I have anyway. Also, you can side-step the issue by setting the time between updates bigger like minutes. Availability should be a non-issue, because if your service needs high availability, you should get a fix IP anyway. > Programs that are in a sleep(30 seconds) call do not use much memory or CPU. They can be trivially swapped out if the system is under memory pressure. A go application like this is going to use less than 10M of RAM all in. In 1962 that's a lot. Today that's nothing. Agree, but 10mb is still infinity times more than zero. :) > Given the existence of a kubernetes configuration in the repository A dynamic DNS script like this should be nowhere near at a Kubernetes cluster. If you think there is a use-case for Kubernetes with this script, you have huge problems anyway (e.g. not understanding what Kubernetes is and how should you operate it properly.) > To be fair, I have no idea what sort of environment involves production traffic in a kubernetes cluster going to a dynamic IP address, and that sounds like something I'd look into before writing a sync script like this. So we are on the same page about Kubernetes. :) |