Vicky seth

Hi Vicky. My name is Meily, and I have overall 11 plus years of experience in the IT field. I started with Windows and Linux profiles. I would say I started with the Linux profile. After that, I was moved to virtualization, then I got the opportunity to work in the cloud environment. I started with IBM Cloud, as I was working with IBM, which gave me the opportunity to work on IBM Cloud. And after that, I got the opportunity to work on the AWS Cloud. Then, I got the opportunity to work on CICD, and then finally moved to DevOps. In my last project, I worked on FinOps as well. So, if I'm going to talk about technology, I have a good experience with IaC, specifically with Terraform. I have a good experience creating modules, including Terraform modules for EC2, S3. I've also created a Terraform module for a GCP project as well. If I'm going to talk about the cloud, I have good experience with AWS cloud, a little bit of knowledge on IBM Cloud, and a little bit on GCP as well. If I'm going to talk about monitoring, I have good experience with Splunk, Datadog, and CloudWatch monitoring provided by AWS. If I'm going to talk about CICD, I have good experience with Jenkins. I also have experience working with CodePipeline, CodeDeploy, CodeBuild, and a little bit of experience with Bamboo as well. For version control, I have experience with GitLab and GitHub. Yes, that's correct.

Automated security scanning can be integrated with a CICD pipeline using a WS tool. If we are referring to a city, we can use AWS services like CodePipeline, CodeBuild, and CodeCommit. For security, we can implement rules to provide least access and use automated security scanning. Automated security scanning can be done using SonarQube, but it depends on the project. Let's assume we're working on a Node.js project. To integrate testing before deploying to production or other environments like dev or test, we can use tools like SonarCube in between, which will perform the testing.

Blue green deployment is a deployment strategy where we have two environments, one is the old environment which is already running and another is the new environment which is a replica of the existing environment. So rather than updating the existing deployment, we are going to create a separate deployment, a replica of the existing environment, and once that replica with the new version is up and running and there is no issue with that, we can switch to that new environment and we can easily achieve this thing with the help of the tools like AWS CodePipeline, CodeDeploy, and CodeBuild.

How do you design Python script that automatically resolve common failure in the AWS EC2 instances. Now if I need to design a Python script then I need to use one of the AWS service that is the Lambda. Now in the Lambda I will get an option to use the Python library with the AWS Boto3 and in order to resolve common failure in the AWS EC2 instance like there are n number of scenarios by which EC2 instance can be failed. So let's talk about the first scenario where I would say the machine is not coming up because of the user data script. Now here what I can do is I can create a Lambda script or rather I would say I can create a Python script. Now this Python script what it is going to do is it is going to check whether that EC2 which is creating with the help of the launch template here I am taking example of the launch template why I am taking example for the launch template because I am expecting we already have a predefined AMI which is there in the launch template. Now I am creating my machine with the help of the launch template and while creating the machine I need to do some testing. Let's suppose I need to do the testing of there is a security tool let's suppose security tool is callis and that is going to be installed on the machine with the help of the user data. Now there is some problem with the user data. So what I can do is I can write my Python script in such a way where it is going to check whether the output of the user data is successful or not. So for that I am going to write a script and if it is successful then it is fine if it is not successful then what I do have the other option either I can send the notification or I can stop the deployment I can do all those things.

When giving an AWS infrastructure with scaling issue, how would you employ Terraform restructure for better stability? Okay. So, here, Terraform is an IaC by which we can create our resources. Now, whatever the resources we need to create, we can mention it in Terraform. So, let's suppose I need to create an EC2 machine. Along with that, I need to create an elastic IP. Along with that, I need to create a role. Along with that, I also need to create a couple of security groups. And, also, I need to create a VPC, a DynamoDB table. All those things I need to do. Now, when I am going to do all those things manually, what will happen is it might take a longer time to create them. Now, if I have Terraform, so I only need to write my code once and then I can use the same code in multiple environments. And if I need to do any changes. Let's suppose I need to create a security group with the name XYZ dev environment, and the same security group, I need to create in the other environment as well. So, I only need to change 'dev' to 'prod' or 'test'. Something like that. It's a small variable change which I need to do. Not a big change. So, everything is there in the Terraform. I just need to do Terraform plan, then Terraform init, Terraform plan, and then Terraform apply. And my resources will be created within 5 minutes, I would say. So, no manual thing or no repetition of the work. No errors, and I can expect the infra to be up and running as I expected. And with scaling, we can use auto scaling in between. This is one of the services which is provided by AWS. And with the help of auto scaling, when there is an increase in traffic, let's suppose there is a web server which are running, and there is an increase in traffic. So, what the auto scaling is going to do is it is going to create more instances. And with the help of Terraform, we just need to write the auto scaling resource. We need to, you know, map it with our EC2 and the other resources which we are creating.

Now, refactor a monolithic Terraform code base. A monolithic Terraform code base could be characterized by several factors, including the use of hardcoded values or the inability to reuse the code across multiple environments. To make the code reusable, we need to use variables instead of hardcoded values. We also need to adopt the approach of using Terraform variable files and dependent options. Furthermore, we need to use the output option as well. To make our code truly reusable, the best approach is to create Terraform modules. A Terraform module is a single code that includes all the resources a customer can use. It provides options for customers to customize their resources according to their own requirements. If a customer does not provide any information, the module will create resources in a standard way. For example, if a customer creates a security group without specifying a name, the module will create a security group that only allows public IP access from the user's machine on port 22 for SSH and port 3389 if it's a Windows machine. A Terraform module allows customers to modify or update resources as needed. For instance, if a customer wants to update the elastic IP, they can do so by providing the necessary options. This approach makes the code reusable across multiple environments and allows customers to customize their resources according to their specific needs.

Okay, it's a Dockerfile from Node 10, okay, it is using version 10 for the Node workdir. That means whatever it is going to do, it is going to do it in the app folder. Now here is the package.json which is we are expecting there in the local path from where we are creating this Dockerfile and we need to copy this thing into the app folder, run npm install, then we are giving this Linux command in order to install and run the app. Now here we are using copy two times, the first copy command we are using where we are copying the package.json to the app folder and the second copy which we are using is copying all the things which are there from where I am creating my Dockerfile to the app folder. Now if I am going with this thing, what will happen, my Dockerfile is on the same path. So that is going to be a potential issue because it is going to copy all the things, all the files which are there in my local directory from where I am creating a Dockerfile. It is going to copy all the things in the app folder. That is something I don't want here. I only want to copy the package.json to the app folder. So this command, copy, is not copy.app, is not required here. We can simply remove this thing. CMD index.js, okay, it seems to be a correct command with the help of the CMD or the entry point we can go to Node and we can start this index.js page and expose 3000, that is the port number which we need to expose. So here the potential issue is with the copy command and I would say CMD as well where we are using the index.js, I think we don't require it here because we are not defining it anywhere in this Dockerfile. So this could be the potential issue.

If we need to manage dependencies in Python, if we are using a Lambda function, the best way is to go with a layer. In AWS Lambda, we have the option for a layer where we can have dependencies that are not already installed on the AWS Lambda machine. Now, what exactly the AWS Lambda is, a serverless environment. Okay. In the backend, there is a Linux machine running, and we have pre-installed software as well. We have portal 3 already installed, we have pandas already installed, we have time already installed. For all those things, we just need to write the input for portal 3, and it will work in my Lambda function. But if there is a software that we require, and that is not installed, like Tableau is not installed. So I need to install that thing. Now I don't have access to the AWS Linux machine running the Lambda. Correct. So what I'm going to do is I only have the console where I can write my script. So what I'm going to do is I'm going to create a layer, and that layer I can include with my Lambda function. And while creating my Lambda function, it will work as expected because it will pick up the dependencies from the layer.

For the disaster recovery, the best approach is to go with multiple availability zones. Let's suppose, if there is a web application which is running. Okay? Now I need to design my web application in multiple availability zones. If one of the availability zones is down, I can still work with the other availability zones. That is one way to minimize the impact of disaster recovery. The second way is to go with other services. Like, we have CloudFront, which we can use. We can use S3 for static web applications. If we can use it on S3, then S3 is one of the best options. We can use CloudFront so that we can have our traffic all over the globe on the AWS network. We can use the WAF for disaster recovery. But the best approach is to go with multiple availability zones. And if the client allows it, then we can also go with multiple regions as well. But if we are going with multiple regions, then we also need to take care of the VPC peering. We also need to establish the connectivity. So all those things, we also need to consider if we are going with multiple regions. We can go with multiple accounts as well, but that is not recommended because we need to create an assumed role. So that is a bit complicated environment for disaster recovery. The first approach is to go with multiple availability zones. And if the client allows it for the money, then we can go with multiple regions as well, like US East 1, US West 2. We can do this as well, but we need to make sure that there is connectivity in between. And in order to have connectivity, we need to use VPC peering and transit gateway.

MongoDB AWS also provides this service like DynamoDB, they are providing. They are also providing the AWS RDS, which we can use with our AWS cloud. So in order to integrate these things together, we need to add a rule in between. And though it's something where we need to define what kind of access a user or application can have, low or deny. And for the Python application, I think it's easy. It's not that complicated. We can create a Lambda function, and we can give the URL of the MongoDB. We can give the username, port number, password, and we can also use the SSM parameter in between, so that we don't have to give hard-coded values for sensitive information. So we can easily achieve this thing with the Lambda function.

ECS is a last container service. Simply, we have Kubernetes, so it is a management tool for multiple dockers, and we need a manager and we need to manage those dockers. So we can use ECS. Now the advantage I would say here is that we can integrate other AWS services, like a monitoring service, which is very important. So with ECS, we can easily integrate the service. We can use roles in between and all areas where we can limit access for the user for the application so we can go with the least privilege model as well. We can reuse. We can store our code in CodeCommit, and that is a version control. So every time we need to update our code, we have the previous code available. So if something happens with our latest code, we can still work with the previous code. So these are the advantages that I will get with ECS.