Test Driven Infrastructure with WSO2

Implementing WSO2 Middleware, without having “real” control over your infrastructure eventually results in chaos. Especially when doing the DevOps way of working. In this blog I’m going to show a possible challenge, and a new way of how to specify infrastructure, and eventually automate it in the deployment pipeline.

Example scenario

Assume we have this imaginary (mini) enterprise environment. On the test (acceptance) environments looks something like this:

Active Directory behind firewall A and MySQL server behind firewall D are existing components running in the infra. And the enterprise just provided VMWare environments where we can run WSO2 Application Server and WSO2 Enterprise Service Bus instances.

After some time the developers managed to implement and deploy a web application and an ESB proxy with on one side a SOAP service that is consumed by the web app and a JDBC adapter that talks with MySQL. The web app implementation is covered with unit tests and maximum code coverage. The WSO2 ESB proxy has a deployment pipeline with a nice automated test script supported by SOAPUI. And all together the deployment pipeline covers a proper CI solution. 

Although the deployment pipeline for the web app and proxy service is fully covered, and both components run perfectly in their own containers, there is still no 100% certainty that this distributed solution will actually work.

Infrastructure questions:

1. There is a trusted LDAP connection for doing user authentication to enter the web application.
1. Is firewall A and B properly configured so that WSO2AS and Active Directory can communicate with each other?
2. Is the handshake policy for doing an LDAPS working?
2. WSO2AS needs to be able to consume and communicate with the WSO2 proxy on the WSO2ESB.
1. Is firewall B and firewall C properly configured for doing an HTTPS : 443?
2. Is the handshake policy properly configured?
3. Are the certificates on both sides not expired?
3. WSO2ESB needs to be able to communicate with MySQL.
1. Is the firewall rule for this communication active?
2. Is the database account working?
4. Is health monitoring in place for both WSO2 environments?
5. Does the technical stack meet with general securiy policies specifically for this infrastructure?
6. Does the technical stack meet with specific operational policies for this infrastructure?

When all the above points are covered / tested and verified on both test-, acceptance- and live-environments, we can say with certainty that the above technical solution works. Intake phase and go live deployment are covered with a implementation plan. The application is ready to go live.

Maintenance

The application is running live for 1 month. Suddenly something breaks on the live environment. A developer is asked to look into the problem, and it will take him at least a day to find out what the hell is going on. It will take an extra day at least to deliver a solution and go live preparations for the fix.

Possible issues:

• A certificate somewhere is expired.
• Some firewall specification accidently changed. Another IP address, port is introduced.

Could this have maybe been discovered faster? 

InSpec

A new product from the Cheff people is a common scripting language called InSpec. Basically it’s possible to approach your application infrastructure in a “Test Driven” way. InSpec is a common language that is easy to learn and understand for people that are working on various different disciplines in your DevOps organisation. (Developers, Network people, Security people, Auditors, Architects etc. etc.) I was attending a demo of InSpec during the Devopsdays 2016 in Amsterdam.

With Inspec it is possible to have a better insight in complicated infrastructures. Generic rules for:

• Network configurations
• Security rules
• Firewall rules
• Protocols
• Application specific rules

can all be scripted (inherrited) for all components that need to be a part of the infra.

Product page : https://www.chef.io/inspec/

Many examples can be found here: 
https://github.com/chef/inspec/tree/master/examples/kitchen-chef

Intergrate InSpec in CI deployment Pipeline

One idea how to apply InSpec scripts is to integrate it in your deployment pipeline with the help of your CI tool. That way it is possble to test remotely if your application will fully function on your infrastructure just by running the tests. The result is that there is more control over your infrastructure, that is sometimes changing. With that you’ll win less unexpected surprises technically.

In a picture it looks something like this:

Enumerated tasks are covered by the automated deployment pipeline

Conclusion

Inspec is really designed for a DevOps workflow. Thanks to the automated tests it is possible to outline compliancy, policy issues and more. There is no reason anymore of getting lost in the infrastructure maze of an enterprise. 

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.