Haproxy Bins

Binaries almost statically linked from Haproxy project.

---

Motivation

Some projects use a proxy as a component for doing different things, like ingress-nginx or haproxy-ingress which are Kubernetes controllers routing network traffic in the background.

For those purposes, it is more comfortable to maintain just a binary, with no-dependencies, and well versioned. The most performant proxy out there is Haproxy, and that is the mission for this repository.

Paths in the project

• .github Github Actions to automate things
• scripts Scripts for building the binary
• libs [autogenerated] Path for already compiled libraries
• tmp [autogenerated] Path for temporary files generated during the execution
• build [autogenerated] Path for final binaries generated during the execution

How to execute

The scripts are designed to work fully automated, so it is only needed to run the main one, executing the following command from the root path of the repository:

bash ./scripts/build-binaries.sh

The scripts with the name pattern build-static-lib-xxxxxx.sh are invoked by the main one on building process, but they can be invoked directly to build the latest version of a library

FAQ

Why do we say almost statically linked?

We link statically most of the libraries. According to the standard, it is not a good practise to link statically things like libc. Following that expert advices, we link statically the rest of the things, trying to include most of the features that comes with Haproxy.

In the following console outputs, you can see that we try it hard for all the environments:

# Show dynamic linked dependencies for Linux x86_64
ldd haproxy_linux_x86_64
 
        linux-vdso.so.1 (0x00007ffe089c8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f71d29c4000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f71d279c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f71d3654000)

# Show dynamic linked dependencies for Linux aarch64 (arm64)
ldd haproxy_linux_aarch64
        not a dynamic executable

Which library versions are used?

Builds are automated and download the latest version of the libraries on each execution. Because of that, a VERSIONS file is generated and attached to each release with the versions for everything.

When do the releases are generated?

Building workflow is executed every Sunday until we improve automation scripts. So the expectation is to release on Mondays if some changes are detected

How to collaborate

This project is done using standard tools. Most of them are already present on most GNU/Linux distributions. We are open to external collaborations for this project. For doing it you must:

• Fork the repository
• Make your changes to the code into a different branch
• Open a PR. The code will be reviewed and tested

We are developers and hate bad code. For that reason we ask you the highest quality on each line of code to improve this project on each iteration.

License

Copyright 2023.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.