Following up on Canary Sandbox Environment (CSE) blog post, in this one we offer further details on our approach to the Mocklord component of the CSE.

By now, it is probably easy to guess what Mocklord is about – mocks (if you have not figured it, it means you likely have not read the previous blog post [nor the title for that matter!]; in any case, we advise you to read the previous post’s content to benefit the most from this entry). So, what does the Mocklord mock?

When the DevOps operator gets to the Infrastructure as Code (IaC) deployment phase, they await with lots of feelings about the end result. They might be curious, they might be anxious, they might also be irritated that it’s their 23rd iteration. 😉 All in all, they run it and await the results. And they know the IaC runs against another company’s APIs. And they know it might create resources. And they know the resources might cost. And they know the IaC might break some already deployed infrastructure. What they probably don’t know is that they could give the same IaC a whirl in an environment where there is no cost to be incurred and no impact on the actual deployment. This is where CSE Mocklord comes in.

CSE Mocklord is being developed as one of two parts of sandbox-like platform designed for testing IaC. It offers access to mocked-up APIs for cloud providers, focusing, in the PIACERE project, on the AWS platform. Internally, it utilizes the powerful moto library. As part of the PIACERE CSE Mocklord effort, we have identified places where there is a need to enhance the current capabilities of moto, especially in validation aspects. The validation enhancements were recently proposed and accepted as a contribution to moto’s public repository.

Moto was made to resemble the actual AWS. It accepts requests and responds similarly to the real service provided by Amazon. While it does not create any resources, it is able to return outputs as if resources were created (and running!). While it is impossible to make moto behave 1:1 like AWS (especially since AWS is a black box, and a complex one as well), moto tries very hard to be as compatible as possible. As moto is not really AWS, it doesn’t need to be provided with all the information that is needed when creating resources on real Amazon services. Sometimes this is beneficial and irrelevant to IaC testing, for example, it is easier to operate by not having to handle credentials. However, this lack of validation is a double-edged sword as in certain aspects the difference between a broken IaC and a working one is exactly in these little details that are provided as parameters of the created resources. As CSEM is aimed to provide platform for testing IaC before deployment on real AWS servers, validation for some parameters was recently added to moto. Specifically, new validation considers:

• Amazon Machine Image (AMI) identifiers,
• EC2 instance types and their regional and Availability-Zone-scoped availability,
• Key pair references.

This makes moto robust against misconfigurations in the IaC, be it typos, lack of proper resource creation ordering, or lack of the referenced resources in the first place!

We are continuing the work on improving moto by providing features expected by dynamic IaC testing platforms. Stay tuned to the PIACERE project to see them coming!