Microservices and the project network

Microservices on DockBoard are just several applications in the same project, talking to each other. There is no service registry to run and no mesh to configure — the project network does it.

How it works

Every project owns a Docker network called dockboard_proj_<projectId>. When an application is deployed into the project:

In local mode

DockBoard creates the network if it is missing and attaches the application to it.

On a remote server

The agent creates the network and writes a docker-compose.override.yml that attaches every service of the stack to it. Nothing to configure by hand.

From then on, applications in the project resolve one another by container name through Docker’s internal DNS.

A worked example

A front end, an API and a database. Create a project, then three services in it:

The Service Mesh tab gives you these strings ready to paste into each application’s environment variables:

# frontend
API_URL=http://dockboard-api:4000

# api
DATABASE_URL=postgres://user:password@dockboard-db-db:5432/db

Attach a domain to frontend only. api and db stay internal — no public URL, no exposed port, nothing to reach from the internet.

The two boundaries

One project

The network is project-scoped. An application in project A cannot reach one in project B by internal name. Go through the public HTTPS URL instead, or put them in the same project.

One Docker host

A project network is one server’s bridge. To spread a single application across machines, switch it to a cluster, which gives it a real overlay network. To keep several applications of a project talking across hosts, either place them on one server or expose the internal service over HTTPS.