amis eureka_如何构建量身定制的amis来升级您的基础架构

amis eureka

There comes a time in everyone’s infrastructure journey that you have to build your own AWS AMIs. Instead of having to configure your instances every time one is provisioned, you create an image that is preloaded with:

在每个人的基础架构之旅中，都有一段时间必须构建自己的AWS AMI。 无需在每次配置实例时都配置实例，而是创建一个预加载了以下图像的映像：

• Needed applications/tools/scripts
  所需的应用程序/工具/脚本
• Patched with all the latest packages
  修补了所有最新软件包
• Security hardening of the OS
  操作系统的安全加固
• Information regarding your environment so it can come online and instantly start working.
  有关您的环境的信息，以便它可以联机并立即开始工作。
• etc…
  等等…

I don’t think I have to sell anyone too hard on why all of the above is nice to have. It also saves you time and effort since instead of doing this PER instance, it is only done once when the image itself is created.

我不认为我要向所有人推销为什么上述所有东西都很好。 这也节省了您的时间和精力，因为创建映像本身仅执行一次，而不是执行此PER实例。

Another benefit of custom images is the concept of “pets” vs “sheep”. When your images are preloaded with everything you need, you can destroy and rebuild your servers as desired. Your servers become sheep which can be swapped out as needed. This is compared to having servers that need to be reconfigured each time they are built. Instead of destroying the servers/pets as needed, you have to take care of them and all the difficulties that come with that (e.g. constantly patching, updating, hardening for security reasons, etc…)

自定义图像的另一个好处是“宠物”与“绵羊”的概念。 当映像中预装了您所需的所有内容时，您可以根据需要销毁并重建服务器。 您的服务器变成了绵羊，可以根据需要交换出去。 与此相比，每次构建服务器时都需要重新配置服务器。 您不必照顾服务器/宠物，而要照顾它们以及随之而来的所有困难(例如，出于安全原因而不断打补丁，更新，加固等)。

In all fairness, you can reduce the pain of vanilla images by using something like Puppet, Nomad, or Ansible. The problem with this approach is that these tools run at build time. As a result of that, when a server boots up, these tools will need 10–20 minutes to configure it. Compared to a custom image that is instantly ready or takes a minute or two to be usable.

公平地说，您可以使用诸如Puppet，Nomad或Ansible之类的东西来减轻香草图像的痛苦。 这种方法的问题在于这些工具在构建时运行。 结果，当服务器启动时，这些工具将需要10到20分钟来配置它。 与立即准备好或需要一两分钟才能使用的自定义图像相比。

Now that we understand some of the problems and benefits, we need to design how we want to build our custom images.

现在我们了解了一些问题和好处，我们需要设计如何构建自定义图像。

When building custom images, much like any automation, we want to make sure we are making smart decisions. We need to produce something that is:

在构建自定义图像时，就像任何自动化一样，我们要确保做出明智的决定。 我们需要产生以下内容：

• Easy to use
  易于使用
• Able to be automated
  能够自动化
• Scalable
  可扩展
• Easy to update
  易于更新
• Secure
  安全
• DRY — Reduce/Remove the need to copy and paste code
  DRY-减少/消除复制和粘贴代码的需要

For our custom images, this is the outline of how this looks:

对于我们的自定义图像，这是外观的轮廓：

• We will create a base image that has all the general dependencies needed by all server types (e.g. patching, monitoring tools, OS hardening).
  我们将创建一个具有所有服务器类型所需的所有常规依赖项的基本映像(例如，修补程序，监视工具，操作系统加固)。
• All other images will use the base images as a starting point and then tack on any additional tools/applications/configurations needed for the function-specific image (e.g. bastion servers, Kubernetes nodes).
  所有其他映像都将使用基础映像作为起点，然后添加功能特定映像所需的任何其他工具/应用程序/配置(例如堡垒服务器，Kubernetes节点)。
• All images/AMIs will be hosted in a central AWS account. From the central account, the images will be shared with our other AWS accounts. This allows us to manage the images from a single account, cuts down on the provisioning time, helps keep us DRY, and overall makes this setup easier to use/manage.
  所有图像/ AMI将托管在一个中央AWS账户中。 从中央帐户，图像将与我们的其他AWS帐户共享。 这使我们可以从一个帐户管理映像，减少配置时间，使我们保持DRY状态，并且总体上使此设置更易于使用/管理。
• Packer will be used for creating the image
  Packer将用于创建图像
• Ansible will be used for configuring the image
  Ansible将用于配置映像
• Terraform will bootstrap the instances created from the image at build time.
  Terraform将在构建时引导从映像创建的实例。
• The images will not contain any secrets/API-keys/passwords. These will be provided by Terraform as part of the bootstrapping process. This is more secure and also makes the images more extensible.
  这些图像将不包含任何机密/ API密钥/密码。 这些将由Terraform作为引导过程的一部分提供。 这样更安全，也使图像更可扩展。

Packer, Ansible, and Terraform will be explained in their own dedicated sections. I will also include code or references which can be used to get you started with custom images in the “Let’s Get Building!” section.

Packer，Ansible和Terraform将在其专用章节中进行说明。 我还将在“让我们开始建设！”中包含可用于帮助您开始使用自定义图像的代码或参考。 部分。

封隔器 (Packer)

For those who are not familiar, Packer is part of the Hashicorp family(so you know it is going to be amazing). It automates the creation of machine images by:

对于那些不熟悉的人来说， Packer是Hashicorp家族的一员(所以您会发现它会很棒的)。 它通过以下方式自动创建机器映像：

• creating a temporary instance
  创建一个临时实例
• configuring the temporary instance according to the instructions you provided
  根据您提供的说明配置临时实例
• creating an image from the temporary instance
  从临时实例创建映像
• terminating the temporary instance
  终止临时实例

Note: Ever since Packer v1.5.0, support for HCL was added into Packer. All of the examples below will be in HCL. If you have an older version of Packer and do not want to upgrade, you will need to convert the examples into the relevant JSON. This doc can help you transition from JSON to HCL.

注意：从Packer v1.5.0开始，对HCL的支持已添加到Packer中。 以下所有示例均在HCL中。 如果您具有较旧的Packer版本，并且不想升级，则需要将示例转换为相关的JSON。 此文档可以帮助您从JSON过渡到HCL 。

Ansible (Ansible)

Ansible is a server configuration tool. Think of tools like Puppet, Puppet Bolt, Chef, Salt, etc… and you’ll be in the same ballpark. It allows you to configure your servers using code. One of the bullet points in the “Packer” section was:

Ansible是服务器配置工具。 考虑一下诸如Puppet，Puppet Bolt，Chef，Salt等工具，您将处于同一状况。 它允许您使用代码配置服务器。 “包装”部分的要点之一是：

configuring the temporary instance according to the instructions you provided

根据您提供的说明配置临时实例