A comprehensive comparison of translation-salt and ansible

Original link: http://jensrantil.github.io/salt-vs-ansible.html

Jens Rantil

Some time ago I needed to evaluate the configuration management system. In combination with the advice from others, I think puppet and chef are overly complex in terms of configuration and operation. Since I am a python powder, I always pay attention to ansible and salt. Ruby is not the language of my cold at the moment, and of course I don't want to provoke a language fight here.

Last year, I spent 6 months of good time configuring the server with Ansible. To become familiar with this tool. Ansible is the best choice for that project because it is easy to use and has complete documentation. The teams I work with try to follow best practices as indicated in the documentation, so that we can get started quickly, and we could draw on structures that have been validated to work.

A few weeks ago I went to Japan to start a 10-day vacation, and I had plenty of time to read some computer magazines and documents in a place where no one knew me at all. Enjoying the delicious sushi, seeing the sights of Tokyo and playing skiing, I found reading a salt PDF document a great pastime.

Of course I took some time to try salt and use the states system. Now I think I have a rough background to the two systems, and I have done a personal color assessment.

Terms

Salt and Ansible were created at the beginning of the execution engine. That is, they can execute commands in one or more remote systems, and they can be executed in parallel.

Ansible supports the execution of arbitrary command-line commands on multiple machines. It also supports the execution module. A ansible module is basically a Python module written in a ansible-friendly way. Most of the standard ansible modules are idempotent. This means that you just need to tell your system what it wants, and the module will try to adjust your system to that state.

Unusable also has the concept of playbook. A playbook is a file that defines a series of module execution sequences for a group of hosts. Playbook can change the host counter by executing the module. This allows us to precisely control multiple machines, such as removing the machine from the load balancer before upgrading an application.

Salt has two modules: the execution module and the state module. The execution module can simply execute commands, such as executing command-line commands, or downloading a file. The state module is more similar to the Ansible module, which defines a state through parameters, while the module attempts to satisfy that final state. Usually the state module calls the execution module to complete the work.

When the state module executes, it executes the module by using States. The status module supports defining state through a file, which is called the SLS file. The mapping between the state and the host is defined in the Top.sls file.

Playbook and SLS files (usually) are in YAML format.

In addition, I want to point out that it is useful to use the remote execution engine when a task needs to use inventory, or when it needs to run on multiple machines.

Architecture

Salt has a salt master, and many salt Minon are connected to the master when initialized. Typically, the command starts at the command line of master. Master then distributes the commands to the Minion. When initialized, minion exchanges a key-building handshake and then establishes a persistent encrypted TCP connection. I can chatter about how salt uses the ZEROMQ library to communicate, but in short, salt Master can connect many minion at the same time without worrying about overloading, thanks to Zeromq.

Because a persistent connection is established between Minion and Salt Master, the command on Salt Master can quickly reach minion. Minion can also cache multiple data for faster execution.

Ansible does not need master, it uses SSH as the primary communication layer. This means it is slower, but no master means it is easier to set up and Test Ansible playbook. Some people also claim that it is more secure because it does not require additional server programs. You can get more information in the "Security" section.

Ansible also has a version that supports ZEROMQ, but requires an initial SSH connection to set it up. I tried this, but to be honest I didn't feel that I was improving. I guess if the playbook is bigger, the host will feel the speed increase.

Ansible recommends using the inventory file to track the machine. The Inentory file basically contains a set of hosts that can be categorized as groups and can be assigned properties to a group of hosts or a single host. You can create multiple inventory files, such as one as a staging environment and another as a product environment.

Salt also supports the use of SSH instead of ZEROMQ, which is salt ssh. But please note that the trial version is still available (and I haven't tried it yet)

Community

I have experience using IRC and mailing lists for these two projects. I've also sent them patch packs, including Python code and some document corrections. Here is a summary of my experience:

The feedback on the ANSIBLE:IRC is very fast and very friendly. But the project seems to lack community influence, more like a person in the lead, namely Michael DeHaan. I'm sorry to say this, but I really like the community because it's more open and friendly for improvement. Ansible Some of the improvement problems have not been repaired and closed, let me feel it to hide the problem. Fortunately, all questions are answered.

Salt needs to continue proving that it welcomes community contributions. IRC feedback has become timely and friendly. Sometimes I need to use a mailing list. I had some mail that didn't respond until 4 days later, but it looks like every message will be followed up in the end.

My impression is that salt has a more mature community and is more welcome to collaborate. I may offend a lot of people when I say this sentence, of course, this is my personal point of view!

Speed

If you think your server is relatively small, speed does not matter, I believe you are wrong. It is always important to be able to iterate quickly. In the long run, slow configuration slows down your entire rhythm. If something takes more than 30 seconds to compile, I'll play Twitter at compile time, which means the compilation will actually take at least 120 seconds. This is also true when deploying.

Ansible always uses SSH to initialize the connection. It's slow. Perhaps Ansible's ZEROMQ implementation (mentioned earlier) will improve this, but initialization will still be slow. Salt uses ZEROMQ by default, so soon.

As previously mentioned, Salt has a persistent minion process. This allows the salt to cache files, speeding up execution.

Code structure

The last thing I can bear is that the Ansible module cannot be imported (because the import executes code). This means that some magic is introduced when the module is tested. Because you cannot import any one module. I don't like magic, but I like pure simple code. It's more like a salt style.

Less magic means more clarity in writing tests to the Salt module. Salt is fully measurable. I'm glad salt has three chapters on testing, including encouraging you to mock some of the infrastructure you don't have to increase testability, such as mocking a MySQL instance.

The above instructions ansible usually have clean and concise code. In which I can quickly jump. However, elevating the code structure is not a concern for the "ansiable community".

Both ansible and salt can be installed through PyPI.

Vagrant Support

When discussing tests, devops people like vagrant. I didn't use it until now. Vagrant can initialize the machine using the modules provided by Slat and ansible. This means that when the machine is initialized, the vagrant can easily use master+minion mode, or perform a playbook.

Task Orchestration

Ansible and salt support orchestration, and I think the choreography rules in ansible are easier to understand and use. Basically, playbook can be split into multiple task groups, each matching a group of hosts (or host groups). Each group is executed sequentially. This is the same order in which the tasks are executed.

Salt supports events and reactors. This means that salt execution may trigger something on another machine. The salt's execution engine also supports monitoring. So the future of this piece of prospect is quite broad. You can use overstate to set up multiple roles in a cluster in a specific order to implement the underlying orchestration.

Ansible is better than salt in choreography, because it's simple. Salt will be better in the future because it is more reactive in cluster changes.

Salt and ansible all support the task through the Machine window. This is useful for ensuring that services are always available, such as when upgrading.

Safety

Ansible uses SSH to transfer data. SSH is a proven protocol. Once the SSH server is properly configured (using a good random number generator), I believe most people will consider the SSH client to be secure.

Ansible can also easily establish multiple non-root users to connect to a single host. If you are very opposed to having a process run with root privileges, then you might consider using Ansible. Ansible supports using sudo to execute modules in root mode. So you can create an SSH connection without using root.

Salt uses the "own" AES implementation and key management. I would like to point out that the "self" here is actually using the Pycrypto package. Salt used to have security problems, but at the same time I think the salt architecture is simple, so security issues can be easily maintained.

It is a little bit to point out that the salt runs master and minion by default in root mode. This configuration can be changed, but it will obviously lead to some new problems, such as the difficulty of installing Debian packages in non-root mode. On master You can configure the Salt command to be non-root mode. I highly recommend doing so.

Sensitive data

All sensitive data should be stored separately and then stored on the configuration machine when needed. If the configuration machine is a system administrator's machine (now usually a laptop), then there is a risk that data will be compromised.

After a long period of thinking, I think the certification master method is a better choice. This means that sensitive data can be forced to reside in a protected place (which, of course, requires an encrypted backup). Salt can store the security certificate in "Pillar". Of course, breaking master would be a devastating blow, but at the same time we just need to secure a single machine. Not all developer computers are safe, especially on trains or airports.

Obviously, ansible users can choose to always perform playbook on a computer that is absolutely secure for storing sensitive data. But do people usually do that?

Audit capability

I think auditing is very important when it comes to discussing security. Salt is better than ansible in this respect. Each execution of the salt is stored on the master for x days. This makes it easier to debug, and it's easy to find suspicious things.

Deployment

Ansible is obviously easier. Because it doesn't need to be deployed. Of course, the salt supports SSH, but most of the cases in the documentation assume that we use the Zeromq method. Of course, SSH will be slower.

The benefit of initializing the Minion is that these minion will connect to master. This allows us to quickly initialize a lot of new machines. The minion-connection architecture is useful if you want to use an automated elastic extension feature similar to Amazon. Each automated elastic expansion machine will automatically become a minion.

The Salt initialization script is very useful and executes quickly. You can handle not a variety of distributions, and the documentation is rich.

Learning curve

Ansible this aspect is better. Ansible easier to learn and improve. Because we just need to make a copy of the ansible git code base and set up some environment variables to execute playbook.

Salt can run in non-master mode. This makes it easier to set up and run the salt. However, for a product environment (and a staging environment) I recommend using master mode to run the salt.

Throughout, the salt function is more flashy, at the expense of steep learning curves. Salt is more modular. This is easy to organize the code structure, but a full mastery of salt requires more learning.

Upgrade

The upgrade salt depends on how the salt was installed at that time. Based on the distribution of Debian, there is an apt code base to store the latest Debian packages. So if you upgrade, you can use Apt-getupgrade. For Ubuntu machines, there is a PPA. The maintenance of these code libraries is very active. The latest release of the 2014.1.0 version of the week (time is a bit long) there is a Debian/ubuntu package.

Upgrading Ansible is easier. You can simply execute git fetch && git checkout .

Document

Two projects have detailed documentation for you to set up and run, as well as develop modules and configurations. In the past ansible has a better document structure than salt. Salt has recently been heavily aerated to restructure the document. I have also contributed my strength to help improve these documents.

Conclusion

For me, Ansible is an excellent tool for automating server configuration and Automating deployment. Setting up the ansible and running it is simple, and the documentation is plentiful.

Further, salt is scalable, fast and well-structured. I found that the salt structure is more suitable for cloud deployment. I will not hesitate to use salt in the future.

In general, it's best to try them out in your project before you make a choice. Anyway configuration and test ansible and salt are very fast.

A comprehensive comparison of translation-salt and ansible