We Keep Coding

How to expose port from container to container on testcontainers?

I want to integration test few services running on docker environment. They have to talk each other as they are connected. So I need to somehow expose port between each other. Is this setup possible using test containers library? I did not find any docks on it.
Tested app running locally, which will connect to dockerised servers:
mysql
backend one
To make it even harder backend one server needs to talk to mysql service.
Is this possible using testcontainers?

Testcontainers supports networks, there are a few examples in the tests.
You need to first create a network (via Network.newNetwork()), and then use withNetwork/withNetworkAliases to "connect" your containers into the same network.

Generally, when network communication between containers is required, a network should be created at docker level and containers should share it.
Things can be simplified by using docker-compose, which by default creates a network for all services declared in docker-compose file. Then containers can communicate via their service name.
I have never used Testcontainers project but I see in docs that has a docker-compose module.
Quoting from above url:
Testcontainers will spin up a small 'ambassador' container, which will
proxy between the Compose-managed containers and ports that are
accessible to your tests. This is done using a separate, minimal
container that runs socat as a TCP proxy.
There is also an example that you can base on, on docs url.

Spring MVC Apache Server integration

I have developed a Spring MVC app that can detect Ajax requests sent into my local environment 'localhost:8000/examplePath' with a json body being received as a mapped parameter. So, until here, all is fine.
My question is: Do i still need to deploy my application on a container 'Apache Tomcat/ HTTP Server for example' for my application to be accessible externally on a possible production environment, and if so why?
I want to better understand the necessity of such, if my backend 'Spring MVC app' can already receive and respond to ajax requests

Spring MVC creates a Web application that must be deployed to a Web Application Server to run. The server handles the low level stuff such as raw sockets and the HTTP protocol.

This is because you can't access from internet to your local environment, you need a public adress to access your application from everywhere only if you want to access it over internet otherwise can do it with a local network connection to access it.
If you want any container, you can do it easy with Pivotal. This a container platform for Spring apps.

Spring Cloud Starter Eureka without a webserver

Is it possible to run an eureka client without running a webserver? The 'spring-cloud-starter-eureka' artifact automatically pulls in 'spring-boot-starter-web'. Why is that? Is it possible to run the client without actually starting up a webserver?
My problem is that starting up a webserver eats up around ~200mb of ram. This is a problem because the memory allocated for the apps I want to use eureka with is ranging from 256-512mb.

It seems you don't need this service of yours to serve web request but still need the it to access your eureka server.
So disable web from the application.
spring.main.web-environment=false
And use the Discoveryclient to fetch the services.
If that is not good enough then remove eureka dependency and Make a rest call using (RestTemplate) to your eureka server to query for the services you need. Eureka exposes a rest endpoint for this. So it can't be used by even non-java/jvm based applications.
You could take a look at this project I wrote some time ago to see how to do this.
If that is not good enough still. Then you might have to write plain java code which you should be writing in the first place unless you have a reason to be using a framework such as spring (Transaction,JPA, web, security etc).

Running a java application on a remote server

I want to run a standalone java application on a remote server. It would not be accessible to clients, but would do background calculations and interact with a database and Secure Socket connection to a third party site. It would also interact with a php site.
Do I have to deploy this with JSP, or can I write a standalone application? If so, how would I deploy a standalone java application (jar file) on a remote server? I understand that I must have them install a jvm on the server (not a problem) but then how would I deploy it (if possible). Would I start it with a command line?
I know I have much to learn, but I am not sure how I would access the command line on a remote server. Through the cPanel?
Thanks.

First of all, you'll want to set up some firewall rules to allow access to that server. I'm hoping that you don't expose that server naked to the Internet.
If all you need is database access exposed on the Internet, I don't see why it can't be a secured web app deployed on a servlet/JSP engine and accessed via a web server. You can leverage basic auth for security, JDBC access to the database from the server, and servlets as controllers to accept requests in a nice REST API.
It'll save you the complications of sockets and inventing your own protocol (use HTTP), starting and stopping the application (now it's just a web server/servlet engine), and deployment (send a WAR file).

Does it really must be a 'standalone' application? I think that in your case the best match would be to use Spring container to load your application within some server (tomcat?) and expose services via standard controllers - with Spring you only have to add some annotations on services methods actually.
Then, your php site can interact with these controllers using for example ajax requests.
If your application is written already, you can easily transform it to run within Spring container. It's very non-invasive and promotes usage of POJOs.

Creating a web service for use in an internal application and exposing it to others

For my web application, I am thinking about using the Spring framework. Initially, I was thinking of having different actions like create user or login, but now I have to expose some functionality to other applications. Should I create a web service that I call from my application and others do as well, or create an action from Spring and then just have others call the web service? It seems like I should minimize the different ways to call something, but does it make sense to call a web service that is running on the same application server as my main app? Would this be a bad idea from a performance stand point?
Update
I was concerned that Tomcat wouldn't be able to serve both the static or dynamic pages on port 80 (so users could go to www.example.com/welcome.jsp instead of www.example.com:8080/welcome.jsp), as well as a web service but I guess it doesn't matter as both are just served as requests from Tomcat. I'm guessing this means I'll have to change Tomcat to run on port 80 and other applications will have access the web service via this port. Or I could leave Tomcat running on port 8080 and put Apache in front on Tomcat on port 80 and Apache will serve the requests to Tomcat. Is that correct?

I'd put the common business logic in a "business service" and :
call it from an action in your web app
expose it as a web service for other applications
To me, there is nothing bad with this approach and it's pretty easy and clean to implement it with Spring. Actually, I would find ugly to expose this business service as web service only and to call it from the web app (and I'm pretty sure that this will be more complicated to implement on the web app side). You have different "usage contexts", just expose the adequate interface for them.
(EDIT: I'm answering a question of the OP posted as comment below)
You can deploy the web application and the web service in the same WAR (but this is just a deployment choice, you could package the business logic in a JAR and use it in several WARs). Regarding the port, I'm not sure to understand your question. Traditionally, you'll use a web server (e.g. apache) in front of your application server. If you don't, you can always choose to run you app server on port 80. Actually, in both case you are free to use whatever port you want. Using port 80 is just convenient.
Yes, your update is correct.