Problem to Be Solved
Setting up the OS and the applications required for a virtual server takes just as much work, time, and expense as for a physical server.
A virtual server is a server that does not depend on hardware, that is, it is a server in software. In practice, multiple virtual machines are emulated on a physical machine. Without any major changes to the physical machine, the virtual machine can function as if it were a physical machine. This is very convenient -- you can create or delete virtual machines immediately whenever the need arises.
Although opportunities for using virtual machines are increasing more than for physical machines, the setup required to use a virtual server (for example, setting up the OS and installing and setting up applications) still takes as much labor, time, and expense as for a virtual server.
Explanation of the Cloud Solution/Pattern
You can use the AWS Cloud to create of a machine image in a state where the operating system, middleware, and applications have already been set up on a virtual server, and use that image to launch a new virtual server. That is, once you have set up the operating system, middleware, and applications, you can copy them for use at any time. Copying the virtual servers like using a rubber stamp lets you generate virtual servers in large quantities,with the environments already set up and ready to go.
While in the past you would have had to do this by taking the physical disk where the environment has been set up and copying it to another disk, or by using separate backup software to copy from disk to disk, this would have been time-consuming and expensive, making it difficult to perform such copying quickly and at high volumes. When using the AWS Cloud, on the other hand, resources such as the servers, disks, and the like, are handled logically, so you can perform such operations easily.
If you create an Amazon Machine Image (AMI) from an Elastic Block Store (EBS) that includes the boot region of the operating system, you will be able to launch an EC2 instance from the AMI, making it possible for you to produce a large numbers of EC2 instances with identical settings.
- Launch an EC2 instance and install the required software.
- Perform the necessary set up and create a state where it is running as a server.
- Capture and save the AMI after confirming proper operation.
- Use that AMI to create the required numbers of servers, when required.
- Using an AMI where the environment has already been constructed frees you from the operations required for setting up the EC2 instances launched based on that AMI.
- You can launch hundreds of EC2 instances with identical operating systems, data, and settings.
- Even when using a script to launch EC2 instances, set up operations are unnecessary if the environment has already been constructed for the AMI, making it possible to simplify the script.
- Not only can you use the AMIs that have been constructed, but you can share the AMIs with specified users, and, if necessary, you can publish the AMIs.
- The point in time at which the snapshot should be taken and the timing with which the AMIs should be updated have to be handled on a case-by-case basis . The way to do so will depend on the system requirements.
- EC2 instances (virtual servers) that are exactly identical are replicated, so when there are items requiring changes in settings for individual virtual servers there is a need for some way to do so.
- Once you create an AMI, any patches or revisions to the base operating system will not be implemented automatically in the AMI. You will have to perform patching and upgrading operations on the individual AMIs.
This operates the same way as the "Bootstrap Pattern" of the Operation & Maintenance Pattern. Because you can construct the operating system and middleware more flexibly in the Bootstrap Pattern than in the Stamp Pattern, you have to consider the trade-offs when determining which of the two patterns to use.