Provide official debian and RPM packages

[codefromthecrypt]

Title: Provide official debian and RPM packages

Description: Right now, everything on the website mentioning "getenvoy" can be removed without breaking people.. except debian and RPM packages.

Can you please host official debian and RPM packages? Seems they can be built from the same binaries used to make docker images similar to #16830

Once this is done, hopefully there's no need for confusion anymore as getenvoy's build and packaging pipeline can quietly turn off.

Relevant Links: https://github.com/envoyproxy/envoy/issues/16830

[codefromthecrypt]

cc @phlax I did a recursive grep and basically this is the last thing people can't do properly upstream.

[phlax]

im very +1 to this - and ultimately would like to create a "request to package" with debian - it really feels like envoy would be incredibly useful to end users to just be able to apt-get install (or rh equiv)

in the interim i would be very happy to create the packaging for us to host these ourselves

...and the necessary deb repo

[phlax]

im wondering about using bazel for this - looks like a reasonable approach - although at least for debian its not clear if source packages are supoorted

in terms of prior art - tetrate's packaging is here https://github.com/tetratelabs/getenvoy-package/blob/master/envoy_pkg/packages/getenvoy_package.bzl

[snowp]

I think in the past there has been some resistance towards hosting/distributing binaries (c.f. https://github.com/envoyproxy/envoy/issues/9006#issuecomment-553546959), but we could always revisit that decision.

@envoyproxy/maintainers for visibility

[phlax]

I think in the past there has been some resistance towards hosting/distributing binaries (c.f. #9006 (comment)), but we could always revisit that decision.

i think that because getenvoy are no longer going to host binaries this role is shifting to CNCF

[snowp]

Talked offline, seems like we've got resources allocated for this so no more complaints from me :)

[jpeach]

FYI https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987544

[phlax]

A quick update on this

I have a ~working prototype that builds debs/rpms for arm and x86 architectures, and tests them installed in a distro containers (#16899 )

It still needs to be figured out how this can best/most efficiently fit into the CI but it seems to mostly work so far

One issue i have is that building with rbe - there isnt an rpmbuild binary for rpms - but its possible that we could work around that with https://github.com/google/rpmpack

[ahmed-adam]

Hi, are there any updates on this ticket? We have also been affected by https://github.com/envoyproxy/envoy/issues/17236 except we are using RPMs.

Until this issue is resolved, does anyone have a workaround as all our builds are currently broken? I found https://cloudsmith.io/~tetrate/repos/getenvoy-rpm-stable/packages/ - would you recommend that repo be used as a workaround?

[phlax]

cc @lizan

not sure about the cloudsmith.io repo or the cause of https://github.com/envoyproxy/envoy/issues/17236

im working on resolving this issue but it will take some time

[phlax]

@codefromthecrypt any ideas on this ?

[codefromthecrypt]

I'll summarize: the reason for opening the issue here is "getenvoy" is going away (eg no longer maintained and we aren't supposed to use the name). bintray is down also as the service went away.

The thing I raised last month #16868 was an interim step reduce confusion for reasons like this. Probably we should remove all references at this point. I had hoped the packages here would have landed by now and obviate the whole thing.

Folks in a pinch can use the same tarballs our tools use https://archive.tetratelabs.io/envoy/envoy-versions.json until this issue or #16830 closes.

Is there something on the packaging here that others could help complete? What's working so far? What's left to do?

[dmitri-d]

FWIW, it's possible to build rpms via fedora copr (https://copr.fedorainfracloud.org/coprs). Online builds are possible, bazel's already there (https://copr.fedorainfracloud.org/coprs/vbatts/bazel/packages/).

[codefromthecrypt]

looks like there is a draft PR out there on this topic, I had no idea.. maybe we are closer! https://github.com/envoyproxy/envoy/pull/16899

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[codefromthecrypt]

should be noted that centos 7 based distributions are still widely in use, so packages should accommodate this, or some sort of clear support matrix be included to say it isn't.

[adaoud-ims]

Any advise how to build Envoy for Centos 7 ?

[gdubicki]

See https://github.com/envoyproxy/envoy-build-tools/pull/154 , @adaoud-ims .

[adaoud-ims]

See envoyproxy/envoy-build-tools#154 , @adaoud-ims .

Thanks @gdubicki, I will have a look.

[GregTheHun]

Has there been any recent updates on this? I'd love to have this as well.

[dekimsey]

Crud. Consul 1.12 just got released and dropped support for envoy 1.18. That leaves CentOS 7 without a viable envoy package on up-to-date Consul.

[JamesXNelson]

yikes... we have a bunch of centos 7 customers who could benefit from native installers... many run in sensitive data centers and don't want to install docker... would love to see this move forward. Is there anything potential contributers can do to help this along?

[mattklein123]

cc @phlax can you potentially update this issue with current status? I know this is being worked on.

[Gregory-N-able]

Bump.

[phlax]

some progress on this - we have just landed code to auto push assets on release - only envoy binaries initially - but it will establish the pipeline

the debs are pretty much ready to publish and we can follow up fairly quickly to add - the main reason i didnt include is that they are slightly larger than expected so wanted to check out the reason before adding

there is an #envoy-release channel on slack now which i would encourage anyone interested in this to join

[codefromthecrypt]

can you describe what you mean by "auto push assets on release"? do you mean attach to GitHub release or somewhere else?

[phlax]

do you mean attach to GitHub release or somewhere else?

github release

[codefromthecrypt]

cool. can you try to get Mac x64 and aarch64 builds up there as well as windows x64? there's been a lot of problems sourcing binaries particularly on Darwin, and we can change the sourcing accordingly.

[phlax]

could you jump on the slack channel ?

it has discussion about these and why they have not been included initially

[codefromthecrypt]

probably best to cite the permalink to here as it is the better record. I have had some difficulty getting into the envoy slack due to it restricting which domains can join. I doubt I'm the only one.

maybe you can restate if there is any plan to expand beyond that or why there won't be? regardless, this is improvement even if partially implemented, so welcome progress.

[phlax]

there is - this is just initial progress establishing the pipeline - there are various issue with all of the other binaries

I have had some difficulty getting into the envoy slack due to it restricting which domains can join. I doubt I'm the only one.

can you clarify the problem - im happy to follow up

[plallin]

Hello! Is there a plan to provide official FIPS-compliant packages? Currently the guidance is to build Envoy from source (ref). This causes issue where there is a requirement to run CI pipelines in air-grasped environment with no Internet access as building Envoy offline is not supported either (ref).

[phlax]

@plallin not an immediate plan - i would encourage you to join the #envoy-release slack channel as we are discussing there which binaries to add

Envoy offline is not supported either (https://github.com/envoyproxy/envoy/issues/20318).

that bug was just closed - so that way should work now

[phlax]

...actually - that bug was partially resolved i think - you can build from a tarball now:

https://github.com/envoyproxy/envoy/blob/main/bazel/README.md#building-from-a-release-tarball

for an air-gapped build you would still need to resolve the deps somehow

[erikschul]

Bump. Tetrate no longer maintains debian or ubuntu packages (since April 2021?):

[yongzhang]

Bump. Latest version in Ubuntu apt source stops at 1.18.

[phlax]

the pipeline is mostly in place - i would be happy to support any effort to complete this, or review any PRs - otherwise it will have to wait until i have time available

[erikschul]

Or just recommend people to download the binary?

[phlax]

Or just recommend people to download the binary?

the recommended, and most supported, way to run is with a container - the distroless image is the most lightweight and secure

the binaries in the containers are the same ones that are posted on the github release pages and the same that will be packaged in debs

running without a container means your system has to meet the glibc requirements of the static compiled bin

[codefromthecrypt]

@erikschul also unlike docker layers or the envoy archive built on it, the binaries attached to releases are not compressed. This means downloading 60M instead of 15.

That said, as this issue is titled (only debian and RPM, not windows or macOS), you could certainly use more tools using the release binary blobs instead of routing through other options to make a debian or RPM, or install manually.

[jhon-conner]

Or official binary file for centos7.

[phlax]

@jhon-conner there isnt a plan atm for adding rpms - if someone was willing to do the work i would be happy to help, but its not a priority atm

[jhon-conner]

@phlax 😄 Thanks for your reply. Actually I compiled the source successfully after refering some documents, of course, https://www.envoyproxy.io/docs/envoy/latest/start/building is included. But the binary file's size is too large, 469MB. Can you figure out how to make it smaller? Any suggestion is appreciated. Sorry, I do not know c++. It's too hard to me. And my command is

bazel --server_javabase=/usr/lib/jvm/java-11-amazon-corretto --host_jvm_args=-Djavax.net.ssl.trustStore=$CI_PROJECT_DIR/keystore.jks --host_jvm_args=-Djavax.net.ssl.trustStorePassword=changeit test  --jobs=16 -c opt --config=sizeopt --copt=-DENVOY_IGNORE_GLIBCXX_USE_CXX11_ABI_ERROR=1 --verbose_failures --distdir=$CI_PROJECT_DIR/ext/ --distdir=$CI_PROJECT_DIR/ext2/ --distdir=$CI_PROJECT_DIR/ext4/ --repository_cache=$CI_PROJECT_DIR/ext --repository_cache=$CI_PROJECT_DIR/ext2 --repository_cache=$CI_PROJECT_DIR/ext4 --linkopt=-Wl,--strip-all //test/...

Yeah, as you see, I built it by gitlab ci, an environment without internet access, downloading external dependencies manually. I put external dependencies in ext, ext2, ext4. And I used llvm.

[phlax]

@jhon-conner the easiest/most supported path for compiling is using the docker build container and the bazel targets, ie

$ ./ci/run_envoy_docker.sh './ci/do_ci.sh release.server_only'

which builds optimized, stripped bins for dist targets

the bazel target you are looking for for a single binary (non-contrib) is

$ bazel build ... --stripopt=--strip-all -c opt //source/exe:envoy-static.stripped

lmk if that helps - the dev docs are due some update in the near future

(EDITED to fix commands)

[jhon-conner]

@phlax 👍 Thanks so much. I'll have a try.

[phlax]

also worth mentioning - the published Envoy bin is statically compiled so should work anywhere with a compatible glibc (not sure what reason for compiling is)

[marcindulak]

also worth mentioning - the published Envoy bin is statically compiled so should work anywhere with a compatible glibc (not sure what reason for compiling is)

Please note that both Fedora and Debian discourage (read mostly not allow) of bundling libraries into executables. Instead the dynamic linking of the operating system libraries should be used.

The suggestion of debundling in Fedora is described here https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling. Tracking of security vulnerabilities is provided as a reason for use of system libraries instead of their copies distributed by the program (envoy) source.

All packages whose upstreams allow them to be built against system libraries must be built against system libraries. In this case, bundled libraries (and/or their source code) MUST be explicitly deleted during %prep

For Debian see https://blog.liw.fi/posts/2023/debian-reasons/#no-bundled-libraries

Debian avoids using copies of libraries, or other dependencies, that are bundled with the software it packages. Many upstream projects find it easier to bundle or “vendor” dependencies, but for Debian, this means that there can be many copies of some popular libraries. When there is a need to fix a security or other severe problem in such a library, Debian would have to find all copies to fix them. This can be a lot of work, and if the security problem is urgent, it wastes valuable time to have to do that.

[phlax]

Please note that both Fedora and Debian discourage (read mostly not allow) of bundling libraries into executables. Instead the dynamic linking of the operating system libraries should be used.

yeah - i think that is why we dont have any packages in the official distros sadly - i did reach out before to see if there was a way (either unpicking our build or having ait allowed) but iirc didnt get a response

for sure in the distro sense it makes no sense to distribute bundled bins - in other contexts - eg distroless container - it makes a lot of sense to do it this way - just as the distro want to control the deps, so do we

i would be so happy if we could find a way to bridge this gap - and would defo up for helping any efforts in this respect

[phlax]

sadly there is not a dh_bazel or similar afaiaa

[liudhzhyym]

Any news?