Hi, thank you for the detailed and informative reply! It definitely helped clarify things. Indeed I had disabled chroot to read the files at runtime, but have since switched to read during init phase . Thank you for the tips on the architecture aspect as well. I will study and explore these options.
Thanks, Reshma On Thu, May 27, 2021 at 11:50 AM Willy Tarreau <w...@1wt.eu> wrote: > 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 >
