DEV Community: Arash Yazdanibakhsh

Running a MongoDB Replica Set Locally: Docker Desktop & Native Windows Setup

Arash Yazdanibakhsh — Thu, 01 May 2025 21:12:57 +0000

When developing modern applications, a replica set configuration is essential to simulate production environments that leverage MongoDB’s high availability and redundancy. In this article, I’ll share two approaches:

Deploying a MongoDB Replica Set Using Docker Desktop
Running a MongoDB Replica Set Natively on Windows Without Docker Desktop
Each method has its merits depending on your environment and constraints.

Deploying a MongoDB Replica Set with Docker Desktop Docker is a great way to quickly spin up isolated environments. In this section, we’ll create a replica set using a custom Docker network and a Docker Compose file.

Step 1: Create a Docker Network

First, create an external Docker network that all MongoDB containers will share. Open your terminal and run:

docker network create mongo-cluster

Step 2: Prepare the docker-compose.yml File

Create a docker-compose.yml file with the following configuration. This file defines three services — one primary and two secondaries. Each service is configured to run with the replica set parameter ( — replSet rs0) and bind to all IP addresses:

version: ‘3.8’

services:

mongo-primary:

image: mongo:latest

container_name: mongo-primary

restart: always

command: mongod — replSet rs0 — bind_ip_all

ports:

- 27017:27017

volumes:

- E:/Program Files/MongoDB/primary/data:/data/db

networks:

- mongo-cluster

mongo-secondary1:

image: mongo:latest

container_name: mongo-secondary1

restart: always

command: mongod — replSet rs0 — bind_ip_all

ports:

- 27018:27017

volumes:

- E:/Program Files/MongoDB/secondary1/data:/data/db

networks:

- mongo-cluster

mongo-secondary2:

image: mongo:latest

container_name: mongo-secondary2

restart: always

command: mongod — replSet rs0 — bind_ip_all

ports:

- 27019:27017

volumes:

- E:/Program Files/MongoDB/secondary2/data:/data/db

networks:

- mongo-cluster

networks:

mongo-cluster:

external: true

Note: Adjust the volume paths (E:/Program Files/MongoDB/…) to your local directories as needed.

Step 3: Start the Containers

In the directory containing your docker-compose.yml file, execute:

docker-compose up -d

This command starts the three containers in detached mode.

Step 4: Initialize the Replica Set

Connect to the Primary Container:
Run the following command to open an interactive Mongo shell (mongosh) session inside the primary container:

docker exec -it mongo-primary mongosh

Initiate the Replica Set:
Within the shell, execute:

rs.initiate({_id: “rs0”,members: [{ _id: 0, host: “host.docker.internal:27017”},{ _id: 1, host: “host.docker.internal:27018” },{ _id: 2, host: “host.docker.internal:27019” }]});

Verify the Setup:
Run:

rs.status();

This command shows the status of your replica set. After the verification Run:

Exit

And go to step 5.

Step 5: Verify Data Persistence

Check your Docker volumes to ensure data is being persisted:

docker volume ls

Connection String

Connect your application using the following connection string:

mongodb://host.docker.internal:27017,host.docker.internal:27018,host.docker.internal:27019/?replicaSet=rs0

Tip: If host.docker.internal fails to resolve on Windows, add the following entry to your hosts file:
127.0.0.1 host.docker.internal

Running a MongoDB Replica Set Natively on Windows (Without Docker Desktop) If you prefer or need to run MongoDB directly on Windows without containerization, follow these steps.

Step 1: Download and Install mongosh

Make sure you have mongosh installed. This shell will help you manage and interact with your replica set.

Step 2: Configure MongoDB via mongod.cfg

Prepare separate configuration files for each MongoDB instance. Below is an example configuration (mongod.cfg) for one node:

mongod.conf

Where and how to store data.

storage:

dbPath: C:\Program Files\MongoDB\Server\7.0\data

Where to write logging data.

systemLog:

destination: file

logAppend: true

path: C:\Program Files\MongoDB\Server\7.0\log\mongod.log

Network interfaces

net:

port: 27017

bindIp: 127.0.0.1

Replica set configuration

replication:

replSetName: “rs0”`

`
Note: Create a similar configuration file for each MongoDB instance, ensuring that the port numbers and data directories are unique (e.g., 27017, 27018, 27019).

Step 3: Start the MongoDB Instances

Run each MongoDB server instance as an administrator. You can launch them manually using a command prompt or create a batch file. For example, to run the instance on port 27017, execute:

“C:\Program Files\MongoDB\Server\7.1\bin\mongod” — config “C:\Program Files\MongoDB\Server\7.1\bin\mongod.cfg”

For convenience, you can create a .bat file with the following content:

`
@echo off

start “MongoDB 7.1” “C:\Program Files\MongoDB\Server\7.1\bin\mongod” — config “C:\Program Files\MongoDB\Server\7.1\bin\mongod.cfg”

start “MongoDB 7.2” “C:\Program Files\MongoDB\Server\7.2\bin\mongod” — config “C:\Program Files\MongoDB\Server\7.2\bin\mongod.cfg”

`
*Run the batch file as an administrator.
*
Step 4: Manually Initiate the Replica Set

Launch the Primary Instance:
If not already running, start the primary node with:
mongod — port 27017 — dbpath “C:\Program Files\MongoDB\Server\7.0\data” — replSet rs0

Connect with mongosh:
Open mongosh as an administrator and execute:

`
rs.initiate({_id: “rs0”,members: [{ _id: 0, host: “127.0.0.1:27017” },{ _id: 1,host: “127.0.0.1:27018” },{ _id: 2, host: “127.0.0.1:27019” }]});

`
Step 5: Optionally Install as Windows Services

For an even smoother development experience, you can install each MongoDB instance as a Windows service. Run the following commands as an administrator:

“C:\Program Files\MongoDB\Server\7.1\bin\mongod.exe” — config “C:\Program Files\MongoDB\Server\7.1\bin\mongod.cfg” — install — serviceName “MongoDB7.1”

“C:\Program Files\MongoDB\Server\7.2\bin\mongod.exe” — config “C:\Program Files\MongoDB\Server\7.2\bin\mongod.cfg” — install — serviceName “MongoDB7.2”
`

Then, register the services with:

`
sc.exe create “MongoDB7.1” binPath= “\”C:\Program Files\MongoDB\Server\7.1\bin\mongod.exe\” — service — config=\”C:\Program Files\MongoDB\Server\7.1\bin\mongod.cfg\”” DisplayName= “MongoDB 7.1” start= auto

sc.exe create “MongoDB7.2” binPath= “\”C:\Program Files\MongoDB\Server\7.2\bin\mongod.exe\” — service — config=\”C:\Program Files\MongoDB\Server\7.2\bin\mongod.cfg\”” DisplayName= “MongoDB 7.2” start= auto
`

Finally, start the services:

`
net start MongoDB7.1

net start MongoDB7.2
`

Note: Running MongoDB as a Windows service may present some challenges; evaluate this option based on your project needs.

Conclusion

Both methods enable you to run a MongoDB replica set locally for testing and development:

Docker Desktop: Provides an isolated, containerized environment that closely mirrors cloud deployments. It’s quick to set up and perfect for multi-node configurations without polluting your host system.
Native Windows Setup: Offers a more traditional approach, especially when containerization is not an option. This method uses configuration files, command-line instructions, and optional Windows service installation.
By understanding and leveraging these approaches, you can develop and test applications that depend on MongoDB’s replica set features with confidence.

Happy coding!

A Deep Dive into YARP and Ocelot

Arash Yazdanibakhsh — Sat, 02 Nov 2024 19:51:57 +0000

Navigating API Gateway Options in .NET Core Microservices: A Deep Dive into YARP and Ocelot
In the evolving landscape of .NET Core microservices, selecting an appropriate API gateway or reverse proxy is fundamental. These tools not only manage routing but also handle authentication, load balancing, and service orchestration, ultimately shaping the scalability and resilience of microservices architectures. Two prominent solutions are YARP (Yet Another Reverse Proxy) and Ocelot, each serving distinct roles within this ecosystem. This article explores the configuration, capabilities, and use cases of both, providing a roadmap for developers and architects in making optimal choices.
YARP and Ocelot at a Glance
YARP—Microsoft’s tailored reverse proxy toolkit—caters to high-performance and scalable microservices architectures. Built with modern .NET Core features, YARP emphasizes high throughput and efficient memory use, making it highly suitable for complex, high-demand systems.
In contrast, Ocelot is a lighter, developer-friendly API gateway crafted specifically for .NET Core environments. Its streamlined setup, focused on routing and middleware, is ideal for less-intensive applications with straightforward traffic requirements and moderate scalability needs.
Configuration Insights and Key Differences
YARP Configuration
YARP’s configuration is notably flexible, offering a high degree of control adaptable to dynamic operational demands. It allows configuration through various mediums, including appsettings.json, environment variables, and inline code.
Key Configuration Features:
• Advanced Routing Rules: Supports complex patterns and rewrites, configurable via JSON or fluent APIs, providing extensive customization for traffic management.
• Load Balancing Strategies: Offers dynamic load balancing with options like Round Robin, Least Requests, and Random, essential for managing high-volume requests.
• Health Checks: Integrated active and passive health checks ensure traffic routes exclusively to healthy instances, enhancing reliability.
Example Configuration Snippet in appsettings.json:

"ReverseProxy": { "Routes": { "route1": { "ClusterId": "cluster1", "Match": { "Path": "/api/{**catch-all}" } } }, "Clusters": { "cluster1": { "Destinations": { "destination1": { "Address": "http://localhost:5000/" } } } } }

Ocelot’s configuration is purposefully straightforward, managed through a JSON configuration file that integrates seamlessly with .NET Core’s configuration system. This simplicity makes it an attractive option for microservices novices or projects with limited complexity.
Key Configuration Features:
• Routing: Defined in JSON, enabling intuitive setup for downstream paths, upstream templates, and HTTP methods.
• Middleware Integration: Includes delegating handlers for authentication, caching, and rate-limiting to improve security and performance.
• Service Discovery: Supports dynamic service discovery through registries like Consul, which enables effortless service scaling and management.
Example Configuration Snippet in ocelot.json:

{ "ReRoutes": [ { "DownstreamPathTemplate": "/api/values", "UpstreamPathTemplate": "/values", "UpstreamHttpMethod": ["Get"], "ServiceName": "valueService" } ] }

Real-World Use Cases
YARP Use Cases
YARP shines in enterprise-level scenarios, particularly where managing extensive traffic or complex routing is essential. It’s an ideal choice for high-demand environments requiring sophisticated load balancing, multi-cloud support, and advanced configuration capabilities.
Ocelot Use Cases
Ocelot is well-suited for smaller applications or organizations beginning their transition to microservices. Its straightforward configuration and deployment make it perfect for projects that don’t demand the robustness of YARP but benefit from a manageable and effective API gateway solution.
Conclusion
The decision between YARP and Ocelot ultimately depends on your project’s scale and specific requirements. YARP provides advanced control and scalability for enterprise-grade microservices, while Ocelot offers a lightweight and accessible solution for simpler use cases. Both tools empower developers and architects to enhance the efficiency, security, and maintainability of .NET Core microservices architectures, paving the way for future growth and flexibility.

Why my mock object not working truly in xUnit test project?

Arash Yazdanibakhsh — Wed, 14 Dec 2022 10:07:44 +0000

I published my question on StackOverFlow help me please.
https://stackoverflow.com/questions/74791761/why-my-mock-object-not-working-truly-in-xunit-test-project