云计算提供虚拟化的资源
It's very common that while terraforming some products you realize that there are some additional or core functionalities that are not yet available in the latest provider, at this particular case, AWS provider.
很常见的是，在对某些产品进行分层处理时，您会意识到最新的提供程序(在这种情况下，AWS提供程序)尚不具备某些附加功能或核心功能。
There are two ways to go, the first one: manually (not really my way), the second one: automate it but without breaking our terraform best practices… and this is the challenge here, our IaC standard is based on three main points:
有两种方法，第一种：手动( 不是我本人的方式 )，第二种：使其自动化，但又不违反我们最佳的最佳实践……这是这里的挑战，我们的IaC标准基于三个要点 ：
Encrypting credentials and secrets at rest and in transit. 对静态和传输中的凭据和机密进行加密。 Using IAM roles instead of local users. 使用IAM角色而不是本地用户。 Using terraform workspaces, so we have just a unique template to maintain. 使用terraform工作区，因此我们只有一个唯一的模板可以维护。So basically we have created a simple orchestrator that fulfill all those requirements -> Terrax
因此，基本上，我们创建了一个满足所有这些需求的简单协调器-> Terrax
But this is not about how we work or just to explain the benefits of our standard.. this is about the workaround we found to deploy resources that in fact are not defined at the provider level, so here we go… bear in mind 1st and 2nd points from out standard.
但这与我们的工作方式无关，也不是为了解释我们标准的好处。.这与我们发现部署实际上在提供者级别上未定义的资源的解决方法有关，因此，我们开始……请记住第一和出标准第二点。
The best explanation is a real example, just a few context, we are terraforming AWS backup at all our accounts with a backup standard for all our products and indeed some backup exceptions which is a great manner of managing your backups at AWS, but.. there was a missing functionality at provider level, there is no available resource for SNS alarms!! a basic functionality that notify when a backup failed.
最好的解释是一个真实的例子，仅涉及几个方面，我们正在使用所有产品的备份标准对所有帐户进行AWS备份，实际上还有一些备份例外，这是在AWS上管理备份的一种很好的方式，但是。提供程序级别缺少功能， SNS警报没有可用资源！！ 通知备份失败的基本功能。
Well... this is annoying but not what about null provider? would help? yep for sure.
好吧...这很烦人，但是null provider呢？ 有助于？ 是的，肯定的。
Here, we use aws-vault to manage the sessions, we have a master session that allow us to login to our security account which we use to assume cross-account roles, therefore meanwhile you are able to maintain a the session from the main thread you will be allowed to assume cross-accounts at shell level, great, but not enough… what if i need into a module with a conditional count, OK… that´s a problem, and what about if that module has to be call “n” times per account based on the products deployed at every account, so please see below our workaround.
在这里，我们使用aws-vault来管理会话，我们有一个主会话，使我们可以登录到我们的安全帐户，该帐户用于承担跨帐户角色，因此，您可以从主线程维护该会话。您将被允许在shell级别上假设交叉账户，很好，但还不够……如果我需要带条件计数的模块该怎么办，好吧……那是个问题，如果该模块必须被称为“ n” ”的时间取决于每个帐户部署的产品，因此请参见下面的解决方法。
First, you have to define a template into the module that will be executed at module call, we use null provider to define a dummy resource just to run a shell script.
首先，您必须在模块中定义一个模板，该模板将在模块调用时执行，我们使用null provider定义虚拟资源，仅用于运行Shell脚本。
Great, now let see how we will manage the aws-vault nesting based on temporary profiles defined at runtime at sub-shell levels :)
太好了，现在让我们看看如何基于运行时在子外壳程序级别定义的临时配置文件来管理aws-vault嵌套：)
Remember, we use just one master profile at aws-vault, so to avoid messing it we use temporary profiles that are dynamically created at shell script execution which indeed means that we use a different aws config file for each of this sub-shell executions but maintaining main thread session.
记住，我们在aws-vault上只使用一个主配置文件，因此为了避免弄乱它，我们使用在shell脚本执行时动态创建的临时配置文件，这确实意味着我们为每个子shell执行使用了不同的aws配置文件，但是维护主线程会话。
This is great in very different ways, one unique shell script runned “n” times (due to count based on applications per accounts) with as many different cross account roles as accounts you have and all with just one key pair (access and secret key) stored locally and fully encrypted.
这是非常不同的方式，一种独特的shell脚本运行了“ n”次(由于基于每个帐户的应用程序进行计数)，其交叉帐户角色与您拥有的帐户一样多，并且全部只有一个密钥对(访问和秘密密钥) )存储在本地并完全加密。
Of course this is a temporary workaround in the meanwhile Hashicorp add the proper resource definition :)
当然，这是一个临时解决方法，同时Hashicorp添加适当的资源定义:)
Hopefully this helps someone.
希望这对某人有帮助。
翻译自: https://medium.com/swlh/terraforming-missing-resources-at-provider-level-74cec799d2
云计算提供虚拟化的资源
相关资源：四史答题软件安装包exe