GCP remote-builder should create VM with External IP in certain ranges. For example 49.70.30.100 to 49.70.30.150
Inside remote builder, VM instance is creating with a random external IP but I want to be in the range.
You can't restrict an ephemeral external IP assignation to a specific range (the 51 addresses in your example range may be already in use somewhere else at the time you launch your build).
Having said that, you can reserve a static external IP address that will be reserved for your project, whether it's in use or not, and assign it to your remote-builder VM with the --address flag as INSTANCE_ARGS.
Note that you'll be billed for the IP address reservation (from January 1st, 2020, whether it's in use or not)
Related
How can we get static IPs for a OCI VM instance? Also, how can I configure reverse DNS for this Oracle-owned IP address?
I have visited https://docs.cloud.oracle.com/en-us/iaas/Content/DNS/Tasks/reversedns.htm but this seems to create a DNS zone and record for normal forward zones. How will Oracle update the reverse DNS zones in their zone files?
The Public IP address assigned to the VM stays with it all through the life-cycle of the Instance until it is terminated. So one way, it is already static/permanent. The other option is to use Reserved IP addresses.
Could you check this link for rDNS question? Looks like it is very similar if not same.
https://cloudcustomerconnect.oracle.com/posts/21ce8bcdef
As far as I know, if you create an image from a running instance, it would by default reboot the instance. Do correct me if I am wrong on this.
For my situation, my free elastic ip are all used up and I need to do some heavy modification on the instance operating system. Before proceeding with those modifications, I would like to at least do a complete backup on everything. Which means I need to create an AMI and do snapshot on the EBS before proceeding. Problem is, I can't afford to lose the public and private IP address of that instance because it would take me more work to update all other softwares in different servers that would connect to it (unless of course if I mess it up and had to use the backup created AMI image after all).
So my questions are:
If I just simply create an image from that instance that is still running without stopping it. It will reboot by default, but would it change it's public and private IP addresses? I noticed that a normal "reboot" when you right click the instance does not change those IP address. Is it the same kind of "reboot" when you create image without stopping the instance?
Is it safer that I stop the instance first before creating an image or creating the image while it's running is safe enough? Consider data integrity.
Thank you
The default reboot during AMI creation will just do a normal reboot. It will not change IP addresses.
The Private IP address will never change.
The Public IP address might change if the instance is stopped.
Best practice is to either use an Elastic IP address (free if attached to a running instance, and you can request more if you need them) or use a DNS Name that resolves to an IP address. That way, if the IP address changes, simple update the DNS entry without needing to change any references.
Why doesn't AWS allocate elastic IP's to all the servers being spawned? They allocate public IP by default to all the servers, which gets lost after a reboot of EC2 instances.
What's the logic behind not allowing elastic IPs automatically?
TL;DR Because Elastic IP (EIP) addresses are not needed for all/most use cases.
There is a limited supply of routable IP addresses. If every server on a public subnet received one, those IP addresses would remain allocated even when the servers were off. If the server was terminated it would be unclear if the use of that IP was concluded or is still necessary for other use. Which brings up the real reason for Elastic IP's.
An Elastic IP address is a static IPv4 address designed for dynamic cloud computing. An Elastic IP address is associated with your AWS account. With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account. [1]
The take away from this is if you're not using EIP's for dynamic cloud computing you're probably using them incorrectly. This is a good example of a correct use case.
If you require a persistent public IP address that can be associated to and from instances as you require, use an Elastic IP address instead. For example, if you use dynamic DNS to map an existing DNS name to a new instance's public IP address, it might take up to 24 hours for the IP address to propagate through the Internet. As a result, new instances might not receive traffic while terminated instances continue to receive requests.[2]
Initially my issue was "How do I RDP into an EC2 instance without having to first find its ip address". To solve that I wrote a script that executes periodically on each instance. The script reads a particular tag value and updates the corresponding entry in Route53 with the public dns name of the instance.
This way I can always rdp into web-01.ec2.mydomain.com and be connected to the right instance.
As I continued with setting up my instances, I realized to setup mongodb replication, I will need to somehow refer to three separated instances. I cannot use the internal private ip addresses as they keep changing (or are prone to change on instance stop/start & when the dhcp lease expires).
Trying to access web-01.ec2.mydomain.com from within my EC2 instance returns the internal ip address of the instance. Which seems to be standard behaviour. Thus by mentioning the route53 cnames for my three instances, I can ensure that they can always be discovered by each other. I wouldn't be paying any extra data transfer charges, as the cnames will always resolve to internal ip. I would however be paying for all those route53 queries.
I can run my script every 30 secs or even lesser to ensure that the dns entries are as uptodate as possible.
At this point, I realized that what I have in place is very much an Elastic IP alternative. Maybe not completely, but surely for all my use cases. So I am wondering, whether to use Elastic IP or not. There is no charge involved as long as my instances are running. It does seem an easier option.
What do most people do? If someone with experience with this could reply, I would appreciate that.
Secondly, what happens in those few seconds/minutes during which the instance loses its current private ip and gets a new internal ip. Am assuming all existing connections get dropped. Does that affect the ELB health checks (A ping every 30 secs)? Am assuming if I were using an Elastic IP, the dns name would immediately resolve to the new ip, as opposed to say after my script executes. Assuming my script runs every 30 secs, will there be only 30secs of downtime, or can there possibly be more? Will an Elastic ip always perform better than my scripted solution?
According to the official AWS documentation a "private IP address is associated exclusively with the instance for its lifetime and is only returned to Amazon EC2 when the instance is stopped or terminated. In Amazon VPC, an instance retains its private IP addresses when the instance is stopped.". Therefore checking nevertheless every 30s if something changed seems inherently wrong. This leaves you with two obvious options:
Update the DNS once at/after boot time
Use an elastic IP and static DNS
Used elastic IPs don't cost you anything, and even parked ones cost only little. If your instances are mostly up, use an elastic IP. If they are mostly down, go the boot time update route. If your instance sits in a VPC, not even the boot time update is strictly needed (but in a VPC you probably have different needs and a more complex network setup anyways).
Another option that you could consider is to use a software defined datacenter solution such as Amazon VPC or Ravello Systems (disclaimer: our company).
Using such a solution will allow you to create a walled off private environment in the public cloud. Inside the environment you have full control, including your own private L2 network on which you manage IP addressing and can use e.g. statically allocated IPs. Communications with the outside (e.g. your app servers) happens via the IPs and ports that you configure.
I want to use the Amazon Web Service free micro-instance for my different projects for testing and personal purpose. But I required some static-public IP on which I can run my server.
Is that possible? From where I can buy just IP and use it with my AWS?
EC2 Elastic IP Addresses
Elastic IPs are tied to an account, not an instance.
You need to look at AWS VPC for this.
Whilst VPC is free outside of the usual instance pricing, it doesn't work with Micro instances (the cheapest ones).
When not using VPC, you're assigned IP addresses through DHCP. When the DHCP lease expires, or you restart, your IP is released back to the pool.
VPC lets you use private IP addressing, you can use it with Elastic IPs and is much easier to integrate with a physical infrastructure setup.
If you're only testing/investigating AWS and have little or no budget to use anything other than a Micro instance, I'd just suck it up and deal with the changing of IPs.
If you've got a budget that lets you use instances other than Micro, then go for VPC.
Also, if you're doing more than testing/investigating I'd recommend starting with VPC straight away as trying to migrate from a non VPC to a VPC infrastructure is a massive PITA.
For every AWS account, 5 free elastic ips are provided. You have to just allocate them to required instance. But make sure that the allocate address(newly created elastic ip) in in use, because you will billed if the Elastic ip is not in use.
Looks like they have configured ARP statically so you can only use the IP address on an instance that was bound to that instance through the EC2 management console.
I just configured one of my instances to use a static IP address other than the one assigned through the management console and rebooted the instance.
I'm still receiving ARP responses on the old address but not receiving ARP responses on the new address at all.
Unfortunately for me, I have a not responding instance (NFS File Server) stuck in a stopping state while I attempt to terminate it.
The IP Address bound to that instance cannot be re-assigned to a replacement instance so now I have to reconfigure
On the whole pricing delima: When you come to think of it, there is a limited amount of static IPs so there must some pricing (supply and demand). This pricing is two fold: 1) for upto a limited number (5 per account) you don't have to pay. 2) if you created one you need to use it if you don't you'll be billed (to prevent every user to get 5 static IPs)