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

Request use of AWS Elastic IP support #223

Open
kevinayres opened this issue Aug 4, 2023 · 2 comments · May be fixed by #243
Open

Request use of AWS Elastic IP support #223

kevinayres opened this issue Aug 4, 2023 · 2 comments · May be fixed by #243

Comments

@kevinayres
Copy link

kevinayres commented Aug 4, 2023

Issue: By using a public IP (not EIP), things like Nginx are bound to that temporary IP. If you shutdown/start the instance, you get a different IP resulting in 'bad gateway' when accessing the API.

One way this project could be even more helpful would be to support EIP on deployment. Example:

  • Deploy neuvector/aws with option for EIP.
  • EIP is created and associated with the instance.
  • Then able to add example workloads, configure policies, and build out a nice demo environment.
  • Can then shut down the instance to stay under budget. Instance size can be altered, etc.
  • Instance can be restarted fully intact for the customer/partner demo.
@kevinayres
Copy link
Author

kevinayres commented Aug 5, 2023

This works for creating the instance, EIP, association:

Providers

provider "aws" {
profile = "default"
}

Variable Declarations

variable "ami-sles15sp5payg" {
type = string
default = "ami-0aa3dc9f3f70b91a7" #AMI for us-west-1
}

variable "key-name" {
type = string
default = "access"
}

Create EC2 instance

resource "aws_instance" "demo-instance" {
ami = var.ami-sles15sp5payg
instance_type = "t2.micro"
key_name = var.key-name
}

Resource block for eip

resource "aws_eip" "demo-1" {
vpc = true
}

Associate the EIP

resource "aws_eip" "demo-2" {
instance = aws_instance.demo-instance.id
vpc = true
}
`

@strophy
Copy link

strophy commented Jun 24, 2024

I ran into this problem as well. I shut down the two instances to save money over the weekend, and when they powered up again, they received different IP addresses. terraform destroy now fails with:

╷
│ Error: Kubernetes cluster unreachable: Get "https://13.38.67.225:6443/version": dial tcp 13.38.67.225:6443: i/o timeout
│ 
│   with module.rancher_common.helm_release.cert_manager,
│   on ../rancher-common/helm.tf line 4, in resource "helm_release" "cert_manager":
│    4: resource "helm_release" "cert_manager" {
│ 
╵

Now I have to manually dig around and destroy the infrastructure I was using to evaluate Rancher. It would be great if the quickstart could be refactored to get the current IP before attempting helm operations in Terraform, or just use an EIP as suggested above.

wombelix added a commit to wombelix/fork_rancher_quickstart that referenced this issue Nov 4, 2024
This keeps the public ip static.

Changes to the instance, e.g. shutdown/start, will not cause an assignment of a new public IP address anymore.

Solves issues were destroy failed at 'rancher2_bootstrap' and 'rancher2_cluster_v2' because the public ip was already removed.

Fixes: rancher#223

Fixes: rancher#242
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants