使用 Terraform、Cloud-init 和 Ansible 实现 AWS EC2 服务器的常用配置

我想在AWS和IBM Cloud两个云平台上使用Terraform创建虚拟服务器,以体验和了解多云工具的实际情况。上次我在IBM Cloud上创建了一个Terraform的配置文件,现在我将其改写为适用于AWS EC2,并进行验证。

这篇文章是关于使用Terraform + Cloud-init + Ansible 在IBM Cloud中自动化部署VSI(虚拟服务器实例)的AWS版本的文章。

Terraform的详细代码可以在takara9/terraform-aws-ec2找到。Terraform的执行环境假设为takara9/vagrant-terraform。

以下是在从GitHub克隆的目录中,列举文件名的同时描述了如何处理的内容。

~/terraform-aws-ec2$ git clone https://github.com/takara9/terraform-aws-ec2
~/terraform-aws-ec2$ tree
.
├── ansible.cfg
├── creat_inventry_ansible_f_terraform.py
├── install.yml
├── main.tf
├── masters.tf
├── nodes.tf
├── playbooks
│   ├── hosts
│   └── setup.yml
├── README.md
└── terraform.tfvars

需要在AWS EC2上进行修正的部分

创建使用Ansible和Terraform的库存(inventory)脚本_f.py。

读取 Terraform 配置文件中输出部分的内容,将节点的 IP 地址、域名和授权密钥写入 Ansible 的清单文件中。

这次重新写AWS EC2时,没有特别的变化。然而,这次我们将Terraform的配置文件main.tf拆分成了三个配置文件。因此,由于aws_instance被分成两个文件,outputs的输出也发生了变化,我们进行了代码修正。除此之外,没有其他功能发生变化的部分。

安装.yml

這是一篇關於使用 Terraform + Cloud-init + Ansible 在 IBM Cloud 虛擬伺服器自動化配置的文章中所提到的,以下是 Cloud-init 的組態文件。

在IBM Cloud中,我们使用了Ubuntu 18.04,因此使用了Amazon机器镜像(AMI)的Ubuntu 18.04。这两个镜像安装的软件包有所不同,为了消除这种差异,我们添加了额外的软件包。

然后,IBM Cloud上的Ubuntu登录用户是root,但在AWS EC2上,用户是Ubuntu,并且不能使用root登录。因此,这就导致了无法通过Ansible进行操作的问题。为了解决这个问题,在install.yml文件中添加了允许使用root登录的步骤。

主机.tf, 控制节点.tf, 节点.tf

将Terraform配置文件放置在拓展名为tf的文件夹中,所有文件都将被读取和应用。因此,这次我们将文件分为三个部分,命名为main.tf,分别承担以下职责。

    • main.tf: 変数宣言、セキュリティグループ、認証鍵の登録などの共通部分

 

    • masters.tf: EC2 の master-0 を起動するための構成ファイル

 

    nodes.tf: EC2 の worker-0, worker-1 を起動するための構成ファイル

根据 AWS 用 Terraform-Provider AWS Provider 的项目,我们将对这部分进行描述。当然,描述的语法将遵循 HashiCorp Configuration Language,但要注意的是,IBM Cloud 和 AWS 的项目名称不同,因此必须进行全面的修改。

剧本

这是一个包含Ansible Playbook的目录。即使是相同的Linux发行版,安装的软件包也会有所不同,而且配置上可能会有差异。为了消除这些差异,在Cloud-init的YAML文件中进行级别对齐,可以使得Ansible Playbook下的Playbook在不同的云服务提供商之间,无需做任何修改,可以直接使用。

terraform.tfvars = terraform配置文件

这是一个收集变量的文件,但随着前面提到的Terraform配置文件的更改,需要进行必要的修改。

利用 Terraform 进行 AWS EC2 的配置定制。

与IBM Cloud的不同只有一个地方。那就是Terraform提供程序会自动下载,所以只需执行子命令init就足够了。

$ git clone https://github.com/takara9/terraform-aws-ec2
$ cd terraform-aws-ec2
$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (1.58.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 1.58"

Terraform has been successfully initialized!
<中略>

$ terraform plan --var-file=/vagrant/.secret_aws.tfvars
<中略>


$ terraform apply --var-file=/vagrant/.secret_aws.tfvars
<中略>
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

Outputs:

master_hostname = [
    ec2-52-69-**-***.ap-northeast-1.compute.amazonaws.com
]
master_public_ip = [
    52.69.**.***
]
worker_hostname = [
    ec2-52-193-**-**.ap-northeast-1.compute.amazonaws.com,
    ec2-54-249-***-***.ap-northeast-1.compute.amazonaws.com
]
worker_public_ip = [
    52.193.**.**,
    54.249.***.***
]

使用 Ansible 实现 AWS EC2 的自动配置

Ansible的Playbook可能可以使用与各个云服务提供商共享的设置。尽管本次的Playbook没有实际进行任何配置,但已确认可以使用Ansible访问并执行命令。

根据Terraform配置文件的更改,我们已经修改了读取Terraform的terraform.tfstate并将其添加到主机清单文件playbooks/hosts中的部分。

$ creat_inventry_ansible_f_terraform.py
$ ansible -i playbooks/hosts -m ping nodes
ec2-52-193-53-92.ap-northeast-1.compute.amazonaws.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
ec2-52-69-53-181.ap-northeast-1.compute.amazonaws.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
ec2-54-249-221-204.ap-northeast-1.compute.amazonaws.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

$ ansible-playbook -i playbooks/hosts playbooks/setup.yml

PLAY [nodes] ************************************************************************************

TASK [Gathering Facts] **************************************************************************
ok: [ec2-52-193-53-92.ap-northeast-1.compute.amazonaws.com]
ok: [ec2-54-249-221-204.ap-northeast-1.compute.amazonaws.com]
ok: [ec2-52-69-53-181.ap-northeast-1.compute.amazonaws.com]

TASK [Test] *************************************************************************************
changed: [ec2-52-193-53-92.ap-northeast-1.compute.amazonaws.com]
changed: [ec2-54-249-221-204.ap-northeast-1.compute.amazonaws.com]
changed: [ec2-52-69-53-181.ap-northeast-1.compute.amazonaws.com]

TASK [Debug] ************************************************************************************
ok: [ec2-52-69-53-181.ap-northeast-1.compute.amazonaws.com] => {
    "result.stdout": "ip-172-31-7-241"
}
ok: [ec2-52-193-53-92.ap-northeast-1.compute.amazonaws.com] => {
    "result.stdout": "ip-172-31-6-60"
}
ok: [ec2-54-249-221-204.ap-northeast-1.compute.amazonaws.com] => {
    "result.stdout": "ip-172-31-10-232"
}

PLAY RECAP **************************************************************************************
ec2-52-193-53-92.ap-northeast-1.compute.amazonaws.com : ok=3    changed=1    unreachable=0    failed=0
ec2-52-69-53-181.ap-northeast-1.compute.amazonaws.com : ok=3    changed=1    unreachable=0    failed=0
ec2-54-249-221-204.ap-northeast-1.compute.amazonaws.com : ok=3    changed=1    unreachable=0    failed=0

总结

通过使用Terraform实现多云架构,在这个验证过程中,我们考察了共同化的程度和相关挑战。以下是研究结果:

    • Terraform 構成ファイル main.tf, masters.tf, nodes.tf は AWS用プロバイダーの仕様に合わせて変更

 

    • Cloud-init の設定ファイル install.yml は、AWS EC2 と IBM Cloud VSI のイメージの差異を埋めるため修正

 

    Ansible プレイブック 共通化できると考えられる

当将Kubernetes和Terraform作为多云工具进行比较时,我们发现以下差异:

    • Terraformの 構成記述言語 HCL (HashiCorp Configuration Language)に従って、共通の記述文法で、各社プロバイダーの仮想サーバーをプロビジョニングできる。

 

    • しかし、Terraform-Providerの記述仕様に従って構成ファイルを記述しなければならない。この記述仕様を使うためには、各社のクラウドの仕様を良く理解していなければならない。

 

    Kubernetesでは、クラスタを構成するマスターやノードは、各社プロバイダーの仕様に従ってプロビジョニングする必要があるが、開発者が利用するマニフェストやコンテナ・イメージのレベルでは共通化できる。

虽然这只是一个粗略的总结,但是我认为使用Terraform可以很容易地自动构建各个供应商的Kubernetes集群。当然,需要考虑使各个供应商的Kubernetes集群配置能够通用,但我觉得完全可以做到。

广告
将在 10 秒后关闭
bannerAds