This document discusses testing infrastructure as code (IaaC) using test-driven development (TDD) principles. It recommends applying different types of automated tests for IaaC: unit tests to check for errors, integration tests to validate functionality, and acceptance/security tests on deployed infrastructure. Various tools are mentioned for testing IaaC written in languages like Terraform, Ansible, Chef, and Puppet at the unit, integration, and security levels. Adopting a testing mindset and tools can help catch errors and non-compliance early in development pipelines.
Test driven development for infrastructure as-a-code, the future trend_Gianfranco Panico
1. TDD for IaaC
the future trend
Dnipro, 28th feb 2018 Gianfranco Panico
2. ĐżŃĐžĐČŃŃ
I am Gianfranco
Dreaming of a world with more and better
automation:
- spreading DevOps mentality
- educating to correct InfraDev approach
5. Typical IaaC
caveats
The 200 paradigm
Stack deployments in the Cloud
are mostly requests to undergo
some provisioning actions. HTTP
status 200 means âcopyâ not
âdoneâ.
Cloud provider changes
AWS keeps âimprovingâ their
offer â adding instance types,
increasing the length of some IDs,
changing SSL certs for services â
every second day.
Collaboration
I ansible this box here, you
terraform that DB instance there,
works fine, right?
Delays & Dependancies
That forgotten firewall rule that
wonât let you download the
Docker image from your registry.
Timeouts
Lambdas timeout happily. Cross
region transfers â guess what? â
do timeout too!
Some operations with infras are
inherently long, and donât give
much sign of progression.
Works⊠too much
The resource is deployed, the
service is up, the port is open.
And all other 65534 ports are â
as well!
6. Infra as a Code
means
applying SDLC methods and
tooling to Infrastructure
Development
8. TDD loop
1. THINK of an expected behaviour
2. WRITE a test that fails
3. WRITE code to pass the test
4. REFACTOR
5. GOTO 1.
9. 1. THINK of an expected behaviour
2. WRITE a test that fails
3. WRITE code to pass the test
4. REFACTOR
5. GOTO 1.
var strong = isStrongPassword('password string');
describe('isPasswordStrong', function() {
it('should give negative result for empty string', function() {
var password = '';
var result = isPasswordStrong(password);
expect(result).to.be.false;
});
});
function isPasswordStrong(password) {
if(!password) {
return false;
}
}
10. unit
integration
Oh Not Yet Another Test Pyramid
acceptance
Do our CD scripts work?
Are instances up?
Am I missing some best
coding practice?
Is code style âdecentâ enough?
Can they connect
to the DB/ELB�
Is Bastion Host up and connectable?
Howâs the security of VPCs?
Am I actually solving the right problem?
slow
expensive
11. Test types for Infra
Unit
â No code is actually
run
â Check internal
consistency
â Check format/style
â Check intrinsic
language constructs
Integration
â Code is run
â Systems are
provisioned
â The result is
validated
â E2E / functional
testing goes here
Security
â On already deployed
infra
â Scans for âexcessesâ
â Respondance to
hardening
standards
â Infra-compliance
20. Computing the sha384sum digest of the deployable
package
$ sha512sum app123.war > app123.sig
and then having Jenkins verify the checksum at deploy
stage
$ sha512sum âc app123.sig app123.war 2>&1 |
grep OK
app_v123.war: OK
Trustable artifact
to guarantee that each and every deployable component had been built through
automation, and as such, has been tested fully before being promoted to production.
