Gopinathan Krishnasamy

Good morning, this is Vopi. I have a total of 7 years of experience in the field of cloud and DevOps engineering. Currently, I work with IBM as a senior DevOps and cloud engineer. I have good experience with AWS, and I am proficient in cloud, Jenkins, Kubernetes, and other related technologies. That's about myself.

So, when we actually do is when we dockerize the application, we will try to put it into the artifactory. From artifactory we will try to pull the images as a containerization and then we will put it into EKS, so it will be cross-region or multi-region and it will be spread across multiple zones. So, there won't be a downtime when you perform multiple operations. So, that's why a typical production environment needs to be set up when you are playing with some Kubernetes containerization or pods.

So for this scenario, I could be using a sonar cube, which is a third-party tool. So that might be scanning the repo whenever there is an issue with the configuration mismatch and then checking out issues. That tool can be used to predict the issues we're getting before getting into issues. It can also be used to scan it properly and to maintain it easily. I strongly recommend using a sonar cube, which is one of the best examples apart from sonar cube. We have multiple tools available in the market that can be used to validate and avoid configuration mismatch issues.

If you want to create infrastructure, Terraform is the best option to create infra. So, you can assist within AWS, there's an option called CloudFormation. You can use CloudFormation to create your infrastructure. So, CloudFormation, if you know Google Cloud Deployment Manager, you can do the same with CloudFormation. But, you know, Terraform is widely used for all cloud environments, including Azure, GCP, IBM Cloud, which can be used as a multi-tool. Infrastructure as code can be used to maintain or create infrastructure in all environments. So, that can be used as well.

So, methodology I could recommend to use is Agile methodology so that we can use CI, CD, continuous integration, continuous deployment. When you talk about the methodology, two kinds of methodologies come into picture. The first one would be Agile, with continuous integration, continuous development so that there won't be a delay in testing, integration, development, and then post-production go live. That is one of the main options of Agile, and then we have a CI, CD pipeline. Whatever changes you make, everything will be done in parallel through CI, CD so that each and every change you make will be pushed into the pipeline, developed, tested, and put into production. Maybe one option is Agile and the other one is CI, CD.

So, I am unsure about this question. What I could say is that maintaining the terraform state file could be one of the key reasons, but I am not sure what meaning they are referring to. The terraform state file is a file which manages all the infrastructure logs, including what things are being created. That file will be used to destroy resources, when you want to destroy them in the future. I think that is what they are referring to, but I am already unsure about this.

I'm not familiar with Visual Script, so let's just focus on the programming languages. I'm familiar with both Python and JavaScript.

So, during peak hours, we can implement a load balance in the autoscaling concept. Autoscaling will take a vertical or horizontal load balance when there's a high load. Based on the load, an e-commerce website can be balanced using autoscaling. This way, the infra can be enlarged to different instances or slowed down. It depends on the requirement to increase or decrease. The best option to handle this is to use an autoscaling group, which is recommended. Since it's an e-commerce site, only for OT, autoscaling in load balance could be a correct answer in this scenario.

so you can introduce a file called "secrets" so secrets can manage all your credentials that can be used in Kubernetes. Apart from that, you can create a vault with one password and store all your passwords under the vault. You can use the AP endpoint of the vault to push a call to the endpoint using the variable name assigned to the credentials, so that credentials will be pulled out from the vault and assigned to the particular variable temporarily, like a one-time token that can be used inside your pipeline or applications. Another way is to use secrets within Kubernetes, where Kubernetes will store all credential information that can be used within Kubernetes. If not within Kubernetes, it's recommended to use a vault or own password that can be used in external tools.