closes #2 Starting services with docker-compose #28

Merged
merged 7 commits into from Jan 9, 2017

Conversation

Projects
None yet
2 participants
@mszarlinski
Collaborator

mszarlinski commented Dec 14, 2016

Finally I managed to setup a Docker configuration, so that the entire application can be started with docker-compose. I will publish images to docker hub in a couple days, so they will be available without a need of building them locally before application startup.
Please review @arey @ryanjbaxter

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 15, 2016

Contributor

I will test it.

Contributor

arey commented Dec 15, 2016

I will test it.

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Dec 15, 2016

Collaborator

Ok, thanks. I expect some problems with order of containers startup. If you encounter any problem, please follow the following steps:

  1. Start config server with docker-compose up -d config-server. Make sure it is up and running by testing /manage/health endpoint.
  2. Start Eureka with docker-compose up -d discovery-server.
  3. Start remaining services with docker-compose up.

Maybe I should add it to README.

Collaborator

mszarlinski commented Dec 15, 2016

Ok, thanks. I expect some problems with order of containers startup. If you encounter any problem, please follow the following steps:

  1. Start config server with docker-compose up -d config-server. Make sure it is up and running by testing /manage/health endpoint.
  2. Start Eureka with docker-compose up -d discovery-server.
  3. Start remaining services with docker-compose up.

Maybe I should add it to README.

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 15, 2016

Contributor

@mszarlinski I've checkout your docker-compose branch then I've executed the mvn clean install -PbuildDocker command line and I've got the following error:

INFO] Building image mszarlinski/spring-petclinic-customers-service
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] spring-petclinic-microservices ..................... SUCCESS [  0.208 s]
[INFO] spring-petclinic-ui ................................ SUCCESS [ 12.660 s]
[INFO] spring-petclinic-monitoring ........................ SUCCESS [  0.765 s]
[INFO] spring-petclinic-customers-service ................. FAILURE [ 29.624 s]
[INFO] spring-petclinic-vets-service ...................... SKIPPED
[INFO] spring-petclinic-visits-service .................... SKIPPED
[INFO] spring-petclinic-config-server ..................... SKIPPED
[INFO] spring-petclinic-discovery-server .................. SKIPPED
[INFO] spring-petclinic-api-gateway ....................... SKIPPED
[INFO] spring-petclinic-tracing-server .................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 43.825 s
[INFO] Finished at: 2016-12-15T19:23:39+01:00
[INFO] Final Memory: 86M/944M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.3.258:build (default) on project spring-petclinic-customers-service: Exception caught: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: org.apache.http.conn.HttpHostConnectException: Connect to localhost:2375 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :spring-petclinic-customers-service

After having updating the docker-maven-plugin to the latest version 0.4.13 the build is passing.

Contributor

arey commented Dec 15, 2016

@mszarlinski I've checkout your docker-compose branch then I've executed the mvn clean install -PbuildDocker command line and I've got the following error:

INFO] Building image mszarlinski/spring-petclinic-customers-service
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] spring-petclinic-microservices ..................... SUCCESS [  0.208 s]
[INFO] spring-petclinic-ui ................................ SUCCESS [ 12.660 s]
[INFO] spring-petclinic-monitoring ........................ SUCCESS [  0.765 s]
[INFO] spring-petclinic-customers-service ................. FAILURE [ 29.624 s]
[INFO] spring-petclinic-vets-service ...................... SKIPPED
[INFO] spring-petclinic-visits-service .................... SKIPPED
[INFO] spring-petclinic-config-server ..................... SKIPPED
[INFO] spring-petclinic-discovery-server .................. SKIPPED
[INFO] spring-petclinic-api-gateway ....................... SKIPPED
[INFO] spring-petclinic-tracing-server .................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 43.825 s
[INFO] Finished at: 2016-12-15T19:23:39+01:00
[INFO] Final Memory: 86M/944M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.3.258:build (default) on project spring-petclinic-customers-service: Exception caught: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: org.apache.http.conn.HttpHostConnectException: Connect to localhost:2375 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :spring-petclinic-customers-service

After having updating the docker-maven-plugin to the latest version 0.4.13 the build is passing.

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 16, 2016

Contributor

Just a few remark: maven version is hardcoded into the Dockerfile:

ADD spring-petclinic-discovery-server-1.4.2.jar /app.jar

Maybe could we use joker?

Contributor

arey commented Dec 16, 2016

Just a few remark: maven version is hardcoded into the Dockerfile:

ADD spring-petclinic-discovery-server-1.4.2.jar /app.jar

Maybe could we use joker?

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 16, 2016

Contributor

I've got a lot of error even if I manually check config-server and discovery-server startup.
Maybe could we enhance startup order by waiting HTTP port is open?
See https://docs.docker.com/compose/startup-order/ and the wait-for-it.sh script.

Contributor

arey commented Dec 16, 2016

I've got a lot of error even if I manually check config-server and discovery-server startup.
Maybe could we enhance startup order by waiting HTTP port is open?
See https://docs.docker.com/compose/startup-order/ and the wait-for-it.sh script.

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Dec 16, 2016

Collaborator

Thanks for advice, I will try to fix it with https://github.com/vishnubob/wait-for-it

Collaborator

mszarlinski commented Dec 16, 2016

Thanks for advice, I will try to fix it with https://github.com/vishnubob/wait-for-it

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 21, 2016

Contributor

@mszarlinski The docker.plugin.version 0.3.258 is very old and do not work on macosx. Please upgrade to the last one.

Contributor

arey commented Dec 21, 2016

@mszarlinski The docker.plugin.version 0.3.258 is very old and do not work on macosx. Please upgrade to the last one.

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Dec 30, 2016

Collaborator

@arey containers startup has been fixed with wait-for-it.sh

Collaborator

mszarlinski commented Dec 30, 2016

@arey containers startup has been fixed with wait-for-it.sh

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 31, 2016

Contributor

I've got timeout at startup even though I may ping my config server http://localhost:8888/info

config-server        | 2016-12-30 20:02:55.761  INFO 1 --- [           main] o.s.j.e.a.AnnotationMBeanExporter        : Located managed bean 'refreshEndpoint': registering with JMX server as MBean [org.springframework.cloud.endpoint:name=refreshEndpoint,type=RefreshEndpoint]
config-server        | 2016-12-30 20:02:55.856  INFO 1 --- [           main] o.s.c.support.DefaultLifecycleProcessor  : Starting beans in phase 0
config-server        | 2016-12-30 20:02:55.974  INFO 1 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8888 (http)
config-server        | 2016-12-30 20:02:55.978  INFO 1 --- [           main] o.s.s.p.config.ConfigServerApplication   : Started ConfigServerApplication in 5.63 seconds (JVM running for 6.785)
config-server        | 2016-12-30 20:02:59.815  INFO 1 --- [nio-8888-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring FrameworkServlet 'dispatcherServlet'
config-server        | 2016-12-30 20:02:59.815  INFO 1 --- [nio-8888-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization started
config-server        | 2016-12-30 20:02:59.832  INFO 1 --- [nio-8888-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 16 ms
discovery-server     | wait-for-it.sh: timeout occurred after waiting 15 seconds for config-server:8888/info
tracing-server       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health
tracing-server       | Error: Invalid or corrupt jarfile /app.jar
visits-service       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health
vets-service         | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health

I've tried to set timeout to zero (no timeout) and all services are waiting config server availability.
The error is coming from web context: /info and /manage/health. We just have to user host:port. With config-server:8888 it's working.

I think we also have to increase a bit the default timeout (15 seconds) because all containers timeout started from the docker-compose up execution. With no timeout:

discovery-server     | 2016-12-30 20:27:22.615  INFO 1 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8761 (http)
discovery-server     | 2016-12-30 20:27:22.617  INFO 1 --- [           main] c.n.e.EurekaDiscoveryClientConfiguration : Updating port to 8761
discovery-server     | 2016-12-30 20:27:22.626  INFO 1 --- [           main] o.s.s.p.d.DiscoveryServerApplication     : Started DiscoveryServerApplication in 11.255 seconds (JVM running for 11.957)
customers-service    | wait-for-it.sh: discovery-server:8761 is available after 17 seconds
visits-service       | wait-for-it.sh: discovery-server:8761 is available after 16 seconds
vets-service         | wait-for-it.sh: discovery-server:8761 is available after 16 seconds
tracing-server       | wait-for-it.sh: discovery-server:8761 is available after 16 seconds

Moreover, the Dockerfile of the Tracing Server has duplicated lines:

RUN bash -c 'chmod +x wait-for-it.sh'
RUN bash -c 'chmod +x wait-for-it.sh'
Contributor

arey commented Dec 31, 2016

I've got timeout at startup even though I may ping my config server http://localhost:8888/info

config-server        | 2016-12-30 20:02:55.761  INFO 1 --- [           main] o.s.j.e.a.AnnotationMBeanExporter        : Located managed bean 'refreshEndpoint': registering with JMX server as MBean [org.springframework.cloud.endpoint:name=refreshEndpoint,type=RefreshEndpoint]
config-server        | 2016-12-30 20:02:55.856  INFO 1 --- [           main] o.s.c.support.DefaultLifecycleProcessor  : Starting beans in phase 0
config-server        | 2016-12-30 20:02:55.974  INFO 1 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8888 (http)
config-server        | 2016-12-30 20:02:55.978  INFO 1 --- [           main] o.s.s.p.config.ConfigServerApplication   : Started ConfigServerApplication in 5.63 seconds (JVM running for 6.785)
config-server        | 2016-12-30 20:02:59.815  INFO 1 --- [nio-8888-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring FrameworkServlet 'dispatcherServlet'
config-server        | 2016-12-30 20:02:59.815  INFO 1 --- [nio-8888-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization started
config-server        | 2016-12-30 20:02:59.832  INFO 1 --- [nio-8888-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 16 ms
discovery-server     | wait-for-it.sh: timeout occurred after waiting 15 seconds for config-server:8888/info
tracing-server       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health
tracing-server       | Error: Invalid or corrupt jarfile /app.jar
visits-service       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health
vets-service         | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761/manage/health

I've tried to set timeout to zero (no timeout) and all services are waiting config server availability.
The error is coming from web context: /info and /manage/health. We just have to user host:port. With config-server:8888 it's working.

I think we also have to increase a bit the default timeout (15 seconds) because all containers timeout started from the docker-compose up execution. With no timeout:

discovery-server     | 2016-12-30 20:27:22.615  INFO 1 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8761 (http)
discovery-server     | 2016-12-30 20:27:22.617  INFO 1 --- [           main] c.n.e.EurekaDiscoveryClientConfiguration : Updating port to 8761
discovery-server     | 2016-12-30 20:27:22.626  INFO 1 --- [           main] o.s.s.p.d.DiscoveryServerApplication     : Started DiscoveryServerApplication in 11.255 seconds (JVM running for 11.957)
customers-service    | wait-for-it.sh: discovery-server:8761 is available after 17 seconds
visits-service       | wait-for-it.sh: discovery-server:8761 is available after 16 seconds
vets-service         | wait-for-it.sh: discovery-server:8761 is available after 16 seconds
tracing-server       | wait-for-it.sh: discovery-server:8761 is available after 16 seconds

Moreover, the Dockerfile of the Tracing Server has duplicated lines:

RUN bash -c 'chmod +x wait-for-it.sh'
RUN bash -c 'chmod +x wait-for-it.sh'
@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Dec 31, 2016

Collaborator

I've pushed a fix and containers are starting properly. Could you please investigate missing traces in tracing-server? Nothing is logged.

Collaborator

mszarlinski commented Dec 31, 2016

I've pushed a fix and containers are starting properly. Could you please investigate missing traces in tracing-server? Nothing is logged.

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 31, 2016

Contributor

Default timeout (15 seconds) is still there. I think we may increase it to 1mn. Don't you?

config-server        | 2016-12-31 16:52:52.926  INFO 1 --- [nio-8888-exec-2] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 14 ms
customers-service    | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761
tracing-server       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761
config-server        | 2016-12-31 16:53:00.365  INFO 1 --- [nio-8888-exec-2] s.c.a.AnnotationConfigApplicationCont
Contributor

arey commented Dec 31, 2016

Default timeout (15 seconds) is still there. I think we may increase it to 1mn. Don't you?

config-server        | 2016-12-31 16:52:52.926  INFO 1 --- [nio-8888-exec-2] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization completed in 14 ms
customers-service    | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761
tracing-server       | wait-for-it.sh: timeout occurred after waiting 15 seconds for discovery-server:8761
config-server        | 2016-12-31 16:53:00.365  INFO 1 --- [nio-8888-exec-2] s.c.a.AnnotationConfigApplicationCont
@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Dec 31, 2016

Collaborator

You are right. I thought waiting is done in a loop, but it is not true for timeout>0.

Collaborator

mszarlinski commented Dec 31, 2016

You are right. I thought waiting is done in a loop, but it is not true for timeout>0.

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 31, 2016

Contributor

I've started 3 times docker-compose up and I always had the following error with visits-service or pets-service:

visits-service exited with code 137
Contributor

arey commented Dec 31, 2016

I've started 3 times docker-compose up and I always had the following error with visits-service or pets-service:

visits-service exited with code 137
@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Dec 31, 2016

Contributor

On tracing-server startup, I've got the following error:

tracing-server       | 2016-12-31 18:22:29.813  INFO 1 --- [           main] com.netflix.discovery.DiscoveryClient    : Getting all instance registry info from the eureka server
tracing-server       | 2016-12-31 18:22:50.449 ERROR 1 --- [           main] c.n.d.s.t.d.RedirectingEurekaHttpClient  : Request execution error
tracing-server       | 
tracing-server       | com.sun.jersey.api.client.ClientHandlerException: java.net.SocketTimeoutException: Read timed out
tracing-server       | 	at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.1.jar!/:1.19.1]
Contributor

arey commented Dec 31, 2016

On tracing-server startup, I've got the following error:

tracing-server       | 2016-12-31 18:22:29.813  INFO 1 --- [           main] com.netflix.discovery.DiscoveryClient    : Getting all instance registry info from the eureka server
tracing-server       | 2016-12-31 18:22:50.449 ERROR 1 --- [           main] c.n.d.s.t.d.RedirectingEurekaHttpClient  : Request execution error
tracing-server       | 
tracing-server       | com.sun.jersey.api.client.ClientHandlerException: java.net.SocketTimeoutException: Read timed out
tracing-server       | 	at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.1.jar!/:1.19.1]
@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Jan 1, 2017

Collaborator

Unfortunately, I am unable to reproduce any of reported issues.

Code 137 stands for SIGKILL, so JVM process was killed from outside somehow. Please also make sure that Eureka server is running while Zipkin server is starting up - maybe it has been terminated too?

Collaborator

mszarlinski commented Jan 1, 2017

Unfortunately, I am unable to reproduce any of reported issues.

Code 137 stands for SIGKILL, so JVM process was killed from outside somehow. Please also make sure that Eureka server is running while Zipkin server is starting up - maybe it has been terminated too?

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Jan 5, 2017

Contributor

In order micro-services could reach the tracing-server, I think you have to add a link to the tracing-server (and maybe a depends on?):

  visits-service:
    image: mszarlinski/spring-petclinic-visits-service
    container_name: visits-service
    links:
     - config-server
     - discovery-server
     - tracing-server
    depends_on:
     - config-server
     - discovery-server
    entrypoint: ["./wait-for-it.sh","discovery-server:8761","--timeout=60","--","java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
    ports:
     - 8082:8082

In this way, Docker compose will open a network route between the tracing server and each microservice.

Contributor

arey commented Jan 5, 2017

In order micro-services could reach the tracing-server, I think you have to add a link to the tracing-server (and maybe a depends on?):

  visits-service:
    image: mszarlinski/spring-petclinic-visits-service
    container_name: visits-service
    links:
     - config-server
     - discovery-server
     - tracing-server
    depends_on:
     - config-server
     - discovery-server
    entrypoint: ["./wait-for-it.sh","discovery-server:8761","--timeout=60","--","java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
    ports:
     - 8082:8082

In this way, Docker compose will open a network route between the tracing server and each microservice.

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Jan 5, 2017

Collaborator

I will check that.

Collaborator

mszarlinski commented Jan 5, 2017

I will check that.

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Jan 6, 2017

Collaborator

Zipkin tracing doesn't work even when starting services without Docker, so this is a bug not related to the Docker configuration. Should I open separate issue for that?

Collaborator

mszarlinski commented Jan 6, 2017

Zipkin tracing doesn't work even when starting services without Docker, so this is a bug not related to the Docker configuration. Should I open separate issue for that?

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Jan 6, 2017

Contributor

Of course, if tracing server does not work without Docker, we could open a new issue.
For this PR, my last comments is about the hard-coded version of the maven version in Dockerfile:

ADD spring-petclinic-discovery-server-1.4.2.jar /app.jar

I don't know if we could use joker or not in Dockerfile. If not, we could customize the Maven <finalName>

Contributor

arey commented Jan 6, 2017

Of course, if tracing server does not work without Docker, we could open a new issue.
For this PR, my last comments is about the hard-coded version of the maven version in Dockerfile:

ADD spring-petclinic-discovery-server-1.4.2.jar /app.jar

I don't know if we could use joker or not in Dockerfile. If not, we could customize the Maven <finalName>

@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Jan 6, 2017

Collaborator

Nice, will look into that as well!

Collaborator

mszarlinski commented Jan 6, 2017

Nice, will look into that as well!

@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Jan 7, 2017

Contributor

By debugging what happen with the tracing server, I've saw that model update/save logs have been removed by the commit: 769c229
We should reintroduce them. Example in OwnerResource:

        LOG.info("Saving owner {}", ownerModel);
        return ownerRepository.save(ownerModel);
Contributor

arey commented Jan 7, 2017

By debugging what happen with the tracing server, I've saw that model update/save logs have been removed by the commit: 769c229
We should reintroduce them. Example in OwnerResource:

        LOG.info("Saving owner {}", ownerModel);
        return ownerRepository.save(ownerModel);
@arey

This comment has been minimized.

Show comment
Hide comment
@arey

arey Jan 7, 2017

Contributor

I've found why zipkin did not receive any traces.
We have to add the following dependency into the spring-petclinic-api-gateway pom.xml:

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-zipkin</artifactId>
        </dependency>
Contributor

arey commented Jan 7, 2017

I've found why zipkin did not receive any traces.
We have to add the following dependency into the spring-petclinic-api-gateway pom.xml:

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-zipkin</artifactId>
        </dependency>
@mszarlinski

This comment has been minimized.

Show comment
Hide comment
@mszarlinski

mszarlinski Jan 7, 2017

Collaborator

I've added ARTIFACT_NAME parameter to Dockerfiles. Let's fix Zipkin issue in new issue: #31

Collaborator

mszarlinski commented Jan 7, 2017

I've added ARTIFACT_NAME parameter to Dockerfiles. Let's fix Zipkin issue in new issue: #31

@mszarlinski mszarlinski merged commit 82939fc into spring-petclinic:master Jan 9, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment