DEV Community: erfankashani

Deploy Application on Azure App Services

erfankashani — Wed, 28 Dec 2022 21:16:53 +0000

Introduction

Hello, after a long break of blogging, I am dedicating myself to share my knowledge with the community via series of posts regarding different architecture designs that I have worked on throughout past year. These designs corresponds to my current learning journey and are open to feedbacks and discussions. Without further due, let's dig in.

Senario

Imagine you are in process of creating a product in form of web application, mobile application, or API endpoint. You have designed and prototyped your business logic in form of an executable package. While this application undergoes different levels of development maturity, you require a mean of presenting and demoing the proof of concept (POC) to your client/audiences with different technical skill levels. There are plenty approaches which can achieve this purpose. Some are mentioned below:

Ship the application as a package to be installed and tested on other developer's laptops.
Package and Deploy the application on an internal server, on-premises infrastructure or internal network for few techsavy audiences to test.
Deploy your application and serve on a public/private cloud provider and create instructions for how the end-user would interact with your app.

As you can see, you have many choices to deploy and present your application. One of the most important lessons I have learnt is that there will never be a silver-bullet tool, design, or architecture which works for all problems. Each project comes with sets of requirements and constraints. An architect or a developer has to make considerations and trade-off which will affect the product's end-goal. Some of the factors you can consider while choosing the correct approach for your product demo are time, skillset, budget, product's maturity level, and enterprise infrastructure availability.

having said that, let us assume we decided to deploy our application to a cloud provider (such as Microsoft Azure). There are yet different abstraction levels we can choose to lower the entry-cost of using cloud services. The price of these abstractions are to lose control over certain parts of the infrastructure your application will run on. Some of the available options are as such:

Deploy your application as a serverless architecture using Azure functions
Containerize and deploy the application using one of the container delivery services on Azure like App Services, Container Instances, or Kubernetes Services.
Deploy the application on a cloud hosted Virtual Machine

As mentioned before, there are situations which choosing one solution would be more beneficial than others. In this example, we would like to deploy our application with minimal architecture alteration and scalability in mind. We will try to containerize and deploy the application on Azure App Service.

Azure App Service

App Service is an Azure cloud offering which allows fast build, deploy, and scaling of Web, Mobile, and API applications. It supports .NET, .NET Core, Node.js, Java, Python, or PHP programs inside of containers. App Service provide a fully managed infrastructure which deals with maintenance, security patches, and scaling. With it's 99.95 percent service-level agreement (SLA)-backed uptime availability, App Service can be good candidate for some production grade applications. We will deploy our first App Service in the following section.

Requirements:

docker
az-cli

Steps:

Generate a new resource group: We will use this logical container to easier manage, monitor, deploy, scale, grant access of resources to a specific group or identity.
Create a new Azure Container Registry (ACR): This image registry hosts your docker images on Azure. For enterprise use-cases look into options such as Jfrog Artifactory.
Create an Azure App Service Plan
Create an Azure App Service
Upload your docker image to ACR and configure the App Service to use the image

We will configure the components using Azure CLI for more interactive approach. For more advance use-cases we can look into Azure ARM templates or terraform for future blogs.

Login using az cli

# install azure-cli on mac-os
brew update && brew install azure-cli

# login
az login

# check the active subscription:
az account show --output table

# change the active subscription (if needed):
az account set --subscription <subscription_name>

Create new resource group

Note: Naming conventions should follow consistent rules throughout your developments. It is a good idea to research your organizational naming conventions and follow them. I will use the following convention in a Camel Case format:

[Compname, Teamname, Projectname, Envname, Resourcelocation (abbreviated), Resourcetype (abbreviated)]
example: SpacexFlycontrolLandingtimeProdCcRg

# create a new resource group:
az group create --name DemoFlaskappDevCcRg --location canadacentral

# check the resource group list
az group list

Create Azure Container Registry (ACR)

# create ACR
az acr create --name demoflaskappacr --resource-group DemoFlaskappDevCcRg --sku Basic --admin-enabled true

# retrieve the registry's credentials
az acr credential show --resource-group DemoFlaskappDevCcRg --name demoflaskappacr

Note: Copy the "password" (not password2) and username in the step above as we will use this to login via docker.

Login and push the image into ACR

In this step you can use the boiler plate flask + docker project from github and follow the instructions:

# login to ACR 
docker login demoflaskappacr.azurecr.io --username demoflaskappacr

# clone the sample flask docker project
git clone https://github.com/erfankashani/docker_flask_app.git
cd docker_flask_app

# build the image
docker build -t docker-flask-app .

# run the image
docker run -p 8888:5000 docker-flask-app

This local container exposes to port 8888 on the host. The successful application can be checked on http://localhost:8888/ URL on your local computer's browser.

Now let us push this built image to docker registry:

# change the image name and tag to latest
docker tag docker-flask-app demoflaskappacr.azurecr.io/docker-flask-app:latest

# push to registry
docker push demoflaskappacr.azurecr.io/docker-flask-app:latest

# check the ACR for the pushed image
az acr repository list -n demoflaskappacr

Create App service

In this step we will create the App Service Plan and then an App Service which can pull images from the registry

# create app service plan:
az appservice plan create --name DemoFlaskappDevAsp --resource-group DemoFlaskappDevCcRg --is-linux

# create the app service (webapp)
az webapp create --resource-group DemoFlaskappDevCcRg --plan DemoFlaskappDevAsp --name DemoFlaskappDevAs --deployment-container-image-name demoflaskappacr.azurecr.io/docker-flask-app:latest

# expose the container's port 5000
az webapp config appsettings set --resource-group DemoFlaskappDevCcRg --name DemoFlaskappDevAs --settings WEBSITES_PORT=5000

# enable the system assigned managed identity (principle-id):
az webapp identity assign --resource-group DemoFlaskappDevCcRg --name DemoFlaskappDevAs --query principalId --output tsv

# retrieve az account subscription-id (subscription-id)
az account show --query id --output tsv


# grant the pulling access from ACR to the webapp managed identity (use principle-id and subscription-id from above)
az role assignment create --assignee <principle-id> --scope /subscriptions/<subscription-id>/resourceGroups/DemoFlaskappDevCcRg/providers/Microsoft.ContainerRegistry/registries/demoflaskappacr --role "AcrPull"

# configure the app to use the managed identity (use subscription-id from above)
az resource update --ids /subscriptions/<subscription-id>/resourceGroups/DemoFlaskappDevCcRg/providers/Microsoft.Web/sites/DemoFlaskappDevAs/config/web --set properties.acrUseManagedIdentityCreds=True

# configure the web app to use the correct docker registry:
az webapp config container set --name DemoFlaskappDevAs --resource-group DemoFlaskappDevCcRg --docker-custom-image-name demoflaskappacr.azurecr.io/docker-flask-app:latest --docker-registry-server-url https://demoflaskappacr.azurecr.io

Grab the URL from azure portal:

use the URL to access the app (please note that the first time load might take longer):

We have a deployed working version of this App Service. There are few more considerations which we make before demoing this application.

Networking

The applications hosted on Azure App Service are by default accessible through public internet and can only reachout to public endpoints. There are series of networking features which can help you define guidelines on the app's ingress (inbound traffic) and egress (outbound traffic). It is important to note that some of these capabilities are dependant on your mode of deployment (aka. single-tenant vs. multi-tenant plans). The following features are available on our multi-tenant service hosted App Service:

Ingress:

App-assigned address: Enables IP-based SSL checks and dedicated unshared inbound addresses for your app
Access restriction: Can limit the app access to specific well-defined addresses. This is a good idea for early demo phases when you would want to ensure your application can be viewed only by specific people.
Service endpoints and private endpoints: Expose a private endpoint and manage the access from resources within a VNet. There are more advanced techniques such as integrating your application with firewalls and load-balancer services like Azure Front Door. These applications are more useful for production and we can discuss them in future blogs based on interest levels.

Egress:

Hybrid connections: Access to private networks that are not connected to Azure.
Gateway-required Vnet-integrations: Access to resources in other VNets in different region via VNet peering.
VNet Integrations: This integration with Virtual Network opens the door to options such as configuring private subnets, exposing static IPs via NAT gateway, defining Network Security Groups (NSGs) for outbound traffic, integrating your app with a secure hub-and-spoke model to communicate with on-premises resources etc.

User Authentication

In this section we will enable user authentication using Microsoft AD Identity provider. Navigate to your App Service resource inside azure portal. Then click on authentication and "Add Identity Provider":

Select "Microsoft" as identity provider:

Your authenticator will require an app registration or service principal name (SPN) to communicate with the Identity provider. You have the preferred options of creating a new app registration from the same page or use an existing app registration followed by this link. In this example we:

allow application access to same tenant users only.
restrict app access to authenticated requests.
return 302 Error code on unauthenticated requests.
enable token storage.

Then press "add" which brings the following result:

To try this feature, attempt to access the URL again. This will require a Microsoft account login and the following pop up would show up:

Basic Scaling

there are two means of scaling your application to support higher number of requests:

Scaling-up: Means adding more resources like CPU, memory, and disk space to your existing app. You can achieve this by altering the App service Plan tier which your App Service is using.

Scaling-out: Create more instances of the VMs that run your application. You can scale out to as many as 30 instances, depending on your pricing tier. There are also autoscaling options to scale up and down your instances based on rules and schedules.

Thank you for following this blog to the end. In the next blog we will look into other aspects of this solution such as:

Secret management
Deployment options
Monitoring
Disaster Recovery

Resources:

Awesome diagrams using Mermaid.js

erfankashani — Thu, 14 Apr 2022 13:02:01 +0000

Today I want to share an awesome library which I discovered recently. Creating diagrams for complicated software can be a time consuming and tricky if you are not using the right tool. Maintaining the diagram to show the most recent structure can be struggle. One of the most common go-to is diagram.net:

This web application allow users to drag and drop elements on a page and rename them to create variety of graphs. In my experience, this application can create really beautiful graphs which take a long Time to create.

My search was not done there. I aim to introduce speed in the diagram creations, version control, and easier interface than finding elements, resizing, and renaming them plenty of times. This is where I found Mermaid

This library is written in Javascript and allows diagram creation using a markdown like syntax. Mermaid can create the following diagrams:

Flowchart
Sequence diagram
Class diagram
State Diagram
Entity Relationship diagram
User journey
Gantt
Pie Chart
Requirement diagram

Some of the benefits of using Mermaid.js:

creating graphs as code
saving time on styling the graphs
version controlling your graphs
easy integration with other libraries like diagram.net

To start we can install the “Markdown Preview Mermaid Support” extension on VSCode:

Then create a diagram directory in your desired codebase (optional). Finally create a markdown file like “app_diagram.md”. Choose the small (open preview to the side) icon on too right corner of your editor or ( shift + command + v for mac). Now you are ready to edit the file. Lets start with some easy examples:

The following showcases a Flowchart using mermaid:



    graph TD;
            A-->B;
            A-->C;
            B-->D;
            C-->D;

Any mermaid code should be entered as a code snippet with “mermaid” tag. Each letter represents a node which are connected via edges.

There are many samples of diagram creation on the mermaid website. I am going to demonstrate a settup that worked for me while creating flowcharts:




<!-- ```mermaid
flowchart Guide
    direction TB
    f[flow]
    s[[Step]]
    i([input])
    d[(Database)]
    Parameters>Parameters]
``` -->
<!-- Resource: https://mermaid-js.github.io/mermaid/#/ -->
<!-- Look at the graph here: https://mermaid.live -->
<!-- Connect to diagrams.net: https://www.diagrams.net/blog/mermaid-diagrams -->

```mermaid
flowchart LR
    subgraph Guide
        direction TB

        f[flow]
        s[[Step]]
        d[(Database)]
        Parameters>Parameters]
    end

    %% add in-line style
    Guide:::someclass
    classDef someclass fill:#f96;


    %%list of parameters
    p1>bank_name]
    p2>seller_info]


    %%list of steps
    s1[[1-withdraw_money]]
    s2[[2-purchase_bike]]


    %%list of flows
    f1[go_to_bank]
    f2[withdraw_from_atm]
    f3[contact_seller]
    f4[trade_bike]


    %%list of databases
    d1[(reads: customer_identification)]
    d2[(reads/writes: customer_balance)]
    d3[(writes: e_document_sign)]


    %% Create the step flows
    s1-.->s2;


    %% s1 flow
    p1-->|inputs|s1
    s1-->|calls|f1
    f1-->|calls|f2
    f2-->d1
    f2-->d2


    %% s2 flow
    p2-->|inputs|s2
    s2-->f3
    f3-->f4
    f4-->d3
\```

There are also other resources where you can export your graphs as PNG or SVG like mermaid.live. Moreover, you can checkout this blog regarding how to transfer your graphs from mermaid to diagram.net (FYI, digram.net does not support all mermaid functionalities)

I hope you have enjoyed this tutorial. Feel free to express your comments.

Regards,

Erfan

Nail the Fundamentals : Git_Good (Git flow best practices)

erfankashani — Sat, 28 Mar 2020 19:06:46 +0000

Have you ever you wished you had a time machine to go back in time and fix that awkward thing you said to someone? or you wanted to choose a different path of decisions for your life? ... as much as I want to write a tutorial on time machines, This blog is about a valuable tool similar to a time machine for developers ...

Git is your best friend when it comes to coding and I regret not using it enough during my undergraduate education. Today I want to discuss the git flow I use day to day in my workplace and hope it brings value to your development journey.

Any repository has two main branches: Master and Development.

Master (Production): is the production code which is being used by the customers. This branch should be ideally bug free. This is not a playground to test new lines of code.

Development (Staging): is the next version of Staging (Master) environment. This means this branch is still close to the master but has one or more new features which are being tested.

To start a new feature in the code base we should:

1) Start with the latest version of the development branch : This is important to always keep your development branch up to date. In big teams you can usually followup with the newest merge requests via the slack or email. This indicates that someone will be altering the current state of development soon and you should pull the latest version of the code: (this avoids future merge conflicts).

to perform this task you can:

git checkout development
git pull

2) Create your new branch: You should create a new branch to work on your new feature and avoid working on development branch. There is usually a convention for naming your branches among your team. My teams's convention is as such: <initials>-<ticket-number>-<featurename> for example I would make my branch using following command:

git checkout -b ek-132-slackbotapirouting

3) Work on your branch: You can make any changes you like to this branch and make sure you commit your changes often as you can revert to older version of code when needed. The commit messages should be a one liner description of what has changes in that commit. This will help you later if you wish to change or squash your commits. Couple of useful git commands when adding and committing code:

git diff                                # will show you all the changes you made. Here if you think you don’t want to add a file just add it to the .gitignore file
git add .                               # will add all the changes 
git add -p                              # here you can see the changes one by one and write (y/n) to add or not add a change 
git commit -m “what this change does”   # to commit the added changes

4) Time to push the code up: When you have the final version of your code, documented, tested, and refactored, it is the time to add this feature or the development branch.

First we will rebase with the development branch to compare the latest changes on development with our branch and deal with any possible merge conflicts:

git checkout development
git pull
git checkout ek-132-slackbotapirouting
git rebase -i development.

You triggered the interactive rebasing. Here you can “reword” or “fixup” commits (basically squashing the commits ) and deal with code-conflict. After rebasing is done, it is time for pushing the code up to the development.

git push -f                       #Force pushing to the ek-132-slackbotapirouting branch

Currently you have your latest changes pushed to the remote branch and rebased with the current state of development branch. This means you will not face a merge conflict when you submit a merge request.

5) Create the Merge request: Now you can create a merge request by going on the web version of your remote repository (ex. Github or Gitlab). Assign the merge request to your software lead for review and copy the request link into the developer's chat for extra code-review. Enable the checkmark for deleting the branch after merging so your repository stays clean.

6) Delete the feature branch: It is always recommended to keep the repository clean.

Deleting the feature branch locally by:

git branch --delete ek-132-slackbotapirouting

 
Deleting the branch remotely by:

git push origin --delete ek-132-slackbotapirouting

Good Practices:

Delete your local and remote branch after merging to keep the repository clean
If you have commits like "fixed a bug" or "fixed white space" make sure to squash them before making merge request
Always rebase before submitting merge request to avoid merge-conflicts
Avoid committing specific files to your development machine or process(ex. Gemfile.lock, .env).

Nail the Fundamentals : Documenting Using Yardoc (YARD)

erfankashani — Fri, 11 Oct 2019 23:09:18 +0000

Disclaimer: Nail the Fundamental series attempt to discuss good coding practices. Theses are personal industry lessons, taught by senior developers and software architects to enhance my skills. Most of the topics are general coding principles while some of them focus on specific coding language.

If you are a junior developer, this is the right place for you as I aim to fill the gap between coding lessons taught in the academia and what happens in the the industry. If you are a senior developer, you can compare your methods with the ones practiced by different organizations in the comments.

Without further ado, In this tutorial we will look into YARD!

Not that yard ... but YARD as in (Yay, A Ruby Documentation Tool). YARD or Yardoc is a documentation generating gem for the Ruby programming language.

Before we jump into it, there is an important question to answer!

Why should I document?

That is a fair question and I carried it when I started working in a development team. Some of the most important reasons to document your codes are:

You will be using them in 6 months: Code that you wrote 6 months ago is often indistinguishable from code that someone else has written. Documentation is the key to understand the code's syntax and implementation.
Increasing usability of the code: If you writing a feature, the code most likely will be integrated into a bigger project. Therefore, you should document it to be easily understood and interpreted by other developers.
Enhancing the On-boarding process: In case of adding a new developer to your team or on-boarding a new department to use your internal tool, documentation reduces the time and effort for them to adapt the codebase.
Simplifying the debugging: Software logs help to indicate where to look for a bug and documentations allow pinpointing the issue in low-level.
Assisting with test-cases: Black-box testing which analyzes functionality of the software relies solely on the requirement specifications document of your code.

I hope by now you have enough reasons to start documenting your code. That definitely makes your code look more professional. so please ...

Why Yardoc?

Yardoc is one of the well known ruby documentation tools and its benefits can be summarized as:

Can be hosted on personal DSL and private servers.
Generates consistant documentation.
Customizable documentation template (using markup language).
Accepts metadata such as tags along with the documentation (similar to Python, Java, and Objective-C).

Installation



# First make sure Rdoc is installed (dependancy on Ubuntu)
sudo apt-get install rdoc

# Mac users don't need to install rdoc since it is installed with
# the newest ruby installation.

# Next, install YARD using gem:
gem install yard

# Finally, to ensure YARD is installed
yard help

Documentation Styles

Most common tags:

@param = Describes the input parameters and their types (variable name can place before or after the type).
- Example: # @param [String] name Inputs the name of the user
- Example: # @param [Numeric] age Inputs the age of the user
- Example: # @param list [Array<String, Symbol>] the list of strings and symbols.
@option = In case you dealing with different options for the same input (use this for hash or array-list).
- Example: # @param [Hash] area_parameter numeric Inputs
- Example: # @option area_parameter [Integer] :length
- Example: # @option area_parameter [Integer] :width
@return = Documents the return-parameter from a method.
- Example: # @return [String] greeting message for the user.
@since = Usually, since is used to show app versions.
- Example: # @since v2.0.0
@raise = Use it only if method raises any exceptions.
- Example: # @raise [ZeroDivisionError] expectation if dividing by zero
@see = Refer user to a URL or other class within the documentation for further explanation.
- Example: # @see www.yardoc.com
@note = Miscellaneous messages that are low priority.
@todo = Miscellaneous messages that are high priority.
@example = Demonstrates an example of how to call the method.
- Example:



# @example Raise an exception using a message from +debug_message+
#   raise AppDebug.fetch('job_number', app_name: 'ExampleApp')

Common practice

add the file .yardoc and /doc to your .gitignore sine they can be generated easily when needed.
Document your private and protected methods. They will not be seen or used by the users but it helps other developers working on the same codebase. It is important to assure the private methods are not visible if you plan to publish the documentations. You can hide them in generating phase by:
yardoc --no-private --protected
When documenting a method, first line holds the Description. Leave a blank # between the description and tags. For Example:



# this is the method's description. 
#
# @param [String] text_input input parameter
# @return [String] returns the printed text
def print_text(text_input)
    #some code ...
end

Keep the order of input parameters consistent with the param orders. This results in easier flow for the reader.
Wrap the text with + to highlight
+highlighted_text+

Hands-on Demonstration

The code is available on GitHub. clone the repository using:



git clone https://github.com/erfankashani/Yardoc_Practice.git

Lets look into the files inside:



cd Yardoc_Practice
nano practise.rb

Most of the tags and the best practices are demonstrated in the code. Feel free to use this file as a reference for yardoc. Next step is to generate the documentation and spin-up the server.

Generate Yardoc

1- Go inside of the repository which you are using
2- Create the documentation by: yardoc <name_of_the_file>, in our case:



yardoc practise.rb

3- Run the web page on your local network (Port:8808):



yard server

After this step, you will notice a new directory called 'doc'. This is where all the HTML and css files are kept to create the documentation webpage. Observe the documentations by typing localhost:8808 in your address-bar of a browser. Take a look at the available methods by choosing methods option from the top left menu. You should see something like this:

By now, I hope you have a good understanding of why we document and how we do it using 'yardoc'. As you follow these simple but effective practices mentioned in the series, you will notice your code quality's improvement. Take the first step by start documenting all your ruby codebases. Let's get ittt...

Resources

Long Story Short: Kubernetes

erfankashani — Mon, 30 Sep 2019 00:05:40 +0000

Disclaimer: Long Story Short series are personal learning experiences as I encounter different development journeys. The aim of these series are to summarize and simplify difficult development concepts and teach them in different levels of proficiency.

The most important lesson I want you to take from this blog is to understand what kubernetes is? and why we use it?

In the era of micro-service architecture, applications are structured as a collection of services which are loosely coupled, easily maintained, independently organized, and owned by smaller teams. This is possible by containerizing different services within an application and using API calls to communicate among them.

This all sounds great until your organization thinks of scaling up or achieving above 90% up-time for the application. Managing couple of containers is not an exhausting activity but when thinking of configuring, deploying, and maintaining 100s of containers simultaneously our approach should be re-evaluated. This is where Kubernetes comes in the picture and automates the container management tasks.

Background Information:

Kunernetes: Is an open-source software which helps managing and orchestrating containers.

It was first developed by google engineers and later donated to Cloud Native Computing Foundation (CNCF).
It is an orchestration tool to deploy, scale up, and manage multiple containers together, therefore automating and enhancing the maintenance process of micro-services. Kubernetes main benefits are:
- assist communicating among containers
- Deploy them properly
- Manage them carefully
- Auto scaling: Always making sure there is certain number of container's copies available.
- Load balancing: Distributing the traffic.
Kubernetes cluster are usually made up of two main parts:
- Master (schedules application services)
- Nodes (listens to the orders from the master)

Now that we have a bigger picture of kubernetes and why we use it, let's dive inside of the cluster architecture and learn about the different components.

Components

Master: Is the control plane (main controller) of the cluster. Usually, users communicate with the master through dashboard graphical interface (GUI) or the command line interface (CLI) via YAML config files. Master's responsibility is to manage all the node events to keep the overall cluster configuration stable and healthy. The multiple components of master are as such:

Kube-APIserver: The front-end of kubernetes which exposes API calls and deals with REST services so developers can communicate with the cluster.
ETCD: Manages state of the cluster. Try to look at it as the database of kubernetes. As a developer, you have to find a reliable method to backup these information in case of a master's crash.
Kube-Scheduler: As the name suggests, it schedules the newly created pods into the nodes based on the given resource requirements.
kube-controller-manager: consists of multiple controllers which manages the cluster and nodes. For example:
- Replication Controller: handles the replicas (series of identical pods)

NODE: Is a part of the kubernetes run-time environment and is hosted on a separate VM or physical machine than the master. Nodes have a series of pods inside of them which allow containers to run inside of them. Node responsibility is to monitor pods and report back to the master. Node's components consist of:

Pods: A logical collection of containers (like docker containers) which need to interact with each other for an application to work. Furthermore, Pods have series of cgroup, kernel space, union file systems inside of them.
Kubelet: Each node has a kubelet which makes sure required podSpects are running healthy on the node. This agent can then report back to the master. their other tasks are to:
- Communicate With API server.
- Execute pods' containers via a container-engine.
- Mount and run pod-volumes and secrets.
- Execute health checks and report back to master.

Podspec: Is a YAML file that describes what each pod should have.

Good to note that kubelets usually use an endpoint to communicate such as tcp:10255.

Kube-proxy: Allows network traffic finds the right node and right pod inside (learn more about networking).

I hope by now you have a high level understanding of different kubernete's components and their role to enable orchestration.

Cool beans, but how do I control and use all of these?

As a devops specialist, you should be able to talk to this kubernetes beast by configuring certain controllers. Therefore, you can spin up your cluster and run your containers reliably inside.

Controllers

Controllers help with application reliability, scaling, and Load balancing. We need to understand different kinds of controllers within kubernetes:

Replicates: Ensures the certain number of pods are running at all times. We use replica-sets to scale up and scale down the pods.
Deployments: Declare updates for pods and replicates. Basically, a deployment manages replicates and replicates manage pods.
DaemonSets: Ensures all nodes copy a specific pod. Monitoring the pods on the nodes to make sure there are all identical.
Jobs: Usually a supervisor process. Jobs are individual processes that happen once or periodically such as database backup.
Services: Allow communication between a set of deployment. Services can be:
- Internal: IP only reachable within cluster.
- External: Endpoint available from node ip.
- Load balancer: Expose the application.
Labels: As the name suggests, it helps us to label and organize components. you can search, delete, and run services based on their labels. We use selectors to find labels.
Selectors: You can use them in two different method:
- equality-based selectors: (==, !=)
- Set-based selectors: (IN , NOTIN, EXISTS)
Namespaces: Give authentication and authorization to different users. extremely useful for bigger teams.

Congratulations! now you know the basic knowledge needed to start getting your hands dirty with the code...

Next step .... code