Hosting Containerized Cloud-Native Stacks (Kubernetes) on GCP Marketplace

Google Cloud Marketplace is the fastest way for the customers to get started on Google Cloud Platform (GCP). GCP Marketplace offers ready-to-go development stacks, solutions, and services to accelerate development so that the users can spend less time installing and more time developing the application.

Why Google cloud marketplace?

• Deploy in a few clicks.
• Production-ready solutions. 
• Augment platform capabilities. 
• Streamlined billing.
• Built using Deployment Manager. 
• Security update notifications.

Steps to place the application on Google cloud marketplace:

The technical integration of the overall procedure is shown in the below diagram.

The main seven steps need to be followed while placing an application to the marketplace are described below.

Step 1: Fetch the helm chart

Download the helm chart of the application from its repository or write the required helm chart of the application. The helm chart mainly contains values.yaml, chart.yaml, and templates files.

The above diagram shows the sample tree structure of the helm chart. Click here to get to know more about helm charts.

Step 2: Create the initial schema

Write the schema.yaml file for the application because a schema defines the general structure to which files should adhere. The general structure of the schema.yaml file.

Step 3: Add an application descriptor

In the template folder of the helm chart, add a file named application.yaml with the contents shown below. The file mainly describes the application and is used in the UI.

Step 4: Write the Dockerfile

Container images are typically built using a Dockerfile and the docker build command-line tool. It is better to publish the Dockerfile and container build instructions in the public repository for the application. This enables customers to modify or rebuild the images, which is sometimes necessary to certify images for enterprise production environments. If the application image depends on a base image such as Debian, or a language run time image such as Python or OpenJDK, then one must use one of GCP Marketplace's certified container images.

Build the Dockerfile using the following command

sudo docker build -t  mongodb . 

Step 5: Push the Docker image to the registry

Container Registry repository must have the following structure:

• The Application's main image must be in the root of the repository. The application's image should be in gcr.io/boxbe00034/mongodb format.
• Deployer folder contains the image to be deployed.
• If your application uses additional container images, each additional image must be in its own folder. For example, if your application requires an Ubuntu 16.04 image, add the image to gcr.io/boxbe00034/mongodb/ubuntu16_04.
• All the images in your application must be tagged with the minor version using semantic versioning of the application.  

Push the built application to the remote GCR (Google Container Registry) so that the application running in the cluster can access the image. The command to push the application to the container registry is :

docker --push gcr.io/boxbe00034/mongodb : 4.0

Once you push the application to the registry, the image registry looks as shown below:

Step 6: Submitting the application

• Enable Partner Portal 
• Add your solution to partner portal:

In Partner Portal, you must add marketing information about your solution, and set up the product versions that you want to list.

• Submit solution for review

Step 7: Getting the GCP Marketplace security check

Once you submit the solution, automatically through the GCP Marketplace platform testing and reviewing operations will take place. Automated testing includes security scanning, functional testing, and integration testing. This platform also provides the application’s end-to-end customer experience, including marketing materials, installation flow, security, and user guide.

Summary

When the application is supposed to publish in the marketplace, it should undergo many important steps, which include, building the image, test, deploy and reviewed by the marketplace teams. This document describes the most important steps to be followed while on boarding an application to the GCP marketplace. This procedure can also be followed for publishing applications in other cloud and container marketplaces such as AWS Marketplace, Azure Marketplace, IBM Cloud Marketplace, Oracle Cloud Marketplace and so on, with minimal changes on the platform, programming and operational dependencies respect to marketplace terms and conditions. 

For building custom based cloud-native stack development & integration, hosting private or public marketplace repositories for existing applications and newly build cloud-native stacks, if you require more details about cloud-native microservices & cloud-native stack transformation, please refer to Yobitel Communications. www.yobitel.com. 

 

Orchestrating Zero-Down Time Blue-Green Deployments for Production Workloads in Kubernetes

This article is mainly concerned about the most trending word in the cloud-native world that is blue-green deployment.

Blue-green deployment is a technique that reduces downtime and risk by running two similar production environments called Blue and Green and among those two, only one of the environments is active and it is serving all production traffic. For example, if Green is active then blue is idle.

When you are updating the application or releasing the new version of the software, then deployment and the final stage of testing takes place in the idle environment. Once you have deployed and fully tested the software in the idle environment, you switch the router, so that now all incoming requests go to idle instead of active. Idle is now active, and active environment is idle.

This technique can eliminate downtime due to app deployment and also it reduces risk. If something unexpected happens with your new version on an active environment, you can immediately roll back to last version by switching back to the idle environment. The actual procedure of blue-green deployment is schematically explained in the below figure.

 

Blue-green deployment provides you to achieve the following goals by eliminating risks that are witnessed in the deployment. 

Possibility of errors is less:

When we are doing online bank transactions, sometimes we will be surprised with the error message saying “bank server is under maintenance” or similar. But with blue-green deployment, you never have to worry about this maintenance screen. Up-gradation is fast and the application can be deployed with the next click on the updation of the software. It would provide near-zero downtime and would present easy rollback capabilities. 

Testing the production environment:

With the blue-green deployment, it is easy to ensure the pre-production environment is as close to the production environment and which is not only important but essential too. The user can test any application while it is disconnected from the main traffic. The team has the eligibility to even load the test if they desire too.

Helps to maintain consistent traffic:

In any e-commerce enterprise, banking sector or any major enterprise where the traffic is high and maintaining the consistent traffic is essential. Blue-green deployment assures that your traffic never stops. Also makes sure that customers can place their order just fine without disruption, which means that the employees overseas continue to do their job without any interruption. The fundamental idea behind blue-green deployment is to shift traffic between two identical environments that running differently in different applications.

Easy recovery:

You might witness times where you would get introduced to bugs and viruses. We can either spend a lot of money on its recovery or we can inevitably find them and recover them. The blue-green deployment helps us to have our older and more stable version of our applications to come back online at a moment’s notice by evading the pain to roll back a deployment.

Example of Blue-Green deployment:

Here, in this example, the Nginx image version 1.10 is updated to 1.11. Let the Nginx image with version 1.10 is in a blue environment, and it is active. The service.yaml file of the application is shown below:

The service pods of the Nginx image with 1.10 are active and are running

 

The green environment is idle and the Nginx image is upgraded to 1.11 version. Once the up-gradation is complete, make the green environment as active and blue as idle. The service.yaml file for the application is updated with the new version. The service pods of the 1.11 version are active and running.

Summary:

Deployments are one of the most important parts of the software development life cycle, therefore all the activities involved should thoroughly be researched and tested to ensure that they are a perfect fit for your system architecture and business. Blue-green deployments need two identical sets of hardware, and that hardware carries added costs and overhead without actually adding capacity or improving utilization. Blue-green deployments are usually utilized for consumer-facing applications and the applications which have critical uptime requirements. The new code is delivered to the inactive environment, where it is completely tested.

For more details about cloud-native microservices & cloud-native stack transformation, please refer Yobitel Communications. www.yobitel.com/cloud-native-services.