Every book has a story, this story has a book
I wanted to resign from my job, my suggestions about working on creating a centralized configuration system have not been considered by the team leader. Worse than that, it was not something he really understood. Even my colleagues at that time didn't understand what is a configuration management system. At that time, "DevOps" wasn't a buzz word and folks in software engineering were not conscious about the power of what was coming next.
Like many of us, I'm lazy when it comes to repeating tasks manually but passionate when I automate them. Automation = Power.
I love automation, and in that previous job, there are hundreds of configuration files and thousands of variables to copy from text files then to adjust in some platforms, a huge number of poorly-configured servers, and hundreds of servers to manage by a very small team.. I wanted to work on the automation of some weekly procedures. I was aware that this is a good solution, but it was not the priority neither for the manager nor for the client. I'm talking about a role within a team of 14 people working on the integration of several heavy applications (mainly Java/Oracle, PHP/Mysql, Nginx, Python/Jython) with a complex architecture, tens of versions/environments to manage, and a critical infrastructure covering all the European continent. You can imagine how the word "change" can be seen as a horror movie for team leaders and decision-makers.
In the beginning, I was obliged to follow my boss's guidelines and the work methods my team has adopted, which have one goal: satisfying as fast as possible the unceasing demands of the client.
No, but .. wait, this is not satisfying for me!
I spent almost two weeks searching and working on some solutions before I convinced my boss to give me the time to set up an application prototype that will ease the heavy load, accelerate daily procedures and reduce human errors.
First, I created a configuration management tool using Python/Sqlite3, I spent weeks developing it and it was funny. Some weeks later, I discovered that a tool called Salt exists and found it then a good solution to replace my homemade platform. It meets the expectations of the integration process, or rather, the continuous integration, deployments, and automatic tests.
I hesitated between several alternatives: Ansible, Puppet, CFEngine, Chef .. etc. The choice was made based on several criteria (I was looking for robust, fast configuration management and remote execution tool that everybody can use without learning a new programming language) .. I have never regretted my choice. I found some difficulties. Let me admit: **many** difficulties. And honestly, when I started learning Salt, the official documentation was not as complete and good as now. I even still think the actual documentation can be better.
This book is the fruit of long hours of work and self-learning.
Well, in the beginning, I wanted to resign from my job, just a few days after discovering Salt, I was in love with it, and with what I was doing and learning. I tried Salt the first time when I saw my team taking more than 3 days (sometimes more) to configure hosted platforms at each deployment (we had more than 10 environments per application). After setting it up, the same procedure was taking less than 1/2 hour.
Through this book, it's your turn to discover SaltStack, and I will be your guide.
What are you going to learn?
You will learn how to:
- How to install and configure Salt
- How remote execution works in Salt
- How to describe your infrastructure and apps deployments using code
- How to create an event-based reactive infrastructure
- How to make automated changes to your data center following conditions you describe
- How to orchestrate your data center and app releases
- What are the best practices
- How to scale Salt when your infrastructure grows
- How to troubleshoot Salt
All examples in this book are tested.
The book comes with a free Salt Cheat Sheet.
