Add docker example by garrettheel · Pull Request #26 · envoyproxy/envoy

garrettheel · 2016-08-20T22:03:28Z

Work in progress, please don't merge

RomanDzhabarov · 2016-08-21T21:47:11Z

make this 8080 as envoy has listener on 80 and on flask app (app.py) when you start it you need 8080

They're in separate containers though, app resolves to the IP of a container that solely runs Flask in this example

mattklein123 · 2016-08-24T22:46:21Z

This will make the image much larger then it need to be. Can we clean /source from the final image?

Yeah, we should definitely do that (especially if we push up real images with binaries to the public repo)

The build image also has a lot of stuff in it that isn't needed, it would be better to just build, and then create a binary image based on just trusty.

envoys

garrettheel · 2016-08-26T18:04:09Z

+    networks:
+      envoymesh:
+        aliases:
+          - service1


Is your intention to scale up service1 and service2 independently for the tutorial?

The idea is to have two different services to show envoy's routing capabilities. @mattklein123 suggested to leave scaling out up until now. But if we want to include that to showcase lb capabilities, then yes, we would scale 1 and 2 independently.

And in fact, it is possible now. Because we colocated the service envoy and the flask app, we can just use docker-compose scale and scale either service and the front envoy will round robbing load balance.

mattklein123 · 2016-08-26T21:40:19Z


 script: docker run -t -i -v $TRAVIS_BUILD_DIR:/source lyft/envoy-build:latest /bin/bash -c "cd /source && ci/do_ci.sh $TEST_TYPE"
+
+after_success:


When does this run? Let's just remove all of the automated push for now. We can do this in a follow up later.

Ultimately we need to only do this on master test runs, so yeah let's not deal with this now

RomanDzhabarov · 2016-08-26T22:25:40Z

+                }
+              ]
+            },
+            "filters": [


do you have plans on having HC on cluster? (I'd just clean unnecessary stuff otherwise)

I agree, if there is no health check config, just delete the HC filter.

mattklein123 · 2016-08-29T16:46:33Z

+            "filters": [
+              {
+                "type": "both",
+                "name": "health_check",


…_cache.cc This avoids a deadlock when a library which is being dlopen'ed creates as part of its static constructors a thread which quickly need to call malloc. We are still in the dlopen call (so with some internal glibc mutex taken) when the thread executes code and later needs to call malloc which in term calls tls_get_addr_tail, which wait for the dlopen mutex to be unlocked. If later the dlopen'ing thread also calls malloc as part of its constructors, we are in a deadlock. Fix is similar to gperftools/gperftools@7852eeb Stack of the dlopening thread: #0 0x00007fd5406ca93c in __lll_lock_wait () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0 #1 0x00007fd5406c45a5 in pthread_mutex_lock () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0 ... proprietary code in the stack envoyproxy#9 0x00007fd5074f0367 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at src/ClientImpl.cpp:15 envoyproxy#10 0x00007fd5074f06d7 in _GLOBAL__sub_I_ClientImpl.cpp(void) () at src/ClientImpl.cpp:85 envoyproxy#11 0x00007fd50757aa46 in __do_global_ctors_aux () envoyproxy#12 0x00007fd5073e985f in _init () from ... envoyproxy#13 0x00007fd53bf9dec8 in ?? () from ... envoyproxy#14 0x00007fd54d637a5d in call_init.part () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#15 0x00007fd54d637bab in _dl_init () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#16 0x00007fd54d63c160 in dl_open_worker () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#17 0x00007fd54d637944 in _dl_catch_error () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#18 0x00007fd54d63b7d9 in _dl_open () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#19 0x00007fd54d61f2b9 in dlopen_doit () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2 envoyproxy#20 0x00007fd54d637944 in _dl_catch_error () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 envoyproxy#21 0x00007fd54d61f889 in _dlerror_run () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2 envoyproxy#22 0x00007fd54d61f351 in dlopen@@GLIBC_2.2.5 () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2 Stack of the newly created thread calling tls_get_addr_tail: #0 0x00007fd5406ca93c in __lll_lock_wait () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0 #1 0x00007fd5406c4622 in pthread_mutex_lock () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0 #2 0x00007fd54d63a2ed in tls_get_addr_tail () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2 #3 0x00007fd53fee877d in tcmalloc::ThreadCache::CreateCacheIfNecessary () at src/thread_cache.cc:344 envoyproxy#4 0x00007fd53fecb4ab in tcmalloc::ThreadCache::GetCache () at src/thread_cache.h:437 envoyproxy#5 0x00007fd53fefeccb in (anonymous namespace)::do_malloc (size=56) at src/tcmalloc.cc:1354 envoyproxy#6 tcmalloc::do_allocate_full<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1762 envoyproxy#7 tcmalloc::allocate_full_cpp_throw_oom (size=56) at src/tcmalloc.cc:1776 envoyproxy#8 0x00007fd53ff01b80 in tcmalloc::dispatch_allocate_full<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1785 envoyproxy#9 malloc_fast_path<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1845 envoyproxy#10 tc_new (size=56) at src/tcmalloc.cc:1980 ... proprietary code in the stack envoyproxy#26 0x00007fd5406c1ef4 in start_thread () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0 envoyproxy#27 0x00007fd5403ba01d in clone () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libc.so.6

This adds the CEL validation tests to ensure the rules defined in API are working as expected. Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>

…#45324) ### Description This PR resolves a use-after-free (UAF) / pure virtual method call crash that occurs during `ConnectivityGrid` teardown when connection pools (HTTP/3, HTTP/2, or HTTP/1) are destroyed while active connection attempts are still ongoing in the background. --- ### 💥 The Bug & Crash Callstack When the `ConnectivityGrid` is deleted, its destructor destroys its underlying connection pools in reverse order. If a pool has active connection attempts, deleting the pool synchronously cancels those attempts. In C++, once a derived class destructor finishes, the object's vtable pointer transitions to point to the base class vtable. Because `destructAllConnections()` is invoked in `~HttpConnPoolImplBase()` (the base class destructor), the connection cancellation callback wrappers execute `onConnectionAttemptFailed()` after the derived pool object has already been destructed. When `onConnectionAttemptFailed()` attempts to write a log trace calling `describePool(attempt->pool())` (which executes `attempt->pool().protocolDescription()`), virtual dispatch invokes a **pure virtual function call** on the base class `HttpConnPoolImplBase`, crashing Envoy instantly: ```log Program received signal SIGSEGV, Segmentation fault. 0x000056453663656e in Envoy::Http::ConnectivityGrid::WrapperCallbacks::onConnectionAttemptFailed() Backtrace: #0 0x000056453663656e in Envoy::Http::ConnectivityGrid::WrapperCallbacks::onConnectionAttemptFailed() #1 0x000056453663606d in Envoy::Http::ConnectivityGrid::WrapperCallbacks::ConnectionAttemptCallbacks::onPoolFailure() #2 0x000056453664e7f1 in Envoy::Http::HttpConnPoolImplBase::onPoolFailure() #3 0x00005645366cb447 in Envoy::ConnectionPool::ConnPoolImplBase::purgePendingStreams() #4 0x00005645366c9d6e in Envoy::ConnectionPool::ConnPoolImplBase::onConnectionEvent() #5 0x000056453666394d in Envoy::Tcp::ActiveTcpClient::onEvent() #6 0x000056453709b0e9 in Envoy::Network::MockConnectionBase::raiseEvent() ... #24 0x00005645366be287 in Envoy::ConnectionPool::ConnPoolImplBase::destructAllConnections() #25 0x00005645366766b8 in Envoy::Http::HttpConnPoolImplBase::~HttpConnPoolImplBase() #26 0x000056453664e70f in Envoy::Http::HttpConnPoolImplMixed::~HttpConnPoolImplMixed() #27 0x000056453664e739 in Envoy::Http::HttpConnPoolImplMixed::~HttpConnPoolImplMixed() #28 0x000056453647099c in std::__1::default_delete<>::operator()() #29 0x000056453647091c in std::__1::unique_ptr<>::reset() #30 0x000056453663a3ad in Envoy::Http::ConnectivityGrid::~ConnectivityGrid() #31 0x000056453663a4f9 in Envoy::Http::ConnectivityGrid::~ConnectivityGrid() #32 0x00005645365de65c in std::__1::default_delete<>::operator()() #33 0x000056453656b55c in std::__1::unique_ptr<>::reset() #34 0x00005645363174fa in ConnectivityGridTest_DestroyGridWithActiveH2Attempts_Test::TestBody() ``` --- ### 🛠️ The Fix Introduced a reloadable feature flag guard `envoy.reloadable_features.conn_pool_grid_early_return_on_teardown` (enabled by default) to shield both H3 and H2/H1 pools during destruction: * **Early Return**: Inside `WrapperCallbacks::onConnectionAttemptFailed()`, we check if `delete_started_` is `true`. If the flag is enabled and the wrapper is already being deleted/torn down, we return immediately, completely skipping the unsafe virtual method lookups on the half-destructed pool object. * **ALPN & Protocol Safety**: This safely protects the system regardless of which pool is being torn down (H3 or H2/H1 mixed pools). --- ### 🧪 Testing & Verification * Added the `DestroyGridWithActiveH2Attempts` unit test to verify that tearing down the `ConnectivityGrid` while an active H2 connection attempt is running does crash without the fix and not with the fix. Risk Level: low, only exposed with log level trace Testing: new unit test Docs Changes: N/A Release Notes: Y Platform Specific Features: N/A Runtime guard: envoy.reloadable_features.conn_pool_grid_early_return_on_teardown Signed-off-by: Dan Zhang <danzh@google.com> Co-authored-by: Dan Zhang <danzh@google.com>

…envoyproxy#45324) ### Description This PR resolves a use-after-free (UAF) / pure virtual method call crash that occurs during `ConnectivityGrid` teardown when connection pools (HTTP/3, HTTP/2, or HTTP/1) are destroyed while active connection attempts are still ongoing in the background. --- ### 💥 The Bug & Crash Callstack When the `ConnectivityGrid` is deleted, its destructor destroys its underlying connection pools in reverse order. If a pool has active connection attempts, deleting the pool synchronously cancels those attempts. In C++, once a derived class destructor finishes, the object's vtable pointer transitions to point to the base class vtable. Because `destructAllConnections()` is invoked in `~HttpConnPoolImplBase()` (the base class destructor), the connection cancellation callback wrappers execute `onConnectionAttemptFailed()` after the derived pool object has already been destructed. When `onConnectionAttemptFailed()` attempts to write a log trace calling `describePool(attempt->pool())` (which executes `attempt->pool().protocolDescription()`), virtual dispatch invokes a **pure virtual function call** on the base class `HttpConnPoolImplBase`, crashing Envoy instantly: ```log Program received signal SIGSEGV, Segmentation fault. 0x000056453663656e in Envoy::Http::ConnectivityGrid::WrapperCallbacks::onConnectionAttemptFailed() Backtrace: #0 0x000056453663656e in Envoy::Http::ConnectivityGrid::WrapperCallbacks::onConnectionAttemptFailed() #1 0x000056453663606d in Envoy::Http::ConnectivityGrid::WrapperCallbacks::ConnectionAttemptCallbacks::onPoolFailure() #2 0x000056453664e7f1 in Envoy::Http::HttpConnPoolImplBase::onPoolFailure() #3 0x00005645366cb447 in Envoy::ConnectionPool::ConnPoolImplBase::purgePendingStreams() envoyproxy#4 0x00005645366c9d6e in Envoy::ConnectionPool::ConnPoolImplBase::onConnectionEvent() envoyproxy#5 0x000056453666394d in Envoy::Tcp::ActiveTcpClient::onEvent() envoyproxy#6 0x000056453709b0e9 in Envoy::Network::MockConnectionBase::raiseEvent() ... envoyproxy#24 0x00005645366be287 in Envoy::ConnectionPool::ConnPoolImplBase::destructAllConnections() envoyproxy#25 0x00005645366766b8 in Envoy::Http::HttpConnPoolImplBase::~HttpConnPoolImplBase() envoyproxy#26 0x000056453664e70f in Envoy::Http::HttpConnPoolImplMixed::~HttpConnPoolImplMixed() envoyproxy#27 0x000056453664e739 in Envoy::Http::HttpConnPoolImplMixed::~HttpConnPoolImplMixed() envoyproxy#28 0x000056453647099c in std::__1::default_delete<>::operator()() envoyproxy#29 0x000056453647091c in std::__1::unique_ptr<>::reset() envoyproxy#30 0x000056453663a3ad in Envoy::Http::ConnectivityGrid::~ConnectivityGrid() envoyproxy#31 0x000056453663a4f9 in Envoy::Http::ConnectivityGrid::~ConnectivityGrid() envoyproxy#32 0x00005645365de65c in std::__1::default_delete<>::operator()() envoyproxy#33 0x000056453656b55c in std::__1::unique_ptr<>::reset() envoyproxy#34 0x00005645363174fa in ConnectivityGridTest_DestroyGridWithActiveH2Attempts_Test::TestBody() ``` --- ### 🛠️ The Fix Introduced a reloadable feature flag guard `envoy.reloadable_features.conn_pool_grid_early_return_on_teardown` (enabled by default) to shield both H3 and H2/H1 pools during destruction: * **Early Return**: Inside `WrapperCallbacks::onConnectionAttemptFailed()`, we check if `delete_started_` is `true`. If the flag is enabled and the wrapper is already being deleted/torn down, we return immediately, completely skipping the unsafe virtual method lookups on the half-destructed pool object. * **ALPN & Protocol Safety**: This safely protects the system regardless of which pool is being torn down (H3 or H2/H1 mixed pools). --- ### 🧪 Testing & Verification * Added the `DestroyGridWithActiveH2Attempts` unit test to verify that tearing down the `ConnectivityGrid` while an active H2 connection attempt is running does crash without the fix and not with the fix. Risk Level: low, only exposed with log level trace Testing: new unit test Docs Changes: N/A Release Notes: Y Platform Specific Features: N/A Runtime guard: envoy.reloadable_features.conn_pool_grid_early_return_on_teardown Signed-off-by: Dan Zhang <danzh@google.com> Co-authored-by: Dan Zhang <danzh@google.com>

garrettheel force-pushed the docker-example branch from 58dd274 to 22391bc Compare August 21, 2016 20:01

RomanDzhabarov reviewed Aug 21, 2016
View reviewed changes

garrettheel force-pushed the docker-example branch from 22391bc to 67af713 Compare August 22, 2016 21:05

mattklein123 reviewed Aug 24, 2016
View reviewed changes

Garrett Heel and others added 2 commits August 26, 2016 10:50

Add docker example

7503691

Add new architecture with a network, a front envoy, and two service

54d80a8

envoys

junr03 force-pushed the docker-example branch from 32da916 to 54d80a8 Compare August 26, 2016 18:01

garrettheel reviewed Aug 26, 2016
View reviewed changes

Jose Nino added 3 commits August 26, 2016 11:19

Remove not needed files

2d3b7b0

Add environment variables for service distinction

9d4735f

Update README

2d02b2a

mattklein123 reviewed Aug 26, 2016
View reviewed changes

Delete CI push to docker. Doing manually for now

6141fc5

junr03 force-pushed the docker-example branch from 23f051f to 6141fc5 Compare August 26, 2016 21:57

Consolidate docs into sphinx

055bcc9

junr03 force-pushed the docker-example branch from d5f30f9 to 055bcc9 Compare August 26, 2016 22:23

RomanDzhabarov reviewed Aug 26, 2016
View reviewed changes

Jose Nino and others added 2 commits August 26, 2016 15:32

Add http2 to cluster manager

fdd1bd1

Merge remote-tracking branch 'origin/master' into docker-example

5dec74c

mattklein123 reviewed Aug 29, 2016
View reviewed changes

Comment thread example/front-envoy.json Outdated

"filters": [

{

"type": "both",

"name": "health_check",

mattklein123 Aug 29, 2016

Copy link
Copy Markdown

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete

antoniovicente mentioned this pull request Aug 3, 2020

tcp tunneling integration flake #12253

Closed

raonitimo mentioned this pull request Aug 5, 2020

Envoy crashes with "assert failure: !api_state.paused_." #12488

Closed

hsuyuming mentioned this pull request Sep 9, 2020

Oauth2 extention not work #13023

Closed

incfly mentioned this pull request Sep 23, 2020

Data race in callback manager / ClusterInfoImpl destruction #13209

Closed

antoniovicente mentioned this pull request Nov 19, 2020

Test flake in OauthIntegrationTest.UnauthenticatedFlow #12960

Closed

danzh2010 mentioned this pull request Mar 10, 2021

quiche: TSAN failure in quic_protocol_integration_test #15414

Closed

ayyatsenko mentioned this pull request Jun 25, 2021

Catch Segmentation Fault using UpstreamStartTls in network filter #17144

Closed

danzh2010 mentioned this pull request Nov 3, 2021

multiplexed_integration_test flaky #18889

Closed

yanjunxiang-google mentioned this pull request Apr 20, 2022

MemorySanitizer: use-of-uninitialized-value issue due to accessing destroyed class member #20913

Merged

RyanTheOptimist mentioned this pull request Jun 2, 2022

TSAN error in h1_capture_persistent_fuzz_test #21547

Closed

huanghuangzym mentioned this pull request Jun 30, 2022

Segfault from ECDS update #14930

Closed

yanjunxiang-google mentioned this pull request Nov 1, 2022

fixing OSS filter_fuzz_test OOM issue when thread_count is 800 million. #23782

Merged

sharmamona mentioned this pull request Nov 18, 2022

RELEASE_ASSERT when creating upstream connection and socket call failed with ENOBUFS #24073

Open

alyssawilk mentioned this pull request Mar 20, 2023

flake in IpVersions/GolangIntegrationTest.LocalReply_DecodeHeader/IPv6 #26182

Closed

garrett528 mentioned this pull request Mar 24, 2023

redis: MULTI EXEC causes crash during mirroring mode #26342

Closed

yanjunxiang-google mentioned this pull request May 8, 2023

Envoy ext_proc filter throw exception when received response timeout Duration is too large #27260

Merged

yanjunxiang-google mentioned this pull request May 22, 2023

Assert(valid) when ext_proc filter apply header mutations #27547

Merged

yanjunxiang-google mentioned this pull request May 30, 2023

ext_proc fuzzer test trigger ENVOY_BUG when clear route cache #27657

Merged

yanjunxiang-google mentioned this pull request Jul 25, 2023

ext_proc filter ASSERT at canIterate() when client not sending trailer #28592

Merged

yanjunxiang-google mentioned this pull request Nov 27, 2023

Revert ext_proc: send attributes #30781 #31017

Merged

danzh2010 mentioned this pull request Mar 15, 2024

quic integration test Asan violation #32340

Closed

juanmolle mentioned this pull request Mar 26, 2024

POC wasm as upstream filter #33119

Closed

nbaws mentioned this pull request May 14, 2024

aws: Memory overwrite protobuf issue triggered by PackFrom #34123

Closed

arminabf pushed a commit to arminabf/envoy that referenced this pull request Jun 5, 2024

Add buildtool dockerimage of TinyGo (envoyproxy#26)

7ed598b

dceravigupta mentioned this pull request Jul 8, 2024

Envoy validate mode not working with envoy.access_loggers.fluentd extension #35098

Closed

Bikara950225 mentioned this pull request Nov 18, 2024

When I use the admin_config configuration in Tap, Envoy fails to start. #37195

Closed

mathetake added a commit that referenced this pull request Mar 3, 2026

Adds CEL validation testing (#26)

f015e7a

This adds the CEL validation tests to ensure the rules defined in API are working as expected. Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>


		script: docker run -t -i -v $TRAVIS_BUILD_DIR:/source lyft/envoy-build:latest /bin/bash -c "cd /source && ci/do_ci.sh $TEST_TYPE"

		after_success:

Uh oh!

Conversation

garrettheel commented Aug 20, 2016

Uh oh!

RomanDzhabarov Aug 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mattklein123 Aug 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

RomanDzhabarov Aug 21, 2016 •

edited

Loading

mattklein123 Aug 24, 2016 •

edited

Loading