we are using Jhipster and docker for our microservices architechture. we just deployed our application stack to docker swarm(docker-compose version 3) with one only one node as active and having issues with Gateway app throwing zuul timeout connecting to backend microservices. We have a different environment where we are not using swarm(docker-compose version 2) and it works great. In swarm I was able curl to backend microservices from Gateway app using containername:port but not containerIp:port. I am lost here as I could not narrow down the issue to whether it is a swarm issue or jhipster issue. I even changed the 'prefer-ip-address: false' in our app properties but it is same issue? Any leads on what the issue could be?
Related
Can somebody help me with this problem.
I have two instances of docker keycloak containers cluster using a postgre Database. I use JDBC_PING for keycloak cluster discovery. The problem is that when checking one of the instances logs I get the following errors:
Error reading JDBC_PING table(https://i.stack.imgur.com/vrsdp.png)
Rollback(https://i.stack.imgur.com/2z0MF.png)
Multiple threads active within it(https://i.stack.imgur.com/lemFD.png)
All of them are deployed on azure ACI using an application gateway for managing traffic.
Can somebody point me in the right direction for debugging?
I don't know what to check.
Only one container throws this error.
Edit: There is not a problem with the keycloak cluster because I disabled jdbc_ping and left only 1 instance, I think it is a connection timeout, because the exceptions are still apearing. It is really weird that it happens only on production, on staging is working fine. Still investigating :(
I have recently faced an issue that made me spend some time to understand what is going on exactly. I have a container with tomcat. Also I have some UI tests running in container (selenium/standalone-chrome-debug with inbuilt selenium server). So I'm running a non-dockerised Java-process which is rising Chrome inside the Selenium container by the url http://localhost:4444/wd/hub which is opening application running in Tomcat container by the url 192.168.1.66:8080/app. This is working perfectly and the only thing I have to do is to set my local IP 192.168.1.66:8080/app instead of localhost:8080/app as an URL of my app.
Recently I had to do the same not in Tomcat container but using locally installed Tomcat. On the same port 8080 192.168.1.66:8080/app is not reachable any more as well as localhost:8080/app. The only working option is to use host.docker.internal:8080/app. But here is the issue - I also make some API calls to that app and host.docker.internal:8080/app is not working in this case because API calls are being made from the outside of docker by non-dockerised Java-process. And I can't use different urls for UI and API for many reasons. For API simple localhost:8080/app would work, but it should work for UI as well at the same time.
What can I do in this situation?
I'm currently struggling with docker and SSL. Let me give you an overview on what I'm trying to do.
I built a microservice-based architecture which is composed by a react web application and some "backend" services written in python and exposed with gunicorn on docker containers. I need to serve it over SSL because of Auth0 which needs the https communication. So, I built the server, bought a domain and got the SSL certificate for the domain with let's encrypt.
Now, here are the troubles, since mi services communicates to each other with a docker network, say services-network. For this reason they refer each other with the url `service:port/example.
At the moment I'm able to successfully connect to my web app with https but whenever this tries to contact the "backend" services the connection is refused because of it came from a non-secure resource (I used http://service:port/endpoint).
I tried to use the let's encrypt certificate generated for the webapp but the communication is blocked with message requests.exceptions.SSLError: HTTPSConnectionPool(host='service', port=8081): Max retries exceeded with url: /endpoint (Caused by SSLError(CertificateError("hostname 'service' doesn't match 'domain.com'",),))
I understand that a possible workaround for this error is to make the services communicate each other without using the docker network but the external one. Anyway I think that is not a good practice and that the communication among containers needs to be done through the docker network.
Finally, my question is: which is the best way to make the containers communicate through https over the docker network?
I personally like to use nginx as a reverse proxy. You would configure it normally and set it to proxy_pass <dockerIp:port>.
Many people like to use traefik.io which has many features including Let's Encrypt integration.
I am in the process of evaluating moving a very large Azure Cloud Service (Web Role) microservice architecture to AKS and have been working through the necessary code and build changes to support it.
In order to replicate the production environment locally for the developers, we run nginx on the host with SSL offloading and DNS (hosted in Azure) A records pointing to 127.0.0.1. When running in the Azure Emulator, the net affect is the ability for both the developer to visit the various web front ends in their browser (i.e. https://myapp.mydomain.dev) as well as hit the various API's in the solution (Web API 2) in Postman/cURL, etc.
Additionally due to how the networking of the Azure Emulator works, the apps themselves can resolve each other through nginx on the host (i.e. MVC app at https://myapp.mydomain.dev can obtain a token from the IdP web API at https://identity.mydomain.dev and then use that token at the API at https://api.mydomain.dev). This is the critical piece and the source of my question.
All attempts at getting the containers themselves to resolve each other the same way the host OS can (browser/Postman, SSL offloading via nginx) have failed. Many of the instructions out there are understandably for linux containers but having adapted the various networking docker-compose settings for the windows container equivalent have not yet yielded an success. In order to keep the development environments aligned with the real work systems, which are tenantized and make sure of the default mapping in nginx to catch all incoming traffic and route it to a specific user facing app/container, it is not as simple as determining a "static" method of addressing these on startup and why the effort was put in to produce the development environments we have today.
Right now when one service (container) attempts to communication with another, it ultimately results in a resolution error as all requests resolve to https://127.0.0.1 due to the DNS A records hosted in Azure for the domain. Since this migration will be a longer term project, the environments need to co-exist so changing the way that DNS is resolved (real DNS A records pointing to 127.0.0.1), host running nginx and handling SSL offloading to the various webroles normally running in the Azure Emulator is not an option.
Is there a way (with Windows containers) to either:
Allow the container to utilize nginx on the host OS transparently (app must still call the API at https://api.mydomain.dev), which will cause the traffic to be routed properly to the correct container/port defined in the docker-compose file?
OR
Run nginx on each container, allowing each container to then resolve and route appropriately without knowing the IP of the other container, possibly through an alias which could be added to the containers nginx.conf before the service starts?
The platform utilizes OAuth2/OIDC and it is critical to maintain the full URL to the other services from the applications perspective. Beyond mirroring production and sandbox environments, this URL's are utilized for redirect URL and post logout redirect URL validation among other things so using "https://myContainerNameForOtherContainerAlias" is not a workable solution.
Will I have the same problem when setting up the AKS environment as well?
Deployed Hazelcast image on Openshift and I have created a route but still not able to connect to it from external Java client. I came to know that routes only work for HTTP or HTTPS services , so am I missing anything here or what do I have to do to expose that Hazelcast instance to outer world ?
And the Docker image for Hazelcast is created and it runs Hazelcast.jar inside the image , does this concern the problem I'm facing ?
I tried exposing the service by running the command
oc expose dc hazelcast --type=LoadBalancer --name=hazelcast-ingress
and external IP with different port number was generated and I tried that as well still getting "exception com.hazelcast.core.HazelcastException: java.net.SocketTimeoutException" and not able to connect to it.
Thanks in advance, any guidance would be really helpful.
According to this, "...If the client application is outside the OpenShift project, then the cluster needs to be exposed by the service with externalIP and the Hazelcast client needs to have the Smart Routing feature disabled".