Wednesday, February 28, 2024

Kubernetes Essentials: A Handy Reference for DevOps Engineers

 This Kubernetes cheatsheet provides a comprehensive reference for managing Kubernetes clusters and applications efficiently. It includes essential commands for beginners and experienced users. From basic cluster information to advanced deployment strategies and observability tools, this cheatsheet covers everything you need to navigate Kubernetes effectively. Whether you're deploying applications, troubleshooting issues, or optimizing resource usage, this cheatsheet is your go-to resource for streamlining Kubernetes operations.

 Cluster Management:

Contexts:

  • kubectl config get-contexts: Lists available contexts.
  • kubectl config current-context: Displays the current context.
  • kubectl config use-context context-name: Sets the current context to the specified one.
  • kubectl config set-context --current --namespace=<namespace-name>: Sets the default namespace for the current context.

Node Information:

  • kubectl get nodes: Lists all nodes in the cluster.
  • kubectl describe node <node-ip> | grep MemoryPressure: Displays memory pressure for a specific node.
  • kubectl top nodes: Shows current resource usage for all nodes in the cluster.
  • kubectl drain <node-name>: Drains a node for maintenance, evicting pods gracefully.

Namespaces and Resources:

  • kubectl create namespace <namespace-name>: Creates a new namespace.
  • kubectl get pods --all-namespaces: Lists pods in all namespaces.
  • kubectl describe namespace <namespace-name>: Describes details of a namespace.
  • kubectl delete namespace <namespace-name>: Deletes a namespace and all its resources.


Pod Management:

Pods:

  • kubectl get pods --namespace=<namespace-name> -o wide|json|yaml: Lists pods in a specific namespace with additional details.
  • kubectl get pods | grep <POD-NAME>: Filters pods by name.
  • kubectl describe pod: Describes details of a pod.
  • kubectl delete pod <POD-NAME> --grace-period=0 --force --namespace <NAMESPACE>: Deletes a pod forcibly.
  • kubectl logs <pod-name> --tail=<lines>: Retrieves the last few lines of logs for a pod.


Deployment Management:

Deployments:

  • kubectl get deployments: Lists all deployments in the cluster.
  • kubectl describe deployment <deployment-name>: Describes details of a deployment.
  • kubectl scale --replicas=5 deployment/<deployment-name>: Scales a deployment to a specific number of replicas.
  • kubectl edit deployment <deployment-name>: Edits a deployment's configuration.
  • kubectl rollout pause deployment/<deployment-name>: Pauses a deployment rollout.
  • kubectl rollout resume deployment/<deployment-name>: Resumes a paused deployment rollout.

Rollout and Rollback:

  • kubectl rollout status deployment/<deployment-name>: Monitors deployment rollout status.
  • kubectl rollout history deployment/<deployment-name>: Displays revision history of a deployment.
  • kubectl rollout undo deployment/<deployment-name>: Rolls back a deployment to the previous version.
  • kubectl rollout undo deployment/<deployment-name> --to-revision=<revision>: Rolls back to a specific revision.


Troubleshooting:

Logs and Events:

  • kubectl logs <pod-name> --namespace <namespace-name>: Retrieves logs for a pod in a specific namespace.
  • kubectl logs <pod-name> --container <container-name> : Retrieves logs for a pod  from a specific container.
  • kubectl describe pod <pod-name> --namespace <namespace-name>: Describes details of a pod in a specific namespace.
  • kubectl get events --namespace <namespace-name> --sort-by='{.lastTimestamp}': Displays events sorted by timestamp in a specific namespace.

Executing Commands:

  • kubectl exec -it <pod-name> -- /bin/bash: Opens a shell in a running pod. (use /bin/sh instead of /bin/bash if running through powershell window)
  • kubectl exec -it <pod-name> -- powershell: Opens a powershell shell in a running pod.
  • kubectl exec -it <pod-name> --container <container-name> -- /bin/bash: Opens a shell in a specific container of a pod.


Miscellaneous:

Exit Code and Restart:

  • echo $?: Displays the exit code of the last application.
  • kubectl rollout restart deployment <deployment-name>: Restarts a deployment.

Scaling and Deleting Pods:

  • kubectl scale deployment <deployment-name> --replicas=0: Scales a deployment to zero replicas.
  • kubectl delete pods --all --namespace <namespace-name>: Deletes all pods in a specific namespace.

Automated Actions:

  • for each in $(kubectl get pods --namespace <namespace-name> | grep Evicted | awk '{print $1}'); do kubectl delete pods $each --namespace <namespace-name>; done: Deletes all evicted pods in a specific namespace.
  • kubectl get pods | grep <pod-name> | awk '{print $1}' | xargs kubectl describe pod : Describe the pods

 

Saturday, January 21, 2023

CloudFlare Page Rules 101: Understanding and Implementing Redirects

Redirecting your website to a secure HTTPS connection is a crucial step in ensuring the security and privacy of your website visitors. However, this can become tricky when dealing with different subdomains, such as the "www" subdomain. One way to do this is by using CloudFlare Page Rules to redirect all HTTP traffic to HTTPS Or all non-www to www with HTTPS

In this blog post, I will show you how to set up redirects using CloudFlare Page Rules for couple of different scenarios:

  1. Redirecting all traffic from http://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  2. Redirecting all traffic from https://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  3. Redirecting all traffic from http://www.sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1
  4. Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilcloudops.blogspot.com/$1
  5. Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilnewdomain.com/$1 - (external domain)

Before we begin, make sure that your website is set up with a valid SSL certificate and that it is active on CloudFlare.

  • Redirecting all traffic from http://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1

    To redirect all traffic from non-www http to https://www, follow these steps:
    • Log in to your CloudFlare account
    • Select the website you want to redirect
    • Click on the "Page Rules" tab
    • Click on the "Create Page Rule" button
    • In the "If the URL matches" field, enter "http://sunilcloudops.blogspot.com/*"
    • In the "Then the settings are" field, select "Forwarding URL"
    • In the "Status code" field, select "301 - Permanent Redirect"
    • In the "Redirect URL/Destination URL" field, enter "https://www.sunilcloudops.blogspot.com/$1"
    • Click on the "Save and Deploy" button






  • Redirecting all traffic from https://sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1































  • Redirecting all traffic from http://www.sunilcloudops.blogspot.com/* to https://www.sunilcloudops.blogspot.com/$1


  • Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilcloudops.blogspot.com/$




  • Redirecting all traffic of a sub-domain from http://blog.sunilcloudops.blogspot.com/* to https://sunilnewdomain.com/$1 - (external domain)



Thanks for reading, CloudOps Signing Off! 😊

        


Installing a Specific version of Node.js and npm in Azure DevOps pipeline

Node.js is a popular JavaScript runtime that allows developers to build server-side applications using JavaScript. npm is the default package manager for Node.js, and it is used to install and manage packages for Node.js projects.

When building Node.js projects, it is often necessary to specify a specific version of Node.js and npm to be used for the build and release process. This ensures that the same version of the tools is used across all environments and prevents compatibility issues. 

This can be done using the Node Version Manager (nvm) or the Node.js installer.

Using Node.js installer:

You can install a specific version of Node.js and npm by using the Node.js tool installer task in Azure DevOps. You can add the task to your pipeline yaml file and configure it to install the desired version of Node.js and npm:











This will install version 14.18.1 of Node.js and version 6.14.15 of npm on the build agent. you can use the following command to check the version:
  • node -v
  • npm -v

If you want to install a specific version of npm instead of using the version installed by NodeTool you can use below PowerShell command into your pipeline after above task.













This will install version 7.14.0 of npm on the build agent.


Using nvm:

nvm is a command-line tool that allows you to easily install and manage multiple versions of Node.js. To install nvm, you can use the following command in your pipeline yaml file:










Once nvm is installed, you can use it to install a specific version of Node.js in your pipeline yaml file using below:















This will install version 14.18.1 of Node.js and set it as the default version for the pipeline.

You can also install a specific version of npm in your pipeline yaml file using below:













This will install version 7.14.0 of npm.

In conclusion, you can install a specific version of Node.js and npm in Azure DevOps by using the Node Version Manager (nvm) or using the Node.js tool installer task in a pipeline. 


Thanks for reading, CloudOps Signing Off! 😊














Saturday, January 14, 2023

Creating a Self-Signed Certificates for Secure Connections

Self-signed certificates can be used to secure web connections, encrypt data sent over the internet, and can be used to authenticate the identity of the server to the client. In this blog post, we will cover the basics of self-signed certificates, how to create them, and how to use them to secure your web connections.

Creating a Self-Signed Certificate

There are several ways to create a self-signed certificate, but in this blog post, we will cover two popular methods: using mkcert and using PowerShell in-built (New-SelfSignedCertificate) cmdlet.

Method 1: Using mkcert

mkcert is a simple command-line tool that can be used to create a self-signed certificate. To create a self-signed certificate using mkcert, you can use script at and can run on PowerShell.













Once you run the script it will first download the mkcert.exe if not exist, and using that will create the Self-Signed Certificate. 









Your directory will looks like below:















Method 2: Using PowerShell

Another way to create a self-signed certificate is by using PowerShell in-built 'New-SelfSignedCertificate' cmdlet. Here is an example of how to use this cmdlet to create a self-signed certificate:

Option 1: Creating a DNS based self-signed certificate









This command will create a self-signed certificate for the different hostnames and store it in the local certificate store.

Option 2: Creating a DNS + IP Address based self-signed certificate














This command will create a self-signed certificate for couple of domains and IP addresses and store it in the local certificate store.

If you want to have the Signer for the Self-Signed certificate then you can first generate the root  certificate and then pass that root certificate while creating the other Self-Signed certificate.

$rootCert = New-SelfSignedCertificate -Subject 'CN=TestRootCA,O=TestRootCA,OU=TestRootCA' -KeyExportPolicy Exportable -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm 'RSA' -HashAlgorithm 'SHA256' -Provider 'Microsoft Enhanced RSA and AES Cryptographic Provider'

New-SelfSignedCertificate -Subject $certFriendlyName -FriendlyName $certFriendlyName -Signer $rootCert -TextExtension @("2.5.29.17={text}$ip&$dnsNames") -CertStoreLocation "cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -NotAfter (Get-Date).AddYears(10)


Note: Self-signed certificates are not trusted by default and will not be recognized by default trusted root CA, so it is important to inform users that they are visiting a self-signed certificate website.


Thanks for reading, CloudOps 
Signing Off! 😊


Saturday, January 7, 2023

Building Visual Studio Solutions with MSBuild - Command Line

 MSBuild is a powerful build tool that is included with Visual Studio. It can be used to build Visual Studio solutions and projects from the command line or from scripts, making it easy to automate builds and deployments.

To build a Visual Studio solution using MSBuild, you can use the following command:

msbuild location: C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\msbuild.exe






msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu"

You can also specify a specific project within the solution to build by using the /target parameter:







msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu" /target:cms.proj

To generate deployment artifacts for a web project using MSBuild, you can use the 'WebPublish' target. This will build the project and create the necessary files for deployment to a web server.

Here's an example of the command to generate deployment artifacts for a web project:







msbuild "D:\a\1\s\solution.sln" /t:WebPublish /p:Configuration=Release /p:platform="any cpu" /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:DeleteExistingFiles=True /p:publishUrl="D:\a\1\s\outdir"

Alternatively, you can specify the OutDir property to specify the output directory for the build artifacts. This can be used in conjunction with the 'Build' target to generate the necessary files for deployment.






msbuild "D:\a\1\s\solution.sln" /t:Build /p:Configuration=Release /p:platform="any cpu" /p:DeployOnBuild=false /p:SkipInvalidConfigurations=true /p:OutDir="D:\a\1\s\outputdirectory"

You can also specify additional parameters, such as /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false /p:VisualStudioVersion="15.0" /v:diag to customize the build process.

Alternatively, you can generate a deployment package by using the 'WebPublish' target with the 'Package' publish method:







msbuild "D:\a\1\s\solution.sln" /t:WebPublish /p:Configuration=Release /p:Platform="any cpu" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\website\\"

This will build the project and create a deployment package using the specified settings. The 'PackageAsSingleFile' parameter specifies that the package should be created as a single file, and the 'SkipInvalidConfigurations' parameter specifies that the build should continue even if there are invalid project configurations. The 'PackageLocation' parameter specifies the directory where the package should be created.

To enabled verbose logging add below parameter to command line:

/v:diag


Thanks for reading, CloudOps Signing Off! 😊