【问题标题】:Amazon EC2 - How to execute the 'launch" part of a Cross-Account AMI Copy?Amazon EC2 - 如何执行跨账户 AMI 副本的“启动”部分?
【发布时间】:2018-08-27 19:09:22
【问题描述】:

上下文

我想执行跨账户 AMI 复制(我真的想在 C# 中使用 Amazon SDK 执行此操作,但也需要从 EC2 控制台的角度来理解它)。目的是在一个帐户(第一个 AMI)中备份一个实例及其卷,然后在另一个帐户中制作此 AMI 的副本(因此现在有两个不同的 AMI,在两个不同的 S3 存储区域中)。

目前,我的代码执行以下操作:

  1. 查找要为其创建图像的实例(基于用户输入)。
  2. 创建此实例的映像 (AMI)。
  3. 镜像成功完成后,我将 AMI 共享到另一个账户(在镜像上使用 LaunchPermissions。目前,我不清楚是否还需要使用 CreateVolumePermission 共享卷)。

在那里,我想进行复制。问题是当我尝试复制它时,我收到了这条消息:

带有 EC2 BillingProduct 代码的图像无法复制到另一个 AWS 账户。

但是,我做了一些阅读,它说我可以做到以下几点:

启动此共享映像的 EC2 实例,然后从此实例创建 AMI。太好了!

这是我的问题

刚才,通过控制台(网站),我登录到第二个帐户,我选择了共享图像并单击了大启动按钮。

接下来,它带我进入一个屏幕,让我选择实例类型(默认为 t2.micro)。此外,还有“配置实例”、“添加存储”、“配置安全组”等步骤。

出于我的目的,我只想备份一个实例及其卷(使用 AMI 来执行此操作)。而不是默认为 t2.micro 之类的东西,我的所有配置步骤不应该只与我从中获取图像的实例相匹配(尽管我只有与第二个帐户共享的 AMI,并且无法真正看到原始实例,只是共享给它的 AMI)?

当我查看原始实例(来自第一个帐户)时,我看到了 t2.medium,并且我看到了安全组,例如:RDP(3389)-HTTP(80)-HTTPS(443)-SSH(22)

换句话说,我只希望我的“启动”具有我使用 AMI 的实例的属性。它不应该默认为这些属性吗?或者,如何将其默认为这些属性?

更多上下文:在我完成此启动后,目的是创建它的 AMI(或“副本”),我认为我不再需要该实例并可以删除它。我只是为了创建“副本”而启动。

【问题讨论】:

  • 原盘是什么类型的?它来自市场吗?这将解释“EC2 BillingProduct 代码”消息。
  • 我其实不确定。我一直被这一切所推崇:“在这里,程序员,做一些亚马逊的事情......去吧!”。所以就在两周前,我一无所知,包括“EC2”是什么。话虽如此,这些实例是我们为客户创建的,用于托管我们基于 Web 的应用程序。我不确定它是否来自市场,或者是否来自我们创建的“Windows O/S 10,更新至此日期,上面有我们的应用程序,更新至最新版本”的图像。跨度>

标签: amazon-web-services amazon-ec2


【解决方案1】:

AMI 独立于实例。 AMI 仅具有与实例相关联的磁盘卷副本。该实例的其他任何属性都没有保存在 AMI 中。

在您自己的账户和区域内,您可以在 EC2 管理控制台中使用 Launch More Like This,这会将实例类型、标签、用户数据等属性复制到新实例。这是控制台的一项功能,反映在 AWS 中的实际 API 调用中。

安全组是完全独立的对象。一个实例可以关联多个安全组,但安全组不会作为实例的一部分进行复制。

底线:没有 API 调用来“克隆”一个实例及其所有属性。您需要在启动期间指定这些属性。

这是保存的有关 AMI 的信息类型:

{
    "Images": [
        {
            "VirtualizationType": "paravirtual",
            "Name": "My server",
            "Hypervisor": "xen",
            "ImageId": "ami-5731123e",
            "RootDeviceType": "ebs",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/sda1",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-1234567890abcdef0",
                        "VolumeSize": 8,
                        "VolumeType": "standard"
                    }
                }
            ],
            "Architecture": "x86_64",
            "ImageLocation": "123456789012/My server",
            "KernelId": "aki-88aa75e1",
            "OwnerId": "123456789012",
            "RootDeviceName": "/dev/sda1",
            "Public": false,
            "ImageType": "machine",
            "Description": "An AMI for my server"
        }
    ]
}

【讨论】:

  • 只是退后一步,起初我们以为只是在某个时间间隔拍摄快照。这将允许我们备份操作系统、更新方式、我们安装的应用程序及其数据。相反,创建 AMI 似乎是一个更好的主意,因为您仍然可以获得快照,而且还可以获得该实例的某种类型的“元数据”(无论可能是什么)。我们还想要两份副本,一份在客户账户中,一份在其他账户中(因此是跨账户共享)。现在我想知道这个元数据是什么,如果它不能让我获得关于我最初映像的实例的信息。
  • AMI 中的数据 保存在快照中。不同之处在于 AMI 可以包含多个快照,以及共享信息。我在上面添加了详细信息。此外,可以从 AMI 启动实例。无法直接从快照启动。
  • 是的,因为可以从 AMI 启动实例,这似乎是比仅拍摄快照更好的方法。现在在我看来,也许我不应该担心是否使用 t2.micro 来启动实例,即使原始实例(创建 ami 的源)可能是 t2.medium。或者原始实例具有一定的安全组。我刚刚启动,所以我可以复制 AMI。如果我因为原始实例失败而需要这个 ami,那么我可以担心这些细节。但出于复制目的,可能不是。你同意吗?
  • 基本上,我想备份客户实例以防万一发生故障。似乎 AMI 是做到这一点的最佳方式。但我不确定最佳实践是什么,因为我只是将脚趾浸入水中。 ...非常感谢您的时间和投入。
  • “最佳实践”是从 CloudFormation 模板启动实例,该模板定义了实例的所有属性。然后,如果需要另一个实例(即使在不同的区域),该模板可用于启动另一个具有完全相同属性的实例。诚然,磁盘不会包含数据的“副本”,但最佳做法是将数据存储在实例外,通常存储在数据库或 Amazon S3 中。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2022-06-18
  • 2014-02-12
  • 2014-01-19
  • 1970-01-01
  • 2013-07-13
  • 1970-01-01
  • 2020-11-02
相关资源
最近更新 更多