$ git push origin mainUsername for 'https://github.com': usernamePassword for 'https://username@github.com': passwordfatal: Authentication failed for 'https://github.com/username/my-repository.git/'

Finally, I solved this issue but I wanted to share this with others so it might be helpful.

Authenticate on Github

To solve this issue, we need to set up a personal access token (PAT) for authentication. First, we need to go to the GitHub settings, and from there we need to scroll down and click on Developer settings.

After that, we need to click on Personal access tokens and from the drop-down, select Tokens (classic).

Now, we need to click on Generate new token, and from the drop-down, choose to Generate new token (classic).

Now, you will get a personal access token and paste it into the Password for 'https://username@github.com' field when you authenticate via the command line.

$ git push origin mainUsername for 'https://github.com': usernamePassword for 'https://username@github.com': PersonalAccessToken

Hopefully, this article will help you if you have faced a similar issue. If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

We'll go through some important Git commands in this article to help you become an expert in version control.

1. git config

To configure Git in your local machine, the git config command is used. It enables you to set up your name and email, define aliases for frequently used commands, and set various preferences.

#To display the current configurationgit config --list#To set up your name and email addressgit config --global user.name "Your Name"git config --global user.email "youremail@example.com"#To define an alias for frequently used commandsgit config --global alias.co checkout

This git config --global alias.co checkout will create an alias "co" for the "checkout" command. So, now you can type "git co" instead of typing "git checkout".

2. git init

A new Git repository is set up using the git init command. In the current directory, it generates a new .git subdirectory that contains all the files required to manage the repository. To create a Git repository, this command must be used once at the beginning of a project.

Imagine you wish to use Git for version control when starting a new software project. The first thing you would do is to initialize a new Git repository using the git init command in the directory (Let's say ~/Desktop/my-project) where you want to keep that project. So, you need to go to that directory and run the following command to initialize the Git which will only create a local git repository.

git init

3. git remote

If you want to push your commits to a remote repository like GitHub, GitLab, or others, the first thing you need to do is to create a remote repository there and then configure the local repository you have just created to push to that remote repository. To do this, you need to run the following command:

git remote add origin https://github.com/<your-username>/my-project.git

This command will add a remote called "origin" to the local repository, which directs to the URL of your remote repository on GitHub. After executing this, you can push your local changes to the remote repository by running git push.

If you want to remove the local Git repository from a remote origin repository, you can use the following commands:

git remote remove origin

To check if there are any remote repositories associated with your local Git repository, you can use the following command which will list all the remote repositories associated with your local Git repository.

git remote -v

4. git add

To add files to the staging area, use the git add command. Changes are temporarily held in the staging area before being committed. Every time a file needs to be committed after being modified, this command needs to be run.

Let's say you have a project that contains the file named main.txt. You wish to commit the file's modifications to your Git repository because you made some changes to it. But, you must first add the file to the staging area using the git add command before you can commit the modifications.

git add main.txt

In case you have modified multiple files in your local repository and want to commit all those files to your Git repository, you can run the following command:

git add .

5. git commit

The local repository is updated using the git commit command. It is used to create a snapshot of the staged modifications along a timeline of a Git project's history. Each commit includes a message that details the modifications made.

git commit -m "Added new content to main.txt"

The -m option allows you to add a commit message that details the changes made in the commit. It is recommended that the commit message should be descriptive and summarize the changes you made.

6. git push

To submit local repository changes to a remote repository, the git push command is used. After a commit, this command must be executed to make the changes available to other developers.

git push origin master

7. git pull

The git pull command is used to update the changes from the remote repository to the local repository. Before making any changes to the local repository, this command must be executed to make sure it is up-to-date.

git pull origin

8. git status

The git status command displays the local Git repository's current status. It displays information about any deleted or untracked files as well as changes made to the local working directory, staging area, and repository.

git status

9. git clone

A copy of a remote repository can be made on a local machine using the git clone command. When creating a new development environment or working on a project with multiple developers, this command is helpful.

git clone <URL of the repository>

10. git branch

You can create, list, or delete branches with the git branch command. It allows the developer to work on different features or versions of the project without affecting the main branch. To start a new branch or change branches, this command must be used.

To list all the branches we can use the following command:

git branch -a -v

To delete a local branch, you need to run the following command:

git branch -d new-branch#To delete a local branch forcefullygit branch -D new-branch

Git will not allow you to delete the local branch if there are unmerged changes in that branch. In that case, you need to use -D flag that will forcefully delete that branch.

To delete a remote branch, the following command needs to be executed but if the remote branch needs to be deleted forcefully then the --force/--f flag should be used.

git push origin --delete new-branch#To delete the remote branch forcefullygit push origin --delete --f new-branch

11. git diff

The git diff command displays the modifications made to a file or set of files between two versions.

git diff

12. git log

A list of commits made to the repository is displayed by the git log command. It shows the information about the commit, including the author, date, and commit message.

git log

13. git merge

The git merge command is used to combine changes from one branch into another branch. When working on the same code, developers can utilize this to integrate their changes before putting them up in a branch.

git merge

14. git show

The git show command provides information about a particular commit. It display the changes made in the commit and other metadata, such as the commit message, author, and date.

git show

15. git reset

The git reset command resets the repository's state to a particular commit. It can be applied to undo repository modifications or to undo erroneous commits. With the git log command, you can get the commit id.

#To reset the reposiotry to a specific commit idgit reset [commit id]#To reset the repository to the previous commitgit reset HEAD^

This git reset HEAD^ will reset the repository to the previous commit and move the HEAD pointer back to one commit.

16. git stash

Changes that are not yet ready to be committed are stored temporarily using the git stash command. It can be used to save modifications before merging or to transition between branches without committing changes.

git stash

17. git checkout

To switch between branches or to create a new branch, git checkout command is used.

# Switch between branches:git checkout feature-branch#Create and switch to a new branchgit checkout -b another-new-branch

18. git rm

To remove a file (main.txt) from both the working directory and the Git repository, the git rm command is used.

git rm main.txt

If you want to keep it in the working directory but remove from Git repository, you can use the following command:

git rm --cached main.txt

Conclusion

In conclusion, Git is a crucial tool for version control in software development. You can become an expert in version control by learning these key Git commands as well as other Git commands. These commands make it possible to manage the codebase and collaborate effectively with other developers. Git commands not only help you save time but also enable you to track changes, correct issues, and maintain a transparent history of the project. You may work smarter and more productively in software development by correctly using Git commands.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

Kubernetes 101: Essential Concepts to Master Before You Begin

So, this article is for you whether you're a beginner just getting started with Kubernetes or an experienced user trying to enhance your understanding. Let's explore some of Kubernetes' key components to realize the full potential of container orchestration! Hopefully, by the end of this artile, you'll have a solid understanding of each of these components as well as how to deploy and manage your containerized apps using them.

Some of Kubernetes' essential components are:

1. Pods

2. Service

3. Ingress

4. ConfigMap

5. Secrets

6. Deployments

7. ReplicaSet

8. StatefulSets

1. Pods

A pod is known as the smallest deployable unit in Kubernetes which represents a single instance of a running process. Pods run inside a node which is a physical or virtual machine in a Kubernetes cluster that runs containers. Usually, a pod is meant to run one container inside it but it can contain multiple containers as well. One common use case is a pod is the sidecar pattern where a main application container run alongside one and more sidecar containers for providing different functionality. For example, a single container inside a pod runs an instance of a web server like Nginx or Apache but in case there are two containers, then the main container runs a web server, and the other running sidecar container provides logging or monitoring capabilities.

In the diagram, we can see that node contains two pods and each pod has a container running inside it. One pod has a my-app container and another pod has a database container.

2. Service

In Kubernetes, when pods are created, they are assigned an internal IP address to communicate with each other. If a pod is recreated, it may be assigned a different IP address that's why these IP addresses are not stable. So, if my-app is communicating with the database app using an internal IP address, we need to adjust the IP address every time the database pod recreation.

To prevent this issue, another component of Kubernetes Service is used. A Service provides a stable IP address for pods. Even if pods are recreated, the Service and its IP address will stay. In the above diagram, if my-app pod will be recreated, it will not affect the life cycle of its service. The service and its IP address will be the same, so we don't need to adjust any IP address anymore. Services also act as a load balancer which means that it catches traffic and forwards it to the pod that is the least busy.

3. Ingress

An Ingress is a Kubernetes component that enables you to expose your services to the public internet. An Ingress performs as a reverse proxy, forwarding incoming requests to the appropriate service based on the rules that you define on the ingress resource. Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer.

In this diagram, we are exposing the my-app application over the public internet. Here, a request from a client first goes to the ingress and then the ingress sends that request to the service of the my-app pod.

4. ConfigMap

A ConfigMap provides a way to store configuration data in key-value pairs for an application separately from your application code. It is an external configuration file for an application. It can be used to store environment variables, database endpoints, or other application settings. It is connected to the pods, so pods can get data that ConfigMap contains.

In this example, to communicate with the database pod, my-app will have a database endpoint/URL named "my-db-service". If we put this endpoint in the application as an application properties file or as an external variable, it will be a problem if the URL will change to "db-service". In that case, the application needs to rebuild which creates a complicated process. We can avoid all these hassles if we simply put this database endpoint in the ConfigMap and adjust it in case of any changes.

5. Secrets

A Secret gives an application a method to store sensitive information like usernames, passwords, certificates, or API keys in an encrypted format. This component is similar to ConfigMap. The only difference is ConfigMap is used to store information in a plain text format while Secrets are used to store encrypted data securely. Secret also needs to be attached to the pod, so that pod gets those secure contents from it.

In this diagram, we can add the database's credentials inside the Secret with proper encryption and connects it to the my-app pods to get those credentials securely.

6. Deployment

A Deployment is a high-level object that manages the deployment and scaling of a set of replicas of a pod. It is known as the blueprint of a pod. It ensures that the desired number of replicas is always healthy and running. It provides a declarative approach to specify your application's desired state, along with the container image, the number of replicas, and any other configuration options. Kubernetes automatically handles the deployment of new replicas and the termination of old replicas when you change the configuration of the Deployment, ensuring that your application is always running and up-to-date.

For example, if we specify 2 replicas in the deployment file of the my-app pod, it will create another pod in another node of the Kubernetes cluster which will also connect to the same Service. In the diagram, we can see that if a pod dies, the service will forward the traffic to another pod running in another node in the same cluster as the Service works as a load balancer. In this way, we can ensure that our application is always running and healthy.

7. ReplicaSet

In Kubernetes, a ReplicaSet makes sure that a certain amount of pod replicas are running at all times. For pods, fault tolerance and scalability are ensured by replica sets. ReplicaSet shouldn't typically be created explicitly. Deployment, on the other hand, is a higher-level object that manages ReplicaSets and gives Pods declarative updates. Instead of using ReplicaSets explicitly, Deployments are recommended.

8. StatefulSet

A StatefulSet maintains a set of stateful Pods and ensures a specified number of stateful pods are always running. A StatefulSet is used for applications that require stable and unique network identities or persistent storage, such as databases. If we want to use the replication of the database pod in another node, we can't use the deployment because the database has its state which is its data. In this case, we need to use StatefulSet which ensures that database reads and writes are synchronized. Deploying a database using StatefulSet is a bit complicated compared with Deployment. So it is recommended to host a database outside the Kubernetes cluster.

Conclusion

In conclusion, Kubernetes is a powerful platform for container orchestration that provides a wide range of components to support the deployment and scaling of your apps. We looked at 8 key Kubernetes parts in this article: Pods, Services, Ingress, ConfigMaps, Secrets, Deployments, ReplicaSets, and StatefulSets. You can construct reliable, scalable, and resilient applications that take full advantage of Kubernetes by comprehending about these components and how they work.

References

1. https://kubernetes.io/

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

Kubernetes and How It Works

As technology is rapidly changing, the deployment, scaling, and maintenance of containerized applications are all automated via the open-source container orchestration technology known as Kubernetes.

Containerization is a process of packaging software in a way that it can run reliably across different computing environments. It has grown in popularity in recent years because it enables developers to build, package, and deploy applications more rapidly and consistently. Several applications can operate on a single host operating system using this containerization technique without interfering with one another. Each container has its own set of dependencies, libraries, and configuration files and is isolated from the others.

Let's understand more clearly with an example. Consider running a web application you have for development purposes on your local environment. To function, the application needs particular versions of Node.js, a database, and a few third-party libraries. As you are using your computer for other purposes as well, installing these dependencies globally and running the chance of conflicts with other programs is not something you want to do. Instead, you can package the application and its dependencies separately from the rest of the system by the container and run in any computer that supports containerization technologies, such as Docker. That container can also be deployed to a cloud platform like AWS or Google Cloud and based on demand, it can be quickly scaled up or down, making it simple to handle traffic peaks without over-provisioning resources.

A Container Orchestrator is a tool that simplifies the management of containerized applications and helps ensure that they are running properly across a distributed system which automates tasks such as network configuration, scaling, and load balancing. Kubernetes is created based on this principle that provides a powerful set of features for managing containerized applications such as:

1. Container orchestration: Kubernetes helps to automate the deployment, scaling, and management of containerized applications across a cluster of nodes.

2. Service discovery and load balancing: Kubernetes has an internal DNS system that helps to discover containers and communicate with each other. It also offers load balancing for distributing traffic between containers.

3. Self-healing: The health of containers is being monitored continuously and restarted or replaced automatically by Kubernetes if they fail or become unresponsive.

4. Auto-scaling: Kubernetes can automatically scale the number of containers based on resource utilization and spikes in traffic.

5. Rolling updates and rollbacks: Without downtime, Kubernetes offers a way to perform updates to containers and if there are any critical issues, It allows for easy rollbacks.

6. Config management: Kubernetes offers a way to manage configuration files and environment variables for containers.

7. Storage orchestration: Kubernetes can manage storage for containerized applications, including persistent storage volumes.

8. Security: Kubernetes offers a range of security features, including role-based access control (RBAC), network policies, and container image verification

Kubernetes Architecture and Components

As a distributed system for managing containerized applications, Kubernetes is composed of a cluster of nodes and those nodes in a Kubernetes cluster are divided into two types:

1. Master node

2. Worker Node

The Component of Kubernetes cluster (Source: Kubernetes)

1. Master Node: The master node runs the Kubernetes control plane components which is a collection of Kubernetes components that are responsible for managing the state of the cluster, scheduling applications, and maintaining communication between nodes. Control plane containers the following components:

• Kubernetes API server: This is the central management point for the Kubernetes cluster. It provides an HTTP REST API that allows end users to interact with the Kubernetes cluster, including creating and managing pods, services, and other objects. The other cluster components also communicate with this API server. The API server is responsible for exposing the cluster API endpoints and processing all API requests as well as authentication and authorization. This API server is the only component that communicates with etcd and also coordinates all the processes between the control plane and worker node components.

• etcd: This is a distributed key-value store used by Kubernetes to store cluster configuration and state information. We can call it the brain of the cluster. It provides a reliable and consistent way to store data across the cluster. etcd stores all configurations, states, and metadata of Kubernetes objects such as pods, secrets, deployment, daemonset, configmaps, etc. As it was mentioned earlier, It only communicates with the API server.

• Kubernetes Scheduler: This component is responsible for scheduling pods onto worker nodes based on available resources and other constraints.

  To deploy a pod, we specify the pod requirements that include CPU, memory, priority, persistent volumes (PV), etc and they deploy it in the cluster. Then Kubernetes scheduler identifies the pod creation request and chooses the best node for a pod that satisfies all the requirements.

• Kube Controller Manager: In Kubernetes, controllers are programs that run endless control loops which continuously observe the state of objects in case there is any difference between the actual and desired state of those objects. The controller manager runs the core controllers that monitor and takes necessary action to maintain the desired state.

• Cloud Controller Manager: The Cloud Controller Manager (CCM) is a component of the Kubernetes control plane that runs when Kubernetes is deployed in cloud environments. It provides an interface between the Kubernetes control plane and the cloud platform API and enables interaction between Kubernetes and the cloud provider's underlying infrastructure. Load balancers, block storage, network routes, etc are a few of the resources that CCM is responsible for managing.

2. Worker Node: The worker node(s) are responsible for running containers and serving application traffic. They contain the following core components:

• Kubelet: This is an agent that runs as a daemon on each worker node and communicates with the Kubernetes API server to manage containers and pods from pod specification. It creates containers based on pod specifications. By starting, stopping, and restarting the containers as needed, the Kubelet makes sure they are running and in good condition. Moreover, it monitors how much CPU and memory are being used by the containers and provides this data to the Kubernetes API server.

• Kube-proxy: The kube-proxy is a network proxy and load balancer for Kubernetes services. It executes on each worker node as a daemonset and routes traffic to the proper container or pod in accordance with the configuration of the service. Iptables rules, which is a default mode, are used by the kube-proxy to control network traffic and guarantee the service's scalability and high availability. With this mode, kube-proxy choose the backend pod randomly for load balancing. Once the connection is made, requests are sent to the same pod until the connection is broken.

• Container runtime: Container runtime is a program that runs containers on worker nodes. It runs on all the nodes in the Kubernetes cluster. It is responsible for starting and stopping containers as well as pulling images from container registries, and allocating containers resources such as CPU and memory. Organizations can select the container runtime that best suits their needs thanks to Kubernetes' support for a variety of them.

Conclusion

In this article, we have discussed the fundamentals of Kubernetes, such as containerization, container orchestrators, and the main elements of the Kubernetes architecture. We've seen how Kubernetes offers attributes like fault tolerance, scalability, and high availability, all of which are essential for operating mission-critical applications.

The fundamental building blocks of Kubernetes, known as Kubernetes objects, will be covered in more detail in the forthcoming article. We will explore the different types of objects, their properties, and how a Kubernetes cluster can use them to manage its resources and applications.

Stay tuned for more information about the interesting Kubernetes world!

References:

1. https://kubernetes.io/

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

In this article, I am going to discuss how I have solved this issue and additionally, before that, I will discuss .envrc and direnv

.envrc

Environment variables and their values can be defined in configuration files called .envrc files which stand for "Environment RC" files. Sensitive data that shouldn't be committed to version control, such as API keys, credentials, and other configuration data, is typically stored in this file. The file, which contains a list of key-value pairs that can be exported as environment variables, is usually stored in the project's root directory.

Similar to .envrc, .env is also a configuration file that sets environment variables but the main difference is that .envrc is specific to direnv, whereas .env is a general-purpose file that may be used by any tool or framework.

Consider that you are working on a project that calls for an API key from a third-party service. In the root directory of your project, run this command in the terminal:

vim .envrc

Then insert this line in the .envrc file:

export API_KEY=YOUR_API_KEY

direnv

Environment variables can be managed using the tool known as direnv, which stands for "directory environment," in a flexible and secure way compared to conventional methods. It allows you to define environment variables for specific directories and automatically exports them when any change has been made into those directories. This can be helpful for projects that need various environment variables for various settings, such as production, staging, and development, or for various stages of development.

Steps to Fix the direnv allow Error

Basic Installation

To install direnv in MacOS, run this command in the terminal:

brew install direnv

Hook direnv into the Shell

direnv must be linked to the shell in order to function properly. Each shell has a unique extension system. Now add the following line at the end of the ~/.zshrc file:

eval "$(direnv hook zsh)"

If you are using Bash then add the following line at the end of the ~/.bashrc file:

eval "$(direnv hook bash)"

In these examples:

• eval function evaluates the string that is passed to it as a shell command.

• To use direnv in the shell, the direnv hook zsh command generates a string of Zsh shell commands to configure.

• For Bash, it's doing the same mechanism.

Configuring the hook of direnv, restart your shell to work properly.

After that, the following command needs to be executed in the terminal to make direnv work.

direnv allow

N.B: If you update the .envrc file, you need to execute the direnv allow command again.

Retrieve Environment Variable

Once the direnv allow command will be executed, you can load the environment variables. You can use the API_KEY variable in your code like this:

import osapi_key = os.getenv("API_KEY")

In this example:

• We need to import os which is a Python built-in module that offers a means to communicate with the underlying operating system. Sometimes, Python interpreter might include this os module by default.

• In the Python os module, there is a function called os.getenv that returns the value of an environment variable.

Conclusion

In conclusion, .envrc and direnv are essential tools for managing your environment variables and making sure that your development environment is configured correctly. The methods described in this article can help you identify and fix any problems, including the direnv allow error. You may optimize your development process and improve your efficiency by following these best practices.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

In this article, we'll look at the 12 kubectl commands that any Kubernetes administrator needs to be familiar with. These commands will help you master Kubernetes, from managing and debugging apps to creating and updating resources. This article will provide you a thorough overview of the most important kubectl commands, whether you're an experienced Kubernetes user or you're just getting started.

1. kubectl cluster-info

This command provides information about the current state of your Kubernetes cluster, including the API server address, the cluster state, and the versions of the components that make up your cluster.

kubectl cluster-info

2. kubectl version

This command displays the version of kubectl that is currently installed on your system, as well as the version of the Kubernetes cluster that it is connected to.

kubectl version

3. kubectl get

This command will provide a list of resources available in your Kubernetes cluster. There are several types of resources:

• Namespace

• Deployment

• Pod

• Node

• Service

• ReplicaSets.

kubectl get all

This command will give the list of all of those available resources in your cluster. To pull a list of a specific resource, you need to use the following command in your terminal.

kubectl get deployment

For a specific namespace:

kubectl get deployment -n namespace

Here, -n is the short form of the flag -namespace. If you don't use any specific namespace, then kubectl get deployment command will return the deployment list from the "default"/current namespace. A namespace is a Kubernetes object that separates a single physical Kubernetes cluster into numerous virtual clusters.

Similarly, If you need to fetch the list of all the pods in a namespace, you can use this command:

kubectl get pods -o wide

here, "-o wide" flag is providing more details about the pod.

So, with this kubectl get command, we can also fetch the list of Node, Namespace, ReplicaSets and Service

4. kubectl Create

The Kubernetes command kubectl create is used to add new resources to a cluster. Users can build resources like pods, services, and deployments using this commands. Here's an illustration of how to build a new deployment using kubectl create:

kubectl create deployment my-nginx --image=nginx

With this command, a new deployment named will my-nginx will be created using the nginx image.

Here is another example of how to create a new cronjob with this command:

kubectl create job my-cronjob --schedule="*/5 * * * *" --image=busybox -- command -- args="echo This is a cron job!"

With this command:

• A new CornJob will be created named my-cornjob which will be running in busybox container

• An echo command will be repeated every 5 minutes

• --schedule flag specifies the schedule for the job in cron syntax

• "*/5 " means to run the job every 5 minutes

• --image flag specifies which container it should run

• --command flag is used to specify which command it should run inside the container.

With Kubernetes' CronJobs functionality, you can automate recurring processes like database backups, log rotations, and more.

5. kubectl edit

With this kubectl edit command, you can edit an existing resource in a cluster. You can modify a resource's configuration in a text editor using kubectl edit, which eliminates the need for you to manually generate a new YAML file.

Here's an illustration of how to change a deployment using kubectl edit:

kubectl edit deployment my-nginx

This command starts a text editor and opens the my-nginx deployment. When you make changes to the deployment's configuration and save the file, the cluster's deployment will be updated.

6. kubectl delete

kubectl delete command will help you to delete any resources such as pod, deployment, service, cornjob in your Kubernetes cluster. So, never just remove anything without knowing everything you need to know about it. Think carefully before executing this command since once the resource is deleted, it cannot be recovered; you must reconstruct it.

kubectl delete deployment my-nginx

7. kubectl apply

The Kubernetes command kubectl apply enables you to create or modify resources in a cluster. Kubectl apply creates or modifies the resource in the cluster to match the configuration by reading the resource's configuration from a file or from standard input.

kubectl apply -f deployment.yaml

Here, kubectl apply command reads a deployment configuration from a file named deployment.yaml and creates a new deployment in the cluster depending on that configuration file. In case, if there will be a file existed on that name, then this command will update that configuration file.

8. kubectl config

In Kubernetes, the command kubectl config allows you to manage the configuration for a kubectl client. The config command can be used to view, edit, or switch between multiple cluster configurations, as well as to manage user credentials and context settings.

Set a Current Namespace

If you are working on a specific namespace, then every time typing a namespace in each command is a hassle. To overcome this, you can set that namespace as a current namespace.

Here is an example of how to set up a current namespace:

kubectl config set-context --current --namespace=NAMESPACE

kubectl config set-context is a command in Kubernetes that allows you to modify the context of a kubectl configuration. The context defines the cluster, user, and namespace that kubectl commands operate. In this example, this command will set the current namespace as "NAMESPACE".

Set Current Context

A context is defined as a named group of clusters and user credentials in the Kubernetes cluster. To set a context, you need to execute the following command:

kubectl config use-context docker-desktop

In this example, this command is used to switch the current context in the kubectl configuration to the docker-desktop context. So, kubectl commands can interact with the cluster running on docker-desktop. You can also use minikube instead of docker-desktop if you want to interact with the cluster running on minikube.

You can check the current context by running this command:

kubectl config current-context

9. kubectl describe

kubectl describe is a useful tool for monitoring and debugging your Kubernetes cluster. It offers a quick approach to obtaining comprehensive information about a resource, making it simpler to understand the resource's current state and spot any problems. It shows details about a resource's status, events, and metadata.

Here is an example:

kubectl describe deployment my-nginx

With this command, you can get details information on my-nginx deployment which includes the status of the deployment, the events that have occurred, and the metadata associated with the deployment.

10. kubectl logs

You may get the logs of a container in a pod using the Kubernetes command kubectl logs. The logs can be used to track down problems with a container or to troubleshoot problems with it.

Here's an example of how you can use kubectl logs

kubectl logs my-pod

If there will be multiple containers in a pod, we can get the log of a specific container this way:

kubectl logs my-pod -c my-container

Here, -c is an option that specifies the name of the container from where you want to retrieve the logs.

11. kubectl exec

You can execute a command in a running container of a pod using the Kubernetes command kubectl exec. It is helpful for debugging, troubleshooting, and monitoring the status of an application.

Here's an illustration of how kubectl exec might be used:

kubectl exec -it pod-name -- bash

In this example, kubectl exec is used to launch a bash shell in the container of the specified pod. The -it flag is used to attach to the shell and interact with it.

If you have multiple containers in a pod, you can use the following command:

kubectl exec -it pod_name -c container_name bash

In this example, -c is used to specify the container name where the shell command will be executed.

12. kubectl cp

In Kubernetes, the command kubectl cp allows you to copy files and directories between a local file system and a container in a pod, or between two containers in the same pod. This can be useful for transferring files between the host and containers, or for copying files between containers within a pod.

kubectl cp <local-file-path> <pod-name>:<container-destination-path>

In this example:

• kubectl cp is used to copy a local file to a container in a pod.

• local-file-path specifies the path to the file on the local file system.

• pod-name and container-destination-path specify the destination of the file within the container.

Conclusion

With that, we have come to the end of this discussion on the 12 kubectl commands for mastering Kubernetes deployments. Please keep in mind that these are not the only kubectl command and there are many more Kubernetes concepts and kubectl commands to investigate.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

In this blog, we will examine the essential elements of an effective disaster recovery plan, including RTO, RPO, and RTA which will help you to keep your business up and running, no matter what life throws your way.

Disaster Recovery

Disaster recovery (DR) refers to the process of anticipating and recovering from unexpected events. The possibility of a disaster, whether natural or man-made, is quite real in a society where technology is the backbone of the economy. Disaster recovery, however, may be a lifesaver with the correct strategy and execution, ensuring that your company remains functioning even in the aftermath of a disaster. The essential elements of an effective disaster recovery plan, from RTO to RPO to RTA, all work together to safeguard your crucial systems, data, and activities. Having a strong, focused, and tested disaster recovery plan is a fundamental need for a business when things go wrong.

Recovery Time Objective (RTO)

RTO refers to the maximum amount of time the application can be offline which will be determined by the business and the DR solution should be able to restore functionality based on the business and all other requirements.

Recovery Point Object (RPO)

RPO is the measure of acceptable data loss in case of a disaster and it determines how much of the last known good data will be recovered based on the backup and replication policies.

Recovery Time Actual (RTA)

RTA stands for Recovery time actual or achievable. This is a measurement of the actual recovery time that was shown during a test run for disaster recovery. The gap between RTO and RTA is an important metric to track. Testing the DR solution regularly will reveal RTA trends over time.

• RTA<RTO then RTO indicates success or lower RTO which is good

• RTA>RTO then RTO indicates the failure to meet business goals or unachievable RTO

Three Disaster Recovery Strategies

Hot Site

A hot site is a fully functional backup location that offers an organization's whole infrastructure, including hardware, software, and data, to enable business continuity in the case of a disaster. A business might set up a hot site at a different location with the same servers, networking hardware, and data storage devices as its main site, along with all necessary data and programs that are pre-installed and updated. The business may immediately move to the hot site in the case of a tragedy and go on with little interruption.

Cold Site

A cold site is a pre-configured facility with minimal power and infrastructure but no hardware or data placed at the time of setup. To store its backup hardware, for instance, a business might rent a sizable data center with enough room, electricity, and cooling, but without any hardware or data already in place. Before using the cold site as a backup location, the organization must first install the needed equipment and software and restore data in the event of a disaster.

Warm Site

The middle ground between the two disaster recovery alternatives is a warm site. It is a backup location that has been pre-configured and is only partially operational, but it includes servers and networking equipment that are necessary for a business to continue operating in the event of a disaster but it might not have all the necessary data and programs pre-installed.

Testing DR Solution

The significance of testing and upgrading disaster recovery plans on a regular basis is to maintain preparation for actual disasters. For instance, a business might have a plan in place for disaster recovery that calls for moving activities to a warm site in the case of a catastrophe. The warm site may not be fully functional or its data may be outdated, which might cause delays and disruptions in the company's recovery operations if the plan is not routinely evaluated and updated. Companies should test their disaster recovery plans on a regular basis and update them as needed, whether that means installing new hardware or software, upgrading data backups, or changing the plan itself to reflect changes in the organization's operations.

As a result, there will be less downtime and business continuity will be maintained in the event of a disaster. This helps to ensure that the disaster recovery plan is prepared to be activated at a moment's notice.

Best Practices

To make sure they have all the information they need in the case of a disaster, organizations should regularly backup their data. To respond to a disaster in an efficient and organized manner, it is also essential to have a clear communication plan in place that specifies who to contact and what information to share. Finally, it's critical to train employees on the disaster recovery plan so that they are all aware of what to do in an emergency. Businesses may assure that they are ready to respond to disasters and reduce downtime and data loss by putting these best practices into effect.

Conclusion

In conclusion, disaster recovery is an essential component of corporate operations that needs careful planning and preparation. As DR affects business cost and reputation, a proper RTO and RPO should be determined by business decisions. Lower RTO and RPO solutions may be more expensive, but they can give businesses more security and reduce downtime in the event of a disaster. To monitor RTA and ensure readiness, the disaster recovery plan must undergo regular testing. The ability to promptly respond to a disaster and maintain business continuity depends on having a solid disaster recovery solution in place and available.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

In this article, let's look at how we can set up Minikube for MacOS

Step 1: Install Homebrew

Homebrew, a popular package manager for macOS, can be used to install Minikube. Run the following command in your terminal if Homebrew isn't already installed on your device:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Step 2: Install Minikube

To install Minikube, run the following command in your terminal using Homebrew:

brew install minikube

Step 3: Start Minikube

You can start Minikube by running the following command in your terminal:

minikube start

If you have a Docker machine installed in your MacOS, you might get the following error while executing the above command. To solve this issue, you need to start the Docker desktop application and rerun the command.

  Exiting due to DRV_DOCKER_NOT_RUNNING: Found docker, but the docker service isn't running. Try restarting the docker service.

Step 4: Set Context

Now you need to set the context to minikube so that the kubectl command can interact with it:

kubectl config use-context minikube

Step 5: Verify Minikube Setup

Now you can verify the status of Minikube using the following command in your terminal:

minikube status

Step 6: Interacting with Cluster

To interact with the newly created cluster in your MacOS, you need to run the following command in your terminal if you have kubectl already installed:

kubectl get po -A

But, if you don't have kubectl installed on your MacOS, then run the following command where minikube can download the appropriate kubectl version:

minikube kubectl -- get po -A

Step 7: Testing Minikube

Now, we can test the minikube by deploying a simple application by following the command in the terminal:

kubectl create deployment hello-minikube --image=kicbase/echo-server:1.0kubectl expose deployment hello-minikube --type=NodePort --port=8080

This might take some time but if you run the following command, the deployment will show up:

kubectl get services hello-minikube

Letting Minikube open a web browser for you is the simplest approach to using this service. To do that run the following command in the terminal:

minikube service hello-minikube

Step 8: Access Kubernetes Dashboard

To access the dashboard of Kubernetes, you need to run the following command which will open a Kubernetes dashboard on the web browser with a user-friendly interface:

minikube dashboard

Conclusion:

In this article, we have learned about Minikube and how to set it up on MacOS with a step-by-step process.

I hope this article has helped you to explore Minikube's capabilities for testing and deploying applications on a single node of a Kubernetes cluster.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

I will try other platforms as well for the cross-posting and I will review those in a future blog post.

What is dev.to

The online social media community and platform dev.to, which stands for "Developer Community," was created especially for programmers and other tech-related hobbyists. It provides a variety of tools, including blogging, forums, job postings, and events, all aimed at building a sense of connection and community among developers around the world. The platform promotes the exchange of ideas and best practices by encouraging users to share their expertise, experiences, and insights with others. Additionally, it gives developers a place to showcase their most recent works and get input from their colleagues, which helps them evolve professionally and strengthen their talents.

What is Hashnode

A contemporary blogging platform called Hashnode makes it simple for users to produce, publish, and share their material with a large audience. It is intended to simplify, streamline, and customize the blogging process, freeing users to concentrate on the blog's content rather than its technical setup and upkeep. Hashnode is a one-stop shop for bloggers trying to expand their online presence because it also provides a variety of services like analytics, comments, and SEO optimization tools. Users can quickly build a blog with a professional appearance, write and publish posts, and share their material on several channels all from one location using Hashnode. Overall, Hashnode is an easy-to-use, adaptable, and feature-rich platform.

What is Cross-Posting

The act of uploading the same content on various platforms or websites is known as cross-posting. This can be done to boost visibility and interaction, reach a larger audience, or just save time by avoiding having to write fresh material for every platform.

Setting up Cross-Posting

1. We need to create an account first in Hashnode

2. Then create an account in dev.to

3. Open the settings and select the Extensions tab

4. You'll discover Publishing to DEV Community from RSS under the Extensions tab. Simply paste the RSS feed URL from your Hashnode into the RSS Feed URL field.

   

5. To get your RSS feed URL, go to your Hashnode dashboard and click on RSS.xml

   

6. A new tab will be opened and you will find your RSS feed URL from the address bar.

   

7. After pasting it into the RSS Feed URL field, click "Save Feed Settings".

8. Then click on "Fetch feed now" and your Hashnode articles will eventually show up as drafts in the dev.to dashboard.

9. You will find the article as a Draft in the dashboard and edit it before publishing it.

10. You might want to add a cover image that will be automatically dragged from Hashnode to dev website. At least, I have faced this issue.

11. So, Upload the image and copy only the part starting from https

12. Add "cover_image" below tags and paste the link.

13. The default value of "published" will be "false" as it is a draft copy. So make it "true"

14. Then click "Save Changes" at the bottom and it will be published instantly.

Conclusion

In conclusion, cross-posting is an effective strategy for bloggers who want to broaden their audience and boost interaction. Blogging professionals can reach new audiences, increase their exposure, and increase traffic to their blogs by distributing their material across a variety of platforms. Popular platforms like Hashnode and Dev.to provide simple cross-posting tools that make it easy for bloggers to distribute their work on several websites. Bloggers can cross-post with confidence by following the instructions in this tutorial, knowing that they are doing everything possible to increase their audience and develop their online presence.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.

What is Base64?

A file (such as an image or video) can be converted into a string of text using Base64 so that it can be transferred over the internet. This is accomplished by taking the file's binary contents and turning it into a set of 64 text-usable characters. In this way, the file can be transmitted as text and still be converted back to its original format once it is retrieved. It's similar to delivering someone a gift wrapped in paper and then having them open the package to retrieve the real gift. In email attachments and when embedding files in HTML, CSS, or JavaScript, Base64 is frequently utilized.

GitLab environment variable

GitLab CI/CD environment variables are used to safely store and manage sensitive data that is required by the pipeline, such as API keys, passwords, and other configuration parameters. You may reduce the security risk of hardcoding sensitive information into your pipeline definition by using environment variables.

While setting up an environment variable, GitLab CI/CD provides a "masked" option that can hide the value of an environment variable from the pipeline logs. This is helpful if we don't want sensitive data, such as passwords and API credentials, to be shown in the pipeline logs. When the "masked" option is on, a variable's value is changed to ***** In the pipeline logs.

Secured pipeline with Base64

Though the "masked" is really an amazing feature of GitLab CI/CD variables, it can't be enabled on multiline variable values. Here comes Base64 which converts the multiline variable values into encoded single-line variable values and after that, I enabled the "masked" option. In the case of single-line values, we can also use Base64 to make it more secure in the pipeline. To mask a variable, there are some certain rules. The variable's value must:

• A single line.

• Characters from the Base64 alphabet (RFC4648).

• The @, :, ., or ~ characters.

How to use Base64

The base64 command-line utility is often pre-installed if you are using a popular Linux distribution like Ubuntu, Debian, CentOS, or Red Hat. There shouldn't be any more actions for you to take.

If you are using Max OS, you can use the HomeBrew command to install base64:

brew install base64

Encoding with base64

To encode a variable, you can use this command:

echo -n "insert_your_variable" | base64

The output of the command is:

aW5zZXJ0X3lvdXJfdmFyaWFibGU=

• The "echo" command is showing the variable's value in the terminal

• "-n" is a subcommand for echo which is telling not to append a newline character to the end of the output otherwise it would additionally append a newline character which will also be encoded by base64 and creates additional problems during decoding.

• | is known as a 'pipe' operator which takes the output of one command and makes the input for another command. In this command, this operator is passing the output of echo -n "insert_your_variable" as the input of the base64 command.

After encoding, add that value as a CI/CD environment variable with the "masked" option enabled.

Decoding with Base64

To decode a variable in the terminal, just use this command with the "-d" or "--decode" after base64:

echo "insert_your_variable" | base64 -d

So, now I am going to show how we can decode the value in the GitLab CI/CD pipeline. We need to use the base64 command to decode our base64-encoded value kept in a variable named SECRET_KEY in a GitLab pipeline. I am giving a project-level example below:

stages:  - deploydeploy:  stage: deploy  script:    - echo "$SECRET_KEY" | base64 -d    - export DECODED_SECRET_KEY="$SECRET_KEY"

The pipeline in this illustration has just one stage, named deploy. At the project level, the variable is stored as SECRET_KEY.

The pipeline initially uses the base64 command to decode the value contained in SECRET_KEY in the script section of the deploy step. After that, the decoded value is then exported and stored in the variable DECODED_SECRET_KEY so that it can be used later in the pipeline.

Conclusion

In this article, you have learned how to do base64 encoding for a variable and stored it in GitLab CI/CD environment variable with the "masked" option. Also, how to decode it in the GitLab pipeline without showing the variable's value in the pipeline logs.

It's crucial to note that using plain text to keep secret keys in your pipeline is not recommended; instead, it's more secure to use GitLab's secret variable feature to store the keys and use them in the pipeline.

I appreciate you taking the time to read this. Your support is much appreciated! If you found this article valuable, please consider clicking the 👉 Follow button and giving it a few claps by clicking the like button to help me create more informative content like this. Thank you for your time! 🖤
Also, follow me on Medium, Twitter & LinkedIn.