Add docker example #26
Conversation
garrettheel
force-pushed
the
docker-example
branch
from
58dd274 to
22391bc
Compare
| "lb_type": "round_robin", | ||
| "hosts": [ | ||
| { | ||
| "url": "tcp://app:80" |
There was a problem hiding this comment.
make this 8080 as envoy has listener on 80 and on flask app (app.py) when you start it you need 8080
There was a problem hiding this comment.
They're in separate containers though, app resolves to the IP of a container that solely runs Flask in this example
garrettheel
force-pushed
the
docker-example
branch
from
22391bc to
67af713
Compare
| @@ -0,0 +1,8 @@ | |||
| FROM lyft/envoy-build:latest | |||
|
|
|||
| ADD . /source | |||
There was a problem hiding this comment.
This will make the image much larger then it need to be. Can we clean /source from the final image?
There was a problem hiding this comment.
Yeah, we should definitely do that (especially if we push up real images with binaries to the public repo)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Is your intention to scale up service1 and service2 independently for the tutorial?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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: | |||
There was a problem hiding this comment.
When does this run? Let's just remove all of the automated push for now. We can do this in a follow up later.
There was a problem hiding this comment.
Ultimately we need to only do this on master test runs, so yeah let's not deal with this now
| } | ||
| ] | ||
| }, | ||
| "filters": [ |
There was a problem hiding this comment.
do you have plans on having HC on cluster? (I'd just clean unnecessary stuff otherwise)
There was a problem hiding this comment.
I agree, if there is no health check config, just delete the HC filter.
| "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 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
Work in progress, please don't merge