\n10. Publishing images to Docker registries

\n10.1 Why bother with Registries?

\n10.2 Available Registries

\n10.3 Publishing an image

\n10.4 Exercise - Publish your services on Docker Hub

\n10.5 Exercise solution

",{"_355":356,"_43":44,"_47":48,"_45":46,"_65":66,"_357":358,"_437":353},"previewContent","

\n Introduction\n
- \n What this book is not\n
- \n Prerequisites\n
- \n How to read this book\n
- \n Tools you need\n
- \n Source code\n
\n
\n 1. Why microservices?\n
- \n 1.1 What are they?\n
- \n 1.2 Microservices induce complexity\n
\n
\n 2. Microservices as seen from the client\n
- \n 2.1 HTTP\n
- \n 2.2 Payloads\n
- \n 2.3 Do you speak JSON\n
- \n 2.4 Client types\n
- \n 2.5 Manual testing\n
- \n 2.6 Exercise - Invoke a microservice manually\n
- \n 2.7 Exercise solution\n
\n
\n 3. Microservices server-side\n
- \n 3.1 About coding the server\n
- \n 3.2 There comes .NET Core\n
- \n 3.3 Introduction to ASP.NET Core\n
- \n 3.4 ASP.NET Core Web API\n
- \n 3.5 Exercise - Create a train scheduling service\n
- \n 3.6 Exercise solution\n
\n
\n 4. Database access using Entity Framework Core\n
- \n 4.1 Introduction to Entity Framework Core\n
- \n 4.2 Scaffold your code and save time\n
- \n 4.3 Exercise - Extend the train scheduling service\n
- \n 4.4 Exercise solution\n
\n
\n 5. Adding UI server-side\n
- \n 5.1 To UI or not to UI\n
- \n 5.2 UI scaffolding with Visual Studio\n
- \n 5.3 Exercise - Add a UI to the train scheduling service\n
- \n 5.4 Exercise solution\n
\n
\n 6. Invoking a service from .NET and .NET Core\n
- \n 6.1 .NET Clients\n
- \n 6.2 Demo: consume the microservice from a WPF client\n
\n
\n 7. Invoking a service from another service\n
- \n 7.1 Same but different but same\n
- \n 7.2 Exercise - Create a ticketing service\n
- \n 7.3 Exercise solution\n
- \n 7.4 Exercise - Consume the scheduling service from the ticketing service\n
- \n 7.5 Exercise solution\n
- \n 7.6 Integration testing of the microservices created\n
\n
\n 8. Introduction to containers and Docker\n
- \n 8.1 Why do we need containers?\n
- \n 8.2 Virtualization could have been the panacea\n
- \n 8.3 Why containers perform better\n
- \n 8.4 Containers in practice\n
- \n 8.5 How containers solve problems\n
- \n 8.6 Containers as microservice hosts\n
- \n 8.7 Exercise - Run a Docker container\n
- \n 8.8 Exercise solution\n
\n
\n 9. Creating and running Docker images\n
- \n 9.1 How images are built\n
- \n 9.2 An ASP.NET Core Dockerfile\n
- \n 9.3 Multi-stage Dockerfiles\n
- \n 9.4 Exercise - Build and run your own Docker image\n
- \n 9.5 Exercise solution\n
\n
\n 10. Publishing images to Docker registries\n
- \n 10.1 Why bother with Registries?\n
- \n 10.2 Available Registries\n
- \n 10.3 Publishing an image\n
- \n 10.4 Exercise - Publish your services on Docker Hub\n
- \n 10.5 Exercise solution\n
\n
\n 11. Executing linked microservice containers in a Docker Swarm\n
- \n 11.1 The need for orchestrators\n
- \n 11.2 Orchestrators commonly used with Docker\n
- \n 11.3 Docker Swarm concepts\n
- \n 11.4 Creating a swarm\n
- \n 11.5 Configuring a stack\n
- \n 11.6 Deploying and managing a stack on a swarm\n
- \n 11.7 Exercise - Run the two services in a Docker Swarm\n
- \n 11.8 Exercise solution\n
- \n 11.9 Integration testing of the stack created\n
\n
\n 12. Microservice clusters using Docker Swarm\n
- \n 12.1 Demo: load-balancing the stack\n
\n
\n The Learn collection\n

\n\n\n\n

Introduction

\n\n

What this book is not

\n\n

I made my best to keep this book small, so that you can learn microservices quickly without getting lost in petty details. If you are looking for a reference book where you’ll find answers to all the questions you may have within the next 4 years of your microservices practice, you’ll find other heavy books for that.

\n\n

My purpose is to swiftly provide you with the tools you need to code your first microservice application using Docker and ASP.NET Core, then be able to look for more by yourself when needed. While some authors seem to pride themselves in having the thickest book, in this series I’m glad I achieved the thinnest possible book for my purpose. Though I tried my best to keep all of what seems necessary, based on my 16 years experience of teaching .NET.

\n\n

I assume that you know what microservices are and when to use them. In case you don’t, read the following Why microservices chapter.

\n\n

Prerequisites

\n\n

In order for this book to meet its goals, you must:

\n\n

Have basic experience creating applications with C#
Know what a Web application is

\n\n

How to read this book

\n\n

This book’s aim is to make you productive as quickly as possible. For this we’ll use some theory, several demonstrations, plus exercises. Exercises appear like the following:

\n\n\n\n

In code samples, a backslash is used in order to wrap long lines. Do not type theses backslashes when you copy code from the book.

\n\n

Tools you need

\n\n

The only tools you’ll need to work through this book are the following:

\n\n

Windows 10
Visual Studio 2017 (Community, Professional or Enterprise)
Docker 17.09 or higher (Community)

\n\n

When installing Visual Studio, make sure you select the ASP.NET and .NET Core components.

\n\n

Source code

\n\n

All of the source code for the demos and do-it-yourself solutions is available at \nhttps://bitbucket.org/epobb/microservicesexercises

\n\n

It can be downloaded as a ZIP file, or if you installed GIT you can simply type:

\n\n

git clone https://bitbucket.org/epobb/microservicesexer\\\ncises.git\n

\n\n\n\n\n\n\n

\n1. Why microservices?

\n\n

If you’re in a hurry, you can safely skip this chapter and head straight to\nthe Microservices as seen from the client chapter. This Why microservices chapter\nis there for those that want to know why microservices should be used.

\n\n

\n1.1 What are they?

\n\n

Microservices are an architectural solution to several challenges faced by modern software. Among other things, they help solve either of the following requirements:

\n\n

over time there may be several front-ends for similar business processes (thick clients, SPAs, mobile applications, IoT devices, …), some of which unpredicted;
applications may be hosted on-premises or in a Cloud infrastructure;
applications should be resilient: they should remain available when outages occur over parts of its components;
applications should be able to scale up: when demand is high it should be possible to run them over several machines in order to handle each request faster;
applications should allow for replications, i.e., having duplicates across different machines or data centers so that computing power outage doesn’t make them unavailable;
large teams working on the same application should be able to work as independently as possible;
future applications are likely to interact with a part of the application you are building.

\n\n

In order to achieve such goals, microservices’ architectures split an application into smaller blocks. If you’ve been architecting applications correctly you probably already separated your application code in projects, but that still makes for one big monolithic application.

\n\n

A monolithic application bundles its pieces together into a single unit. that cannot easily meet the requirements expressed above. Here’s what a fictitious monolithic application could look like:

\n\n\n

\n\n\n

On the positive side, a monolithic application is easy to code and deploy.

\n\n

In order to meet the requirements expressed earlier, a microservice architecture splits the application into several services. The following could be a microservice architecture corresponding to the monolithic application shown above:

\n\n\n

\n\n\n

How you split the functionality can be debated. It is generally good practice to make sure each service meets a functional need of its own.

\n\n

\n1.2 Microservices induce complexity

\n\n

Services are likely to depend on each other; which doesn’t appear in the schema above. For instance, considering the application above an order would most probably reference a client and several products. Which brings some questions like how do services reference each other? There are answers for that depending on what needs to be achieved. For instance there may be a service-discovery service, or a mediation layer.

\n\n

This is just an example of the complexity that a microservice architecture brings. We’ll see more later but the scope of this book is not to cover it all, especially since there are potentially many answers to each problem.

\n\n

What I want you to understand is that a microservice architecture is nothing simple. As the needs grow, the complexity will grow faster than in an equivalent monolithic architecture. My advice: use microservice architecture when you need to meet requirements like the ones listed at the beginning of that chapter. Otherwise keep with monolithic architectures, be it a service-based monolithic architecture.

\n\n

Anyway, my point is about complexity not impossibility. There’s a lot of awesome tooling out there today that makes a microservice architecture much easier to code, assemble and deploy. We’ll see some of them in this book.

\n\n\n

\n2. Microservices as seen from the client

\n\n

A microservice architecture is made of services. Those services handle HTTP communication that request or send data. In case you’re familiar with this, you can head straight to the exercise. Otherwise, let’s review the fundamentals so you can build your knowledge over solid basis.

\n\n

\n2.1 HTTP

\n\n

Services, whether they are microservices or not, are usually called over HTTP. Here’s the schema of an HTTP request:

\n\n\n

\n\n\n

A client sends a request to a server. The client may be a mobile application, an IoT object, a SPA application (Angular, React, …) or whatever you please - including another service. By the way, services will be calling each other in a microservice architecture. The server is what you code, and it contains the business logic.

\n\n

HTTP in itself is pretty simple. It’s a text-based protocol where the client:

\n\n

opens a TCP connection to the server;
sends data (the request, see below) to the server;
receives data (the response, see below) from the server;
closes the connection.

\n\n

The request is made of two parts: headers and possibly data, separated by a blank line (did I tell you HTTP was simple?). It may look like that:

\n\n

GET /index HTTP/1.1\nHost: www.mysite.com\n

\n\n\n\n

In the above example there is one single header (Host) and no data. The first line states a verb, a URL, and the version of the HTTP protocol being used. The verb corresponds to what the client wants to do, for instance:

\n\n

GET is used to fetch data without modifying server data
POST is used to update server data
DELETE is used to - ahem! - delete server data, or at least request deletion.

\n\n

GET requests do not contain a data payload in the request since the headers and URL are sufficient, but the other types of requests contain data. Here’s an example POST request, but an UPDATE request would look similar:

\n\n

POST http://server:51426/api/TrainSchedules HTTP/1.1\nContent-Type: application/json\nHost: server:51426\nContent-Length: 94\n\n{\"departureTime\":\"2018-04-03T21:56:48.6711219+01:00\",\"d\\\nistanceKm\":1054,\"destination\":\"Berlin\"}\n

\n\n\n\n

The payload here is JSON, a widely used format for services as we’ll see very soon.

\n\n

The server processes the request and returns a response using the same TCP connection that was used for the request. That TCP connection is then closed. Here’s an example response:

\n\n

HTTP/1.1 200 OK\nContent-Type: text/html\nContent-Length: 81\n\n<html>\n    <body>\n        <p>Welcome to our site</p>\n    </body>\n</html>\n

\n\n\n\n

Just like the request, the response is made up of two parts: headers and possibly data, separated by a blank line. Plus a first line that confirms the protocol and provides a status code and message. The status code’s first digit is the most important: 2 means everything was alright, 4 means there was a problem processing the request (you know, that ubiquitous 404 Not found).

\n\n

There can be many more headers. In the above example you can see the two headers that are commonly used in responses. Content-Type tells the client how the data (what comes below the blank line) should be interpreted. It’s a MIME type. MIME types are well established. Though there are many possible MIME types, only some of them are used for services.

\n\n

\n2.2 Payloads

\n\n

We are focusing on services, right? A (micro)service is mostly used for computer-computer interaction, so it needs a MIME type that’s appropriate for its payloads (the data that is sent in requests and received in responses).

\n\n

Extensive work from the OASIS consortium in order to standardize services at the beginning of the century (wow, that sounds so vintage) established the XML format for payloads; the consortium even wrapped it into the SOAP standard (which is made of XML). So services used the text/xml MIME type for quite a while, and many still do.

\n\n

Then came SPA applications (Angular, React and the likes), which became widely used endpoints for user consumption of services. Those applications run in the browser using JavaScript that happens to be slow at XML processing. Sure, JavaScript can parse and produce XML, but it’s a painful process for it. What JavaScript can easily parse and produce is its own format: JSON. Since JSON is as easily read by humans as XML and less verbose, it quickly became the norm for services.

\n\n

So that’s where we stand today: (micro)services use mainly JSON as their payload format for requests and answers, plus XML sometimes.

\n\n

\n2.3 Do you speak JSON

\n\n

If you aren’t familiar with JSON, don’t worry: it can be learnt very quickly. Think of it as anonymous C# objects. For instance, consider the following declaration:

\n\n

var myObject = new() {\n  Foo = \"bar\",\n  Value = 5.5,\n  Really = true\n}\n

\n\n\n\n

This anonymous object instantiation in C# is almost JSON. Let’s replace the equal signs with semicolons, and wrap property names with quotes. This is what we get:

\n\n

var myObject = new() {\n  \"Foo\": \"bar\",\n  \"Value\": 5.5,\n  \"Really\": true\n}\n

\n\n\n\n

We’re almost there. We currently have an hybrid C#-JSON code. Now let’s remove the variable declaration and call to new since they don’t describe a value (they describe what we want to do with the value). This is what we get:

\n\n

{\n  \"Foo\": \"bar\",\n  \"Value\": 5.5,\n  \"Really\": true\n}\n

\n\n\n\n

Guess what? This is valid JSON. It simply represents the data for an object that has 3 properties.

\n\n

Now suppose you want to describe an array of object values: all you need to do is use brackets around them. And line returns count as spaces. Yes, all just like C#. Here’s one such array:

\n\n

[\n  { \"Foo\": \"bar\", \"Value\": 5.5, \"Really\": true },\n  { \"Foo\": \"tball\", \"Value\": 2.3, \"Really\": false }\n]\n

\n\n\n\n

That’s almost all there is to JSON. I could show an example of a complex property value, but that would be just recursive use of the first sample and I’ll spare you that.

\n\n

\n2.4 Client types

\n\n

Once a (micro)service is published and listens over HTTP (that’s what we’ll do in this book), many different types of clients can consume it:

\n\n

heavy clients like UWP, WPF, Windows Forms;
browsers using SPA applications like Angular, React, Vue.js, Knockout or jQuery, or even plain JavaScript
mobile applications;
IoT devices, e.g. your fridge ordering milk when it senses you’ll soon be running out of milk;
other services, which makes for a services-based architecture;
utilities like command-line applications.

\n\n

In this book you’ll use WPF, command-line and services as the clients of your services.

\n\n

\n2.5 Manual testing

\n\n

Once you start building a microservice, you’ll want to test it. A microservice usually has no user interface, hence testing requires you to send HTTP requests and check for the response.

\n\n\n\n

An obvious tool is your browser. When you type a URL in the address bar, your browser issues an HTTP GET request to that URL. Downside: you have no control over the headers it sends. Which means that you really need another tool.

\n\n

Good news: there are many tools out there that will enable you to issue HTTP requests like Fiddler or Postman. You can go on and use any tool you like really; for simplicity sake in this book we’ll use the Invoke-WebRequest command that is part of PowerShell since it’s already present on your Windows machine. If you’re using a Linux-based machine, you can use the curl command. Even PowerShell accepts the curl command (and maps it to its Invoke-WebRequest command).

\n\n

Suppose you want to make the following HTTP request: GET http://someserver/api

\n\n

You could issue the following PowerShell command:

\n\n

Invoke-WebRequest http://someserver/api\n

\n\n\n\n

This is the actual HTTP request that gets issued:

\n\n

GET http://someserver/api HTTP/1.1\nUser-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; f\\\nr-FR) WindowsPowerShell/5.1.16299.98\nHost: someserver\nProxy-Connection: Keep-Alive\n

\n\n\n\n

You aren’t required to provide other parameters since GET is the default HTTP verb used by the Invoke-WebRequest command. The response is provided in full details, but if you are interested only in the data payload, you may get the Content property from the result:

\n\n

(Invoke-WebRequest http://someserver/api).Content\n

\n\n\n\n

When you need to use a verb other than GET you’ll surely need to send data. The Invoke-WebRequest command allows you to provide your data using the Body parameter and the verb to be used is passed through the Method parameter.

\n\n

Invoke-WebRequest -Method POST -Body '{\"foo\":\"bar\",\"val\\\nue\":10}' -Header @{\"Content-Type\"=\"application/json\"} h\\\nttp://someserver/api\n

\n\n\n\n

Note that in the command above we’re also sending a Content-Type header in order to tell the server that we’re using JSON as the payload data format - this depends on the specific API you call.

\n\n

This is the actual HTTP request that gets issued when the command above is executed:

\n\n

POST http://someserver/api HTTP/1.1\nContent-Type: application/json\nUser-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; f\\\nr-FR) WindowsPowerShell/5.1.16299.98\nHost: someserver\nContent-Length: 24\n\n{\"foo\":\"bar\",\"value\":10}\n

\n\n\n\n

Let’s try this on a real-world example.

\n\n

\n2.6 Exercise - Invoke a microservice manually

\n\n\n\n

https://en.wikipedia.org/w/api.php?action=query&format=\\\njson&prop=info&list=allpages\n

\n\n\n\n

\n2.7 Exercise solution

\n\n

From a PowerShell command-line, type the following and check the returned Content:

\n\n

Invoke-WebRequest \"https://en.wikipedia.org/w/api.php?a\\\nction=query&format=json&prop=info&list=allpages\"\n

\n\n\n\n

Make sure the HTTP response status code is 200 OK.

\n\n

[Produces(\"application/json\")]\n[Route(\"api/NextDeparture\")]\npublic class NextDepartureController : Controller\n{\n}\n

\n\n\n\n

Replace it with the following code:

\n\n

[Produces(\"application/json\")]\n[Route(\"api/NextDeparture\")]\npublic class NextDepartureController : Controller\n{\n  public IActionResult GetNext()\n  {\n    return Ok(new {\n      DepartureTime = DateTime.Now.AddMinutes(50),\n      Number = \"5423\",\n      Destination = \"Paris\"\n    });\n  }\n}\n

\n\n\n\n

From the Debug menu click Start Without Debugging\n
Point your browser to the following URL (port number varies):

\n\n

http://localhost:51426/api/NextDeparture

\n\n

From a PowerShell command-line, type the following and check the returned Content:

\n\n

Invoke-WebRequest http://localhost:51426/api/NextDepart\\\nure\n

\n\n

The Learn collection allows developers to self-teach new technologies in a matter of days.

\n\n

Published books

\n\n

To be published

\n\n

Learn Docker
Learn Kubernetes
Learn Unit Testing

\n\n

\n\n","tocStructure",[359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436],{"_76":77,"_43":78,"_70":-5,"_79":80,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":86,"_70":-5,"_79":87,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":92,"_70":-5,"_79":93,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":95,"_70":-5,"_79":96,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":98,"_70":-5,"_79":99,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":101,"_70":-5,"_79":102,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":104,"_70":-5,"_79":105,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":108,"_70":-5,"_79":109,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":111,"_70":-5,"_79":112,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":114,"_70":-5,"_79":115,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":118,"_70":-5,"_79":119,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":121,"_70":-5,"_79":122,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":124,"_70":-5,"_79":125,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":127,"_70":-5,"_79":128,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":130,"_70":-5,"_79":131,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":133,"_70":-5,"_79":134,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":136,"_70":-5,"_79":137,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":139,"_70":-5,"_79":140,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":143,"_70":-5,"_79":144,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":146,"_70":-5,"_79":147,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":149,"_70":-5,"_79":150,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":152,"_70":-5,"_79":153,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":155,"_70":-5,"_79":156,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":158,"_70":-5,"_79":159,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":161,"_70":-5,"_79":162,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":165,"_70":-5,"_79":166,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":168,"_70":-5,"_79":169,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":171,"_70":-5,"_79":172,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":174,"_70":-5,"_79":175,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":177,"_70":-5,"_79":178,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":181,"_70":-5,"_79":182,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":184,"_70":-5,"_79":185,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":187,"_70":-5,"_79":188,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":190,"_70":-5,"_79":191,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":193,"_70":-5,"_79":194,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":197,"_70":-5,"_79":198,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":200,"_70":-5,"_79":201,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":203,"_70":-5,"_79":204,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":207,"_70":-5,"_79":208,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":210,"_70":-5,"_79":211,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":213,"_70":-5,"_79":214,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":216,"_70":-5,"_79":217,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":219,"_70":-5,"_79":220,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":222,"_70":-5,"_79":223,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":225,"_70":-5,"_79":226,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":229,"_70":-5,"_79":230,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":232,"_70":-5,"_79":233,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":235,"_70":-5,"_79":236,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":238,"_70":-5,"_79":239,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":241,"_70":-5,"_79":242,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":244,"_70":-5,"_79":245,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":247,"_70":-5,"_79":248,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":250,"_70":-5,"_79":251,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":253,"_70":-5,"_79":254,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":257,"_70":-5,"_79":258,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":260,"_70":-5,"_79":261,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":263,"_70":-5,"_79":264,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":266,"_70":-5,"_79":267,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":269,"_70":-5,"_79":270,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":272,"_70":-5,"_79":273,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":276,"_70":-5,"_79":277,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":279,"_70":-5,"_79":280,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":282,"_70":-5,"_79":283,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":285,"_70":-5,"_79":286,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":288,"_70":-5,"_79":289,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":291,"_70":-5,"_79":292,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":295,"_70":-5,"_79":296,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":298,"_70":-5,"_79":299,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":301,"_70":-5,"_79":302,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":304,"_70":-5,"_79":305,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":307,"_70":-5,"_79":308,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":310,"_70":-5,"_79":311,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":313,"_70":-5,"_79":314,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":316,"_70":-5,"_79":317,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":319,"_70":-5,"_79":320,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":322,"_70":-5,"_79":323,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":85,"_43":326,"_70":-5,"_79":327,"_72":81,"_88":-5,"_89":-5,"_90":-5},{"_76":77,"_43":329,"_70":-5,"_79":330,"_72":81,"_88":-5,"_89":-5,"_90":-5},"publicChapterContent","nextChapter","sections",[419,420,421,422,423],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\n10. Publishing images to Docker registries

\n10.1 Why bother with Registries?

\n10.2 Available Registries

\n10.3 Publishing an image

\n10.4 Exercise - Publish your services on Docker Hub

\n10.5 Exercise solution

Table of Contents

Introduction

What this book is not

Prerequisites

How to read this book

Tools you need

Source code

\n1. Why microservices?

\n1.1 What are they?

\n1.2 Microservices induce complexity

\n2. Microservices as seen from the client

\n2.1 HTTP

\n2.2 Payloads

\n2.3 Do you speak JSON

\n2.4 Client types

\n2.5 Manual testing

\n2.6 Exercise - Invoke a microservice manually

\n2.7 Exercise solution

\n3. Microservices server-side

\n3.1 About coding the server

\n3.2 There comes .NET Core

\n3.3 Introduction to ASP.NET Core

\n3.4 ASP.NET Core Web API

Project structure

Controllers, actions and routes

Complex return types

\n3.5 Exercise - Create a train scheduling service

\n3.6 Exercise solution

\n4. Database access using Entity Framework Core

\n4.1 Introduction to Entity Framework Core

\n4.2 Scaffold your code and save time

\n4.3 Exercise - Extend the train scheduling service

\n4.4 Exercise solution

\n5. Adding UI server-side

\n5.1 To UI or not to UI

\n5.2 UI scaffolding with Visual Studio

\n5.3 Exercise - Add a UI to the train scheduling service

\n5.4 Exercise solution

\n6. Invoking a service from .NET and .NET Core

\n6.1 .NET Clients

\n6.2 Demo: consume the microservice from a WPF client

\n7. Invoking a service from another service

\n7.1 Same but different but same

\n7.2 Exercise - Create a ticketing service

\n7.3 Exercise solution

\n7.4 Exercise - Consume the scheduling service from the ticketing service

\n7.5 Exercise solution

\n7.6 Integration testing of the microservices created

\n8. Introduction to containers and Docker

\n8.1 Why do we need containers?

The deployment hassle

Continuous integration

Upgrading common dependencies

DevOps

\n8.2 Virtualization could have been the panacea

\n8.3 Why containers perform better

\n8.4 Containers in practice

Containers

Some vocabulary: containers and images

Running a simple image

Running a server image

\n8.5 How containers solve problems

\n8.6 Containers as microservice hosts

\n8.7 Exercise - Run a Docker container

\n8.8 Exercise solution

\n9. Creating and running Docker images

\n9.1 How images are built

\n9.2 An ASP.NET Core Dockerfile

\n9.3 Multi-stage Dockerfiles

\n9.4 Exercise - Build and run your own Docker image

\n9.5 Exercise solution

\n10. Publishing images to Docker registries

\n10.1 Why bother with Registries?

\n10.2 Available Registries