Hi, On Wed, May 26, 2021 at 10:43:17PM +0530, reshma r wrote: > Hi Tim thanks a lot for the reply. I am not familiar with what a sidecar > process is. I will look into it. If it is specific to haproxy, if you could > point to some relevant documentation that would be helpful.
It's not specific to haproxy, it's a general principle consisting in having another process deal with certain tasks. See it as an assistant if you want. We can do a parallel at lower layers so that it might be clearer. Your kernel deals with routing tables, yet the kernel never manipulates files by itself nor does it stop processing packets to dump a routing table update into a file. Instead it's up to separate processes to perform such slow tasks, and keep it in sync. > >I am making a > > socket call which periodically checks whether the portal has been changed > > (from within haproxy action). > > Leaving aside the writing to file bit for a moment, is it otherwise okay to > do to the above within Haproxy alone and read the config fetched from > portal into a global variable instead of saving to file? Or is it not an > advisable solution? Actually this is what I am doing at present and I have > not observed any issues with performance... What you must never ever do is to read/write files at run time, as this is extremely slow and will pause your traffic. It can be supported to load a file during boot from Lua for example since at this point there is no network processing in progress. We only slightly discourage from doing so because most often the code starts by reading during init and two months later it ends up being done at runtime (and people start to disable chroots and permission drops in order to do this). It's possible to read/set process-wide variables from the CLI, so maybe you can send some events there. Also as Tim mentioned, it's possible to read/set maps from the CLI, that are also readable from Lua. That may be another option to pass live info between an external process and your haproxy config or Lua code. In fact nowadays plenty of people are (ab)using maps to use them as dynamic routing tables or to store dynamic thresholds. What is convenient with them is that they're loaded during boot and you can feed the whole file over the CLI at runtime to pass updates. Maybe that can match your needs. Last point, as a general architecture rule, as soon as you're using multiple components (portal, LB, agents, etc), it's critically important to define who's authoritary over the other ones. Once you do that you need to make sure that the other ones can be sacrified and restarted. In your case I suspect the authority is the portal and that the rest can be killed and restarted at any time. This means that the trust you put in such components must always be lower than the trust you put in the authority (portal I presume). Thus these components must not play games like dumping files by themselves. In the best case they could be consulted to retrieve a current state to be reused in case of a reload. But your portal should be the one imposing its desired state on others. For example, imagine you face a bug, a crash, an out-of-memory or whatever situation where your haproxy dies in the middle of a dump to this file. Your file is ruined and you cannot reuse it. Possibly you can't even restart the service anymore because your corrupted file causes startup errors. This means you'll necessarily have to make sure that a fresh new copy can be instantly delivered by the portal just to cover this unlikely case. If you implement this capability in your portal, then it should become the standard way to produce that file (you don't want the file to come from two different sources, do you?). Then you can simply have a sidecar process dedicated to communication with this portal in charge of feeding such updates via the CLI at runtime (or maybe you can retrieve them directly from the portal using Lua or whatever other solution that best suits your needs). Reasoning in terms of worst case scenario will help you figure the best control flow, and to design a solid solution that covers all use cases at once. Hoping this helps, Willy
