DEV Community: chrisedrego

4 easy steps to setup AWS WorkSpaces (Screenshot’s included)

chrisedrego — Thu, 01 Jul 2021 18:55:36 +0000

A simple 4 steps guide to set up AWS WorkSpaces.

What is AWS WorkSpaces?

AWS WorkSpaces is a desktop as a service offering from AWS. Users can connect from PC, Mac Desktops computers by downloading the clients or use the web clients. AWS WorkSpaces is only available for specific regions. AWS WorkSpaces supports Amazon Linux, Windows 10 bundles with pre-installed software packages. AWS WorkSpaces contains Free Tier available as well.

4 Steps to setup AWS WorkSpaces

Below are the steps used to setup AWS Workspaces

1. Head over to Amazon WorkSpaces.

2. Click on Quick-Setup

This Guide is about setting up much of the stuff automatically.

3. Select the WorkSpaces Bundle & Provide the user details.

There are a couple of bundles to choose from which contain specific software packages pre-installed & provide the username and email address.

Wait for some time.

You’ll be getting an email that would contain a Registration Code (keep that handy) and click on the WorkSpaces link to set the password. -->

4. Download & Launch AWS WorkSpaces Client

There are two ways to have Amazon WebSpaces client

Standalone Client → https://clients.amazonworkspaces.com/
Web Client → https://clients.amazonworkspaces.com/webclient

Once you have Downloaded & Installed the client, Enter the Registration code you received in the email and log in to it.

“If you found this article useful, feel free to 👏 clap many times or share it with your friends. If you have any doubts regarding the same or anything around the DevOps Space, get in touch with me on Linkedin, Twitter, Instagram.”

Kubernetes AutoScaling Series: Cluster AutoScaler

chrisedrego — Thu, 03 Jun 2021 19:05:14 +0000

A Complete Zero-to-Hero Guide to Kubernetes Cluster AutoScaler which allows scaling the number of nodes based on the resource requests and avoids having your pods waiting in the Pending State.

AutoScalling in Kubernetes

Kubernetes is feature filled with all the good-ness one of which is scaling, it’s often & assumption that Kubernetes comes with AutoScaling **as default, but that’s hardly the case, we often need to tweak the bars to make things actually work. Today we would discuss how we can use *Kubernetes Cluster AutoScaler *to **scale Kubernetes Nodes.

What is ClusterAutoScaler?

Cluster Autoscaler is an amazing utility that automatically upscales & down-scales the number of nodes based on the request of the resource for pods.

Cluster Autoscaler can be used to scale both the Kubernetes Control Plane(master nodes) or Data plane (worker nodes aka minion). For the purpose of this demo, we would choose an AWS-based on-premise cluster provisioned using KOPS.

In order for Cluster AutoScaler deployment to authenticate to AWS and scale the number of nodes, there are a couple of ways to do so.

Attaching the nodes IAM policy with appropriate permissions.
Creating an IAM user and create Kubernetes secrets and attaching the secrets to Cluster AutoScaler Deployment.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:SetDesiredCapacity",
"autoscaling:DescribeTags",
"autoscaling:TerminateInstanceInAutoScalingGroup"
],
"Resource": [
"*"
]
}
]
}

KOPS is an amazing tool that helps to create/bootstrap the clusters. In the case of AWS, KOPS provision the nodes in the form of Instance groups which are AutoScaling groups in AWS.

Pre-requisites:

kubectl CLI
KOPS
Kubernetes Cluster (v.1.14.0+ preferably)
Metrics Server (The Complete Guide on Metrics Server? -> link )

How does Cluster AutoScaler really, Scale?

Cluster Autoscaler follows a cycle through which it continuously checks if there is any pod that is Pending state because of inadequate resources of the available nodes in the cluster, if that's the case it adds new nodes to make sure the pods get scheduled. The way it determines is also based on the request which is specified the pod spec, that's why it's pretty much expected to make sure that we provide a realistic request value to the pods (nothing less, nothing more)

Cluster Autoscaler decreases the number of nodes that are consistently unneeded for a significant amount of time. A node is unneeded when it has low utilization and all of its important pods can be moved elsewhere.

kubernetes/autoscaler

Getting Started

In this demo, we would be using an on-premise Kubernetes Cluster already set up on AWS using kops.

Clone the Github repo **https://github.com/chrisedrego/clusterautoscaler**

Creating a Test Instance Group

For testing, we would create a dedicated Instance group with nodeSelector as node: test-node *so while testing the pods would only get scheduled on this node. We have selected the *t3.medium type as it has the following configuration.

**compute/vcpu:** 2vcpu
**memory:** 4Gi

Make the required changes in the existing config use the CLUSTER_NAME, SUBNET_NAME, and apply the configuration in the steps mentioned.

export KOPS_STATE_STORE='s3://STATE_STORE_URL'
export KOPS_CLUSTER_NAME='CLUSTER_NAME'
kops create -f ./kops/test-node.yaml

kops update cluster --yes
kops rolling-update cluster --yes

Verifying the new InstanceGroup & nodes are Ready.

***# Specify the new Instance Group Name***
INSTANCE_GROUP=''
aws autoscaling describe-auto-scaling-groups | grep $INSTANCE_GROUP

***# Check if new nodes are added***
kubectl get nodes

Creating a Test Deployment

For Testing, we will create a test deployment that has **nodeSelector *set to *test-node *with the **request* values set accordingly. In this case, we have provided the requested memory to 2Gi.

Deploying Cluster AutoScaler

Once you have already cloned the repo, there is a folder called **cluster-auto-scaler, **which contains three different ways of deploying, for the sake of simplicity we would use a single auto-scaling group.

Single Auto-Scaling Group
Multiple Auto-Scaling Group
On-Control Plane (on the master nodes)
Autodiscover (auto-discover using tags)

There will be a slight change required before applying the changes.

- --skip-nodes-with-local-storage=false

- --nodes=**<MIN_COUNT>:<MAX_COUNT>:<INSTANCE_GROUP>**

MIN_COUNT: Minimum number of nodes.

MAX_COUNT: Maximum number of nodes.

INSTANCE_GROUP: AutoScalingGroup / InstanceGroup

Make sure before applying the min-count and max-count should be between the actual range of InstanceGroup.

Stimulating Load.

We would be stimulating the load by increasing the number of replicas.

As we already know that the machine t3.medium has 4Gi memory, **as *there are other resources as well that makes the usable memory around *~3.7Gi

Before ClusterAutoScaler: Pending

Before ClusterAutoScaler, we assigned the test app memory of 2Gi and tried scaling the application to 2 replicas. In this case, it fails as a single node (t3.medium) doesn't have enough resources and we have the pod in a Pending state. (2Gi X 2 = 4Gi > 3.7~Gi)

kubectl scale deploy test-app --replicas=2

After ClusterAutoScaler: Running

After ClusterAutoScaler, it finds that the pod is in a Pending state and hence tries to assign a new node to the cluster, after doing so the Pod is scheduled onto the new node, once it's part of the cluster and everything works fine.

Recommendations: Cluster AutoScaler

Here are few recommendations to keep in mind.

Specifying the request of the pods

Specifying the request helps CA to get details of the resource request and accordingly can scale the cluster. Make sure to keep the value realistic and not too high as that might lead to false upscaling and can burn your cloud budgets.

Have an HPA for deployments

HPA ensures that pods scale automatically based on the increase in the request which ideally will trigger CA to scale the nodes accordingly and scale down when needed.

Avoid running in Production workloads

Avoid running ClusterAutoScaler where we can have a mission-critical application that can have issues while getting rescheduled on different nodes.

if you found this article useful, feel free to 👏 clap many times or share it with your friends. If you have any doubts regarding the same or anything around DevOps, get touch with me on Linkedin, Twitter, Instagram.

6 Easy steps for sharing AWS Encrypted RDS snapshot between two accounts.

chrisedrego — Sat, 29 May 2021 08:20:37 +0000

This is a hassle-free guide to share AWS Encrypted RDS across two different AWS accounts within 7 easy steps.

Overview

Login to the Source Account, Create a snapshot from RDS.
Creating KMS Key (with details of the destination account)
After the snapshot is created, Create a new copy of the snapshot & attach the KMS key.
Share the newly created snapshot to the destination account.
Log in to the **Destination Account, **head over to **Shared with me **snapshots, and create a new copy of the snapshot.
1. Restore the copied Snapshot into a new RDS Instance.

Changes at the Source Account

1. Create Snapshot

Cannot share an Encrypted Snapshot straight away.

Click on Share Snapshot, we can see that we cannot directly share the snapshot. For that, we have the KMS key to the rescue.

2. Create KMS Key

Open Key Management Service (KMS)

Create a Symmetric key, and add a label along with permission.

Enter the AWS Account ID and save the KMS key.

3. Create a Copy of the Snapshot

Once the snapshot is created, Select Snapshot, Click Actions > Copy Snapshot

Provide a name & select the newly create KMS key under the Master key

3. Share Snapshot with Destination account

Once the Copy of the snapshot is created, click on Actions > Share snapshot

Provide the AWS Account key and click Save.

Changes at the Destination Account

1. Import the Shared snapshot

Snapshot which we have shared from the source account will be available in the Shared with me tab under the snapshot window for AWS RDS.

Create a Copy of Snapshot click on Actions > Copy snapshot

2. Restore the Shared snapshot into RDS

Once the Copy of the share snapshot is created we can Restore the snapshot.

Select the Snapshot, Click on Actions > Restore Snapshot

Provide the Details for the new RDS instance and there we go!!.

“if you found this article useful, feel free to show some ❤️ and click on ❤️ many times or share it with your friends. Also follow us for more DevOps content”

MYSQL Operator: A MYSQL ❤ affair with Kubernetes

chrisedrego — Sat, 29 May 2021 08:18:16 +0000

We will explore how to easily provision, backup, restore & monitor MYSQL Instances on Kubernetes the easy way using MYSQL Operator.

“Running databases in Kubernetes is one shiny disco ball that attracts a lot of limelight. Although Databases by their very nature are stateful, on the other hand, Kubernetes is more inclined towards running stateless & ephemeral applications, which makes them two different worlds apart, although to make them one ❤ we have MYSQL Operator. As there is some great amount of work done worldwide in the Open Source community by Oracle, Presslabs & Percona providing rich MySQL Operator’s which make running MYSQL on Kubernetes a hassle-free experience.”

What is MYSQL Operator?

Operator are applications written ontop of kubernetes which makes challenging & domain specific operations automated & easy. We are choosing *MYSQL Operator* from *Presslabs which makes running **MySQL as a service* with built-in High-Availability, Scalability & Monitoring quite simple. A single definition of MYSQL Cluster can include all the information needed for backup, storage along with MySQLD configuration.

Architecture of MYSQL Operator

The whole infrastructure runs on top of Kubernetes, along with **Github Orchestrator** which is an open-source tools that provides a pretty intuitive UI, also we have the MYSQL Operator which does the actual heavy lifting & provisions various MySQL Nodes & Services, what’s even greater is that each MYSQL Instances has mysqld-exporter service running which can be used for monitoring.

Reason’s to use Presslabs MYSQL Operator

Automatic on-demand & scheduled backups.
Initializing new clusters from existing backups.
Built-in High-Availability, Scalability, Self-Healing & Monitoring.
Save money & Avoid vendor lock-in’s
Best suited for Microservices Architecture.

Prerequisite

Basic understanding of MYSQL, Kubernetes & Kubernetes Operator
Install the following tools: kubectl, helm

Installing MySQL Operator using helm

It’s a simple straightforward way to install mysql-operator with helm, run the following commands, based on the version of helm installed on your machine.

Provisioning: MYSQL Cluster

Once, we are done installing MYSQL Operator the next step is to provision MYSQL cluster instance with credentials, storage & MySQL configuration.

In this case, we have configured a root password which needs to be base64 encoded, we can do that with help of base64encode, along with it we can configure mysqld configuration an persistent volume claim for storage.

List & Describe the available MYSQL Instances

kubectl get mysql
kubectl describe mysql/<NAME_OF_MYSQL_CLUSTER>

Connecting to a MySQL Instance

kubectl -n mysql-operator run mysql-client --image=mysql:5.7 -it --rm --restart=Never -- /bin/bash

mysql -uroot -p'changme' -h '**mycluster-mysql.default.svc.cluster.local**' -P3306

Exposing MYSQL Cluster Publically using Ingress

There are some minor tweaks needed in the Ingress configuration such as adding the port number along with service to be exposed when it comes to TCP Servies, i have already addressed it in this blog.
Setting up a Standalone MYSQL Instance on Kubernetes & exposing it using Nginx Ingress Controller.

Backups

Backups are done pretty easily in an automated fashion with On-demand or Scheduled backups. Backups are stored on an Object Storage such as AWS S3, GCloud Bucket, Google Drive & Azure Bucket. Backups are done using rclone.

Creating Backups

In order for backups to be uploaded on these object storage we need to provide the credentials for the same using Kubernetes Secrets which need to base64 encoded.

We can list or view the status of the backups. MysqlBackups are actually runs as Jobs inside of Kubernetes Cluster.

kubectl get MysqlBackup

kubectl describe MysqlBackup/<BACKUP_NAME>

Creating Scheduled Backups

Operator provides a way in which clusters can be periodically backed up in regular intervals by specifying a cron expression.

Restoring Backups

Initializing a cluster from existing backups

There are often at times the need to spawn databases in Microservice environment which are restored from a point in-time backup or snapshot. MYSQL Operator makes it pretty easy by defining initBucketURL which points to backup archive file along with secret initBucketSecretName to access the file.

Monitoring & Visualization

MYSQL Operator comes along with built-in monitoring & visualization with the help of Orchestrator and mysqld-exporter service.

Orchestrator

Orchestrator is developed by Github, which allows to provides a replication topology control & high availability and bird-eyes view of the whole MYSQL Cluster farm.

In order to access the Orchestrator we can port-forward the service

kubectl port-forward svc/mysql-operator -n mysql-operator 3003:80

mysqld-exporter

Each MYSQL Cluster which is provisioned, have mysqld-exporter pod which captures metrics/information about individual clusters. This service can be used by Prometheus to scrape the metrics & provide valuable insight about the database.

We need to define a service which exposes the mysqld-exporter pod which runs on port 9125

In order to access the mysqld-exporter, lets port-forward the service.

kubectl port-forward svc/mycluster-exporter-svc 9125:9125

Final Notes

Although, we have learned to provision, scale,monitor mysql instances making production databases run on Kubernetes, the most important thing to look forward is the underlying storage for Persistent Volume as there are a couple of Storage Backends such as EFS, NFS that support RWX, but often don’t work well.We can certainly opt for EBS, Azure disk, local disk although we can still run into problems like for EBS ReadWriteMany isnt a supported. In that case we can prefer options such as Ceph, GlusterFS, Rook which are production ready but have complex side for setup & maintenance.

“if you found this article useful, feel free show some ❤️ click on ❤️ many times or share it with your friends.”

Kubernetes Monitoring: Kube-State-Metrics

chrisedrego — Sat, 29 May 2021 08:13:38 +0000

In a pursuit to monitor our Kubernetes Cluster we often need the right set of tools to capture, the right metrics. Although there are a couple of tools present already, today let’s discuss Kube-state-metrics.

What is Kube-State-Metrics?

Kube-State-Metrics is an open-source light-weight utility used to monitor the Kubernetes Cluster. As the name suggests, it provides information about the state of a couple of Kubernetes objects by listening to Kubernetes API. Kube-State-Metrics acts like a Swiss Army Knife that provides metrics for a long list of Kubernetes-Objects.

Installing: Kube-State-Metrics

git clone [https://github.com/kubernetes/kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
kubectl apply -f kube-state-metrics/examples/standard/

This will go ahead and install all the components needed such as ServiceAccount, ClusterRole, ClusterRolebinding along with Deployment, and Service.

Let’s test it locally, by exposing the service, run the command

kubectl port-forward svc/kube-state-metrics -n kube-system 8080:8080

Scrapping: Kube-State-Metrics with Prometheus

As we already, know Kube-state-metrics is Prometheus friendly let's get started with scrapping the Kube-State-metrics with Prometheus.

Assuming that you have already installed on Prometheus on your cluster, you can use the above Prometheus Configuration to start scraping metrics.

if you found this article useful, feel free to click ❤️ heart many times or share it with your friends.

Monitoring Nginx Ingress Controller with Prometheus & Grafana.

chrisedrego — Sat, 29 May 2021 08:11:12 +0000

Before getting started we need to make sure that we have the following tools installed.

Nginx Ingress Controller
Prometheus
Grafana.

Let’s install Nginx-Ingress Controller, Prometheus, Grafana with ***helm3***

helm repo add nginx-stable [https://helm.nginx.com/stable](https://helm.nginx.com/stable)
helm repo update

helm install controller  nginx-stable/nginx-ingress 
--set prometheus.create=true --set prometheus.port=9901

helm install prometheus stable/prometheus
helm install grafana stable/grafana

You can tweak the installation as per your needs, more details on this on https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-helm/

One extra work that is needed is that we need to expose a service that listens to the port that contains the Nginx-Ingress-Controllers Prometheus Metrics in our case it's 9901.

Once we have created the service we now can go ahead and add the endpoints for Prometheus to scrape. We need to make sure although Prometheus is present inside of the Kubernetes cluster so that in the case easily resolves the internal Domains of the Nginx-ingress controller.

The next step is to use the above configuration as a Prometheus configuration. After which we can open Prometheus and head over the /targets page and verify if the ingress endpoints state is UP

To check what are the different types of metrics that Nginx Ingress Controller emits, we can head over to the Prometheus Dashboard and type in the console n*ginx. where *we receive a long list of different metrics that it emits.

Let's Graph it up: Grafana

Adding Prometheus DataSource in Grafana

Go ahead and add Prometheus as the data source in Grafana

Head over to Grafana Configuration > DataSource > Add Data Sources

Adding Dashboard in Grafana

Now, since we have added the Prometheus as a Datasource, we now need to added Dashboard for Nginx Ingress Controller. To make it less hassle-free there is already a Dashboard in place that gets everything set up with a few clicks.

Here’s is the link to the awesome dashboard for Grafana. **9614**
NGINX Ingress controller dashboard for Grafana

Bingo! Here-we-go!

We have now successfully able to set up Prometheus to scrape the metrics and Graphana to show the eye-catchy visualization for Nginx-Ingress-Controller.

if you found this article useful, feel free to click ❤️ Heart many times or share it with your friends and also follow me for more articles like these

Kubernetes Monitoring: Metrics Server

chrisedrego — Sat, 29 May 2021 08:04:08 +0000

Kubernetes Monitoring Series: Understanding the what, why, how & behind the scenes — Metrics-server.

What is Metrics Server?

Metrics Server is another useful lightweight tool that can be added to your Kubernetes Monitoring arsenal. As the name suggests Metrics Server provides metrics for resource utilization like CPU & Memory. Metrics Server discovers all the nodes in the cluster and queries the kubelet which is an agent that runs on each node and further forwards the details for resource utilization i.e CPU/Memory to Kubernetes API Server which exposes it as a Metrics API endpoint.

In most of the managed Kubernetes as a service offering from cloud vendors, it does come as an addon by default, as well a couple of bootstrapping tools like Kube-up.sh. If you are using minkube it can be enabled as an addon.

Why do I need the Metrics Server?

Although the Metrics Server misses all the glitter and glamour compared the rest of Monitoring tools offer with visualisation and dashboard, if you use features such as Horizontal Pod AutoScaler, Vertical Pod AutoScaler, kubectl top, or Kubernetes Dashboard then you do need the Metrics Server to provide resource utilisation metrics for them.

How to view the Metrics Server?

There are two ways to capture the information in the Metrics Server.

kubectl top command
Metrics endpoints /apis/metrics.k8s.io/v1beta1

kubectl top commands more of works like the top commands in Linux, which provides the details of the resources utilizes for pods & nodes.

kubectl top nodes 
kubectl top pod

Both the commands, provide metrics details about the resources consumptions (CPU/Memory) and displays the order based on the resources usage.

Kubernetes metrics endpoint can be accessed directly as follows.

kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/

kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes

This returns a response about resource utilization for nodes and pods present in the cluster.

How to install Metrics Server?

Before installing the metrics Server we need to ensure that the Aggregation layer is present. Aggregation Layer helps to further extend the existing core Kubernetes APIs by adding additional APIs.

Enabling metrics server as an addon in minikube

minikube addons enable metrics-server

Cloning the Metrics Server repository and applying the manifest.

git clone [https://github.com/kubernetes-sigs/metrics-server](https://github.com/kubernetes-sigs/metrics-server)
cd metrics-server
kubectl apply -f manifests/base/

OR

You can also deploy the v3.0.6 that works with some minor tweaks.

kubectl apply -f [https://gist.githubusercontent.com/chrisedrego/0dc6d79f25c2235934c2835d0e8952c9/raw/e22fdd4fa6476165a46968120afe4bd52538ae0b/kubernetes_metrics_server.yaml](https://gist.githubusercontent.com/chrisedrego/0dc6d79f25c2235934c2835d0e8952c9/raw/e22fdd4fa6476165a46968120afe4bd52538ae0b/kubernetes_metrics_server.yaml)

This basically installs metrics-server along with related Kubernetes Objects.

Service Account
APIService (v1beta1.metrics.k8s.io)
Deployment
ClusterRole/ClusterRoleBinding/Roles/RoleBinding
Service.

Conclusion

Metrics Server overall is best suited where we have Horizontal Pod Autoscaler/Vertical Pod Scaler, Kubernetes Dashboard or view the stats emiited by kubectl top command, it’s not ideal solution where the metrics emitted can be scrapped by Prometheus.

Troubleshooting

Finally, once the metrics server is installed we can wait for few seconds and then try running **kubectl top nodes **or **kubectl top pods **or by hitting the **Metrics Server endpoint **by kubectl get — raw “/apis/metrics.k8s.io/v1beta1/nodes.

Well in case if you do run into an issue where you are not able to scrape the metrics in that case, you can head over the issues tab for the metrics-server repository. https://github.com/kubernetes-sigs/metrics-server/issues/

if you found this article useful, feel free click ❤️ Heart, many times or share it with your friends.

Deep Dive with Provisioning AKS RBAC Enabled Kubernetes Cluster using Terraform.

chrisedrego — Sat, 29 May 2021 07:58:58 +0000

In this long descriptive blog post, where we would understand what is Infrastructure a code. Understanding the what, why, and how behind **terraform **and how to a provision simple RBAC enabled Azure Kubernetes Service (AKS) Cluster using Terraform.

What is Terraform, anyways?

Terraform is an open-source, cross-platform Infrastructure as a code,(Iaac) software tool that is provided by Hashicorp which is available on Windows, Linux, Mac, and other OS. Terraform provides a better way to provision Infrastructure on various platforms and cloud providers with the help of a configuration file (main.tf). Terraform uses a high-level configuration language called HCL(Hashicorp Configuration Language) which is more human-readable, and easy to understand.

So in simple words, instead of manually configuring the Infrastructure which involves point and click through User Interface to provision Virtual Machines, Storage, Networking, and other resources on various cloud providers such as (AWS, Azure, Google Cloud). We can automate, version control the same task for provisioning infrastructure with the help of Terraform. Along with all the goodness which Terraform has to offer, it also abstracts the underlying complexity while provisioning the infrastructure.

Imagine, a Life without Infrastructure as a code

Suppose, if you have been given a task to provision a Virtual Machine on Azure it involves.

Open your favorite browser (Chrome for me!)
Head over to portal.azure.com
Navigate to the Virtual Machine Page.
Provide the name, and then select the type, and then click and click **and **click as you configure it and wait till it gets created. Sound’s simple isn’t it?

Now imagine getting the same task, but spinning up to 100 Virtual Machine’s well that involves me doing the same task all over and over again, *click click click… **Sound’s simple isn’t it? but isn’t that too much. *(Frustrating)

So, Why Infrastructure as a Code, then?

Below are a couple of reasons to choose infrastructure as code against the traditional point and click.

Integrate best practices and standards as the Infrastructure is stored as code.
**Version Control **helps to incrementally, implement, and provision infrastructure, also with the ability to rollback to a specific version if needed.
Helps the task of creation, scaling, and deletion to be easily Automated.
**Tracking **the changes as the infrastructure is version controlled.
**Reusability, **as the code as well as the configuration files, can be later be reused and shared among teams.

Now since we have understood the goodness that Infrastructure as code has to offer, lets quickly get an overview of how would we create an AKS Cluster using Terraform.

Just an Overview.

Let’s discuss the overall flow, of provision AKS using Terraform.

Terraform Authentication to Azure:

Initially, we would be creating a Service Principal in Azure and provide its credential to Terraform for Authentication to Azure.

Communication with Azure API:

After successfully authenticating to Azure using the credentials provided, Terraform would then communicate with Azure Resource Manager and send requests for provisioning the resource on Azure.

Azure Provisioning the Resource:

Azure or any cloud-based provider for that matter, based upon the resource requested checks the availability of the resource a then provisions the requested resource. Azure in the background does most of the heavy lifting and hides the underlying complexity.

Prerequisites.

Terraform CLI
Azure Account
Text Editor(Optional)
Azure CLI (Optional)

– you can skip this section if you already have terraform, text-editor, azure-cli installed on your machine.

Installing Terraform.

Terraform is a very simple command-line executable, which is available on all major platforms like Windows, Linux, and macOS as well as OpenBSD and Solaris.

We would now quickly setup Terraform on the Windows environment in 3 easy steps.

Download the executable of Terraform from the official website and extract the executable.
Create a folder under the C:/ Drive or any drive for that matter and name the folder as terraform, and move the terraform.exe into that folder.
Add the full path of the folder which now contains terraform in my case it’s C:/terraform/ in the environment variables. This can be done by typing sysdm.cpl *in the run and then navigating to the *Advanced tab and then clicking on Environment Variables.

In order to verify if the terraform has successfully installed, we can open up the command prompt and type in terraform –version, if everything went well you should have Terraform’s version displayed.

Choosing a text-editor (Optional)

Downloading a third-party text-editor is completely optional for that matter, as you can also use notepad, vim which would be completely fine, but for ease and a bunch of other features, I prefer to use visual studio code.you can download and install visual studio code from this official link.

After downloading and installing visual studio code you can install the terraform extension which helps in a lot of ways such as syntax highlighting, linting, formatting, validation, and auto-completion.

All the files presented in this demo is hosted on Github Repository. https://github.com/chrisedrego/aks_terraform

Installing Azure CLI

Azure CLI is available on all the major operating systems including Windows, macOS, and Linux. Please refer to the official download link.

Authentication to Azure using terraform.

In order to provision Infrastructure on any given cloud provider for that matter, we first need to authenticate as well as make sure that we have the required permissions needed for the requested resources.

As we are focusing on Azure as a cloud provider, let’s understand the various ways in which we can authenticate to Azure using Terraform.

Authentication using Azure-CLI
Authentication using Managed Service Identity
Authentication using Service Principal

For now, we would be Authenticating to Azure using Service Principal, before that let’s have an understanding of what is a Service Principal.

What is a service principal?

Service Principal is a security identity that has certain roles, permission assigned to it to access specific Azure resources.

Why do we need a service principal?

When a Service Principal is created it generates credentials that are used by applications to authenticate to Azure and access cloud-based resources on Azure. In this example, the Service principal will be used by Terraform to authenticate to Azure.

Two ways to create a Service Principal

Azure Portal
Azure CLI

Creating a Service Principal using Azure (Portal)

Before creating a Service Principal, we need to make sure we provide, just the adequate amount of permission needed. Providing the Service Principal a much higher amount of resources then what’s expected, exposes the system to vulnerability and thereby decreases the overall safety & security.

Step 1: Log in to your Azure Portal, and in the search bar type in *“App registrations” *and then head over to the App registrations page.

Step 2: **Click on **New Registrations, After which you’ll have a page which requests for the name of the application, supported Account types as well as redirect URL.

Provide a unique application name followed by which you can provide a Redirect URL (optional) . A Redirect URL can also be set to *http://localhost* or any valid domain name which has https-enabled.

After creating the Service Principal there is more it as we need to configure the required permissions needed as well as also grab the credentials needed for authentication.

In this case, we need to take note of the Application (client_id), Directory (tenant_id) and then head over to the Certificate & secrets tab to get access to secrets.

After grabbing hold of the client_id, client_secret & tenant_id head over to your Azure Subscription page and get the **Subscription Id **which would also be needed.

Adding roles/permission to SERVICE PRINCIPAL

After successfully creating the Service Principal for Terraform we need to make sure that we assign the Service Principal specific Roles that are needed, which will allow Terraform to provision the requested resources.

We can provision roles to the Service Principal for an entire Subscription or just to specific Resource group as well, below I have attached the Screenshot in order to go with both the approaches.

Adding Contributor access to the Service Principal at the subscription level.

Adding Contributor access to the Service Principal at a specific Resource Group level.

Creating and Assigning roles to Service Principal (Azure CLI)

(You can skip this step if you already used the above approach by using the Azure Portal)

I have mentioned similar steps but using the Azure Portal UI below, you can skip this step if don’t have Azure CLI installed on your machine.

az login

After Authenticating to Azure, select specific Subscription id if in case you have many, you can view your subscription id with the help

az account list

Select the subscriptionId of the account and then set the account

az account set --subscription "SUBSCRIPTION_ID"

Now after switching the Subscription account on your machine, we can create and assign the service principal Contributor access for the subscription

$ az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/SUBSCRIPTION_ID"

After which now it outputs a JSON which contains the clientId,tenantId,password

{
"appId": "00000000-0000-0000-0000-000000000000",
"displayName": "azure-cli-XXX",
"name": "http://azure-cli-XXX",
"password": "0000-0000-0000-0000-000000000000",
"tenant": "00000000-0000-0000-0000-000000000000"
}

When we now have Service Principal created with the Role as contributor access along with its client_id, client_secret/password, tenant_id and subscription_id which we will be using in terraform so now we all set to start (terraforming)

Now, Let's start Terraforming

All the code, mentioned here is present on my Github Repository.

For the purpose of simplicity we would just create a folder named as aks-basic, which would have three files, lets have a basic understanding of all these files.

main.tf (configuration)
variables.tf (variables)
outputs.tf (output)

**main.tf: **contains the details of the cloud provider and the resource to be provisioned on the cloud provider specified.

variables.tf — contains the list of variables and the values, which are referenced inside of the main.tf file.

*outputs.tf *— contains the value which would be returned/output after successfully provisioning the infrastructure, which can be later be used by other modules.

You can consider the modules in terraform as a function, which is a combination of (main.tf + variables.tf + outputs.tf) which is where the main.tf is the body of the function which has certain operation while as variables are inputs for the main.tf which are passed to functions, as a final resultant final output the outputs.tf can be considered to be as return value that module returns.

main.tf

provider “azurerm” {

# Azure Provider version (Optional)

version = “=1.34.0″

# Credentials are specified authenticating to Azure

client_id = “${var.client_id}“

client_secret = “${var.client_secret}“

tenant_id = “${var.tenant_id}“

subscription_id = “${var.subscription_id}“

}

resource“azurerm_resource_group” “rg”{

name = “${var.resource_group_name}“

location = “${var.resource_group_location}“

}

resource“azurerm_kubernetes_cluster” “testcluster”{

name = “${var.cluster_name}“

location = “${var.resource_group_location}“

resource_group_name = “${azurerm_resource_group.rg.name}“

dns_prefix = “dns”

agent_pool_profile {

name = “agentpool”

count = 3

vm_size = “Standard_B2ms”

}

service_principal {

# Specifying a Service Principal for AKS Cluster

client_id = “${var.client_id}“

client_secret = “${var.client_secret}“

}

# Tag’s for AKS Cluster’s environment along with  nclustername

tags = {

environment = “test”

cluster_name = “${var.cluster_name}“

}

# Enable Role Based Access Control

role_based_access_control {

enabled = true

}

}

Breaking down, the main.tf

In this case, let's understand main.tf to have a better understanding of what’s going on in the background.

Provider Block

provider “azurerm” {

version = “1.28.0”

client_id = “${var.client_id}“

client_secret = “${var.client_secret}“

tenant_id = “${var.tenant_id}“

subscription_id = “${var.subscription_id}“

}

As we already know, that terraform can be used to provision cloud resources on multiple cloud providers such as AWS, Azure, GCP, Heroku. a provider is responsible for understanding API interactions and exposing resources. The provider comes into the picture at the very initial phase while interacting with the Cloud Provider (Azure), as you can call it as an entry point to decide which cloud provider would we be provisioning the resources. To understand more about the various cloud providers that terraform has to offer to refer to the official link

In this block, we watch carefully we are specifying the Azure (arurerm) Azure Resource Manager provider along with the credentials from the Service Principal to authenticate to Azure.

AZURE_RM_KUBERNETES_CLUSTER

resource“azurerm_resource_group” “rg”{

# Name/Location of the Resource Group in which the

AKS cluster will be created.

name = “${var.resource_group_name}“

location = “${var.resource_group_location}“

}

resource“azurerm_kubernetes_cluster” “testcluster”{

name = “${var.cluster_name}“

location = “${var.resource_group_location}“

resource_group_name = “${azurerm_resource_group.rg.name}“

dns_prefix = “-dns”

agent_pool_profile {

name = “agentpool”

count = 3

vm_size = “Standard_B2ms”

os_type = “Linux”

os_disk_size_gb = 100

}

service_principal {

client_id = “${var.client_id}“

client_secret = “${var.client_secret}“

}

tags = {

environment = “test”

cluster_name = “${var.cluster_name}“

}

role_based_access_control {

enabled = true

}

}

*azurerm_kubernetes_cluster *block is used to define the overall configuration needed to spin a Kubernetes cluster, in this case, we wouldn’t be configuring a highly advanced Kubernetes cluster with all the subnet and other networking details specified, to know more about how to highly configure a Kubernetes cluster refer to the official link

name & location as we know specifies the name and the location where the AKS cluster will be created.

resource_group_name refers to the above block of the resource group name specified.

dns_prefix is the DNS prefix which will be used for the API Server of the AKS Cluster. in our case, we have specified it as DNS which will further contain a unique domain name. which will together form a unique endpoint which presents the API server for the AKS Cluster.

Example: dns-3xMXa.hcp.eastus.azmk8s.io

**Agent_pool_prefix **contains a lot of details about the nitty-gritty details about the type & count of Virtual machines that would be used along with the disk size and OS installed on them.

**tags **are an optional entity but prove useful to tag or label resource on Azure which performs a certain operation.

**role_based_access_control **a is set enabled which makes sure that the Kubernetes Cluster will be RBAC enabled.

Resource group

resource “azurerm_resource_group” “rg” {

name = “${var.resource_group_name}“

location = “${var.resource_group_location}“

}

A resource group in Azure is used to logical group the resources in Azure. As we are provisioning an AKS Cluster in Azure we are providing a resource group in which the cluster will be created.

variables.tf

variable “client_id” {

description = “contains the Client Id for service principal”

client_id = “XXXXX-XXXX-XXXXX-XXXXX”

}

variable “client_secret” {

description = “contains the Client Secret for service principal”

client_id = “XXXXX-XXXX-XXXXX-XXXXX“

}


variable “tenant_id” {

description = “contains the Tenant Id for service principal”

client_id = “XXXXX-XXXX-XXXXX-XXXXX”

}


variable “subscription_id” {

description = “contains the Subscription Id for service principal”

client_id = “XXXXX-XXXX-XXXXX-XXXXX“

}


variable “resource_group_name” {

description = “contains the name of the Resource Group”

default = “test_rg”

}


variable “resource_group_location” {

description = “contains the location Resource Group of cluster”

default = “XXXXX”

}

variable “cluster_name” {

description = “contains AKS Cluster Name”

default = “XXXXX”

}

we had a look close to the main.tf we haven't specified the much of the values hardcoded, rather all of them refer to var followed by the name of the variables all of these variables are specified in these variables.tf.

Please make note that its not recommended approach to store secrets/credentials in plain text **variables.tf **file, you could store these variables in environment variables if in case of CI/CD environment as the secret to avoid exposure and thereby hampering the security.

Now after understanding the nitty-gritty details of what main.tf and variables.tf is, let's learn how to plan and apply the configuration present in the main.tf on Azure.

TERRAFORM: STAGES

Let’s quickly understand what does each phase has to offer, as we would be implementing the same while we provision an AKS cluster.

terraform init is used to initialize the current module or folder that we are currently in which contains the main.tf and if there is any cloud provider block defined inside of the main.tf in the current directory where terraform init command is run, it goes ahead and downloads the binary need in order to communicate with APIs of the specific cloud provider.

terraform plan does a great job as it authenticates to the cloud provider, and then provides a summary of what will be the changes that will be applied after applying configuration present in the main.tf

terraform apply After running a terraform plan once we have understood that the proposed changes are needed to be applied, we can now run terraform apply which goes ahead and start provisioning the infrastructure with our approval.

terraform destroy, After successfully provisioning the resource on cloud providers, if we want to destroy the changes, we can run terraform destroy which goes ahead and destroys the resources.

Let’s understand each stage in a bit of detail here.

TERRAFORM: INIT

We need to navigate to the module/directory which contains the code (main.tf) after which you need to run the terraform init.

What magic does Terraform init do?

When we run terraform init it goes ahead and initializes if there is any external module specified in the main.tf as well if the provider block is declared it goes ahead and downloads the binaries needed in order for future communication with the specific cloud provider. In this case, if we run terraform init, it goes ahead and downloads the azure binaries inside .terraform directory, this binary is useful for communication with the Azure API.

Output after running: terraform init 
Initializing the backend... 
Initializing provider plugins... 
Terraform has been successfully initialized! 
You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. 
If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

TERRAFORM: PLAN

When you run the command terraform plan it goes ahead and gives us an overview, about how the infrastructure would look like after applying the configuration that needs to be provisioned. The resultant output from the terraform plan often lists the resources that would either be created (+) , removed (-), or modified (+/-).

terraform plan can be compared to the Linux command diff (+) (-) (~)

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

+ create

Terraform will perform the following actions:

# azurerm_kubernetes_cluster.testcluster will be created

+ resource “azurerm_kubernetes_cluster” “testcluster” {

+ dns_prefix = “dns”

+ resource_group_name = “TEST”

+ “environment” = “test”

}

+ addon_profile {

+ aci_connector_linux {

+ enabled = (known after apply)

}

+ http_application_routing {

+ enabled =

(known after apply)

}

........

........

+ service_principal {

+ client_id = “92409b6a-00eb-40f7–9af6–16faef7206c8″

+ client_secret = (sensitive value)

}

}
# azurerm_resource_group.rg will be created

+ resource “azurerm_resource_group” “rg” {id = (known after apply)}
Plan: 2 to add, 0 to change, 0 to destroy.

— — — — — — — — — — — — — — — — — — — — — — — —

If we have to look carefully terraform gives us a complete overview of how changes will be applied (+) sign means the specific resources will be added, this immensely helps us when don’t want to directly apply the changes but rather would like to see what changes will occur and based upon the output if it seems suitable we then go ahead and apply the plan.

TERRAFORM APPLY

Fingers crossed, after having a rough idea of how the state of our infrastructure would look after running terraform plan, we can now go ahead and run terraform apply

What does terraform really do?

*terraform apply *command does the actual heavy lifting, it goes ahead and ensures that the expected configuration that is mentioned in the configuration file is provisioned on the cloud provider.

Running terraform apply **commands re-runs **terraform plan and output’s the overview of the proposed state of the infrastructure along with confirmation to apply the changes, with a Yes or No and also generates local state files which contain the current state of infrastructure on the cloud in context to the resources mentioned

(YES == wait)

After entering yes on the terraform apply prompt, just sit back and wait as it might take some time,

azurerm_resource_group.rg: Creating…

azurerm_resource_group.rg: Creation complete after 5s [id=/subscriptions/f7e20517–6ec1–460d-9712-aa3ee55ccc6a/resourceGroups/TEST]

.testcluster: Creating…

.testcluster: Still creating… [10s elapsed]

…..

.testcluster: Creation complete after 13m27s

[id=/subscriptions/XXXXXX/resourcegroups/TEST/providers

/Microsoft.ContainerService/managedClusters/testcluster]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Boom! finally, we have an AKS Cluster launched.

We were successfully able to provision an AKS Cluster with terraform.

If you do face any issues, please do let me know, All the code mentioned in this blogpost is available on my GitHub repository (aks_terraform)

Till then happy Terraforming… :)

if you found this article useful, feel free to click ❤️ Heart many times or share it with your friends.

How to Setup CI/CD Pipeline using Gitlab-CI to Deploy to Azure Storage & Azure CDN.

chrisedrego — Sat, 29 May 2021 07:56:58 +0000

A Complete Zero-to-Hero guide in setting up a CI/CD Pipeline using Gitlab-CI to deploy with the help of Azure Storage

For the purpose of this demo, I have already created a simple Angular 7 application that is hosted on Gitlab, the application is a simple, digital clock that looks something like this.

The Overview

The above diagram describes the whole process, right from a developer pushing the code, to the point where the CI/CD Pipeline builds & deploys the code to Azure Storage (Blob) which is linked to Azure CDN Endpoint.

Developer goes ahead and performs the development locally of the application after which he goes ahead and commits and pushes the code to the version control system in our case it’s Gitlab.
We would then have Gitlab perform the CI/CD in the form of the steps mentioned in gitlab-ci.yml file.
From Angular 2 onward’s we use Typescript. the typescript was released by Microsoft and is super-set of JavaScript. For the purpose of this tutorial we are using Angular 7 which uses typescript, the browser doesn’t understand typescript so hence we need to Build the application which converts it into Native JavaScript so that it can be rendered by the browser.
After Building the application, which converts the Angular 7 Application from Typescript to JavaScript we have a dist folder that contains the final build containing static (html,css, js) files which are then uploaded to Azure Storage.
After uploading the files to Azure Storage, for hassle-free access to the Angular Application by the end-user, we would be using a CDN Endpoint which helps us to further optimize the delivery, boost performance with the help of caching as well as adding redirection rules which we would be discussing later.
CDN Endpoint can then be linked to the Custom domain name, by creating CNAME Record in your DNS Zone.

Now since we have understood the overall flow for Deployment, lets get started.

Creating Azure Resources (BLOB + CDN ENDPOINT):

In this case, as we already know we would be deploying the Angular application’s static build content over to the Azure Storage and that would be made accessible using a CDN Endpoint. We need to create a Storage Account along with a Blob, as well as a CDN Endpoint which will be pointing to the respective blob containing the static build files.

Azure Storage Account (WHAT? WHY? HOW?)

An azure storage account contains all of your Azure Storage data objects: blobs, files, queues, tables, and disks for our example we would be using blobs.

Creating a Storage Account

After the Creation of the Storage Account create a Blob/Container in order to store static Angular build files.

After Blob is created we need to grab the Access Keys for authentication on the Gitlab-CI platform for uploading the content to Azure.

Creating Azure CDN Profile + Endpoint.
For Caching, Increased Performance we would be using Azure CDN. We need to first create a CDN Profile under which we will be creating a CDN Endpoints.

We used Verizon Premium, which allows us to configure redirection rules, and loads of other features that are present, more on this later.

Creating & Configuring AZURE CDN ENDPOINT.

Let’s create a CDN Endpoint for the application to be accessible in this case , we need to click on +Endpoint and then enter the name of CDN Endpoint, and select the Origin Type as Storage as we need to link the CDN Endpoint to the Storage Blob and then select Origin Hostname with the Storage Account hostname URL. Followed by which we need to provide the Origin path which includes the name of Blob Name.

Optimised types in CDN Endpoint.

There are two types of Optimisation type which includes.

General web delivery.
Dynamic site acceleration.

After having used both the types, i prefer to use Dynamic site acceleration as its more optimized, and has better performance and faster caching as compared to General web delivery, but with higher price tag involved.

**Probe Path: **Probe path includes the file placed on the origin server to optimize network routing configurations for the CDN. In our case the origin server is Storage Blob to which the CDN Endpoint is pointing to.

After successfully creating the CDN Endpoint, here’s how it looks like, we need to now make sure that whenever the user enters the CDN Endpoint URL which is linked to the storage blob it should be able to access the website but that’s not how it works by default, as it's not able to locate index.html.It’s never recommended for the user to enter **www.domainname.com/index.html** as that adds an extra overhead from the user's side to append index.html each time he wants to access the website. In order to fix this, we will be using Verizon CDN Portal to configure the redirection rules for index.html as well as http-to-https redirection.

Configuring rules for CDN endpoint.

We need to click on Manage, which will redirect us to Verizon Portal in order to configure the rules.

In this case, we will configure two rules.

1. HTTP-to-HTTPS Redirection Rule:

This will perform a URL-redirect if in case the user request for http it will perform a URL redirect to https.

2. URL Rewrite (index.html):

This rule will perform URL rewrite so that even if the user enters the CDN endpoint it will perform URL rewrite and add index.html automatically so that it removes the overhead for the user to append index.html to the domain name each time.

STEPS TO CONFIGURE THE RULES.

After the CDN portal opens up we need to click on ADN, as we have DSA as a CDN type enabled and then click on Rules Engine after which we now can configure the rules for the same.

1. http-to-https redirection

<rules schema-version=“2” rulesetversion=“2”

rulesetid=“XXXXXXX”

xmlns=“http://www.whitecdn.com/schemas/rules/2.0/rulesSchema.xsd”>

<rule id=“XXXXXXX” platform=“adn” status=“active”

version=“0” custid=“XXXXXXX”>

<description>tymmychn_http_to_https</description>

<!–If–>

<match.request-scheme value=“http”>

<feature.url-redirect code=“301”

pattern=“/XXXXXXX/tymmychn/tymmychn/(.*)”

value=“https://%{host}/$1” />

</match.request-scheme>

</rule>

</rules>

2. url rewrite for index.html

<rules schema-version=“2” rulesetversion=“2”

rulesetid=“XXXX”

xmlns=“http://www.whitecdn.com/schemas/rules/2.0/rulesSchema.xsd”>

<rule id=“XXXX” platform=“adn” status=“active”

version=“0” custid=“XXXX”>

<description>tymmychn_rewrite_index.html</description>

<!–If–>

<match.always>

<feature.url-user-rewrite

pattern=“/XXXX/tymmychn/tymmychn/$”

value=“/XXXX/tymmychn/tymmychn/index.html” />

</match.always>

</rule>

</rules>

After applying the rules here how it should look like.

INDEX.HTML — URL REWRITE

For HTTP-TO-HTTPS Redirection.

After Saving the Rules it will take some time for the changes to the reflected, which can be up to 4 hours and in the worst case even more. After the Pending XML changes to Active XML that’s an indication that the changes have been applied.

BACK TO GITLAB.

Now after setting up the whole infrastructure that was needed at the Azure side, which involved setting up a storage account which will have blobs that could store the Angular static build files (HTML, CSS and JavaScript) as well as to serve the end-user with help of CDN Endpoint for fast delivery.

Now its time to configure the CI/CD pipeline on Gitlab, as we already know that GitLab provides a simple way to configure CI/CD on each repository by mentioned all the steps in .gitlab-ci.yml file.

image: chrisedrego/azng_ubuntu:latest

stages:
  - build_deploy

build_deploy:
  stage: build_deploy
  script:
    - az login -u $AZ_USER_NAME -p $AZ_USER_PASSWORD
    - az account set --subscription $AZ_SUBSCRIPTION_ID
    - npm i -g @angular/cli &&  npm install --save-dev @angular-devkit/build-angular
    # - /usr/bin/ng build --output-hashing none --base-href https://tymmychn.blob.core.windows.net/tymmychn/
    - /usr/bin/ng build --output-hashing none --base-href https://tymmychn.azureedge.net/
    - az storage blob upload-batch -s ./dist/tymmchyn -d $BLOB_NAME --account-key $ACCOUNT_KEY --account-name $ACCOUNT_NAME 
    - az cdn endpoint purge -g $RESOURCE_GROUP --name tymmychn --profile-name tymmchyn --content-paths "/*"

https://gitlab.com/chrisedrego/tym_mchyn/-/blob/master/.gitlab-ci.yml

Link to this GitLab-repo contains the codebase along with the gitLab-ci.yml. In this case, let’s quickly examine the GitLab-ci.yml and here what it does.

Line 1: IMAGE, refers to the link to the docker image that I have used for this example which contains the needed tools involving Azure CLI and Node JS, NPM

After which we have declared the stages, followed by which we have defined single-stage named “build_deploy”.

First, we authenticate to the Azure using az login and the username and password which are stored as secret variables in this case. More on Gitlab Secrets on this link.

After authenticating and selecting the right subscription if you multiple subscriptions (9,10)

Gitlab already does the overhead of cloning the repository with the branch on the which we are currently, so taking that into consideration we can now go ahead and perform the following steps:

install Angular CLI
Install Angular-Devkit (Optional)
Install all the dependent packages in the package.json for Angular Application
Use Angular CLI to go ahead and build the Angular Application and then set the base-href to the CDN-Endpoint. The reason behind setting the base-href is that once the application is hosted and when we try to access the application from the CDN endpoint at runtime, we face an issue while trying to access the application as its not able to locate the absolute path of Javascript files.
After the build is created in the specific folder mentioned in angular.json present in your root directory, we can now go ahead and upload the files in the Storage Blob.
After successfully uploading the contents we make sure that after each commit/push we get the latest code by removing the purged content which might previously be present as cache on the CDN Endpoint node.

Now if the pipeline was successfully and the Verizon rules have applied, we can head over to our CDN Endpoint and we should see the final magic.

Well, that looks good.

if you found this article useful, feel free to press >> ❤️ love many times or share it with your friends.

21 Best Practises in 2021 for Dockerfile

chrisedrego — Sat, 29 May 2021 07:50:42 +0000

“This is a curate long-list of 20+ Best Practises for Dockerfile for the Year 2020”.

Since the inception of Docker on 20th March 2013, it has already taken the world by storm, by revolutionizing the way how easily applications can be packaged and delivered across multiple platforms with ease. All though containers existed, even before the Docker era, what made Docker stand out of the crowd and making it globally famed was the fact that, it easily bootstrap most of the underlying complexity involved with containers in general, making it fairly available on all the major operating systems & platforms with power of open-source community always backed for better support.

Docker has always been my personal favourite in terms of the technology shift that has happened in recent years. From the transition of the bare-metal machines to Virtual-Machines in most respect. Similarly, Docker is replacing Virtual Machines with containers for all good reasons. Docker, in a nutshell, contains some basic components involved which start off with a simple Dockerfile which is a plain-text file where we write the (code) which contains a straightforward set of steps or instructions which define what needs to be done in simple terms and what you want your application to contain and how it would run. After writing the Docker file we build an image out of it (consider this as executable) which gets created after compiling some code (Dockerfile). After the image is built we need to launch that image. Launching an Image creates a container which is a running instance of the image, which is similar to launching an executable which is running instance of the executable.

CHOOSE MINIMAL BASE IMAGES

Every custom image that we build in docker needs to be built on top of an existing base image, we need to cherrypick and select images that are more minimal & compact. There are various flavours available which offer light-weight images. These include Alpine, Busybox and other distribution-specific images like Debian, Ubuntu, CentOS which have -slim *or *-minimal version of them to choose from.

While choosing a base image, it does need to be a perfect mix of choosing the image which offers the needed support, tools and binaries along with being lightweight. As some time you might also come across issues where choosing a lightweight image involves a trade-off with compatibility with the application and not having the needed dependencies or libraries need to run the application.

FROM alpine

WORKDIR /app

COPY package.json /app

RUN npm install

CMD [“node”,“index.js”]

REMOVE CACHE PACKAGES

For our application to run inside of a container it often requires a runtime environment, dependencies & binaries. While trying to install packages from package-manager such as (apt, apk, yum), it often first downloads the packages from the remote source-repositories on to the local machine and then installs the package. After installing packages, often at times cache package files that were downloaded get stored and consume additional unnecessary space. The best recommendation is to remove these cached/package files after the package is installed, this further optimizes the docker image.

Depending on the type of the image which is used there are different package managers which have default locations where the package-managers cache is been stored, some of which are listed below.

**Image/Distro: **Debian / Ubuntu

**Package Manager: **apt

*Location of the Cache: */var/cache/apt/archives

**Image/Distro: **Alpine

**Package Manager: **apk

*Location of the Cache: */var/cache/apk

**Image/Distro: **centos

**Package Manager: **yum

*Location of the Cache: */var/cache/

In the example below, we will be installing Nginx webserver to server static HTML webpages. As we install the Nginx package alongside we will also remove the cache packages that have been stored in the specific path of the cache directory. In this case, as we are using alpine we have specified the directory which contains the cache for the packages.

FROM alpine

RUN apk add nginx && **rm -rf /var/cache/apt/***

COPY index.html /var/www/html/

EXPOSE 80

CMD [“nginx”,“-g”,“daemon off;”]

An alternative to the above solution in the case of alpine is to use –no-cache which ensures that no cache is stored for the package that would be installed, which removes the additional need of deleting the packages manually.

FROM alpine

RUN apk add –no-cache nginx

COPY index.html /var/www/html/

EXPOSE 80

CMD [“nginx”,“-g”,“daemon off;”]

AVOID MULTIPLE LAYERS

Wow! this burger is an eye-candy with these extra layers of patty & cheese, which makes it really yummy & heavy. Docker images are similar to this burger with each extra layer which gets added to the Dockerfile file while building the image it makes it more heavier. It’s always recommended to make sure to keep the number of layers as low as possible.

Below is a Dockerfile that contains instruction where we install Nginx along with other utilities that are needed. In the case of Dockerfile, each new line of instruction forms a separate layer.

FROM alpine

RUN apk update

RUN apk add curl

RUN apk add nodejs

RUN apk add nginx-1.16.1-r6

RUN apk add nginx-mod-http-geoip2-1.16.1-r6

COPY index.html /var/www/html/

EXPOSE 80

CMD [“nginx”,“-g”,“daemon off;”]

Above Dockerfile can be optimized with the help of chaining and effectively using && and ** where ever needed to reduce the number of layers created for the Dockerfile.

FROM alpine

RUN apk update && apk add curl nginx nginx-mod-http-geoip2-1.16.1-r6 \

rm -rf /var/cache/apt/*

COPY index.html /var/www/html/

EXPOSE 80

CMD [“nginx”,“-g”,“daemon off;”]

With the help of chaining, we have clubbed most of the layers and avoided creating multiple layers which overall helps to optimize the Dockerfile to make the burger look even more Yummy.

DON’T IGNORE .DOCKERIGNORE

.dockerignore *as the name suggests, is a quick and easy way to ignore the files that shouldn’t be apart of the Docker image. Similar to the *.gitignore **file which ignores the files from being tracked under version control. Before going further any further, let’s understand **build-context. While building a Dockerfile all files/ folders in the current working directory are copied & used as the build context. The tradeoff here is that if the current working directory from where we are building the Dockerfile contains Gigabytes of data, in that case, it often increases the unnecessary build time, well that’s a problem, does that mean we have to move the Gigabytes of data to separate directory while building Dockerfile, Naah!!, but then how do we solve this?

.dockerignore to your rescue, it can be used for a couple of use-cases some of which I have been mentioned below:

Ignore files & Directories which are not needed to be part of the image which will be built.
Avoid accidentally copying Sensitive data.

Let’s try to understand this a bit better with an example of Dockerfile in which we will be dockerize a nodejs application and use .dockerignore to ignore the files/directories which are not required to copied at the time of building this image.

Ignore unrequired files & directories

FROM node:10

WORKDIR /nodeapp

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

In this case, we are choosing node:10 as the base image, setting the app as the working directory for our docker image, exposing port 8888 for external access, after which we copy the package.json and then install all the dependencies mentioned in package.json using npm which will create a node_modules directory which will contain all the latest dependencies installed under it after which comes the crucial part where we copy all the contents from our current working directory in the docker image. Often at times while copying all the contents from the current working directory there is certain files/directory which is not needed, in this case, its node_modules because we have already installed the latest binaries using npm install. so with that in mind, we can add node_modules in the .dockerignore to avoid it being copied over while the image gets build.

2. Avoid copying sensitive details.

Developers cannot deny the fact of storing .env, ssh keys, certificates, and files that contain sensitive details in their local development environment (been there done that), while it makes things easy to access it exposes the overall system to a whole new level of vulnerabilities and security loops-holes. however, these practices should be avoided by all means, as well as in order to prevent further damage in a development environment that contains Docker the best thing that can be done is to avoid these files from getting copied over in the docker image that we are building. This can be easily done with the help of .dockerignore by specifying the files that need to be avoided from being accidentally copied over.

So ideal here’s how our .dockerignore file should like

node_modules

.env

secrets/

*pem

*.md

In this case, we have added, node_modules which isn’t needed as mentioned above, .env as it might contain sensitive details or variables specific to the local development environment which shouldn’t create a conflict in other environments such as staging, production. We have also excluded all sensitive data stored in the .*pem* files as well as the files that are present in the secret folder along with markdown/documentation files that are often not needed inside of a Docker Imag

CHOOSE SLIM VARIANTS

While choosing a base image, one should prefer to choose a much slimmer & minimal base image. They are often tagged as -slim or -minimal. These images are lighter and have far less footprint as compared to their default counterparts.

Here are a couple of examples of a slim version vs default counterparts.

CUT THE ROOT

Every image that we built using docker has default user as root, well that is a security evil, hence we refer to it as “cut the root”. Most of the time, we don’t need the user for the images to be root, as we can specify a default user with all the minimal permission needed for the application to function inside of the container

Below is an example of an image in which we don’t specify a user which means the default user is **root, **Well that’s where we have opened a whole new level of a security loophole.

FROM node:10

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

Now, since we are aware of the fact that having the default user means root in order to avoid this we can specify the default user besides root.

FROM node:10

RUN user add -m nodeapp

USER nodeappuser

RUN whoami

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

REMOVE THE UNWANTED

While trying to dockerize an application our primary goal is to make sure that the application run’s inside of a docker container successfully. It often happens that after choosing the base image, there are a lot of tools and packages, utilities that do come along with the image its either that we can choose to use -slim /-minimal version of the image or prefer to remove tools and utilities which might not be needed.

TAG WISELY

Tags are a unique way for the image to be identified. While tagging the image we can use any specific naming convention of our choice but its would-be really is optimal to choose the image tag based upon features, commit, or something which is more meaningful. Tags are for the end-user to choose which version of the image to use

Example of tagging involves tagging them with an incremental version of the image or use git versioning hash to be used, all of this can be integrated into your CI/CD pipelines for automating the purpose of tagging the images

SO NO TO LATEST TAG

Been there done that, haven faced a lot of issues with docker images being tagged*: latest* , here are a couple of reasons why I prefer not to use the latest tag anymore.

myimage: latest is similar for it being tagged with nothing, or let’s say the default myimage (which has no tags)

Avoid using the latest tags for Kubernetes in production as that makes it far hard to debug and find out which version might have caused the problem. That’s why it’s often recommended to tag images meaningfully with a specific version which depicts the changes which occur and rollback if needed. It breaks the whole philosophy behind unique tags that depict different versions.

PUBLIC OR PRIVATE REGISTRY

The question here is to choose between a Public Image or a Private Image?

Public images are great, basic, and easy to use for smaller teams that are not that concerned about the overall security of the system.

Private images stored with an added layer of security and ensure that only authorized personnel can access these images. Docker hub, as well as a couple of other container registry tools, provide the option to choose between Public or private images (although in the case Docker hub you can only choose to have 1 image as private in the default-free plan)

KEEP IT SINGLE

Keep it Single, what it really means though is to keep the philosophy of single application for a single container. This applies to a lot of real-world things as well, The Single Responsibility Principle for software design also applies to Docker images as well. An image should represent only a single piece of application, thereby avoiding the overall complexity.

It’s often a good practice having a modular approach towards dockerizing the whole application stack, which might get involved which solving the issues that might arise unexpectedly. For example: If we trying to dockerize an application that has a dependency for MYSQL as the database we shouldn’t club both the application as well as the database in a single image, but rather split both the instances in separate Docker images.

USE LINTER

Linter is a simple piece of software that analyzes the code for a given language and then detects errors, suggests best practices write from the moment that you are writing the code. There are a couple of linters which are available for each language. In the case of Docker, we do have a couple of linters that you can choose, some of which are mentioned below.

My personal favorite is Docker Linter which is vscode extension which indicates warnings or syntactic errors right as you go.

DONT STORE SECRETS

Just how it is in real life, never disclose your secrets. Same when it comes to Dockerfile never store plaintext username, password, or other sensitive so that it gets revealed. To avoid secrets from being stored using .dockerignore to prevent accidentally copying files that might contain sensitive information.

AVOID HARD CODING

While this principle does not just apply to Dockerfile but also Software Design in general, it’s often not recommended to hard-code values inside of a Dockerfile. The best example could be instead of hardcoding specific version of the software which might update or need to change we can dynamically pass the values for them at build time using ARGS.

*ARGS *— is a keyword in Dockerfile that allows us to dynamically pass values to the Dockerfile at build time.

To better understand this, let's have an example.

ARG VERSION

FROM node:$VERSION

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

Using Dynamic values to pass and build the images.

docker build -t testimage –build-arg VERSION=10 .

docker build -t testimage –build-arg VERSION=9 .

With this technique, we can dynamically decide the version of the base image to choose from rather than hardcoding it and pass the value of the version at runtime

AVOID DEBUGGING TOOLS

While building the image their often at times we add debugging tools such as curl, ping, netstat, telnet, and other networking utilities which further increase the overall size of the image. It might be a good choice to avoid adding these debugging tools in the Dockerfile and only install them when actually needed at runtime.

ADDING METADATA

LABEL is a keyword in the Dockerfile which adds metadata details about Dockerfile.

LABEL allows text-based metadata details to be added to the Dockerfile which adds more verbose information. LABEL can be used to add details about the maintainer name and email address for the Dockerfile,. In the example below, we have added details about the maintainer as well as the version of the image.

FROM node:10

**LABEL version=“1.0” maintainer=“Chris Rego <cXXXXXXo@gmail.com>”**

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

USING VULNERABILITY CHECK

Vulnerability check!

With the recent attack on Tesla’s Kubernetes Infrastructure, it made everyone understand that the move from Bare-Metal-Machines to Virtual-Machines all the way up to containers never fixes the security loopholes that often get left behind. Well, there are a couple of best practises in terms of security that can be followed while Dockerizing and application such as taking care of secrets/credentials, avoid using root user as the default user for the container and couple of others. A better approach to counter-attack security vulnerabilities in the container sphere is to include tools / technology-driven towards performing reliable security checks towards the container which are present in your environment. There are a couple of tools present that can be added to your security arsenal.

AVOID COPYING EVERYTHING

It’s always good to COPY , but it’s wise to copy selectively. In the case of Docker, it’s recommended to try to avoid using COPY . . which tends to copy everything from your current work directory to that of your Docker image. It’s recommended to choose only the files which are needed to be copied as well as also specify files in .dockerignore from accidentally copying (unwanted or files that contain sensitive data)

FROM node:10

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

For example below we avoid the use of copying everything and rather specify only the files/directory which is exclusively needed which decreases the risk of an accidental copy of unwanted data which might ultimately lead to a bloated Docker image as well as increased build time overall.

FROM node:10

WORKDIR /app

COPY package.json ./

RUN npm install

COPY index.js src ./

EXPOSE 8888

CMD [ “node”, “index.js” ]

USE WORKDIR WHEN NEEDED

WORKDIR is another important keyword in a Dockerfile that helps to do most of the heavy lifting and avoids the additional use of creating & navigating to a specific working directory when needed.

WORKDIR can be extensively used in a specific use-case where we involve writing an additional step in Dockerfile which involves navigating to the specific directory. In that case, we safely remove these references of navigation i.e. cd by just using WORKDIR

FROM node:10

RUN mkdir -p /app/mynodejsapp

COPY package.json /app/mynodejsapp

RUN cd /app/mynodejsapp && npm install

COPY . ./app/mynodejsapp

EXPOSE 8888

CMD [ “node”, “index.js” ]

In this case, we have to create a folder using **mkdir **and then for each additional reference we have to mention the whole path for that specific folder and also it involves navigating to the folder using cd, all of this additional reference which is present can be replaced with a simple WORKDIR

FROM node:10

WORKDIR /app/mynodejsapp

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 8888

CMD [ “node”, “index.js” ]

In this case, WORKDIR automatically creates a folder if it doesn’t exist as well there is no additional need for navigation to the current work directory as WORKDIR as already done what it’s supposed to do.

MULTI-STAGE BUILDS

The multi-stage build technique is best suited in the scenario where the docker image contains the process of building the application inside of the Dockerfile, While it’s fine to build the application with all dependencies but for further optimization, we can further segregate the process of build and final deployment which is needed into two stages. Dividing the whole image into two stages helps to make sure that we avoid unnecessary dependencies that get early needed while building the application and which aren’t needed anymore after the build.

Using Multi-Stage build is a good practice as it encourages to keep only the things which are needed in the final Docker image and leaving behind all the build-dependencies and other files that are not needed.

# STAGE ONE: INVOLVES BUILDING THE APPLICATION

FROM node:10 AS build

WORKDIR /myapp

COPY package.json index.js ./

RUN npm install ./

# STAGE TWO: COPYING THE ONLY CONTENTS

# NEEDED TO RUN THE APPLICATION WHILE

# LEAVING BEHIND THE REST

FROM node:10-prod

WORKDIR /myapp

COPY –from=build /app/package.json /app/index.js ./

COPY –from=build /app/node_modules /app/node_modules ./

EXPOSE 8080

CMD [“node”, “/app/index.js”]

In this above example, we have separated the whole Dockerfile into two stages. The first stage involves installing the required dependencies and then copy only the files that we actually need into the second stage which will be the final build that will be used. This approach offers separation of concern as well as ensures that we can cherry-pick and select what really goes inside of the final build which will be used.

LASTLY CACHE

Let’s talk about something which is really important now that is cache.

Packaging and Building overall takes a lot of time, the same applies while building a Dockerfile which contains a series of steps that ultimately gets build into a docker image. While building a Docker Image, Docker will build step-by-step from top-to-bottom and checks if any step which is mentioned already has a layer which is present in the cache, if the layer already exists then it doesn’t build a new layer rather it will use an existing layer which overall saves a lot of time.

Caching proves effectively helpful while updating changes to the Dockerfile as well as when the Dockerfile contains often series of instruction which involves downloading specific packages, over the network often takes more time as well as consumes additional network bandwidth this can be reduced drastically with the help of caching. Although Docker provides cache by default there are chances that the cache might break due to changes that are detected which is expected behavior. So it’s the end-user responsibility to ensure that the instruction which is present in the Dockerfile is played out in specific order to avoid the cache from breaking as the order matters for caching.

Caching in Docker follows a chain reaction so that at the beginning itself if there are changes that are detected in the Dockerfile then the instruction mentioned after that, are not consider to be cached and that basically breaks caching. Therefore it’s often recommended to include steps that are predicted not to change frequently at the beginning of the Dockerfile which will ensure that caching won’t break. Docker will cache the results of the first build of a Dockerfile, allowing subsequent builds to be super fast. The cache will only work only if there is a cache stored if we delete that cache next time we try to build the image it will rebuild from scratch and consume time. Docker works quite intelligently and provides on the go caching without any additional configuration.

Docker is quite a flexible tool it allows us to completely ignore the cache while building the image which can be done using –no-cache. This makes sure that while building the image caching mechanism doesn’t work but this leads to an increase in the overall build time.

THIS NOT THE END

As I had promised this is a 20+ list of best practices for Dockerfile for 2020, I will be adding more to the list as I go along on this dark, unknown endeavor in building great Docker containers. If you did

How making Vada Pav is similar to that of Multi-Stage Docker Build?

chrisedrego — Sat, 29 May 2021 07:46:02 +0000

“This post is about how to build, light-weight, highly optimized Docker images with the help of a multi-stage image build technique, to get the most out of this article it’s expected for the viewer to have a **basic understanding of Docker. if not, you could follow along and the rest would be a history”

THE NOBLE VADA PAV

Vada Pav is the most beloved Indian street food, which doesn’t burn a hole in your pocket and it’s a perfect combination of Spicy, Sweet, Salty all at the same time, A soft cushiony pav, stuffed with a golden-fried spiced (potato) patty, covered with coriander chutneys and a sprinkling of garlicky masala — the vada pav is food heaven, an instant energy booster, rightly termed as disco-in-your-mouth.

HOW TO MAKE THE NOBLE VADA PAV ?

Ingredients:

Pav (an Indian round dumpling bread)
Potato
White Flour
Vegetable Oil
Salt & Spice
Chilly (Garnish)

Steps:

Get a Potato + Wash + Peal + Boil + Smash > Make Round dumpling of the potato.
Cover it with Batter (White Flour + Water) and Deep Fry the round dumpling of the potato in Oil
Put Potato dumplings in the bread granish it with green chillies & sliced onions

WHAT MAKES A VADA PAV REALLY GOOD?

WHAT MAKES A VADA PAV REALLY BAD?

This is what a really bad, ugly looking Vada pav looks like, which contains most of the unrequired things which were used while creating the Vada Pav itself, that includes oil spill on top of it, with white flour on the vada pav which was used to make the batter as well as left-over potato peels. well, that’s a complete disaster.

What really made the difference between both of them, were that the bad vada pav contains most of the stuff which was used to make it vada pav, which isn’t even needed while serving finally to Mr. Gordon Ramsay.

Wait, How is Vada Pav, Related to that of Dockerfile?

WHAT IS A MULTI-STAGE DOCKER BUILD?

“It’s a technique which involves removing all the unrequired tools, dependencies needed to build an application and only contain the final application build which helps to create lightweight Docker Images.”

The Multi-Stage Docker build feature is available from Docker 17.05 onwards. Using Multi-Stage build is a good practice as it encourages to keep only the things which are needed in the final Docker image and leaving behind all the build-dependencies and other files that are not needed. This involves breaking the Dockerfile into two or more stages, Build stages contains tools needed for building the application inside of the DockerImage and then the Second stage will only contain the final build artifacts being copied from the first layer to be executed.

In order to get a better understanding of how Multi-Stage Docker builds works to let’s understand the same with the help of an example. In this case, we would be Dockerizing a NODE.JS application and separate it into two stages and Build and Execution stages.

In the above example, we could see that there are two stages, the first stage copies files required to build the application after which the dependencies are installed and finally the application is built. the build application is then copied into a final stage which contains instructions to execute the application.

The Final image copies the contents from the build stage using the COPY instruction and specifies the reference of the image from which the contents can be copied, this really helps in only containing the final application which is needed rather than the build dependencies, and tools which are not needed when the application is used by the end-user. Thereby it improves the overall performance & size of the Docker image which is built.

So if compare the Analogy of Dockerfile with that of Vada Pav, the both mean the same thing is to remove unrequired Build Dependencies

CONCLUDING

What is really common between a good Vada Pav and a Docker Image is that we need to avoid any build level dependencies that are present while finally serving it to end-user. In order to further understand the best practises that can be applied while Building Docker images here’s a curated list 20+ of tips and tricks that can be followed.

Kubernetes Monitoring Series: Kubeview

chrisedrego — Fri, 28 May 2021 13:42:58 +0000

What is KubeView?

KubeView is a simple Web interface that provides the complete overview of the Kubernetes Objects across namespaces and how they are interconnected to each other with intuitive UI & icons.

Displays the details about the following Objects.

Deployments
ReplicaSets / StatefulSets / DaemonSets
Pods
Services
Ingresses
LoadBalancer IPs
PersistentVolumeClaims
Secrets
ConfigMaps

Installing: Kubeview

Before Installing KubeView, make sure to have helm installed on your machine.

git clone https://github.com/benc-uk/kubeview cd kubeview/charts/ helm install kubeview kubeview

This will go ahead and install all the components needed such as ServiceAccount, ClusterRole, ClusterRoleBinding along with Deployment, and Service.