kube-monkey VS terratest

Not in the typical sense, but we have plenty of standard practices and cross-team checkpoints to limit risk. By the time we're deploying changes to production, the work has had a card created, assigned points (which necessarily involves discussing scope and risk), architected (as a group), code peer reviewed, hit unit tests (automated), integration tests (automated), functional tests (automated), smoke tested (automated) end-to-end tests (a few automated, but mostly manual by QA), acceptance tested (by QA and business), resilience tests (chaos engineering with kube-monkey), been deployed to at least 3 environments (with the same exact same artifacts, just with config changes), and monitored for failures (pod restarts, log anomalies, etc -- all automated). Deploy to production is well communicated, and ANY team can request a halt to the deploy if they have concerns.

Part of being a cloud native company means designing services for failure. What happens, for example, if the payment service/pod goes down? Do the rest of your services continue operating normally? One thing tools like kube-monkey does is automatically kill pods for you on a certain date at a certain time in order to plan for failure events. Just wondering if anyone has dove into the deep end with this type of tooling and really just gone all out, besides Netflix?

Chaos Mesh is a popular solution (about 5k GitHub stars), but — obviously — not the only one. E.g., Litmus is a powerful platform to test many things, and kube-monkey might be a good option for more basic stuff.

Exactly the kind of thing I love to see! Sounds like a great use case for a tool like kube-monkey as well.

Kube Monkey

Terratest is a Go library that provides tools and patterns for testing infrastructure, with first-class support for Terraform, Packer, Docker, Kubernetes, and more. It's used to write automated tests for your infrastructure code.

I think I found it. This is the one right? https://github.com/gruntwork-io/terratest/

What it does in parallel is basically init/plan/show using terratest on every subdirectory on your repository tree or provided paths. The output is either a JSON summary or a custom made Junit XML test file you can ingest into your tests reader. It took it around 8 minutes to map the entirety of our bloated repository.

You could deploy to a separate account (usually dev first), you can use terratest, you could try something like LocalStack. I dare say there’s other methods.

Was wondering if anyone has tried https://github.com/gruntwork-io/terratest to test their infrastructure. I like it because I can write golang tests! Thats a big plus for me.

Once there is a CI pipeline for delivering infra changes you can add static code analysis tools (checkov) and even start testing changes (terratest)

https://github.com/gruntwork-io/terratest/blob/master/test/azure/terraform_azure_example_test.go https://github.com/gruntwork-io/terratest/blob/master/examples/terraform-backend-example/main.tf

Another plus is to add tests into your workflow, just by adding a run step with terratest

Terratest: Framework de testes para Terraform, os testes devem ser escritos em Golang.