Containerizing API Gateways using Alpine Base Image

In the previous article, we've learned how to containerize an API Gateway built using ASP.net Core and Ocelot. Today, we'll explore the cool things that Alpine Linux images bring when containerizing microservices and API gateways.

Articles in the Series

This article belongs to a series of articles that explains the importance of API gateways and how to build them using ASP.net Core. If you're interested to learn more about API gateways, it might be a good idea to spend some time reading the articles listed below.

Abstract

In the previous article, we've identified several areas of improvement from the approach we've used for containerizing our API gateway and downstream services, among them is the size (294+ MB) of the container images produced by Windows Nano Server. The size of containers might not seem to be a big deal but it has impact to the availability and maintenance cost of your software.

Pay attention to the size of the container images from the previous article (294+ MB).

Cons of Using Bigger Container Images

  • Slower transfer from your office to your container registry.
  • Slower transfer from container registry to web server.
  • Higher cost of image storage and backups.

The factors listed above is irrelevant if your application don't really require high availability. However, the effect of these factors start to bite back for large scale applications especially for containerized apps that need to be replicated in huge numbers (100 container instances for a single image?)

To address the issue, we'll be using microsoft/dotnet-nightly:2.1-runtime-alpine image for containerizing our API gateway and dowstream services. The size of an Alpine Runtime image is around 88 MB which is quite cool and efficient though it still lags behind NodeJS (88 mb with express server code).

Alpine Linux Base Image

Reducing the size of our container images is not really that difficult, all we have to do is to change two lines in the dockerfiles that we've used from the previous article. If you are interested to test the alpine images on your machine, you might want ot clone this repository from GITHUB.

Step 1: Update Dockerfiles.

Step 2: Containerize API Gateway and Downstream Services

Step 3: Verify Build Results

Pay attention to the 50% reduction in size of our container images (294 down to 131+ in megs). Again, if your business is small, the return of investment in implementing this tiny detail is quite low. However, if you're spending 10k-100K USD a month for storing container images, this tiny change of base-image can save you 5k-50k (50%) in operational cost.

Step 4: Run your containers to test if they still work

Testing Container Endpoints

To verify that all endpoints are working on your machine (Damn), you can open the endpoints listed below:

Conclusion

In this article, we've addressed the size of docker images produced by Windows Nano Server by replacing them with Alpine Base images dedicated for ASP.net core runtime. In the next article, we'll try to remove the pain of manually setting up a DNS record through the use of a compose file and Docker networks.

Related Articles


Get Razer from Amazon!


Comments

  1. If there is an error in the .net runtime optimization service - fixingerror.com, then it becomes troublesome to launch apps or play games on your desktop. In case none of the above methods work in fixing the error, you can always temporarily deactivate the .Net optimization service. Doing this will not affect your NET framework but will prompt you to do a few repairs to it.

    ReplyDelete

Post a Comment

Popular posts from this blog

Microservices: Picking the .NET Framework for your containerized applications.

API Gateway in a Nutshell

API Gateway: Response Aggregation with Ocelot and ASP.net Core

Security: HTTP headers that expose web application / server vulnerabilities