Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add docker example #26

Merged
merged 13 commits into from
Aug 29, 2016
Merged

Add docker example #26

merged 13 commits into from
Aug 29, 2016

Conversation

garrettheel
Copy link
Contributor

Work in progress, please don't merge

"lb_type": "round_robin",
"hosts": [
{
"url": "tcp://app:80"
Copy link
Member

@RomanDzhabarov RomanDzhabarov Aug 21, 2016

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

@@ -0,0 +1,8 @@
FROM lyft/envoy-build:latest

ADD . /source
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

Copy link
Member

@mattklein123 mattklein123 Aug 24, 2016

Choose a reason for hiding this comment

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

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.

networks:
envoymesh:
aliases:
- service1
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

@@ -15,3 +15,7 @@ env:
- TEST_TYPE=docs

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:
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

}
]
},
"filters": [
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

deleted

"filters": [
{
"type": "both",
"name": "health_check",
Copy link
Member

Choose a reason for hiding this comment

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

delete

nezdolik pushed a commit to nezdolik/envoy that referenced this pull request May 4, 2024
…_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
    envoyproxy#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
    envoyproxy#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
arminabf pushed a commit to arminabf/envoy that referenced this pull request Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants