Rahul Goplani

Hey there. I'm Rahul Gokplani. I have completed my graduation in 2018. And my branch of specialization was engineering in electronics and communication. Then, normally, I've started my career as a Linux system admin, and during that period, I realized that cloud and DevOps technology was something moving into the market, and I started learning AWS. I got an opportunity in one of the startups, Scrip2 Technologies, where I joined as an associate cloud engineer. Unfortunately, after the year COVID hit us very badly, and that startup got shut down, so I had to look for another opportunity in the market. Since I was good in DevOps technologies and tools, I got an opportunity in BS Intelligence Private Limited, which is a company located in Noida. Currently, I'm working here as a senior DevOps engineer. My tools and technologies include Kubernetes, Terraform, AWS Cloud, and we are using Azure Cloud to a limited extent. In AWS, we use EC2, IAM, CloudWatch, CloudTrail, and RDS. Additionally, for our department, we use GitHub actions for CICD. This is all my current tool stack.

Well, so far, disaster recovery what we generally practice is that we have all of our infrastructure created with Terraform. Terraform is one of the infrastructure as a service in the cloud. And if something goes wrong in any region, within a half hour we are able to replicate that whole infrastructure in another region. That is the practice we have. Also, in case of databases, we have databases in different availability zones. This is just in case something happens to one of the availability zones in that region. We have some replicated servers in another zone. So, we can plan for any kind of disaster recovery. We should have a plan for infrastructure as a goal.

Well, so we have one infrastructure locally. And we need to address all of this infrastructure to our AWS Cloud Platform. In that case, we have one service in AWS that I am unable to recall the name right now. However, by using that service, we can use our local infrastructure setup into our cloud platform. Like, we have a lot of services for servers: EC2 instances. For databases, we can use RDS. For storage, we can use simple storage service, S3. And for security purposes, we have user access management with IAM and AWS.

So, if multiple engineers are working in a Terraform code base, what we can do is put our TFC state file in one of the S3 buckets. And that way, we can log that state file, so when someone else is trying to run any of the apply commands, it will block that key with the engineer who made the last change. So another engineer will not be able to perform any Terraform commands. That way, we can.

put our TF straight file. So better, we use a directory kind of a solution, in case of a large-scale environment. We can have users with this kind of active directory integration. That way, we will have a more secure way.

We can use, KMS This is one of the encryption servers offered by AWS. For encrypting data of any of the service in cloud. In terms of how it differs from s 3, to be honest, I'm I couldn't understood, question, clearly here. Yeah.

There's a problem with the if condition over here. The reason is the if condition is not in the string, and we are appending that string over here.

Problem I see over here is CID or IP for both protocols. Like, it's open for everyone, 0.0.0.0/0. So this is a wide open network which can lead to security risks.

So, in this case, if we have a microservice-based architecture, we can use EKS, the elastic Kubernetes service offered by AWS. That way, we won't have to handle the servers, and we won't have to bear the cost of it. Just we'll have to pay $70 per month for EKS. And we will have containers and ports deployed over there, which would be maintained as auto-scalable whenever the requirements come up, like CPU utilization goes high or something, then automatically a new port will be rolled out. And so, that is how it will be auto-scalable. And yeah, for maintaining SOC 2 compliance requirements, we can restrict third-party installations, and we can ensure that the third-party tools which we are using in our clusters are following SOC 2 guidelines.

So for maintaining high availability, we can always have an auto scale for a Kubernetes cluster. Let's say if CPU utilization is going high, then we can have a new instance rolled out, and automatically the respective pods will be scheduled on that. I don't have much idea on automatic failover.

Sorry. So for having a CICD workflow with Docker, what we can do is we can have a GitHub actions where we can write a workflow file. We can mention the destination where we want to push our image. We want and we have we can mention a step of build, and then we can mention a push location where we want to push. The location could be a container registry or it could be AWS Elastic Container Registry or maybe Azure Container Registry, whatever it is. So prior to that, we can run some vulnerability scanning. We can run any of the previous scan, TF scan, or we can use Wazoo for checking out the vulnerability on that code. Also, after creating the image, as well, we can scan the image as well. That is also an option. And then yeah, so that is the way we can have our CICD workflow. CD is mentioned here, but maybe we can use GitOps, any of the GitOps technologies like Argo CD to check if any of the changes happen on GitHub, on Argo CD code base. And it will automatically capture that change, and it will deploy that new image into our Kubernetes system.