While I admire your intention to learn about Microservices and Docker, your question has a fundamental problem.

What is clear to anyone who has done microservices, is that you don't build an app using microservices from scratch.

You need a monolith. A big monolith in production with issues. Then you identify the boundaries and the seams and start splitting your monolith.

Building an app using the microservices approach from scratch is a secure recipe for disaster. Microservices are complex. A lot. Deployment is complex, communication is complex, logging is complex, data consistency is complex. Beyond all added complexity to a fresh new project, you risk of splitting your non-monolith into the wrong pieces and to find out when it's too late.

Now, as a mere mental experiment, and since you want to learn:

1. Try to identify potential service boundaries. From your description I see at least 4 different services:
   1. Authentication/Authorization/Users
   2. Blog Posts
   3. Comments
   4. Dashboard/Website (Lol, I matched the list letters with initials)
2. Create #n different Node applications, each having its own database (the frontend does not require any).
3. Decide how the services should communicate. You have many possibilities here:
   1. Each service expose a REST API and the fronted queries them via AJAX.
   2. The frontend collects the data from the other services REST API before rendering the page, hiding the backend services from the public.
   3. Communication happens via lower lever protocols like Protocol Buffers or Thrift.
   4. You get to have completely asynchronous communication, using queues (RabbitMQ) to exchange requests and responses which may or may not arrive.
   5. If you choose a synchronous communication, remember to implement a circuit breaker.
4. Using Docker and Docker-Compose orchestrate the infrastructure.
5. Profit (hopefully).