As part of your deployment process, you are configuring your continuous integration (CI) system to build AMIs.
You want to build them in an automated manner that is not time constrained and is also cost-efficient.
Which method should you use?
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - D.
The AWS documentation mentions the following.
If your organization uses Jenkins software in a CI/CD pipeline, you can add Automation as a post-build step to pre-install application releases into Amazon Machine Images (AMIs)
You can also use the Jenkins scheduling feature to call Automation and create your own operating system (OS) patching cadence.
Spot instances are an obvious choice because the requirement for the question is "not time constrained" as well as "cost-efficient" solution.
For more information on Automation with Jenkins, please visit the link:
http://docs.aws.amazon.com/systems-manager/latest/userguide/automation-jenkins.html https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+PluginIn order to build AMIs in an automated manner that is not time constrained and cost-efficient, there are multiple methods that can be used. Let's go through the options given:
A. Attach an Amazon EBS volume to your CI instance, build the root file system of your image on the volume, and use the CreateImage API call to create an AMI out of this volume.
This method involves building the root file system of the image on an EBS volume attached to the CI instance, and then using the CreateImage API call to create an AMI from this volume. This approach allows for the creation of the AMI to be independent of the actual CI instance, which can be terminated after the AMI has been created. However, it may be time-consuming to build the entire root file system on the EBS volume, and also EBS volumes can be costly to run for a long time.
B. Have the CI system launch a new instance, bootstrap the code and apps onto the instance and create an AMI out of it.
This method involves launching a new instance and bootstrapping the code and applications onto it before creating an AMI from the instance. This approach is relatively quick and cost-effective, as it does not require a long-running EBS volume. However, it can be challenging to manage the state of the instance during the bootstrap process, and it may be more difficult to ensure consistency across multiple AMIs created in this way.
C. Upload all contents of the image to Amazon S3 launch the base instance, download all of the contents from Amazon S3 and create the AMI.
This method involves uploading all the contents of the image to Amazon S3, launching a base instance, downloading all the contents from S3, and creating an AMI from the instance. This approach can be cost-effective as it does not require long-running instances or volumes. However, it may take longer to transfer large image contents to S3 and download them to the base instance. Additionally, downloading large contents from S3 can sometimes cause latency or throughput issues.
D. Have the CI system launch a new spot instance, bootstrap the code and apps onto the instance and create an AMI out of it.
This method is similar to Option B, but instead of launching a regular instance, a spot instance is launched. Spot instances are spare compute capacity that AWS offers at a reduced cost compared to On-Demand instances. This approach can be cost-effective and allows for flexibility in terms of when the instance is launched. However, it can be challenging to manage the state of the instance during the bootstrap process, and the spot instance can be interrupted and terminated by AWS if the price of the instance rises above the bid price.
In summary, Option B and Option D are both viable options for building AMIs in an automated manner that is not time constrained and cost-efficient. Option B may be simpler to implement, but Option D could offer additional cost savings if the spot instance is available at a lower price than On-Demand instances.