New Features for AWS Image Uploading

Share
Share

A while back we introduced utilities to help with image management in AWS EC2. Especially uploading a custom image is not necessarily something you’d do in a minute on the spur of the moment and thus the ec2uploadimg can come in handy. Some people agree and have picked up the tool only to find that a few important use cases were not considered in the previous implementation. What if instances launched in EC2 cannot get a public IP address? What if there is no default VPC configured on purpose in the account?

Well these issues are now addressed with the release of python-ec2uploadimg-1.1. The new release has some new command line options that help you better define the use of the helper instance that is used to create the new image you want to register in EC2.

The –use-private-ip command line option is used to tell the upload utility to connect to the private IP of the helper instance rather than trying to connect to a public IP address. Thus, if you are in a completely sealed of network that is connected via VPN gateway or direct connect to your own network you no longer have to jump through special hoops to make image uploading possible with ec2uploadimg. The –vpc-subnet-id option lets you define the use of the VPC subnet into which the helper instance should be launched. With this feature the account being used to upload the image does no longer have to have a default VPC defined.

While the new features make the tool more useful, that’s not all that has changed. The new release depends on the boto3 toolkit rather than the previous version. This has the advantage that when new regions are rolled out by Amazon, support for those new regions is available immediately as the structure of boto3 is more dynamic and the end points are not hard-coded as they were in the previous incarnation of the toolkit. With the change to boto3 the way the ec2uploadimg utility waits for AWS has changed as well and there are now two command line options instead of having just one previously. The –ssh-timeout argument controls how long the utility should wait and attempt to make a connection with the helper instance, while the new –wait-count argument lets you bump the number of times the utility will wait for the default operations time out to pass before complaining that something didn’t work. The default operations timeout is 600 seconds and thus providing –wait-count 2 on the command line would wait 1200 seconds for example for instance creation, volume attachment, or snapshot creation, i.e. any operation EC2 is instructed to perform by the upload utility. The time check is short circuited, i.e. if an operation completes in 100 seconds then the code will progress after 100 seconds and not wait for the timeout to complete.

Hopefully the new features will be useful. Don’t forget the tools are developed on GitHub  and contributions, feature requests, and reports are welcome.

Share
(Visited 1 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet

Robert Schweikert
2,908 views