Hi Aurelien, Thanks again, some closing comments on the original query and a follow-up on the SPOE approach related to performance.
>You could have a basic webserver on the host serving those files locally via HTTP. That's not an option in my case because the exact requirement here was to implement a "healthcheck" on an endpoint like "/admin" which is served from within HAproxy as it checks the state of HAproxy, not the "backend server". Note, more importantly, I should be able to modify this "admin healthcheck" to return 404, whenever desired. One possible way is using ACLs and using socket to modify the value https://www.haproxy.com/documentation/hapee/latest/traffic-routing/blue-green-deployments/, but I was looking for an alternate way where "state can persist" between restarts by only modifying "one source of truth". >And from your task use core.httpclient to safely fetch/parse the file and update your global variable periodically. Ya, unfortunately, this seems like the way, but definitely overkill for "admin healthcheck" which was my simple use case. >Register a custom cli from lua script (core.register_cli). Yup, thank you for recommending this approach. It feels a bit cleaner than what I had done. I did it by implementing a custom "lua service" which sets global variable to a value that's passed as body to the request. The CLI approach is of course better. However, both approaches have the same problem "someone has to be in charge" of making sure that both "HAproxy global variable" and "value on disk" are in sync as I wanted something that persists between restarts. >Considering SPOE requires much more efforts to setup compared to lua, And another thing is, it is probably cheaper to read the "global variable in lua" than waiting on SPOE to respond via unix/tcp socket. I'm new to HAproxy, and I'm yet to do this experimentation. On Tue, Oct 18, 2022 at 1:06 AM Aurelien DARRAGON <[email protected]> wrote: > > I really appreciate the response. This confirms, that "everything in > > runtime mode" uses the same thread pool as HTTP workers. This also says > > that the onlytime we can use "blocking IO" is in "initialization mode", > > ie, at HAproxy startup/reloads. > > Happy to help! > > > Considering what we've already established in this email, it looks like > > HAProxy has no way to serve a "static file" which changes after HAproxy > > has been initialized. @Aurelien, please confirm! This seems like a big > > limitation, there has to be a workaround. Is it just acceptable in > > HAproxy world to "reload instead", every time a file is modified on disk? > > Right now I can think about 2 different options: > > You could have a basic webserver on the host serving those files locally > via HTTP. > And from your task use core.httpclient to safely fetch/parse the file > and update your global variable periodically. > > Or > > Register a custom cli from lua script (core.register_cli). > Then from a custom system script watch for files changes (or check > periodically), and when updating is required, use local haproxy > stats socket from your script to execute your custom lua cli > that is in charge of updating the global variable. > (Passing arguments to custom lua cli is supported) > Note: Alternatively this solution can be implemented with lua service + > local curl/wget with payload from the system script to trigger the service. > > But if anyone out there knows about a better approach, please feel free > to share your thoughts on this. > > > The only non-blocking functions available to use is via "socket class". > > Is it too crazy if we use "socket object" to do network IO to a process > > we write that acts as a proxy to do disk operations? > > > Considering SPOE requires much more efforts to setup compared to lua, > depending on your needs you could consider sticking to lua coupled with > a basic tcp or http middleware that does the file to tcp/http proxy > (either existing webserver or custom script using socat/netcat). > > Aurelien > -- Cheers, Abhijeet (https://abhi.host)
