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:
#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. #9006 (comment)), 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

[adaoud-ims]

Any advise how to build Envoy for Centos 7 ?

[gdubicki]

See envoyproxy/envoy-build-tools#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 (#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.