I am trying to debug my app in testing environment, my app is running in pod, I said 'pod' because I am not familiar with Kubernetes, its manage client looks like this:app running schematic diagram. I have learn I should set idea like this idea RUN/Debug Configurations schematic diagram. And should restart and redeploy my app, I changed Dockfile firstly. the origin instruction is FROM xxx/java:alpine VOLUME /tmp ADD recruitment.jar app.jar ENTRYPOINT ["java","-Xmx2048m","-jar","/app.jar"] and I changed this to FROM xxx/java:alpine VOLUME /tmp ADD recruitment.jar app.jar ENTRYPOINT ["java","-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005","-jar","/app.jar"] but it always show error like this Error running 'face_remote': Unable to open debugger port (888.88.888.888[not real]:5005): java.io.IOException "handshake timeout". I am not sure with this ip,sicne I use 'ping 888.88.888.888' instruction can not success. I use this ip because Swagger request url's domain name's ip is this.this main enter image description here. and I guess if the app is running in docker or k8s and it will have a different Interactive mode. not same like just running in linux
most of the attached image are not visible.
IP address should be accessible from your local system
[888.88.888.888] note sure this is correct.
debug port also need to be mapped from your local system
-use port forwarding
ex:kubectl port-forward 5005:5005
If you have configure port forwarding then you can use localhost:5005 for debugging
I see three things that you can check:
Check the IP address:
The jar file runs inside a Docker container, which runs inside a pod. To access the pod you usually go through a service and an ingress. The ip you are using is most likely hitting the ingress/service or any other higher layer.
To attach a remote debugger, you will need to connect directly to the PodIP. One way of doing this is to first connect to your kubernetes cluster using the tool kubectl (some configuration required) and make a port forward from your pod: kubectl port-forward my-pod-c93b8b6df-8c4aa 5005:5005 pod (as an example, the pod instance name is my-pod-c93b8b6df-8c4aa).
This will open a connection from your local computer into the pod. Then you will need to identify the PodIP by kubectl describe pods my-pod-c93b8b6df-8c4aa and use that in IntelliJ
Check if the port is exposed:
Make sure you expose the port 5005 from the pod in your test environment (similar to exposing a port when you run the container locally).
How to do this depends a bit on how you are running your Kubernetes cluster. If you use Helm chart, you can just add a configuration like this in the port section of your deployment yaml:
- containerPort: 5005
name: debug
protocol: TCP
Check debug-command address:
Last thing is to make sure you are adding the correct address in the command line option. As IntelliJ suggest in the debug editor: for JDK9+ use …suspend=n,address=*:5005 and for JDK8 and below use …suspend=n,address=5005
Related
I'm using a Windows machine with Docker Desktop installed. My project does not live inside a docker container.
But as evident to https://youtrack.jetbrains.com/issue/IDEA-263484, it seems that Docker Desktop has overridden my host file to function properly, and the following code now returns an incorrect hostname.
InetAddress.getLocalhost().getCanonicalHostname() // host.docker.internal
This is my host file
#...
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# Added by Docker Desktop
192.168.128.75 host.docker.internal
192.168.128.75 gateway.docker.internal
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section
Is there another standard method (that is cross-platform) to detect real machine hostname that works with Docker Desktop installations?
As mentioned in the linked issue and in Rob's answer, I could probably add an entry in my host file to mitigate this issue, but this might not work too well if the IP gets changed, and requires additional setup.
It looks like getCanonicalHostname() takes the first entry for your IP address. It's not the best solution, but if you add an entry for 192.168.128.75 above the one for host.docker.internal, that one gets picked up.
I've installed the minikube instance on my local computer (--driver=docker). The minikube ip is 192.168.49.2. When I start minikube (minikube start --memory 7168) I get no errors on console. But trying to ping the minikube ip fails. What I do wrong?
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
minikube Ready control-plane,master 9d v1.20.2 192.168.49.2 <none> Ubuntu 20.04.1 LTS 5.4.72-microsoft-standard-WSL2 docker://20.10.3
Recall that minikube is local Kubernetes - it runs a single-node Kubernetes cluster on your personal computer so that you can try out Kubernetes. Now, it doesn't run the Kubernetes cluster in your local box, it runs it inside a VM.
That is why you can't simply access Node IP from your local. Another way to see it is that in Kubernetes you can create NodePort Service to access your workload outside of your cluster but this doesn't work when you are running Kubernetes using minikube - and the reason is the same as mentioned above.
Now, how you work around that is by using minikube service <<YOUR_SERVICE_NAME>> command. This will create a tunnel to access your application - which is exposed using the Service - from outside of the K8S cluster.
You can try minikube tunnel as mentioned by #Hackerman but I have never tried it.
Just to add a bit on top of the previous answer. There is docker bridge limitation that makes it impossible to route the traffic to Linux containers. That is why the minikube tunnel and service were implemented as workaround for that.
minikube tunnel runs as a process, creating a network route on the
host to the service CIDR of the cluster using the cluster’s IP address
as a gateway. The tunnel command exposes the external IP directly to
any program running on the host operating system.
Alternative way to that you may find interesting would be using an ingress which was enabled in #9761 pull request:
.\minikube-windows-amd64.exe addons enable ingress I1121 00:59:39.443965 3000 translate.go:89] Failed to load translation file for en: Asset translations/en.json not found
* After the addon is enabled, please run "minikube tunnel" and your ingress resources would be available at "127.0.0.1"
* Verifying ingress addon...
* The 'ingress' addon is enabled
On your windows system, after the creation of the container that is created by the initial "minikube start", you can see the "minikube instance" by typing "docker ps". This is the minikube 'master' node running in this container.
It would look something like this:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6293ca0ba5b0 gcr.io/k8s-minikube/kicbase:v0.0.25 "/usr/local/bin/entr…" 2 hours ago Up About an hour 127.0.0.1:59539->22/tcp, 127.0.0.1:59540->2376/tcp, 127.0.0.1:59537->5000/tcp, 127.0.0.1:59538->8443/tcp, 127.0.0.1:59536->32443/tcp minikube
In the PORTS column you will see ports that are forwarded by virtue of the way that minikube start the docker container. You can see these kinds of forwards are handled by docker the same as for any contain that you might do a "docker run -p port:port"
Notice that the first port forward in this list is the ssh port: "127.0.0.1:59539->22/tcp".
When you do a "minikube tunnel", minikube will open ssh.exe instances that you can see in your windows task manager if you enable the Command Line display in the column settings.
Those 'tunnels' would look like this:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -N docker#127.0.0.1 -p 59539 -i C:\Users\steve.sims\.minikube\machines\minikube\id_rsa "-L 8080:10.102.174.166:8080"
If I take that command apart and only run this from the command prompt:
ssh docker#127.0.0.1 -p 59539 -i C:\users\steve.sims\.minikube\machines\minikube\id_rsa
Then I get an interactive remote window into the minikube VM (or node). Typing 'ifconfig eth0' I get:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.49.2 netmask 255.255.255.0 broadcast 192.168.49.255
So, indeed my minikube ip is 192.168.49.2, but it is an internal address as the folks above mentioned.
Other than that, the -N parameter on the ssh means "no command" and the -L on the end is the port forward flag in port-to-forward:destination-socket format. Of course, so all of the tunnels are coming across that initial docker -p port:port forward that minikube established when the container was started.
If it is useful, you can create your own ssh instances from that line's format by script and they will work just as well.
To load some code, I need a clean local AEM Author instance running on my laptop. I start it using CLI like :
bash$ java -jar aem-author-p4502.jar -nointeractive
Default user/password is then admin/admin to access AEM on http://localhost:4502. I'm ok with that but I've tested from another computer and port 4502 is open from full local network.
I'd like to limit access only from localhost, maybe by configuring listener address to 127.0.0.1 only. How ?
Recent AEM versions uses Apache Felix Lightweight HTTP Service as HTTP Server. I found how to bind it to 127.0.0.1 when it is embedded in AEM.
Configuration file is crx-quickstart/launchpad/config/org/apache/felix/http.config. I added last line :
:org.apache.felix.configadmin.revision:=L"1"
org.apache.felix.http.session.timeout=I"10"
org.apache.felix.https.jetty.protocols.excluded=[ \
"SSLv3", \
]
org.apache.felix.proxy.load.balancer.connection.enable=B"true"
service.pid="org.apache.felix.http"
org.apache.felix.http.host="127.0.0.1"
Now AEM Author is available only from localhost.
Maybe you can try to add an exception on your firewall to the port 4502 and only enable connections from your local and deny the others.
Regards,
I cannot have my tomcat server started and at the same time use internet.
either I can start Tomcat (in Eclipse) and internet is not available.
or I can access the internet but tomcat cannot be started.
Here the original probleme I had when I first wanted to use Tomcat and display my html page on localhost.
GRAVE: StandardServer.await: create[localhost:8005]: I find a way to start the Tomcat Server: in the terminal:
sudo lsof -i : 8005 # checks port 80
sudo route -n flush
sudo route add default 192.168.1.1
then I can use tomcat and localhost:8080 but my internet connexion is dead
if I want my internet connexion then I stop the tomcat server by clicking on the red square in eclipse and then in the terminal I do:
sudo route -n flush
sudo route add default 192.168.0.1
THen I can use internet but tomcat cannot be restarted. I have to undergo the first process.
this of course is a very boring process and I would like to know what 's wrong and how I could fix it.
I use tomcat 9 / Mac OS sierra / Eclipse Neon3
When you say "my internet connexion is dead", do you mean that your network connection drops or that your DNS lookups fail? (What do you think this command is doing and why are you performing it: sudo route add default 192.168.1.1?)
If your program is modifying your system's connectivity settings, I would strongly recommend against preventing it from doing that. There's no reason for it to do so at that level, a more appropriate place to set settings would be at some deploy stage.
Alternatively, you could run your app in a Docker container which I strongly suspect will solve your problem. Visit www.docker.com to learn more.
I'm trying to connect JVisualVM, running on my local machine, to a remote machine which is running a WildFly server (version 8.1.0, to be specific.)
I didn't configure the WildFly server myself, and I don't know who did, but I do know that I can log in as an administrative user from my local machine by pointing my browser at:
https://[ip address of the remote machine]:9443/console
Note that it's https, not ordinary http, and that the port for that has been set to 9443 (I think the default is 8080 or 9990 or something... IDK, I saw a lot of port numbers online. I have been explicitly told that http was disabled for this WildFly server).
I can SSH into the remote machine. I can navigate to the bin directory for WildFly and run jboss-client.sh. I have to connect on port 9999 (I think the default is 9990 for that?)
I copied the jboss-client.jar (under bin/client) to my local machine and ran JVisualVM from the command line like this:
.\jvisualvm.exe -cp:a C:\[path to]\jboss-client.jar
It launches fine. File > Add Remote Host: Then I entered the IP. OK. I right clicked on it under Remote in the tree and picked Add JMX Connection. I entered
service:jmx:http-remoting-jmx://[ip]:9999
I checked off that I wanted to use the security credentials and entered the username and password. Checked off to save the security credentials. Left "Do not require SSL Connection" unchecked. Hit OK. It immediately spat out the message
Cannot connect to admin#service:jmx:http-remoting-jmx://[ip]:9999 using service:jmx:http-remoting-jmx://[ip]:9999
I also tried the port 9443, 9990, and 8080 instead. None of those worked. I tried https instead of http in the protocol name. That also didn't work.
What am I missing? How is it that I can access the console, and connect with jboss-client.sh, but I can't use JVisualVM? Is there some log I can use somewhere to see what's wrong? Maybe someone can point out a configuration I've missed somewhere?
Not sure if it's important or not, but my local machine is running Windows 10 with JDK8 installed. The WildFly server is using Java 6 on CentOS 6.3.
You need to add the jboss-client.jar (or jboss-cli-client.jar) to the class path for JVisualVM. The library can be found in the bin/client directory of the WildFly install.
I used the following command to add the library to the class path.
jvisualvm --cp:a ~/servers/wildfly-10.0.0.Final/bin/client/jboss-client.jar
Then I used service:jmx:remote+http://[ip]:[port] and was able to connect.
I don't know if someone else is also (still) having the same issue (Wildfly10 on a remote machine where management console is available at 9443 with HTTPS). The following worked for me.
For ssh connections:
Starting jvisualvm with jboss-client.jar
jvisualvm --cp:a #JBOSS_HOME/bin/client/jboss-client.jar
Using the following connection string:
service:jmx:remote+https://remote-server:9443
NOTE: I used here remote+https
Provide username and password
Hope this helps.
you missed run jstatd command in remote host ,
this little program is RMI server that possible connection from client to remote host though you using jmx connection it used jmxrmi protocol for that connection .
so first in remote host create file name as security.policy with this contain :
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
off course you must in file section for linux put explicit path and then of creation this file put it in bin directory of jdk.home
then you should run this command on remote host
$JAVA_HOME/bin/jstatd -J-Djava.security.policy=path of /security.policy -J-Djava.rmi.server.hostname=remote ip address -J-Djava.net.preferIPv4Stack=true
then you could connect to server off course with correct settings.
Include jboss-cli-client.jar and jboss-client.jar under \lib\visualvm\platform\lib and restart jvisualvm to pickup new jars.