I am creating a backup machine to run simultaneously next to my live machine. I have created a mirror copy of the instance and volume but for some unknown reason when I go to the IP address, I get a 'page canot be displayed' message.
Here are the exact steps I took:
Create snapshot
Create new volume from snapshot
Create new instance (Ubuntu Server 12.10)
Attach new volume to instance (sda1)
Start instance
Wait for status checks to complete
Associate IP address with instance
Am I missing something? I assume the IP address should resolve instantly?
Any advice would be appreciated
Thanks in advance!
Instead of doing those steps , You can create AMI out of that instance and launch that instance ,It will be the same copy of earlier instance .
Related
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.
We have a RHEL 7.2 EC2 instance and we are trying to install Oracle 12C EE server. We have assigned an Elastic IP to the instance to make sure that the Public IP address does not change when we restart the server. But we saw that the hostname of the instance gets changed on a server restart.
Problem: There are a few steps in oracle installation where we need to mention the hostname of the EC2 instance (i.e. private DNS), so we are hardcoding the hostname during oracle installation. But the problem is if in case the hostname gets changed in every server restart then the installed software wont work (since it holds previous host name) - how to resolve this issue?
Please let us know on the best practices to resolve this issue.
IP addresses do not change in EC2 with a simple restart. They only change with a complete stop, followed later by a start. If you are using a VPC, which you most likely are, then the private IP address will not change even with a stop/start.
If you want a solution that will work even if you move the installation to a different EC2 instance, then you should create a Route53 private hosted zone, attach it to your VPC, and then create a custom DNS name for this server.
If you are using VPC (which is the default now) the private IP should not change upon restart or stop start.
My understanding is that you're having issue with hostname reset to the default ip-x-y-z-k upon os reboot causing issues with oracle database.
This is usually caused by cloud-init (embedded in the AMI).
I suggest you to go through these steps:
First set the hostname in your os:
$: hostnamectl set-hostname Your-New-Host-Name-Here --static
Edit your '/etc/hosts' to match the private IP:
<private_ip> <hostname>
Check the value of HOSTNAME in '/etc/sysconfig/network' it should match your hostname.
Finally, to solve the issue, I suggest to remove the following lines from '/etc/cloud/cloud.cfg'
set_hostname
update_hostname
update_etc_host
To test if it works stop and start the instance, the private IP should stay the same as before and the hostname should be the one you defined.
I hope this helps.
G.
My application consists of two components: server and agent.
I am using Vagrant to create two EC2 instances. One for each application component.
First, I create the server instance and provision it with Chef.
Now, I am trying to provision the agent instance. To do so, I need to download the agent deployment package from the server instance to the agent instance.
The best way is to use scp with the server instance private ip.
How can I share the server private ip address with the agent provision process (Chef)?
Seems the vagrant host manager plugin (https://github.com/smdahlen/vagrant-hostmanager) could help.
From the documentation
You can customize way, how host manager resolves IP address for each
machine. This might be handy in case of aws provider, where host name
is stored in ssh_info hash of each machine. This causes generation of
invalid /etc/hosts file.
Custom IP resolver gives you oportunity to calculate IP address for
each machine by yourself, giving You also access to the machine that
is updating /etc/hosts. For example:
config.hostmanager.ip_resolver = proc do |vm, resolving_vm|
if hostname = (vm.ssh_info && vm.ssh_info[:host])
`host #{hostname}`.split("\n").last[/(\d+\.\d+\.\d+\.\d+)/, 1]
end
end
I have an ec2 instance serving a webpage with apache. I created an autoscaling group using an AMI of this instance in the launch config. Once CPU went over 80% and the autoscale policy ran, a new instance was created. But the CPU of my original instance continued to rise and the CPU of my new instance remained at 0%.
The new instance was not serving the web page. I am guessing this is because apache was not started with the launch of the image. I tried to ssh into the new instance to run "service httpd start" but I got the following error:
ssh: Could not resolve hostname http://ec2-xxx-xx-xxx-xxx.compute-1.amazonaws.com:
nodename nor servname provided, or not known
Why could I not ssh in? How do I configure autoscaling to automatically start apache on launch?
It would appear that you are attempting to ssh to a host with http:// in the hostname. Remove that and ssh should work.
Assuming that you created an AMI to use in AutoScaling, you would need to ensure that you chkconfig httpd on in the source instance before creating a new AMI for AutoScaling.
In order for you to connect to an EC2 instance you need two things:
The Security Group associated with your instance has an inbound rule that allows SSH communication.
Make sure you have the private key generated for the instance. Note: This is only needed if you chose to use a key in the first place.
If those two things are correct, then you can connect to your instance like this:
ssh -i "PATH_TO_YOUR_KEY.pem" ec2-user#ec2-xxx-xx-xxx-xxx.compute-1.amazonaws.com
For the other point, that is, to make sure you can start apache on launch, you can do two things:
As #atbell mentioned on a previous answer, you can make sure that the chkconfig YOUR_SERVICE on is on the AMI used to start your instance.
You can add a command as user data to your LaunchConfiguration so it runs it as soon as the instance is started:
What this will do is run start YOUR_SERVICE start as soon as the instance can respond to commands. So, whenever your AutoScaling group creates another instance, your service will surely be started. Note that the commands added to the user data field of the LaunchConfiguration are, by default, going to be executed as sudo.
I created an instance of ubuntu ec2 yesterday and I was trying to configure it and I stopped the serer before going home last night, when I tried log on to the same instance using ssh from my ubuntu I am getting an error which says connection timed out. I am not able to login to the instance now
If you stopped the instance, and the instance was ebs-backed then you should be able to start it using the ec2 api.
Describe the instance using the ec2-describe-instances/instance-attributes api and use ec2-run-instance start it. Once started, use the above api to retrieve the public dns name.
Using this you should be able to login to that same machine again.
if you have terminated an instance-store based virtual machine, then you can kiss it goodbye.