dotnet-microservices

Trying to setup multiple connected microservices. All commands noted below are executed in the root project directory. This guide currently contains:

Overview
The First Microservice
Timesheetr

Overview

API	Ports	Healthcheck	Swagger
Users API	`51xxx`	Healthcheck	Swagger
Projects API	`52xxx`	Healthcheck	Swagger
TimeEntries API	`53xxx`	Healthcheck	Swagger

SQL	ConnectionString
Users DB	`Server=users-db;Database=UsersDb;User Id=sa;Password=yourStrong(!)Password`
Projects DB	`Server=projects-db;Database=ProjectsDb;User Id=sa;Password=yourStrong(!)Password`
TimeEntries DB	`Server=time-entries-db;Database=TimeEntriesDb;User Id=sa;Password=yourStrong(!)Password`

The First Microservice

Web API

Let's create the first API. The first microservice is all about users. Paste the commands below in the command line to create the project.

dotnet new webapi -o ./src/Users.Api

Setting up Visual Studio Code

After adding some controllers and Swagger configuration (commit 313ec11), the Users API is live on port 5001 (https) and 50010 (http). Running the API is as simple as running the command below.

dotnet run --project ./src/Users.Api/Users.Api.csproj

Using the command line to run the application is an insult to our IDE since it has a button for it. By adding a launch.json and a tasks.json (both generated by Visual Studio Code), we can run the users api by the press of a button (commit 201bfd1).

Using Entity Framework

The Users Api will store user data. We'll be using a combination of Entity Framework and SQL Server. We start by installing the necessary Nuget packages to the solution. Using the Nuget Package Manager extension, installing packages is a breeze. We need the following packages:

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.Design

After configuring EF and setting up the CRUD actions in the controllers, we still need to create the database and migrations. Open a terminal window and paste the commands below.

dotnet tool install --global dotnet-ef
dotnet ef migrations add CreateUsersDB --project ./src/Users.Api/Users.Api.csproj

The first commands installs the EF tools needed to run migrations. If they are already installed, you can skip this command. The second one will migrate the database to a version that corresponds with how it is configured in the code. After running the dotnet ef migrations-command, notice there is a Migrations-folder added to the project.

After verifying the migration looks good, It is time to actually update the database scheme. Running all migrations can be done using the command below.

dotnet ef database update --project ./src/Users.Api/Users.Api.csproj

Commit 9a3f636

Docker

To develop using Docker a lot easier, it's recommended to install the Docker extension for Visual Studio Code.

Also because of some https issues, the following commands need to be run beforehand.

# Mac
dotnet dev-certs https -ep ${HOME}/.aspnet/https/aspnetapp.pfx -p Password
dotnet dev-certs https --trust

# Windows
dotnet dev-certs https -ep %USERPROFILE%\.aspnet\https\aspnetapp.pfx -p Password
dotnet dev-certs https --trust

# Linux
dotnet dev-certs https -ep ${HOME}/.aspnet/https/aspnetapp.pfx -p Password
# dotnet dev-certs https --trust is only supported on macOS and Windows. You need to trust certs on Linux in the way that is supported by your distribution.

Dockerize Users API

The first step is creating a Dockerfile. This is easy using Visual Studio Code. Use the Add Dockerfile to Workspace-command to start the wizard. Because the Users API is the only thing running in this container, we map the ports the the default http (80) and https (443) ports.

Verify the image by building and running it.

docker-compose build
docker-compose up

Debugging is possible using a new Visual Studio Code configuration. Since the API is running in Docker, it is impossible to access the local SQL Server so no request will currently succeed. The only way forward is Dockerize the SQL Server.

Commit 2eed146

Dockerize SQL Server

To let the Users API communicate with SQL Server, we also need to create a container. By quickly adding some lines in the docker-compose.yml we have a container ready (commit 69db2c4).

Normally the EF migrations run on startup. Because of the Docker setup, it is possible the SQL container isn't ready yet at the moment the API setups. To fix this quick and dirty, I've added a migration controller. By using this controller it is possible to migrate the database manually (commit 8fbcd38).

At this point we have a working SQL container. There is only one problem with it. If the container gets deleted, we lose all our data. To counter this, we will mount a volume to the container. This was the data will get saved on our host machine in stead of the container (commit 8abf5ca).

Timesheetr

The application we're creating is a timesheet application. In our application we have three aggregate roots: Users, Projects, and TimeEntries. Every day a User must complete a timesheet with TimeEntries to record on which Projects (s)he has worked today. Not every User can contribute to every Project, they need to be added.

Users

The Users microservice is the service we've just created. Except for some port changes, this service is already finished. This service only manages the users object. Some simple CRUD actions are enough.

Projects

The Projects microservice manages projects on which users can record time. This service will not only do some simple CRUD-actions, but should also add Users to a project. Some communication to the Users service will be needed. A first CRUD setup (without communication to other services) can be found in commit e85f2d0.

Time Entries

TimeEntries will consist of a user, a project, and some time data. This service needs to communicate with both the users and the projects service. A first CRUD setup (without communication to other services) can be found in commit 0273ce1.

dienomb / dotnet-microservices Goto Github PK