Skip to content

Use the recommended c-ares DNS backend instead of evdns? #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
edmorley opened this issue May 13, 2024 · 6 comments
Open

Use the recommended c-ares DNS backend instead of evdns? #188

edmorley opened this issue May 13, 2024 · 6 comments

Comments

@edmorley
Copy link
Member

edmorley commented May 13, 2024

The upstream PgBouncer project supports multiple DNS backends, described in the table here:
https://www.pgbouncer.org/install.html

That page then goes on to say:

c-ares is the most fully-featured implementation and is recommended for most uses and binary packaging (if a sufficiently new version is available). Libevent’s built-in evdns is also suitable for many uses, with the listed restrictions. The other backends are mostly legacy options at this point and don’t receive much testing anymore.

By default, c-ares is used if it can be found. ...

However, the pgbouncer binaries used by this buildpack currently use evdns instead of c-ares since the library for the latter isn't in the Heroku base image.

The library is small, so we (the languages team) would be open to adding it to the base image to allow this buildpack to switch to the c-ares backend - if that would be of interest to the Data team?

https://packages.ubuntu.com/noble/libc-ares-dev
https://packages.ubuntu.com/noble/libcares2

@edmorley
Copy link
Member Author

@mble Any thoughts on this? 🙂

@edmorley
Copy link
Member Author

@mble-sfdc Oh sorry realised I CCed your personal account rather than your work one.

I forgot to mention, that if this library was something the Data team did want, there would be a lag between when we add it to the base image and when it's available in Private Spaces at run time (due to the way image rollouts work there), so to be safe we'd need to wait several weeks after adding before recompiling pgbouncer in this buildpack. (So the sooner we'd add the package the better for avoiding blocking you.)

@mble-sfdc
Copy link
Contributor

@edmorley It's probably something we could consider. If we can get it into the stack images, I think we can look at building it with c-ares support.

We've got a whole thing lined up around this buildpack to do some renovation so it would align well with it, I think.

edmorley added a commit to heroku/base-images that referenced this issue May 22, 2024
So that PgBouncer can use its recommended `c-ares` based DNS backend:
heroku/heroku-buildpack-pgbouncer#188
https://www.pgbouncer.org/install.html
https://c-ares.org/

The package is named `libcares2` on Heroku-24 and `libc-ares2` on older stacks:
https://packages.ubuntu.com/noble/libcares2
https://packages.ubuntu.com/jammy/libc-ares2
https://packages.ubuntu.com/focal/libc-ares2

This only adds ~200 KB to the run image.

I've not added the corresponding headers to the build image, since:
- For the PgBouncer use-case they can instead be installed in the build
  environment used to compile the PgBouncer binaries.
- There don't seem to be many popular `c-ares` language bindings that
  people might use directly in their apps.

GUS-W-15826387.
@edmorley
Copy link
Member Author

I've added c-ares to the run images in heroku/base-images#307 however note that:

  1. It won't be on common runtime until the next base image update (probably next week)
  2. Even after that base image release (incl GitHub release and https://devcenter.heroku.com/changelog entry) it won't yet be on private spaces until the next AMI is generated and rolled out across all channels (up to a couple of weeks after; status can be seen via runtime-ops)

Also, I chose not to add the headers to the build image (since there don't seem to be much need for them for eg c-ares bindings used by apps themselves), so the libc-ares-dev package will need to be installed via apt-get in the Dockerfile in this repo used for the PgBouncer build itself.

@edmorley
Copy link
Member Author

edmorley commented Jun 25, 2024

The addition of the c-ares package to the base image has propagated to all environments.

As such, it's now safe for this buildpack to start compiling builds that have that backend enabled.

Note: The build Dockerfile/scripts will need to install the headers (libc-ares-dev) for the backend to be enabled during compilation.

@mble-sfdc
Copy link
Contributor

Fantastic, thanks @edmorley

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants