关于EC2的AKI和ARI

本文介绍了Amazon Elastic Compute Cloud (EC2) API 2008-02-01版本的重要更新,包括用户可选内核、可用区选择及弹性IP地址等功能,这些新特性提升了EC2服务的灵活性与可控性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在下面的文章中有详细说明,注意看绿色的字体。

原文:http://www.jamesmurty.com/2008/04/29/programming-ec2-version-2008-02-01/

Amazon has released an updated version of the Elastic Compute Cloud (EC2) API with the version name 2008-02-01. This release includes a number of new features that were not available in the 2007-08-29 version of the API that I discussed in the book Programming Amazon Web Services (PAWS). To help keep my readers up-to-date with the capabilities of the EC2 service, this article contains a description of the new features and demonstrates how to use them in code.

The 2008-02-01 EC2 API provides three important new features:

  • User Selectable Kernels – Choose to run an alternative Linux kernel on your instance, in order to benefit from newer or differently-configured kernel versions.
  • Availability Zones – Choose the locations in which your instances will run. You can distribute your instances across different locations for better fault tolerance, or concentrate them in a single location to minimize network latency and data transfer costs.
  • Elastic IP Addresses – Reserve your own public IP addresses in the EC2 environment, and assign these addresses to your instances on demand. Elastic IPs allow you to make an instance accessible at a known public IP address, without the need to use a dynamic DNS service to simulate a static IP.
Getting Started

The code examples in this article are based on an updated EC2 client implementation that has been added to the sample code archive on the PAWS Examples web site. In this article I will use the Ruby implementation, but the archive also includes equivalent implementations in Java and Python.

Download the latest PAWS_examples.zip archive file, unzip it, and change to thePAWS_examples/ruby directory. This directory should contain two EC2 clients:

$ cd PAWS_examples/ruby
$ ls EC2*
EC2.rb            EC2_2008-02-01.rb

The first file, EC2.rb, contains the original EC2 API implementation from the PAWS book. The second file, EC2_2008-02-01.rb, contains new and updated methods that work with the latest EC2 API version 2008-02-01. This is the EC2 client we will use in this article.

Start an interactive Ruby session with the irb command, and create a client object from the latest EC2 API implementation:

irb> require 'EC2_2008-02-01' # => true

irb> ec2 = EC2.new('YourAwsAccessKey', 'YourAwsSecretKey')

To confirm that you are using the correct API version, use thedescribe_images method to list the Amazon Machine Images (AMIs) provided to the public by Amazon. The listing should include different image types identified by the :type attribute. The image types should include machine,kernel and ramdisk images. Some machine images will also have :kernel_idand :ramdisk_id attributes.

Here is a portion of the results from a listing of Amazon’s images. The first item is a kernel image, and the second is a machine image that includes kernel and ramdisk identifier attributes:

irb> require 'pp'  # => true

irb> pp ec2.describe_images(:owners => 'amazon')
[{:type=>"kernel",
  :is_public=>true,
  :architecture=>"x86_64",
  :owner_id=>"amazon",
  :state=>"available",
  :location=>
   "ec2-public-images/vmlinuz-2.6.18-xenU-ec2-v1.0.x86_64.aki.manifest.xml",
  :id=>"aki-9800e5f1"},
  . . .
 {:type=>"machine",
  :is_public=>true,
  :architecture=>"i386",
  :kernel_id=>"aki-a71cf9ce",
  :owner_id=>"amazon",
  :ramdisk_id=>"ari-a51cf9cc",
  :state=>"available",
  :location=>"ec2-public-images/fedora-8-i386-base-v1.06.manifest.xml",
  :id=>"ami-f51aff9c"},

The kernel and ramdisk image types are new additions to the EC2 API. They make it possible to select an alternative Linux kernel.

User Selectable Kernels

The User Selectable Kernels feature allows you to choose to run an alternative Linux kernel on your instances, in place of the default kernel provided by Amazon. In prior versions of the EC2 API there was only one kernel available for each instance type; a variation of the Linux 2.6.16 Xen kernel. You can now choose from a collection of kernels that have been made available by Amazon or Amazon-endorsed vendors.

With a range of kernels now available in EC2, it is easier to take advantage of kernel improvements or alternative kernel configuration settings that may benefit your application. Unfortunately, the range of kernels is still limited to what Amazon and other vendors provide. You cannot create your own customized kernel, though hopefully it will become possible to do so in the future.

New Image Types: AKIs and ARIs join AMIs

Alternative kernels are made available in the EC2 environment as a new type of image, known as an Amazon Kernel Image (AKI). Because some kernels require additional drivers when they launch, there is another new image type called an Amazon RAM disk Image (ARI) which stores driver files. These two image types join the venerable Amazon Machine Image (AMI) which has always been used in EC2 to store an instance’s root volume.

On the Amazon Machine Images page, you can see a listing of the publicly available kernel, ramdisk, and machine images. This listing contains links to pages with further information about the images. For example, the page for a kernel image may describe the kernel’s configuration, indicate whether it requires a ramdisk image, and include links to module files that are compatible with the kernel. This information can help you decide which kernel will work best with your application.

You can also use the DescribeImages API operation to programmatically list all the images that are available to you. The listing returned by the service will include an attribute that describes the type of each image, and you can also tell the type of an image from the beginning of its identifier string which will be ami-aki- or ari-.

Amazon machine images may be configured with default values for the kernel and ramdisk that instances will use. If you list the attributes for Amazon’s Fedora 8 public AMI (ami-f51aff9c), you can see that it is associated with the kernel image aki-a71cf9ce and ramdisk image ari-a51cf9cc:

irb> pp ec2.describe_images(:image_ids => 'ami-f51aff9c')
[{:type=>"machine",
  :location=>"ec2-public-images/fedora-8-i386-base-v1.06.manifest.xml",
  :is_public=>true,
  :owner_id=>"amazon",
  :architecture=>"i386",
  :kernel_id=>"aki-a71cf9ce",
  :state=>"available",
  :ramdisk_id=>"ari-a51cf9cc",
  :id=>"ami-f51aff9c"}]
Selecting Your Kernel

To run your instance with an alternative kernel, you specify the identifiers of your chosen kernel and ramdisk images when you perform the RunInstances operation. Not all kernels require extra drivers, so you will only need to include the ramdisk identifier when the kernel’s description page indicates that the ramdisk is necessary.

You can select any of the available kernel images when you launch an instance, however it is your responsibility to check that the kernel will actually work with the AMI you are launching. EC2 will not prevent you from using a kernel that is incompatible with the machine’s image or the instance’s architecture, nor will it force you to use the correct ramdisk image. Before you launch an instance with a non-standard kernel, you should always double-check that it is compatible with your AMI.

To demonstrate how to select an alternative kernel, we will launch an instance based on the Fedora 4 Getting Started machine image (ami-2bb65342) that has been available for some time. However, we will launch it with the new 2.6.18 Xen 3.1.0 kernel (aki-9b00e5f2) instead of the default 2.6.16 version.

To launch the instance, invoke the run_instances method and provide a:kernel_id option to specify the alternative kernel’s identifier. Because this newer kernel does not require a ramdisk image, you will not need to include the:ramdisk_id option.

irb> reservation = ec2.run_instances('ami-2bb65342', 1, 1,
                      {:key_name => 'ec2-private-key',
                       :kernel_id => 'aki-9b00e5f2'})

Once the instance has entered the running state and has been assigned a public DNS name…

irb> pp ec2.describe_instances
. . .
  :instances=>
   [{:public_dns=>"ec2-72-44-52-218.compute-1.amazonaws.com",
     :image_id=>"ami-2bb65342",
     :kernel_id=>"aki-9b00e5f2",
     :state=>"running",
     :id=>"i-fb1ad992",
     . . .

…log in to the instance using ssh, and confirm that it is indeed running with the 2.6.18 Linux kernel.

$ ssh -i ec2-private-key.pem root@ec2-72-44-52-218.compute-1.amazonaws.com

ec2# uname --kernel-release
2.6.18-xenU-ec2-v1.0

On an instance, you can find out which kernel and ramdisk images it is using by referring to the kernel-id and ramdisk-id metadata items:

ec2# curl -f http://169.254.169.254/2008-02-01/meta-data/kernel-id
aki-9b00e5f2

If your instance is running with a non-standard kernel and ramdisk, these metadata items will return the identifier values. If you did not specify an alternative kernel or ramdisk, or if the instance was launched using an earlier API version, these metadata items may return 404 errors. This is the case for the instance we just launched, which does not have an associated ramdisk image:

ec2# curl -f http://169.254.169.254/2008-02-01/meta-data/ramdisk-id
curl: (22) The requested URL returned error: 404
Modules for User Selected Kernels

If you launch an instance with a non-standard kernel, it is likely that the machine image will not include compatible kernel modules. If you check the module files available by default on the Getting Started AMI, you will see that they are not compatible with the new kernel you are running:

ec2# ls /lib/modules
2.6.16-1.2069_FC4  2.6.16-xenU  2.6.17-1.2142_FC4

To obtain kernel modules that are compatible with your chosen kernel, you must either obtain pre-compiled module files, or compile them yourself. Fortunately, the information page for the 2.6.18 kernel includes a download link for compatible modules. To install these modules, you can simply download an archive file and extract its contents to the root of your instance’s file system:

ec2# wget http://ec2-downloads.s3.amazonaws.com/ec2-modules-2.6.18-xenU-ec2-v1.0-i686.tgz
ec2# tar xzf ec2-modules-2.6.18-xenU-ec2-v1.0-i686.tgz -C /

ec2# ls /lib/modules
2.6.16-1.2069_FC4  2.6.16-xenU  2.6.17-1.2142_FC4  2.6.18-xenU-ec2-v1.0

ec2# modprobe -l
/lib/modules/2.6.18-xenU-ec2-v1.0/kernel/security/seclvl.ko
/lib/modules/2.6.18-xenU-ec2-v1.0/kernel/security/commoncap.ko
. . .

Pre-prepared module files are only available for some of the alternative kernels. For the kernels without readily available modules, you should check the EC2 developer forums to see if anyone has posted details on where to find modules, or how to compile them.

Bundling AMIs to Use a Specific Kernel

When you use the latest version of the ec2-bundle-vol tool to create your own AMI from a running instance, the tool will refer to the instance’s metadata to discover which kernel and ramdisk images it is using. The tool will then automatically apply these settings to the bundled image it creates, which means that you can easily bundle a new AMI from an instance without having to manually specify the kernel or ramdisk identifiers.

If you wish to explicitly set the kernel and ramdisk identifiers, the ec2-bundle-voland ec2-bundle-image tools allow you to do so by providing the --kernel and --ramdisk options. There are a few situations where you may need to explicitly set these options:

  • If you are bundling an image created outside EC2, and you want the AMI to use an alternative kernel or ramdisk.
  • If you are bundling a running instance, but you want the resultant AMI to use a different kernel or ramdisk.
  • If you do not trust the ec2-bundle-vol tool to retrieve the instance’s settings from the metadata service.
Availability Zones

The Availability Zones feature allows you to specify the location, or locations, where your instances will be deployed and run by the EC2 environment. By controlling the placement of your instances, you can easily disperse them across multiple EC2 locations for better fault tolerance, or concentrate them in a single location to minimize network latency and data transfer fees.

You can specify the location for your instances when you launch them, or you can skip this step and allow EC2 to decide where to place your instances based on the availability and health of each location. In prior API versions, EC2 always chose the location for instances and there was no way you could control, or query, their location.

EC2 Locations: Regions and Zones

EC2 data center locations are described in terms of “regions” and “availability zones”. A region is a broad expanse such as a country or geographic area. At present there is only one EC2 region available, the U.S. East Coast, so the2008-02-01 API release does not provide a way to specify alternative regional locations.

An availability zone is a smaller area than a region. Each availability zone is a distinct location that is designed to be insulated from failures in other zones, yet at the same time to have fast and cheap network connectivity to other zones within the same region. In other words, you can expect that instances running in one zone will be insulated from network, power or disaster failures in another zone, despite the fact that the zones are all located in the same region.

New Transfer Fees for Cross-Zone Data

With the release of the availability zones feature, Amazon updated the pricing model for EC2 to add a fee for data transfers between instances in different zones. From July 1st 2008, it will cost 1¢ per GB to transfer data from an instance in one zone to instances in other zones. Data transfer between instances in the same zone will be free, provided you use the instances’ private IP addresses to communicate rather than their public or Elastic IP addresses. Because many current EC2 users have instances that were automatically distributed across multiple availability zones by the prior EC2 API versions, Amazon has delayed introducing this new fee until after June 30th 2008, to give users time to relocate their instances and avoid the extra fees.

Zone Names

The latest EC2 API version has a new operation, DescribeAvailabilityZones, to list of the name and status of each EC2 availability zone. You can use thedescribe_availability_zones method in the EC2 client to list these zones:

irb> ec2.describe_availability_zones
=> [{:name=>"us-east-1a", :state=>"available"},
    {:name=>"us-east-1b", :state=>"available"},
    {:name=>"us-east-1c", :state=>"available"}]

The listing includes the name of each zone and its “state” (status), which should generally be available. From the zone listing above, you can see that there are currently three availability zones: us-east-1aus-east-1b, and us-east-1c.

These zone names are deliberately vague because the name of an availability zone is not intended to identify a specific physical location. On the contrary, the relationship between zone names and actual physical locations is different for each EC2 user. In other words, my us-east-1a location may be different from your us-east-1a location.

If you run all of your instances in a single zone, they will be physically near each other because that named zone is mapped to a single specific location in your EC2 account. However, when other EC2 users run instances within this zone name, their instances may or may not run in the same physical location as yours, depending on whether their zone name happens to map to the same physical location.

Launch an Instance in a Zone

To run an instance in a specific availability zone, you must specify the target zone name when you launch the instance. There is no way to relocate an instance from one zone to another after it has been launched. In the updated EC2 client, you can specify the availability zone location where an instance will run by providing a :zone option to the run_instances method.

Here is the command to launch an instance in a the us-east-1a zone:

irb> ec2.run_instances('ami-2bb65342', 1, 1,
         {:key_name => 'ec2-private-key',
          :zone => 'us-east-1a'})

=> {:groups=>["default"],
 :owner_id=>"916472402845",
 :instances=>
  [{:type=>"m1.small",
    :public_dns=>nil,
    :reason=>nil,
    :index=>"0",
    :launch_time=>"2008-04-21T03:32:55.000Z",
    :key_name=>"ec2-private-key",
    :image_id=>"ami-2bb65342",
    :zone=>"us-east-1a",
    :state=>"pending",
    :id=>"i-4df73324",
    :private_dns=>nil}],
 :reservation_id=>"r-03a05c6a"}

In the EC2 service’s response to this method, the :zone attribute indicates the availability zone location where the instance is running. In the new API version, both the RunInstances and the DescribeInstances API operations return an XML document with the element item/placement/availabilityZone to describe the instance’s location. You can also check which zone an instance is running in from the instance itself, by referring to the placement/availability-zonemetadata item:

ec2# curl -f http://169.254.169.254/2008-02-01/meta-data/placement/availability-zone
us-east-1a
Elastic IP Addresses

The Elastic IP Addresses feature allows you to reserve your own public IP addresses within EC2, and to programmatically associate these addresses with your EC2 instances. An Elastic IP address can be assigned to any of your instances, or reassigned from one instance to another, within a matter of minutes. Once the address is associated with an instance, you can access the instance via this public IP address and use it as if it were a standard static IP.

With Elastic IP addresses, applications you run on EC2 instances benefit from having a static IP address which allows for easy DNS mapping and address-based filtering. You also gain the added benefit of being able to reassign the address from one instance to another should an instance fail, or need to be replaced.

In Chapter 7 of the book Programming Amazon Web Services, I described how to use dynamic DNS services as a work-around for the lack of static IP addresses in EC2. Now that EC2 includes the Elastic IP feature, this work-around is no longer necessary.

The following new operations were added to the EC2 API to support Elastic IPs. I will describe these operations in more detail below.

  • AllocateAddress - Reserve an Elastic IP address for your own use.
  • ReleaseAddress - Release a reserved address that you no longer need.
  • DescribeAddresses - List the addresses you have reserved, and the instance associated with each address (if any).
  • AssociateAddress - Assign an Elastic IP address to one of your instances.
  • DisassociateAddress - Remove the association between an Elastic IP address and an instance.
Reserve an Elastic IP

To reserve an Elastic IP address for your own use, you need to allocate an address to your EC2 account. Each address you allocate belongs to you whether you are actively using it or not, and the address will remain yours until you explicitly release it. To discourage hoarding of Elastic IP addresses, Amazon imposes a limit of 5 addresses per account, though you can request an increased limit. There is also a fee for Elastic IP addresses that you have reserved but are not using: you will be charged 1¢ per hour for each address that is not associated with a running instance. There is no charge for addresses that are associated with an instance.

You can use the EC2 client’s allocate_address method to reserve an Elastic IP address. This method returns the address that has been allocated to your account:

irb> ec2.allocate_address
=> "75.101.151.147"

You can list all of the addresses that you have allocated to your account with the describe_addresses method:

irb> ec2.describe_addresses
=> [{:public_ip=>"75.101.151.147", :instance_id=>nil}]

Because we have not yet associated our Elastic IP with an instance, the:instance_id attribute in the last response has no value. Remember that you will be charged 1¢ for each hour that you keep this address without associating it with an instance.

Associate an Elastic IP with an Instance

To make an instance accessible via an Elastic IP, you associate the IP address with the instance. When you associate an address with an instance, the instance’s prior public IP address is replaced with the elastic one. The address association process takes a few minutes, during which time the instance will not be reachable from the Internet via the old or new public addresses. Although the instance may not be publicly visible, it will always remain accessible to other EC2 instances via its private IP address, which never changes.

Here is a command that uses the associate_address method to assign the75.101.151.147 Elastic IP address to the instance i-fb1ad992. Remember to close any ssh or other network connections to your instance before you associate the address, as any existing connections will break or behave strangely when the public address changes.

irb> ec2.associate_address('i-fb1ad992', '75.101.151.147')
=> true

Now, when we list the Elastic IP addresses in our account, the listing shows the instance that is associated with the address:

irb> ec2.describe_addresses
=> [{:public_ip=>"75.101.151.147", :instance_id=>"i-fb1ad992"}]

When you associate an Elastic IP address with an instance, the EC2 service will run a process behind the scenes to remove the instance’s original public IP address and replace it with your elastic address. It may take a few seconds before the DescribeAddresses operation shows the latest association between an address and an instance, and it could take several minutes before the instance becomes accessible through its new public address.

An instance can only ever have a single public IP address. When you launch an instance, the EC2 environment automatically assigns it a dynamic public IP address from a pool of addresses. If you associate an Elastic IP address with an instance, the original dynamic address is retired and returned to the pool when your Elastic IP takes its place. If you disassociate an Elastic IP address from an instance, the instance will be assigned a new dynamic address to take the place of the elastic one, and your Elastic IP will no longer map to any of your instances. If you terminate an instance that is associated with an Elastic IP address, the service will disassociate the address before the instance is terminated.

Reassign an Elastic IP between Instances

It is possible to reassign an Elastic IP address from one instance to another, without manually disassociating the address from the original instance. When you do this, the original instance will be assigned a dynamic address, while the Elastic IP address will be assigned to the target instance. The ability to reassign an Elastic IP provides a powerful mechanism to redirect traffic from one instance to another without changing the destination address used by clients.

You can reassign your Elastic IPs to any of your instances whenever you wish, by simply associating the address with a new instance. If we were to launch a new instance with the id i-4df73324, here is the command that would reassign our Elastic IP address from the original i-fb1ad992 instance to the new i-4df73324 instance:

irb> ec2.associate_address('i-4df73324', '75.101.151.147')

Be careful though, because when you reassign an Elastic IP address in this way, neither instance will be accessible from the Internet for a number of minutes until the address association process is finished.

Disassociate and Delete Elastic IPs

To prevent traffic destined for an Elastic IP address from reaching any of your instances, you can use the disassociate_address method to remove the address from its original instance without reassigning it to another one:

irb> ec2.disassociate_address('i-4df73324', '75.101.151.147')

Within a few seconds of invoking this command, a listing of your addresses will confirm that the association has been removed, although it will take a few minutes for the whole disassociation process to finish.

irb> ec2.describe_addresses
=> [{:public_ip=>"75.101.151.147", :instance_id=>nil}]

If you no longer need an Elastic IP address, you should delete it from your EC2 account to avoid paying the hourly unused-address fee. You delete an address from your account using the release_address method.

irb> ec2.release_address('75.101.151.147')

If you intend to use this address in the future you should not release it, because there is no way to reclaim the same address later on. In many cases, it may be worth keeping an infrequently-used Elastic IP address, because the convenience of having a known IP address will outweigh the cost. On the other hand, if you wish to be able to access your instance via a known DNS name but you only run the instance occasionally, you could use a dynamic DNS service as an alternative to keeping an Elastic IP address.

Conclusion

The new features in the 2008-02-01 version of the EC2 API make the service more flexible and powerful, giving you greater control over the distribution, addressing, and configuration of your virtual machine instances. Now it is time to think about how you can best take advantage of these features in your own applications.

For more information about the latest EC2 API features, refer to Amazon’s 

### ComfyUI-AKI 项目概述 ComfyUI-AKI 是基于 ComfyUI 的扩展版本,专注于提供更便捷的操作体验功能增强。此工具集成了多种实用特性,使得用户能够更加高效地管理处理 AI 绘画任务[^1]。 ### 使用指南 对于希望深入了解并有效利用 ComfyUI-AKI 功能的用户而言,建议参考一系列基础教程。这些教程不仅涵盖了软件的选择理由及其优势劣势分析,还包括详细的安装指导、模型加载方式等内容[^2]。具体来说: - **环境准备**:确保本地开发环境满足最低需求; - **安装过程**:按照官方文档指示完成必要的依赖项部署; - **启动应用**:执行命令行指令来初始化应用程序实例; ```bash git clone https://github.com/your-repo/comfyui.git cd comfyui pip install -r requirements.txt python app.py ``` 上述代码片段展示了如何克隆仓库至本地,并设置所需的 Python 库环境以便顺利运行程序。 ### 获取资源 除了遵循标准流程外,还可以访问特定链接或平台以获得额外的支持材料技术文档。例如,在某些情况下,开发者可能会分享预训练好的模型文件或其他辅助性数据集合供社区成员交流学习之用[^3]。 ### 模型下载与使用 当涉及到具体的模型操作时,《全面指南》提供了关于 Stable Diffusion 这类流行框架下常见模型的具体说明。这有助于理解不同类型的神经网络架构特点及应用场景,进而做出明智的选择[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值