I am doing a lift and shift with software from an on-premises architecture. There are two servers (main and auxiliary) that have to talk to one another over the network. I currently have tested and confirmed that I can manually add their hostnames and private IP address to the hosts file ("C:\Windows\System32\drivers\etc\hosts") and the software works fine.
For those that don't know, this file is used by Windows to map a network hostname like EC2AM-1A2B3C to a IP address. So if I added the hostname and IP address of the main server into the hosts file of the auxiliary server, then the auxiliary server could route to the main server. (i.e. PS> ping EC2AM-1A2B3C would then work).
How could I pass the required information to both servers? They both have to know the other server's private IP address and hostname. If this is not possible at server spin-up time, how might the servers connect and pass this information? I would really like to automate this if possible.
According to your description, I have some suggestions that you can refer to.
If you want two EC2 instances to be able to communicate with each
other, you can use the method of adding rules to the security group.
(1) Create security groups for your instance 1 and instance 2 respectively.
(2) Add an inbound rule to the security group of instance 1, chose "ICMP-ipv4". Enter the security group ID of instance 2.
(3) Create the inbound rule for instance 2 in the same steps.
For more information on security group rules you can refer to the official document.
You have tried adding the hostname and IP address of the primary
server to the host file of the secondary server. To tell each other
the IP Address of the other machine. Amazon CloudFormation cannot
handle the circular dependency between the two instances.
You can refer to the answer of this question. To realize that both instances know each other's IP address.
Hope these suggestions are useful to you.
Related
I have 3 VMs (app, content, DB) that are part of an application deployment. I need to clone multiple copies of this VM set. There is a common web server for all sets that proxies requests to the app server in each set.
Because hostnames are duplicated, I believe I can put each SET of 3 VMs into their own subnet and prevent communication and hostname duplication.
The web server will be outside these subnets (I guess in its own subnet).
If you have multiple hosts with the same hostname in the same VNET, will they have the same internal DNS name? The fact that they are firewalled into separate subnets should prevent cross traffic?
The web server will proxy based on IP address, since hostname will not resolve easily.
An alternative is one web server per VM set, 4 servers per VNET. This will work, but means 25% more VMs to manage.
Anyone suggest the "typical" way a network engineer would architect this? (Yes this could be cross posted to networking group, but it is dependent upon Azure specifics as well as general network architecture).
Many thanks experts.
You cannot have multiple hosts with the same hostname and internal DNS name. These have to be unique. The alternative seems more favorable here.
I would like set DNS records visible from instances inside the Google cloud.
For example if I query DNS from my PC I'll get one IP; however if I query DNS from the instance I'll get another IP. (A record to be exact)
Ideally I'd like doing this in most sane/convenient way possible; since I can install caching DNS server on every instance and setup authorative results; and forward caching for the rest (I guess bind9 can do that, never tried it before). But this is configuration sync mess; and it's not elegant. I kinda assume there might exist a better way.
One solution is to use totally different zones for different sets of machines and use the DNS search path to select.
So for example you could set up
server1.internal.yourdomain.com IN A 1.2.3.4
server1.external.yourdomain.com IN A 5.6.7.8
Then set up your machines with resolv.conf containing either
search internal.yourdomain.com
or
search external.yourdomain.com
And then when you lookup server1 on such a machine it will return the address from the appropriate zone. This scheme means you don't need to rely complex routing or IP detection. You will be immune to incidents where internal or external IPs get leaked into each others result.
Of course this does mean that you aren't keeping any IP addresses secret, so make sure you have other security layers in place (you probably shouldn't rely on secret IPs for security anyway)
Assuming you want your VM instances to be able to query other instances by name, and retrieve the desired instance’s private IP, this is already baked into GCP.
Google Cloud Platform (GCP) Virtual Private Cloud (VPC) networks have an internal DNS service that allows you to use instance names instead of instance IP addresses to refer to Compute Engine virtual machine (VM) instances.
Each instance has a metadata server that also acts as a DNS resolver for that instance. DNS lookups are performed for instance names. The metadata server itself stores all DNS information for the local network and queries Google's public DNS servers for any addresses outside of the local network.
[snip]
An internal fully qualified domain name (FQDN) for an instance looks like this:
hostName.c.[PROJECT_ID].internal
You can always connect from one instance to another using this FQDN.
Otherwise, if you want to serve up entirely arbitrary records to a set of machines, you’ll need to serve those records yourself (perhaps using Cloud DNS). In this case, you’d need to reconfigure the resolv.conf file on those instances appropriately (although you can’t just change the file as you see fit). Note that you can't restrict queries to only your own machines, but as David also mentioned, security through obscurity isn't security at all.
Google Cloud DNS Private DNS was just announced to beta and does exactly what you need
I'm setting up a test web farm in Azure. Consisting of:
Four Ubuntu Servers
Two balancers running HAProxy + Keepalived
Two web servers running Apache
Keepalived has been configured and everything has been working fine. HAProxy performs great.
My issue is that I want to enable the Keepalived failover clustering, but I can't seem to figure out how to create an Input Endpoint in Azure for the virtual IP address that the Keepalived VRRP is using.
In other words, I want to create an Input Endpoint for a virtual IP address in Azure, but not for an existing VM. So far, the only thing I've been able to do is create Input Endpoints for existing VMs (using their IP) for specific port numbers. I want to be able to configure:
Take TCP requests on port XX and map them to IP address YY.YY.YY.YY on port ZZ
Anyone know of a way to do this? I've looked on both portals (new and old) and the closest thing I see is the Cloud Services page for my VNET has the Input Endpoints listed. But no add/edit button.
This is not currently possible in Azure. Azure IaaS VMs do not yet support multiple IPs per interface, so keepalived will not be able to move a VIP between the nodes. We tried to do the same thing and were told it's not currently available. However, it's supposed to be on the road-map and it is "coming", as is the ability to have multiple interfaces per machine.
Input endpoints are to expose some service on a single VM (it's a NAT), and they are not attachable to an actual interface. The only option that I thought through, was to use Azure's Traffic Manager to round robin between the two HAProxy instances using two exposed endpoints, with a health check to fail to a single HAProxy instance if one fails.
I just created a new site on my IIS on Amazon's EC2 and I was wondering if there is a way to access it publicly without assigning a domain.
In detail. I created a new site dev.example.com which is accessible when I am logged in my instance. Is there a way to access it outside by doing let's say 54.xxx.xx.xxx:80:dev.example.com
I don't know if that's even possible so any hints are appreciated
You can definitely do this, but here's what you'll need to do:
Make sure IIS is configured to route any incoming connection on a particular IP address to your site. This is distinct from IIS specifically listening for a particular hostname (e.g. mywebsite.com).
As an alternative to the above, you could also manually set your DNS on your local computer and then use your web browser to visit mywebsite.com. From IIS's perspective, a user will have requested mywebsite.com just as if public DNS were set
As far as the IP address you visit, your instance will either have an ephemeral Public IP Address which will be reset when the instance is stopped and started, or an Elastic IP Address, which persists across restarts.
As #Anthony Manzo mentioned, you'll need to make sure that your Security Group associated with this instance allows Port 80. In addition, you may want to disable Windows Firewall completely (or check that it allows Port 80 on all three "Zones" (Windows Firewall has 3 different zones to manage).
Afaik the IP addresses assigned to EC2 instances can change throughout its lifetime and therefore you should instead generate an Elastic IP Address (which will always direct to your instance). That way, you don't have to deal with DNS yourself and still are always able to connect to your instance.
Have a look at the "Security Groups" on the left hand of your EC2 web console. You'll have to allow TCP 80 (and whatever else) in the Security Group (probably 'default') first.
I need to set up a custom DNS server within EC2. I have one instance that acts as the DNS server, and N other instances that use this DNS server to connect to one another. Is this posible? Basically, I need to modify the DHCP settings for the N instances so that they connect to the DNS server. I can't find any good documentation on modifying the DHCP settings for an instance.
Note: I did find some documents, but they seem to only apply to Amazon VPC. Is there any way to do this without using VPC?
Short answer - no. You need a VPC. But once you have the VPC created - you can effectively do whatever you like with it.
Long answer - traditional AWS hosting gets an address directly from Amazon. This means you've got no control whatsoever of the IP addresses.
New accounts however come with a VPC by default, which means you can install a machine to act as a DNS server. (And I've done this in the past using Windows Active Directory)