I have two spring projects. One project having web-socket implementation which sends messages to the client and second project have some other services and classes. Before in the client side, I am defining two proxies. One for main services, another one for receiving web-socket messages and I have to run both the projects on different-different ports. Now I want both the projects to run on the same port. Is there any way to do that. I also have a doubt that once first project is hosted on a port ( suppose 8080 ), will web-socket push notification work properly on the same port?
While it is not possible to run both projects on same port there are other ways you can achieve this. You can use a gateway (For ex: kong) service or package your applications and deploy on a tomcat server. I prefer deploying applications to tomcat (If you don't have many services) as you need to put extra efforts to maintain gateway.
Related
I've been reading through the nameko docs, and it is all good and clear, except for one part.
How do you actually deploy your nameko microservice?
I mean, it is clear how we deploy RESTful APIs in flask_restful, for instance. But with nameko?
If two microservices should communicate, how do we move them into the "listening" state?
I am not sure I understand your problem.
For each nameko service you define AMQP_URI constant that point to your RabbitMQ instance.
If each of your services have the same AMQP_URI, it make possible communication through sending rpc calls (where you have a queue per service endpoint) or using pub/sub messaging because service use the same RabbitMQ instance.
You can also have HTTP REST API. You must define endpoint in nameko service with http decorator (see example here: https://nameko.readthedocs.io/en/stable/built_in_extensions.html). In your confguration you have to define PORT for you web server, e.g. port 8000: WEB_SERVER_ADDRESS: 0.0.0.0:8000. And make this port accessible for the World.
I have two EARs which are deployed on a single Weblogic server. The two EARs are A and B.
"A" has a service that "B" needs to access. B needs to access this service and get the data synchronously.
I do not want to use REST or other HTTP methods as it would slow down the communication.
Is there something like RMI for SpringBoot that works within the Same server?
Or is it equally faster to use a REST call within the same server compared to an RMI based solution?
I went through Spring Remote, but it seems to be for communication between different servers. Please let me know if this is the case.
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat. In PCF we never mention the port number. In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
This is a pretty broad question, so I'm going to answer with a pretty broad response but link you to where you can find more details, if you are inclined to dig in more.
How PCF works internally when deploying Spring boot project
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat.
When you run cf push -p my/cool/file.jar (or even file.war), the cf cli extracts everything from that archive and pushes it up to CF. CF stores your app files & then your app is staged.
During staging, the Java build pack runs. It looks at all the files that were pushed & tries to determine what to do with them. It knows how to handle several different types of apps [1], including both standard WAR files & Spring Boot apps. The build pack will check your app to see if its one of the supported types in order [2] and will select the first match.
After selecting the type of app, it runs through and installs what is necessary to run your app. For a Spring Boot app, that's basically just the JVM. For a WAR file, it installs Tomcat & a JVM. In addition, it writes out the configuration & start up commands necessary for CF to launch your app.
At this point staging is complete and you have what is called a "droplet". If you have any additional questions on the staging workflow, read here for more details [3].
At this point, the app would be started. The platform takes the droplet that was created and executes the command specified by the build pack to start the app [4]. If all goes well, your app will then be up and running on CF.
In PCF we never mention the port number.
Correct. The platform will tell you the port on which your application should listen. For Java apps, you don't have to do anything. The Java buildpack will handle configuring Spring Boot or Tomcat to start and listen on the correct port.
For Spring Boot apps, you can look at the start up command to see how it's doing this. For Tomcat, it happens in the server.xml that's generated by the Java buildpack [5].
In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
Yes and no. Each application you run can have multiple instances. If you scaled your app to have three instances, that would be roughly like having 3 Tomcat instances in your classic approach.
The main difference is that there would be no Apache Web Server in front. On Cloud Foundry, this is not necessary because it has it's own load balancer called Gorouter [6] which handles proxying traffic to your app and load balancing across available app instances.
This is a classic mistake that people new to CF make. They try to replicate classic architectures and shoehorn a reverse proxy into their app when it's not necessary. This is one of the benefits of CF. It handles routing traffic to your app in a scalable way, freeing you up to focus more on your app.
[1] See "Standard Containers -> https://github.com/cloudfoundry/java-buildpack#additional-documentation
[2] https://github.com/cloudfoundry/java-buildpack/blob/master/config/components.yml#L18
[3] https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
[4] https://docs.cloudfoundry.org/concepts/overview.html#apps-anywhere
[5] https://github.com/cloudfoundry/java-buildpack/blob/master/resources/tomcat/conf/server.xml#L21
[6] https://docs.cloudfoundry.org/concepts/architecture/#routing
No. The simple answer is each instance of ur application jar is running in its own container within PCF. So there is no clash of using the same port numbers.
I am trying to introduce Pact in our company. However the consumer calls APIs using providers SDKs and the host-port is dynamically determined using Kubernetes. I am new to all this backend technology so trying to understand how do we deal with this since it will be impossible to get host/port into pom.xml if its dynamic?
It depends whether you're talking about port of the mock service in the consumer tests, or the port of the provider in the verification step.
In the consumer tests, is it possible to provide a test implementation of the part of the SDK that looks up the port? Perhaps you could contact the provider team to see they could supply one that would allow you to set a known port?
In regards to the provider, you would typically run the verification step against a locally running provider in the CI build, not against one deployed into a live environment, so a known port should be able to be used.
If I deploy an EAR on WAS 6.1 and I want to use a remote ejb client, i need to know the url.
Now I know the host name where the EAR is deployed but i need the port number also. On WAS console when i go to Ports, I see many ports running different services. Which one is the one on which the EAR is listening?
Is it the one marked BOOTSTRAP_ADDRESS?