My goal is straightforward, I wish to start simple. One micro-service using Spring Boot running on one Docker container, a second micro-service running on another Docker container and a Web-based UI running on a third Docker container.

The goal is to not only have the micro-services communicate with one another through a common URI, but also have the Web application be able to communicate with them as seamlessly as possible. I will be using Nginx as a reverse proxy for the Web UI to find services.

For example, micro-service 1 should be called by using /api/service1, and the second service /api/service2. The Web application has a front-facing URL and it's JavaScript code delegates to the services when needed.

I'd like to be able to use go to "mysite.com", which brings up the main page; however, I could possibly navigate to "mysite.com/api/service1" or "mysite.com/api/service2" and still get a response, even though these the Web site and the two services are running in separate containers.

So, on my local machine, how could I set up three container applications, two for each of the services and the other running a Web site, so they all can still communicate with one another and the entire orchestration can be seen from an outside observer?

I would like to orchestrate this using Kubernetes (I am using KIND [Kubernetes in Docker]), but my ultimate goal is to set up a development environment on a local machine to simulate a Cloud environment and use best practices in doing so; Apparently doing this declaratively in YAML is what is required, but looking at the documentation, with services, nodeports, pods, namespaces, etc, it's quite a confusing trek. I recently started creating pods and found out they deployments were preferred for "best practices".

I'm running in a Windows environment, I use Docker for Windows (Docker version 19.03.1, build 74b1e89). I've enabled the Kubernetes support for Docker for the purposes of creating deployments. I'm using a Docker image for the Oracle server built using the instructions here (https://github.com/oracle/docker-images/tree/master/OracleDatabase/SingleInstance) Note: Windows users, please edit those scripts and make them all conform to Unix line endings.

I'm using Spring Boot Tools Suite (basically the one which is bundled with Eclipse) to create simple micro-services, Nginx on its own instance as a reverse proxy and still yet one other instance for dishing up the Web content.

This is an example YAML file I used for the purposes of running the same image under the guise of two different services:

apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    name: dev
---
apiVersion: v1
kind: Service
metadata:
  name: echo-api
  namespace: dev
spec:
  selector:
    name: echo-api
  clusterIP: None
  ports:
  - name: echo-api
    port: 8080
    targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: echo2-api
  namespace: dev
spec:
  selector:
    name: echo2-api
  clusterIP: None
  ports:
  - name: echo2-api
    port: 8080
    targetPort: 8080
---
apiVersion: v1
kind: Pod
metadata:
  name: echo-api
  namespace: dev
  labels:
    name: echo-api
spec:
  hostname: echo-api
  subdomain: default-subdomain
  containers:
  - image: echo-api:0.0.1-SNAPSHOT
    command:
      - sleep
      - "3600"
    name: echo-api
---
apiVersion: v1
kind: Pod
metadata:
  name: echo2-api
  namespace: dev
  labels:
    name: echo2-api
spec:
  hostname: echo2-api
  subdomain: default-subdomain
  containers:
  - image: echo-api:0.0.1-SNAPSHOT
    command:
      - sleep
      - "3600"
    name: echo2-api

What I am trying to accomplish is completing this with the proper YAML that uses best practices; the set-up a Web site and micro-services, all running on conceptually "different" virtual containers, yet still allow for a debugging environment on a local machine. A container running NGinx (aside from the Web site itself) would be used as a reverse-proxy to communicate with the services.

I am trying to achieve a configurable end-result of a local development environment which can allow for rapid development and testing of microservices in a simulated, complete end-to-end orchestrated environment before they are even deployed to the Cloud.