I am currently doing a research on building Microservices using spring boot and Docker. Luckily I found this blog
Event Sourcing in Microservices Using Spring Cloud and Reactor by Kenny Bastani. You can find the github project source code here.
I really want to up and run this example because it has the functionalities/technologies that I was looking for.
I am running Ubuntu desktop 16.04 OS and already installed the following software mentioned on the said blog.
Maven 3
Java 8
Docker, Docker Machine
Docker Compose
Then executed the following scripts. This is also based on the blog. I just reduced the virtualbox-memory & virtualbox-disk-size to avoid computer freeze.
$ docker-machine create event-source-demo --driver virtualbox
--virtualbox-memory "1000" --virtualbox-disk-size "20000"
$ eval "$(docker-machine env event-source-demo)"
$ sh run.sh
After running the above scripts, The following snippet errors occurs.
2017-03-18 22:33:14.025 INFO 5136 --- [ main] com.netflix.discovery.DiscoveryClient : Getting all instance registry info from the eureka server
2017-03-18 22:33:14.151 ERROR 5136 --- [ main] c.n.d.s.t.d.RedirectingEurekaHttpClient : Request execution error
com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused (Connection refused)
at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.1.jar:1.19.1]
at com.sun.jersey.api.client.filter.GZIPContentEncodingFilter.handle(GZIPContentEncodingFilter.java:123) ~[jersey-client-1.19.1.jar:1.19.1]
at com.netflix.discovery.EurekaIdentityHeaderFilter.handle(EurekaIdentityHeaderFilter.java:27) ~[eureka-client-1.4.4.jar:1.4.4]
at com.sun.jersey.api.client.Client.handle(Client.java:652) ~[jersey-client-1.19.1.jar:1.19.1]
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) ~[jersey-client-1.19.1.jar:1.19.1]
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74) ~[jersey-client-1.19.1.jar:1.19.1]
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:509) ~[jersey-client-1.19.1.jar:1.19.1]
at com.netflix.discovery.shared.transport.jersey.AbstractJerseyEurekaHttpClient.getApplicationsInternal(AbstractJerseyEurekaHttpClient.java:194) ~[eureka-client-1.4.4.jar:1.4.4]
a
It seems like created docker images not linked to each other or was not able to establish connections.
Please let me know if you need more log details.
Related
i has dev and test two env that delpoy with k8s cluster.
dev:
rpc frame : dubbo 2.7.0
protocol:dubbo
JVM version:open jdk1.8
operate system : redhat 8.5
kernel.sysrq=1
vm.swappiness=10
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
net.ipv4.neigh.default.gc_thresh1=4096
net.ipv4.neigh.default.gc_thresh2=6144
net.ipv4.neigh.default.gc_thresh3=8192
test:
rpc frame : dubbo 2.7.0
protocol:dubbo
JVM version:open jdk1.8
operate system : redhat 7.9
kernel config:
kernel.sysrq=1
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-iptables=1
net.ipv4.neigh.default.gc_thresh1=4096
net.ipv4.neigh.default.gc_thresh2=6144
net.ipv4.neigh.default.gc_thresh3=8192
with my project updata lib, but netty was still in 4.1.25version,when i deploy to test on k8s pod , it will throw an timeout exception via dubbojson.
however it was work well on dev.
or update netty version to 4.1.71 on redhat 7.9 , the timeout exception was gone.
the tcpdump that i get of netty4.1.25 on test env show everthing was normal
ie:
docker container (psh ack)---provider
provider (psh ack)---docker container
docker (ack) --- provider
tcpdump show data had been reccived and ack to provider,but netty was timeout to read data.
when i use two server ,one os is redhat7.9, anther os is redhat8.5,both installed docker
i pull image(problematic) delpoy on both server , the timeout not exists anymore.
has anyone can help me.
begin, i was think that ,may be it was netty version too lower has compatiable operation system version.
after test, that was wrong.
I'm trying to install the kubernetes on a centos host. While following the official kubernetes docs for the installation process. After i try to execute the command systemctl enable --now kubelet terminal is giving the below output.
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-unit-files ===
Authentication is required to manage system service or unit files.
Authenticating as: root
Password:
When i try the same command with sudo, its giving me the below error.
Failed to execute operation: No such file or directory
Could someone please help me to fix this? Official link is below.
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
I'm trying to connect to a SonarQube server running on my machine in a Docker.
I installed the SonarLint plugin in IntelliJ, when I create the new connection to the server, given the token to the plugin, it shows:
Failed to connect the server. Please check the configuration. Error:
Fail to request http://localhost:9000/api/system/status
this URL works in the browser, giving back
{"id":"BF41A1F2-AWlcxJRKJ9-nWLU3WeGl","version":"7.6.0.21501","status":"UP"}
in the SonarLint log it says:
Caused by: java.net.ProtocolException: Unexpected status line:
I just pulled the last sonarqube image from docker repository and run it with only the port forwarding option (-p 9000:9000)
My environment:
SonarQube server version: 7.6.0.21501 ;
Java: 1.8.0_181
Docker: 2.0.0.3 (31259)
IntelliJ: Community 18.3.5
I found a workaround.
use the machine name instead localhost.
I am running SonarQube on both java and javascript code inside a CentOS VM. I pulled the sonarqube docker image and am running the container. I exposed port 9000 and am able to open up localhost:9000 and interact with the sonarqube gui. When I run the sonar-scanner from the command line on the JavaScript code using this command:
sonar-scanner -Dsonar.projectKey=javascript_code -Dsonar.sources=. -Dsonar.host.url=http://localhost:9000 -Dsonar.login=admin -Dsonar.password=admin
I get a fully analyzed project. As well as the JavaScript code I can run it on the Java code using the maven build. Both work correctly from the command line.
When I add it into a Jenkins Pipeline I do the exact same commands and get the following:
Error: SonarQube server [http://localhost:9000] can not be reached
Caused by: Fail to get bootstrap index from server
Caused by: Failed to connect to localhost:9000
Caused by: Connection refused (Connection refused)
I also tried when starting the container to use --network="host" instead of publishing port 9000, but it still does not connect from the Jenkins Pipeline. Everything works correctly when I am running the commands from the Command Line, just when I try to put it into a Jenkins Pipeline.
Any suggestions on how to fix this? Thanks.
*Edit: Using the sonarqube plugin I was able to get my analysis to run as a Jenkins Job. However, when I try to add the analysis into the pipeline I get the same SonarQube server cannot be reached error. It says it skips my project because the project has been banned form the build due to previous failures and gives me this error message:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar (default-cli) on project sonarqubeproj:
Unable to execute SonarQube: Fail to get bootstrap index from server: unexpected end of stream on Connection{localhost:9000, proxy=DIRECT hostAddress=localhost/127.0.0.1:9000 cipherSuite=none protocol=http/1.1}: \n not found: limit=0 content=… -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar (default-cli) on project feedback-tool-ui: Unable to execute SonarQube
The problem you are facing is most likely related to how you run jenkins.
I assume you also run jenkins via docker. this means that in the context of jenkins, localhost is not your host system, but the jenkins container. This means you need to adapt your sonarqube-url to reference the host system.
Therefore you have multiple options:
use the public ip of the host system
use the docker ip of the host system
resolve the ip via dns. docker has an internal DNS and if those container run in the same network, you can normally reach them by containername.
sidenote:
i am not sure if you are using docker-compose or kubernetes, but if you are not using it, you might also want to dive into docker-compose as it is just a simple yaml-config in which you can easily start up servers.
I've just installed docker on my windows 7 machine. When I start Docker QuickStart, I get following error which seems to be while creating the machine:
Creating machine...
(default) Unable to get the latest Boot2Docker ISO release version: Get https:/
/api.github.com/repos/boot2docker/boot2docker/releases/latest: dial tcp 192.30.2
52.124:443: connectex: A connection attempt failed because the connected party d
id not properly respond after a period of time, or established connection failed
because connected host has failed to respond.
(default) Copying C:\Users\robot\.docker\machine\cache\boot2docker.iso to C:\Use
rs\robot\.docker\machine\machines\default\boot2docker.iso...
(default) Creating VirtualBox VM...
(default) Creating SSH key...
Error attempting heartbeat call to plugin server: read tcp 127.0.0.1:60733->127.
0.0.1:60732: wsarecv: An existing connection was forcibly closed by the remote h
ost.
Error attempting heartbeat call to plugin server: connection is shut down
Error attempting heartbeat call to plugin server: connection is shut down
Error attempting heartbeat call to plugin server: connection is shut down
Error attempting heartbeat call to plugin server: connection is shut down
Error creating machine: Error in driver during machine creation: read tcp 127.0.
0.1:60733->127.0.0.1:60732: wsarecv: An existing connection was forcibly closed
by the remote host.
Looks like something went wrong... Press any key to continue...
There is a similar issue in docker/machine/issues/2773.
Try and see if the issue persists when creating a machine yourself instead of using quick-start:
Find where docker-machine.exe has been installed (or copy the latest released one in your %PATH%) and use that, from a regular CMD session:
First test the existing machine:
# find the name of the machine created.
docker-machine ls
docker-machine env --shell cmd <nameOfTheMachine>
docker machine ssh <nameOfTheMachine>
Then try creating a new one:
docker-machine create -d virtualbox <aNewMachine>
docker-machine env --shell cmd <aNewMachine>
docker machine ssh <aNewMachine>
I do not have a solution but found the root cause.
I had installed boot2docker and has been using for months. I had been creating all
my vbox images on the same folder all the while.
One fine day I decided to archive my machines and changed the folder in which I was creating the vbox images. It started giving this wired error. I reverted back my archive and tested again. It started working fine.
The difference I found on both the set up was, in the archived folder it was skipping the ca cert creation step and was directly creating the machine. In the new folder it was creating a cert and then creating the machine. It looks like the server doesn't like the new certs!!!!