1. Project Overview & Quickstart (envoyproxy/envoy)
File: README.md
Cloud-native high-performance edge/middle/service proxy
Envoy is hosted by the Cloud Native Computing Foundation (CNCF). If you are a
company that wants to help shape the evolution of technologies that are container-packaged,
dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's
involved and how Envoy plays a role, read the CNCF
announcement.
Documentation
- Official documentation
- FAQ
- Example documentation
- Blog about the threading model
- Blog about hot restart
- Blog about stats architecture
- Blog about universal data plane API
- Blog on Lyft's Envoy dashboards
Related
- data-plane-api: v2 API definitions as a standalone
repository. This is a read-only mirror of api. - envoy-perf: Performance testing framework.
- envoy-filter-example: Example of how to add new filters
and link to the main repository.
Contact
- envoy-announce: Low frequency mailing
list where we will email announcements only. - envoy-security-announce: Low frequency mailing
list where we will email security related announcements only. - envoy-users: General user discussion.
- envoy-dev: Envoy developer discussion (APIs,
feature design, etc.). - envoy-maintainers: Use this list
to reach all core Envoy maintainers. - Twitter: Follow along on Twitter!
- Slack: Slack, to get invited go here.
- NOTE: Response to user questions is best effort on Slack. For a "guaranteed" response please email
envoy-users@ per the guidance in the following linked thread.
- NOTE: Response to user questions is best effort on Slack. For a "guaranteed" response please email
Please see this email thread
for information on email list usage.
Contributing
Contributing to Envoy is fun and modern C++ is a lot less scary than you might think if you don't
have prior experience. To get started:
- Contributing guide
- Beginner issues
- Build/test quick start using docker
- Developer guide
- Consider installing the Envoy development support toolchain, which helps automate parts of the development process, particularly those involving code review.
- Please make sure that you let us know if you are working on an issue so we don't duplicate work!
Community Meeting
The Envoy team has a scheduled meeting time twice per month on Tuesday at 9am PT. The public
Google calendar is here. The meeting will only be held
if there are agenda items listed in the meeting
minutes. Any member of the community should be able to
propose agenda items by adding to the minutes. The maintainers will either confirm
the additions to the agenda, or will cancel the meeting within 24 hours of the scheduled
date if there is no confirmed agenda.
Security
Security Audit
There has been several third party engagements focused on Envoy security:
- In 2018 Cure53 performed a security audit, full report.
- In 2021 Ada Logics performed an audit on our fuzzing infrastructure with recommendations for improvements, full report.
Reporting security vulnerabilities
If you've found a vulnerability or a potential vulnerability in Envoy, please
open a GitHub Security Advisory.
This is the preferred reporting channel, as the reports can be triaged directly on GitHub.
Alternatively, you may email [email protected].
For further details please see our complete security release process.
OSS fuzzing
ppc64le builds
Builds for the ppc64le architecture are not covered by the envoy security policy. The ppc64le architecture is currently best-effort and not maintained by the Envoy maintainers.
Other builds
Releases
For further details please see our release process.
File: docs/README.md
Building documentation locally
There are two methods to build the documentation, described below.
In both cases, the generated output can be found in generated/docs.
Building in an existing Envoy development environment
If you have an existing Envoy development environment, you should have the necessary dependencies and requirements and be able to build the documentation directly.
If using the Docker build container, you can run:
./ci/do_ci.sh docsBy default configuration examples are going to be validated during build. To disable validation,
set SPHINX_SKIP_CONFIG_VALIDATION environment variable to true:
SPHINX_SKIP_CONFIG_VALIDATION=true ./ci/do_ci.sh docsIf not using the Docker build container, you can run:
bazel run --@envoy//tools/tarball:target=//:html @envoy//tools/tarball:unpack "$PWD"/generated/docs/Using the Docker build container to build the documentation
If you do not have an existing development environment, you may wish to use the Docker build
image that is used in continuous integration.
This can be done as follows:
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'To use this method you will need a minimum of 4-5GB of disk space available to accommodate the build image.
Creating a Pull Request with documentation changes
When you create a Pull Request the documentation is rendered by Azure Pipelines.
To do this:
- Open docs job in Azure Pipelines.
- Navigate to "Upload Docs to GCS" log.
- Click on the link there.
How the Envoy website and docs are updated
The docs are published dynamically by Netlify on every commit to main. This process is handled by the
envoy-website repo
For tagged commits the docs are built statically by the archive repo,
which in turn triggers a rebuild of the website.
2. Official Technical Reference & Guides (envoyproxy/envoy-website)
Envoy website
This is the repo for the Envoy website.
The website is built with bazel using Pelican and Sphinx.
The site is deployed to Netlify.
Envoy's documentation for release versions is stored in https://github.com/envoyproxy/archive/.
Contribute content to the website
Site data
Site data is stored (or created) in yaml files in the site/data directory.
Add adopter logo
Envoy is happy to recognize projects that use the software in production.
These are not intended to be an advertisement, but a show of support for the project.
All supporting organizations will be listed in alphabetical order.
To be added to our adopter list, you must meet at least 2 of these criteria:
- Be a participant and active contributor in the community, eg:
- contributing code
- raising or resolving issues
- sponsoring EnvoyCon
- Publicly disclose your usage of Envoy, eg:
- Have an existing Envoy maintainer vouch for and approve your pull request
To add your logo, please send a pull request.
Envoy website development
Sphinx is used to build the latest docs, and Pelican is used to assemble the static files into a site.
The build process is managed by bazel to ensure reproducible builds and manage external data.
All content, data and customizations are stored in the site directory
Build using Docker
This is the recommended way to build the site.
The composition is designed to make use of a Bazel cache on your host system.
Docker: export your `UID`
By default Docker cannot see your user's UID, so you need to export it to run the container build.
This ensures that any files created inside the container - the site build and any cache files - are owned
by the host user.
$ export UIDDocker: build the website
$ docker compose up --build -d websiteThis will take some time on first run - you can tail the logs with:
$ docker compose logs -fOnce the build has completed the website should be available at http://localhost:8000.
If you are not running the automatic rebuild and you make changes you can rebuild the site with:
$ docker compose run buildBuild the site on your host machine
If you would prefer not to use Docker you can build directly on your host machine.
Host: install bazel
The expected version of Bazel can be seen in .bazelversion.
It is recommended to install Bazel with Bazelisk as this will pull in the
correct Bazel version.
If you have Yarn installed you can install Bazelisk with that.
From inside your local copy of the envoy-website repository, run:
$ yarnHost: install a compiler
You will need a compiler (clang or GCC) and some related dev tools installed to build the docs.
For example, on a Debian-based system, these can be installed with:
$ apt get install build-essentialIf you build without the docs, you can ignore this requirement.
Host: build the website
$ ./build-website.shTips for site development
Automatically rebuild during development
The site can be made to auto-rebuild when changes occur in the site/ directory.
If you are using Docker you can trigger this by setting the following in your environment,
before bringing up the Docker composition:
$ export BUILDER=live
$ docker compose up --build -d websiteIf you are building on your host you can just run the rebuild script directly:
$ ./rebuild.sh ./site ./build-website.shBuild without the docs
If you only need the non-docs parts of the website to be built, set the following environment
variable.
Set this before building in Docker or on your host:
$ export BAZEL_BUILD_OPTIONS="--config=nodocs"Debug build
You can enable richer logging.
Set the following environment variable before building in Docker or on your host:
$ export DEBUG=1Put frequently used env vars in `.env`
Docker compose will source the .env file before running.
For example, if you always want the site to build "live", add the following to .env
export BUILDER=live