Instance IP Address Communication
Just as it can be important for an instance to know information about itself, it can be important for other instances to know information about the instance. The most obvious reason is that one instance may need to send traffic to another; for example, a web server may need to communicate with a database residing on another instance.
How can the web server learn the database instance’s IP address so that it can make a connection and send traffic? (And, by the way, you would want the database instance’s private IP address so that your traffic travels only within AWS.) Obviously, one method is for the account user to start the database instance via the AWS Management Console, get its IP address, start the web server and log on to it, and manually make the connection to the database instance. Just as obviously, that inconvenient method doesn’t align with the whole automated aspect of cloud computing, does it? Consequently, a number of techniques have been created to handle the dynamic communication of instance information to other instances.
Better: you may pass a file with the database IP address in it into the web server when it’s launched. Of course, the database IP address has to be inserted into the file, which the database server can do by running a text-editing script to insert its own IP address (discovered as metadata) into the file.
Put simply, when most organizationsbegin running fairly complex applications, they discover that manual configuration is insufficient, via the Management Console and user data. A different but common technique is to move to a configuration management mechanism. One important element of this technique is to enable instances to communicate their IP addresses to one another, but these techniques are also used for other important information that an instance may need, suchas the username and password for connecting to a database or which code packages should be loaded onto the instance.
Some organizations use this kind of technique to identify a set of scripts that should be loaded onto the instance; these scripts, in turn, download software packages and configure the packages, insert the instance-specific information into the application’sconfiguration management mechanism, and then connect to other resources within the application.
Figure 6-4 illustrates the flow of activities for an instance using this configurationmanagement mechanism:
✓ Launch: In Step 1, an instance is launched with user data supplied thatindicates what kind of role the instance should play in the application (aweb server, for example). At this point, it’s a bare instance — it has onlythe bare operating system, but no application software or applicationconfiguration information.
✓ Self-discover: In Step 2, the instance self-discovers its IP address (withthe help of the instance metadata IP) as well as any other informationit needs to communicate to other instances in the application. At thispoint, it’s a self-aware instance — it has knowledge about its AWS configuration.
✓ Self-configure: In Step 3, using the role information passed in on theinitial launch, the instance connects to the application configurationmanagementmechanism and downloads software packages, installationscripts, and configuration instructions. It then self-configures to becomea role-ready instance — in this case, one that’s fully configured to be aweb server for the application.
✓ Update configuration management: In Step 4, the instance then communicatesinformation required by other instances in the application to theconfiguration management mechanism. It would load its own IP address,its role, and possibly other information to the configuration managementmechanism. It would then download from the configuration managementmechanism information about other instances and resourceswithin the application that it needs to communicate with. It’s now anapplication-ready instance.
✓ Connect to other application instances: In Step 5, the instance thentakes the information it retrieved from the configuration managementmechanism and sets up connections with other instances and resourcesthat are part of the application. For example, a web server would usethe IP address, username, and password information that it retrieved tomake a connection to a database instance and set up a connection to thedatabase itself. It may also retrieve information about a load balancerthat it needed to register with to begin accepting connections from theInternet and then use that information to register with the load balancer.
This approach to instance configuration has a lot to recommend it. All application configuration information is stored in one place. Little information is necessary at launch-time to trigger a full instance configuration. The process of full instance configuration ensures that other instances can learn what they need to know about the newly launched instance to communicate with it properly, and the newly launched instance can learn about all the resources it needs to communicate with.
For a technology to support this mode of operation, you have a number ofoptions. Obviously, you can use text documents stored somewhere that’s accessible to all instances — S3 comes to mind. The instances can even access storage within your own data center, although that strategy runs the risk, if your data center is inaccessible for some reason, of new instances not being able to join your EC2 applications.
Another common approach to the storage of configuration information is to leverage DynamoDB, AWS’s own key-value service. For configuration information, it would be extremely easy to use, and the flexible key-value schema, which allows for flexible records per key, would allow instances to store instance-specific information — information required in order to access anexternal service that supplies data needed by the instance while operating.
