Cloud Developer Days 2019

How many software product developers does it take to attend Cloud Developer Days 2019? The second edition was bigger than before and full of rooms, experts, and knowledge. This time around we geared up and took the team of three, and still weren’t able to attend every panel. Fortunately, the power of a joke didn’t catch us – there was no need to replace the bulb.

Some facts about the conference itself:

• 3 conference rooms
• 34 sessions
• 28 speakers
• Over 250 attendees
• 100% in English

There was a massive amount of knowledge presented over the sessions. But there was one that I was especially interested in – “Secure and testable immutable infrastructure” held by Wojciech Gawroński really made a difference. Let’s talk about what it means, what immutable infrastructure is, and why we care or at least should care to keep it secure, with the necessary quality in mind.

Read also: Cloud Developer Days: A New Place to Be

What is a Cloud Infrastructure?

Let’s start from the beginning – what infrastructure really is? Everything should be considered with the cloud in the context of the cloud, of course. There are many definitions but the one I like the most:

“An entire collection of hardware, software, networks, data centers and other equipment used to develop, test, operate, monitor, manage and/or support IT services”.

In simple words, we need servers with the configured operating system (OS) and additional required software to run our application. The question is how do we get those servers, set them up, or install the required software. I usually split it into two different phases:

• Setting up hardware and installing the OS
• Installing all other software

The first and most natural approach we can take here is manual installation. So, we go to the cloud management portal or other management tools of our choice and choose a new virtual machine. Then we pick an operating system to install and apply all changes. After a few minutes, we get our brand new shiny VM ready to use. This is the end of phase 1. As a second step, we log into the newly created server and configure all required settings. Next, we install all the software needed to run our application. This is the end of phase 2.

But… Hold on a second…This is a cloud and I need 20 servers like that installed by Friday this week. Setting up one took me a whole day. I can’t make it, I need to automate this. So what can I use?

You probably know that you can use the Terraform tool to spin up 20 servers in a short time. The use of Terraform will complete phase 1; we will have 20 fresh servers with the operating system on them. For phase 2 we can use my favorite tool: Ansible. Thanks to it, you can set up 20 servers and install the required software in a few days. This is the end of phase 2.

These two approaches, of course technically very different, but have one thing in common – they are mutable. What does it mean to you?

Let’s imagine that you installed those 20 servers one by one the first one you installed on Monday morning but the 15th one on Tuesday afternoon. Of course, you follow the same steps but are you sure the server number 15 is 100% the same as the first one? Probably not, because number 15 got the latest operating system updates on Monday evening. You think that you have server A but get B instead. I’d like to highlight here that there is nothing wrong with mutable configuration and you can successfully use that approach for the infrastructure. I’ll leave it to you to decide if this is something suitable for your business or not.

I find one major challenge with that. If one has a highly automated infrastructure and needs to deploy many servers to different teams for several different versions of developed applications, he’d like to be 100% sure that he won’t need to invest more time in resolving configuration issues. If one certifies that an application works on a server with configuration A he doesn’t want to run it on B before performing some tests and certifying that it works there as well. What you need is called immutable infrastructure. In this approach, if I request server A, I get A and exactly that. Nothing more, nothing less. From a technical point of view phase previously mentioned, phase 1 and phase 2 combine into one. We can achieve that using already prepared images with all settings and software included. A good tool to create such images is called Packer.

Once you create an image you can easily deploy and redeploy it. You also don’t allow any settings or software to be updated. If there’s a need for an update, you simply create another version of an image.

Read also: PWNing 2018 Conference: The Future of Enterprise Safety

Why Should You Care About Testing?

At this stage, I’d like to get back to the original question and how Wojciech Gawroński helped to answer it in his session. Why and how should you care about testing immutable infrastructure and keeping it secure? We always want to be 100% sure that what we get is what we want, and this is stable and safe to use. We need to test the images to avoid any failures that may cost serious money and be sure our infrastructure is secure and free of malware that can be used to destabilize the system or infect other systems. The real question here is how to do this and do this right.

During his presentation, Wojciech showed us a few tools that may help to test the immutable infrastructure.

4 interesting tools can be used to perform tests of the infrastructure:

• Serverspec – Serverspec tests your servers’ actual state by executing commands locally, via SSH, via WinRM, via Docker API, and so on. So you don’t need to install any agent software on your servers and can use any configuration management tools, Puppet, Ansible, CFEngine, Itamae, and so on.
• InSpec – InSpec is an open-source testing framework by Chef that enables you to specify compliance, security, and other policy requirements. Built on the Ruby programming language, InSpec tests are meant to be easily digestible. If you’re familiar with testing frameworks such as RSpec and Serverspec, the InSpec code will look similar. InSpec can run on Windows, many Linux distributions, and Docker containers.
• Molecule – it’s designed to aid in the development and testing of Ansible roles. Molecule provides support for testing with multiple instances, operating systems and distributions, virtualization providers, test frameworks, and testing scenarios. Molecule encourages an approach that results in consistently developed roles that are well-written, easily understood, and maintained.
• TestInfra – With Testinfra you can write unit tests in Python to test the actual state of your servers configured by management tools like Salt, Ansible, Puppet, Chef, and so on. Testinfra aims to be a Serverspec equivalent in Python and is written as a plugin to the powerful Pytest test engine.

With these tools, you will be able to automate tests of your infrastructure and make sure you deliver high-quality and secure solutions.

Conclusion

As for the conference itself… During those two days, we were able to gather loads of expert knowledge. CSHARK is already using cutting-edge technology presented in sessions to improve the quality of our solutions and meet customers’ needs. Aside from using Microsoft Azure as the core technology, we also push Kubernetes and Docker as a very important part of the ecosystem. Presented information on this stack helped us develop new skills and expand already existing ones. Our customers already benefit from this knowledge, since we always stay up to date, directly translating book smart into street smart.

Read also: Cloud Developer Days 2019: An Automation Tool for Azure