Fueling Curiosity, One Insight at a Time

While using sidekiq-scheduler if your schedule file is named as sidekiq.yml make sure to add the schedule config entry.
i.e :scheduler: -> :schedule .
For eg:

:scheduler:
  :schedule:
    fetch_user_info_from_slack:
      cron: '0 6 * * * Asia/Kolkata'
      class: FetchSlackUserInfoJob
      queue: 'default'
      description: 'This job fetches user info from slack and updates the database'

AWS - ami
If you want to create two instances in different regions within the same Terraform file, using the same AMI, you should first ensure that the AMI is available in both regions. If it's available in both regions (i.e.- "us-east-1" and "us-east-2") , you can proceed to use the same AMI for both instances. Otherwise, you should use two different AMIs.
For example :

provider "aws" {
  alias  = "us-east-2"
  region = "us-east-2"
}

resource "aws_instance" "instance" {
  provider      = aws.us-east-2
  ami           = "ami-id-1"
  instance_type = "t2.micro"
}

provider "aws" {
  alias  = "us-east-1"
  region = "us-east-1"
}

resource "aws_instance" "instance1" {
  provider      = aws.us-east-1
  ami           = "ami-id-2"
  instance_type = "t2.micro"
}

Git rebase is a command to reapply commits from one branch onto another, effectively rewriting the commit history.
1. Use git rebase main to start.
2. Resolve conflicts manually in files.
3. Add resolved files git add <file>.
4. Continue rebase git rebase --continue.
5. Finally, force-push changes git push <remote> <branch-name> —-force.

Using the command “git push origin feature-branch -f” forces the remote repository to match the precise state of the local repository. However, it should be used with caution because it has the ability to overwrite remote modifications and cause data loss.

Using git rebase command allows you to modify the history of your repository by changing a sequence of commits. It lets you to reorganise, modify, and merge commits. Git rebase is commonly used for resolving conflicts.

The <<-EOF and EOF are Terraform's heredoc syntax, This syntax enables the creation of multiline strings in Terraform configuration files without the need to manually insert newline characters (\n).

To check if an instance is running using Terraform, you can use the following command:
terraform show
This command displays the current state of your infrastructure as recorded by Terraform. It will show information about the resources that Terraform has created, including details about the EC2 instance, such as its ID, IP address, and other attributes.

If we want to create an instance in different regions within the same Terraform file, we need to use provider aliases. In Terraform, a single file typically contains one default provider configuration for ‘aws.’ To work with multiple regions, we use provider aliases.
Instead of having two separate provider blocks, we add aliases to them. For example:

hcl
provider "aws" {
  alias  = "us-east-2"
  region = "us-east-2"
}

resource "aws_instance" "example" {
  provider       = aws.us-east-2
  ami            = "ami-id"
  instance_type  = "t2.micro"
}

provider "aws" {
  alias  = "us-east-1"
  region = "us-east-1"
}

resource "aws_instance" "example1" {
  provider       = aws.us-east-1
  ami            = "ami-id"
  instance_type  = "t2.micro"
}

This way, we can create instances in different regions using a single Terraform file, and each instance is associated with its respective region through the use of provider aliases

how to troubleshoot the visibility of an AWS EC2 instance.
discovered that instances may not appear in the console if deployed in a different region , verified instance existence by providing the correct region in the AWS console.
example:

provider "aws" {
 region = "us-east-2"
}

if you are using ngrok to expose your localhost , you can serve that in a static domain.
Every time you start ngrok it will use the same domain name

ngrok http --domain=<your-domain>.https://ngrok-free.app|ngrok-free.app <port>