Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: terraform script added for Infrastructure(IAC) #1

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sijandh35
Copy link
Member

Introducing Terraform for Infrastructure Management

This pull request (PR) introduces Terraform for managing our project's infrastructure. Terraform, developed by HashiCorp, is an Infrastructure as Code (IaC) tool that will help us automate and streamline our infrastructure provisioning and management. By integrating Terraform, we aim to achieve consistency, scalability, and efficiency in our infrastructure processes.

Key Changes

  • Added initial Terraform configuration files for [describe the specific components, e.g., "setting up AWS ECS, VPCs, and security groups"].
  • Created Terraform modules to encapsulate reusable infrastructure components.
  • Defined provider configurations and environment-specific variables.
  • Updated documentation to include instructions on how to use Terraform for infrastructure management.

Benefits

  • Consistency: Ensures that our infrastructure is defined and provisioned in a consistent manner across all environments.
  • Automation: Reduces the manual effort required to manage infrastructure, leading to faster deployments and fewer errors.
  • Scalability: Facilitates easy scaling of infrastructure as our project grows.
  • Version Control: Allows us to track and version our infrastructure changes using Git, providing a clear audit trail and the ability to revert to previous states if needed.

Testing

  • Verified Terraform configurations using terraform plan and terraform apply commands in a staging environment.
  • Ensured that all resources are created and configured correctly according to our requirements.
  • Conducted peer reviews(@nrjadkry, @mahesh-naxa) and incorporated feedback to improve the initial setup.

Next Steps

  • Migrate Terraform configurations to OpenTofu, an open-source alternative for infrastructure management.

Notes

  • Ensure you have the necessary permissions and API keys configured in your environment before running Terraform commands.

@sijandh35 sijandh35 requested a review from spwoodcock June 5, 2024 11:44
@sijandh35 sijandh35 self-assigned this Jun 5, 2024
@sijandh35 sijandh35 added the enhancement New feature or request label Jun 5, 2024
@sijandh35 sijandh35 requested review from dakotabenjamin and removed request for eternaltyro June 19, 2024 04:28
sijandh35 pushed a commit that referenced this pull request Jun 21, 2024
@spwoodcock spwoodcock requested review from spwoodcock and removed request for spwoodcock June 30, 2024 09:32
Copy link
Member

@spwoodcock spwoodcock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have very little hands on experience with Terraform to be honest, but this looks sensible to me.

I do think it's a little insane how much config is required to set up an EC2 instance, S3, and DB 😂

Will this config change much over time / do you think it's maintainable?



# Redis-main
resource "aws_elasticache_cluster" "redis-main" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are we using Redis for in DroneTM?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spwoodcock Initially i thought somewhere we would use celery for background task so i added configuration for Redis, For now i will comment this in the code and make a new PR.

@spwoodcock
Copy link
Member

Also, getting locked into an RDS managed database is a bad idea IMO.

If we deploy the same way as FMTM, we won't need it.

I would like to deploy a managed database cluster ourselves via Kubernetes to be honest - it's not too tricky.

Could you give me a rough cost estimate for RDS for a year please so I can easily compare?

@sijandh35
Copy link
Member Author

sijandh35 commented Jul 2, 2024

Current Pricing Details

@spwoodcock here is rough esitmate of our current setup from AWS Calculator:

  1. Instance Cost:

    • 1 instance(db.t3.micro) x 0.026 USD hourly x 730 hours in a month = 18.98 USD
    • Amazon RDS PostgreSQL instances cost (monthly): 18.98 USD
  2. Storage Cost:

    • 100 GB per month x 0.131 USD = 13.10 USD
    • Storage pricing (monthly): 13.10 USD

Total Estimated Monthly Cost:

18.98 USD + 13.10 USD = 32.08 USD

Note: This is a rough estimate. Additional charges such as data transfer costs may apply but are expected to be minimal.

@spwoodcock
Copy link
Member

spwoodcock commented Jul 3, 2024

I would seriously doubt t3.micro would be good enough.

Maybe at the start if we just deploy the API without a proxy it's fine, but with more services it's unlikely.
(2 core 1GB ram right?) We probably need more RAM.

Could we just remove RDS and manage our own database via a container for now.
Eventually we will deploy in Kubernetes and will handle scaling that way.

DroneTM needs to be easy to deploy outside of HOT/NAXA too, meaning not relying on vendor-locked technologies ideally.

@dakotabenjamin
Copy link
Member

@spwoodcock , my thoughts on this is that its fine for IaC to be opinionated towards our needs or restrictions so long as sufficient documentation and images exist for others to build and deploy on their own infrastructure. I don't have an issue between running the database as a container vs RDS. Good "vendor-neutral" IaC should be engineered such that components are decoupled and either approach will work. Later down the line if we feel it beneficial to change (we need better backup management or IOPS controls), we can migrate the database over.

A more pressing concern that I wished we had addressed earlier is that there seems to be some duplicated effort here with our existing terraform modules. Any chance you could look these over and see if there's some alignment with existing work?

Questions on design:

  1. Why setup modules in steps? Doesn't terraform handle dependencies through 'requires'?
  2. Does the EC2 need to be public and be issued an eip? Wouldn't the load balancer act as a public access point for that?
  3. Can we manage sensitive info like passwords in Secrets Manager?
  4. On the topic of vendor locking, can we use ghcr.io rather than ECR?

@spwoodcock
Copy link
Member

Agree with your points!

As you suggested, we should all have a call to discuss the way forward 👍

@sijandh35
Copy link
Member Author

@dakotabenjamin @spwoodcock Thank you for the review lets discuss more on the call when everyone is free.cc @mahesh-naxa, @nischalstha9 .

  1. Why setup modules in steps? Doesn't terraform handle dependencies through 'requires'?

We are using modules in Terraform to organize code by grouping similar services together. I have reviewed the Terraform modules you mentioned, where different repositories are created for each module. While that is a valid approach, it could introduce challenges with version management and state management across multiple repositories. Let’s discuss this further on our next call. If we plan to implement similar workflows across all HOT setups, organizing in that manner shouldn’t be an issue.

Additionally, we are planning to use Terragrunt or OpenTofu for deployment across different stages (dev, stage, prod). I hope this modular architecture will support that. What are your thoughts on this?

  1. Does the EC2 need to be public and be issued an eip? Wouldn't the load balancer act as a public access point for that?

    Actually, EC2 is not needed here as we are using ECS for deployment. I am using EC2 just to connect to the database, which is on a private network, so I made EC2 also on a private network to connect to the database. However, this can be removed in the future as we can directly connect using ECS sessions. Currently, I am using an EC2 instance that falls within the free tier limit, which is t2.micro.

  2. Can we manage sensitive info like passwords in Secrets Manager?

    Yes, that's a good idea. We will implement it on the pipeline.

  3. On the topic of vendor locking, can we use ghcr.io rather than ECR?

    Okay, that won't be a problem.

And also, @spwoodcock, we have a complete setup that can be run on a single VM using different open-source services, which can also be migrated to managed vendor services and vice versa. Could you please review it? It’s in our repository.

@spwoodcock
Copy link
Member

spwoodcock commented Jul 17, 2024

Hey @sijandh35, I'm not sure we really discussed the Drone TM infrastructure as a team.

The only conversation I had about it was that NAXA would handle the deployments temporarily (i.e. a dev server), until HOT takes over in the future.

With this in mind, we would probably align our deployment with other tools at HOT, including the IaC.
We are of course very happy to collaborate on the IaC setup - your input would be very helpful for the team 🙏

But for the short term, do you think it's best we leave setting this up until we need it & have time to review it all together?
The deployment could be done manually quite easily, if it's going to be shut down eventually.

Do you think this makes sense too @dakotabenjamin?

@mahesh-naxa
Copy link
Collaborator

Agreed @spwoodcock, i have been working on terraform modules on top of work that has been done by Yogesh, i believe we should setup a call so we can discuss and better align the work that we have been doing. Also i can use some help & direction as well.
cc: @dakotabenjamin @sijandh35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants