Satyabrata Karan

Hi. I'm a senior DevOps engineer. I have 12 years of experience in IT. Out of that, I have 5 years of experience as a DevOps engineer. Along with that, I have experience with cloud computing and automation engineering. So far, I have worked in different domains, including the Fintech industry and investment banking. In my last project, I worked with Nomi Solution. Here, I'm working as a senior DevOps engineer and part of the cloud engineering team as well. Here, I've taken care of the AWS cloud and its automation and done a lot of automation using Terraform and Python. I've also worked on Red Hat Linux, parallel Python, and shell scripting. Along with these tools, I've experienced working with Oracle database and optimizing SQL queries. I'm also familiar with MongoDB and CICD pipeline in Jenkins, taking care of the CICD pipeline, optimizing it, and understanding critical CICD pipelines for build and deployment activities. Also, I have experience with monitoring tools like Datadog, Splunk, and CloudWatch on the AWS side. That's all about me. Thank you.

Yeah. So, when we talk about AWS CloudFront for three automation. So we have to share S3 bucket name, and we need AWS credentials like AWS ID and a passkey, which my user ID is supposed to have S3 bucket access, executable access as well, and download access as well for the S3 bucket. Then we can check-in history we have data or not.

We have to import the library. Here, if the microservice architecture is dockerized, then we have to create a Dockerfile. And we have, like, as we know in Dockerfile, we have to write step by step about the image construction. Then we can write the docker build command, which will build the image file, and it will be stored in the architecture. All these things we can also write together in Python, making it automated. For that, we need to call import docker. And using docker, we can create a Docker object, and from that object, we can call different methods.

So if we want to optimize the document sizes, then we have to import the light version of the source in the doc file so that the image file will not get loaded too much. There are two types of sources, one is the light version and one is the full place library version. For example, Alpine, we can use Alpine light. The image will reduce from 100 MB to something like 2 MB or 3 MB. In that way, we can optimize the Docker image file.

In this case, we think about monitoring the Python application. For example, the URL, SEDP or HTTPS URL, we need to monitor. And the application logs, we need to monitor using different monitoring tools such as SumoCloud or Grafana. Then we can monitor the applications using Datadog or Splunk and the URL using Uptrends. Sorry. Yeah. Uptrends. In that way, we can monitor and restrict the application downtime and observe the application downtime.

So if we talk about Docker containers in a CICD pipeline, then we have when the Docker image is being built in the pipeline process, we need to take care of the security, like Docker has the compatibility to deal with passwords in a secure, encrypted way that we can use.

I don't have any idea on this.

So this is a transcription. I see there is a if block, else block, and if block. 10 4 dot TXT file, if it is a file type, then it is saying file exists. Actually, instead of hyphen f, we can write hyphen zed also whether it is a zero-sized file or, geosized file or not. And f hyphen f is for file type. So for this file type, then only this tech, this condition will pass and the rest of the thing will run. Otherwise, simply the condition may be wrong here.

In this case, we think about the load balancer auto scaling tool. And that load balancer connects to a target group, the target group points to two EC2 instances. We need to have two instances in the target group, and load balancers should be pointing to two availability zones. And both are, like, two instances are supposed to be in different availability zones. So one, if one availability zone goes down or the application goes down, then it will get the same data from the other submit. In this way, we can perform a 0 downtime deployment.

I'm not sure where to start with this question.

For any application, we can think of a disaster recovery plan where we have a similar application in another region, another availability zone. And data should also get back up into the DR server, and we should test under DR. And we have to take the backup of the data, like, weekly or monthly and keep it up to date in the DSR board. In this way, we can make a strategy for recovery and backup of the application.