Migrate to Kubernetes

This is the hands-on repository for the blog entry Migrating to Kubernetes.

The repository covers the complete process of migration from bare metal to an advanced deployment with Helm on Kubernetes. Since environments (database, server, client) can now be generated on the fly, we also use this feature to build a separate environment for each merge request and display it in Gitlab as Review App. Read the article for detailed instructions!

Scenario

The exemplary single page application is written with Angular and has a NodeJS backend. It is built in a classic 3-tier-architecture, consisting of Client Tier (Client), Logic Tier (Server) and Data Tier (DB).

The plan was to create a CI/CD pipeline for this exemplary application. The project ought to be deployed on Kubernetes and Gitlab CI had to be used as CI tool. To manage Kubernetes the package manager Helm, respectively Helm-Charts, are used.

Tests will be executed automatically including a readyness probe. Multiple internal test environments should be created: an internal test environment identical to the current live state of the application (staging), an internal test environment for the master branch (dev), and an internal test environment for each feature branch (/feature). This is intended to create a special Developer Experience having a separate environment for production, staging and each review branch. This way, each new feature can be viewed individually and it is possible to see which effects each feature has on the application as a whole. New features can be presented to third parties, such as customers, in their own review app.