Subhendu Sekhar Patro

Hey. Hi. So first of all, thanks for the opportunity. So this is Shubhinde. It will basically belong to Odisha. We are currently staying in Hyderabad. So, I hold around 4 and a half years of experience in AWS, which includes various AWS tools such as EC2, EBS, S3 buckets, and API gateway, load balancer, ECS, and EKS, all those things in AWS. But apart from that, in DevOps tools, I have good experience in Jenkins, Docker, Kubernetes, and there are few DevSecOps tools as well, such as JAP, SonarQube, HadoLink, and Kubelinter. These are the few tools which I have worked on. And for monitoring and logging cases, I have worked with ELK, CloudWatch, and OpenSearch. These are the few tools I have worked with. So, I am currently working in MinuFi Technologies. It's been 1 and a half, 1.7 years to be precise. I have been working in MinuFi Technologies. So, that's pretty much it. Thank you.

Docker, Python, and AWS services. So we've been exploring the option of automating infrastructure using Terraform or Cloud Development Kit. We can use Docker, specifically Python-based Docker images. So we can run them as Lambda functions, or we can simply run them as an ECS service or if you prefer, go with Kubernetes because if you're going for EKS service, we have thought that if your application is communicating with other microservices and certified cases, we can go with the case. Otherwise, ECS would be more preferred in my point of view. So we need to create a robust CI/CD pipeline that might be if you want AWS services, we do have AWS CodePipeline using AWS CodePipeline. We'll code deploy all those agents. Using that, we can deploy our code. And the same thing, if you want to replicate the production environment, we just have to use the same safety or same tool to create a similar kind of infrastructure in higher environments as well. And for deployment, the CD is there anyway. So we can create an approval stage and move it to further environments. So that's how we can design this workflow using Docker, Python, and internal AWS services. Suppose we are communicating with Adi or something, it will be easier to communicate and establish a communication. In terms of Adi, also previously, there were services and limitations. Like, it used to be difficult creating those using OIDC and annotating that role to the service account. But now as the port identity agent came, so it becomes easier for them also to communicate.

We can use AWS CDK for infrastructure as a code. To be honest, I have never worked with AWS CDK, but I have a good idea of using TypeScript with AWS CDK. We can provision the AWS resources. The same thing applies to Terraform. If you're using Terraform as an edge infrastructure as a code tool, and you want to focus on a specific use case like network provisioning. So, in that case, both of them work fine, but Terraform gives us additional benefits. We can create one artifact, and that artifact can be deployed. Other than that, Terraform uses a state file. We can create our network in these VPCs with an internet gateway, NAT gateway, DHCP settings, route table associations, security groups, and all those technical things. We can create using both of them.

So just an automated approach to scale, Kubernetes deployment in response to increased web traffic. We can set up Horizontal Pod Autoscaling. That's something we can do. Based on requests, we can automate auto-scaling our number of pods. That too, again, we have to count the CPU and memory usage. We have to keep the resource limits as well, because in case of data centers, we should not over-provision the resources. That's one thing we can do. We can create a deployment. In a deployment, we can keep the number of replicas, the desired replica count, the minimum, and the maximum number of replicas. Again, for infrastructure level, the node groups and node pools will also have auto-scaling groups. There will be a target node group option as well, which you can choose.

Okay, for a zero downtime deployment strategy for cumulative charge data, we will be having various things, such as blueprint deployment, canary deployment, and other deployment methods like A/B testing. There are various methods, but highly, what I have seen is people are using deployment or canary. In deployment, there will be another replica of our existing application. Suppose v1 is existing, v2 will be created, and the traffic will be shifted to v2. Then v2 will be live, and v1 will be getting deprecated. That approach we can go, but in that one, resource allocation will be more. Other than that, we can do a canary deployment. The traffic will be moving slowly using a gradual traffic shift. We can also use a service mesh. In that, the traffic will be moving slowly, for example, 10% traffic will be going to v2, and 90% will be going to v1. If everything is working fine, we can slowly move forward, like 30/70, 40/60, and then eventually, v1 will be deprecated, and v2 will be fully active.

How would you include a Terraform module? Yeah, we can define Terraform modules and while we want the Terraform module in our main.tf file, we just need to call that module. If you want to reuse them in multi-cloud environments, we'll have TFR files so we can get multiple TFRs, or else we can use Terraform Registry in that case to reuse this knowledge in multiple stages. You know? So, multi-cloud infrastructure components in the sense that we need multiple providers, block and based on my understanding.

First of all, we should not be using the default key. We need to create a key each time we launch in an instance, then using data block, and we have to import that. Yeah. We just have to keep an output of that key into a file, and we need to define that file here. And security group IDs, we should not hard code. I am a spine. Extension type is fine. The key name is something that keeps this risk at bay. And the security ID should be fine. Apart from this listing, the SSS key which is being created is. We need to create that SSS key also needs to be in contact. That's one thing.

I'm not able to find an error. Maybe the three statements which have been written, I'm not sure whether that might be one issue. Other than that, Docker will have been "t" and then come. The tag needs to be very light in this case, apart from the time.

First of all, if you are going for hybrid cloud, we need to do all these steps, direct connect checkup for the network connectivity from on prem or it might be some other cloud to headless cloud. So once the network setup has been done, using Kubernetes in the sense, suppose there are a few models, not more than the models which are running the front end, we can do here. And that using Glue, we'll be able to work with the tools, the Airflow, and we will be using SalesMaker, something we might use from AWS. Those things will be communicating with each other, how to design a system to auto scale content? Like, normal given is the deployments with HP enabled. The secret should be kept in secret managers. The configuration file should be in a config map. That's it. Coming up from there. The volumes we can mount are EFS or EBS. That's how the EKS stuff works.

What methodologies would you apply in the DevOps website? Yeah. So the first of all, the assigned methodology would be applied. So there should be some sprint plans in place initially. Then once the code is there, we can check using GetGuardian or CheckMaths. And we have these tools that will be checking if there are any credentials or any vulnerabilities in our code, then we can scan the code using SonarQube. Once the scan is done, we can build it. During the build, the dependencies will be there. We can use dependency track to get an edge on the field of material. Then comes the step where once the build is done, the Docker file will be there to scan. We'll be scanning the Docker file in place. Once the Docker file is scanned, a Docker image will be created. Then we will use a few other tools to scan the Docker container. Once the Docker container is running fine and there are no vulnerabilities, we can deploy it in Kubernetes. Before deploying the application, the QB intern would be used to check the YAML files to see if they are following any complaints. Then once the deployment has been done, we need to make sure no secrets are exposed. We need to check that in terms of networking, there should not be any ports initially open to the Internet. The application should be in private subnets and exposed via a load balancer at the API gateway. If it's an API gateway, we need to make sure that the authorization step is in place. There are a few things you need to keep in consideration while deploying an application to meet the compliance guidelines. That's it. Thank you.