Ansible of architecture : beyond the configuration management
You have passed about already February, 2013/11 / Michael DeHaan's a Ansible Works of CTO to 29, Ansible's Architecture: Beyond Configuration Management management /> `_ that I am writing an article.
I thought that this article is a very good article to explain the architecture of Ansible, so I will publish the translated version with permission of DeHaan.
However, there are many places where this person does not translate successfully because it is poetical and meaning is difficult to say that this sentence is one sentence long. Please pointed out when there is a wrong place.
Ansible of architecture : beyond the configuration management
There was something nice argument about what Ansible is like, it was very strange, so let's classify what is Ansible here.
Ansible is often introduced as a "configuration management" system. But is this really a correct explanation?
Genuine 構成管理 system defines a remote machine in a strict model. These were derived from CFEngine 2 which began 15 years ago. The model runs in Pull mode and Push mode, and the model decides what that server should be, such as by checking with machines that are managed by its own variables (we call "facts"). End users are very welcome to automate, but they are not interested in configuration management and their architecture. Mostly, I just send a file and see if the service is working properly. The architecture to be compiled is good for configuration management, but lacks flexibility for multistage applications with DB, web services, applications and so on. In the typical case of deploying modern distributed applications, many people use other application deployment tools and launch other automation tools. Classic configuration management - "/ sbin / service foo start " declarative that "service is moving to stand up at the time of start-up" instead of リソースモデル , that model to conceal the service of implementation - is Of course it works properly. Ansible has these. A lot. More than 170 of the module is included with the Core, 「バッテリー同梱(batteries included)」 it. Module, your 道具箱 is like a tool that is in the, Ansible is like a 6 foot tall NASCAR-garage-worth tool box (Yakuchu : this parable do not know a little better).
In contrast, アプリケーションデプロイシステム (Capistrano and Fabric is very famous in the classic configuration management user), giving the script that describes the operation for the series of interest, to run in the following. Scripts execute remote machines in parallel through abstracted (eg ssh) connectors and rich features. Simply not only to compile a rigid model of the remote system, the ability to jump over a groove located between the system and the service, box (Yakuchu : beyond the groove between the thought is that to say that for each server) application To be sent. However, typical of these tools, there is a need in the configuration management system 宣言的な抽象化 there is no function of. However, because Ansible uses a declarative resource model, configuration management and application deployment can be executed in the same way as easily. Also, because it uses a data- oriented automation language, there is no need to implement rules for automatic execution in code and there is no danger of complicating software projects. For developers, Ansible probably feels like an application deployment system written by someone with configuration management background. Because you can handle all the resources - git repo, service, configuration file, load balancer etc - from the settings for automating your application. The problem with the script is that it is software code, not what it is executed as it is "wonderful" you wrote. Software code requires effort to write and maintain, possibly growing to such a degree that it becomes hard to read. - And it will not support a resource model that avoids a fragile condition. So Ansible uses a reliable declarative model and abstraction layer brought from the world of configuration management, rather than writing the automation process using Ruby or Python, to run something like an application deployment system I decided to decide.
Well, as I talked about both, I will bring two together. We 構成管理 and アプリケーションデプロイ believe that it is somewhat arbitrary is to separate. - In the real world, the ultimate goal is to deploy business applications. Therefore, I am ambiguous about this boundary. Everyone is thinking about this direction. We usually do not have a "configuration management" user group, we have DevOps and an automated user group. This is all to deploy the application, it is happy with the product. Ansible is also a configuration management tool and application deployment tool. 両方の世界のいいところ uptake, has been realized a hybrid solution to remove the legacy aspects of each system.
In addition オーケストレーション (Orchestration) there is a concept. This is a word used for many different things, I think that we need some more soft words, but there is no other suitable word. This means one of the following completely different things depending on the context.
- Basic function of sending commands to the remote system
- Basic function to send instructions to resources to remote system
- Trigger to execute automated things in configuration management
- Before other systems indicate how the system is configured
- For example, a function to build a workflow system that can be used for many purposes, such as a pipeline depending on the step of writing an IT process
Ansible can do all of these. And say more, Ansible can not only all of the above, the last of the kind - 多くの目的に使えるワークフロー - to automate in a text-based, can be built. You probably graphical IT program (for example, Cisco Process Orchestrator _ old but it is powerful that like) It uses too large a tool and it does not fit the recent DevOps which uses best practice of source code management system which can handle very easily with a text editor.
Many people think that Orchestration is the concept of instructing things already built on some of the connection layers (glue layer). Taking in Ansible, Orchestrationはすべての心臓部分である。 - Dealing with your computer resources and services as orchestra. She plays a brass instrument session combined with the violin, plays a string instrument, and comes back to the solo of the first clarinet. It is very natural to describe these.
For this reason, Ansible is 即時のローリングアップデート excel in Continuous Deployment like. - I burn languages a lot of functions to make things very easy. We include concepts such as "host loops", "delegation", rolling updates in the concept from the beginning, and all of them are the first class of languages. The very first use case when we decided to launch the Ansible project was to make rolling update possible for everyone in the conference room. Ansible is less than half of the text on the page, and it can perform rolling update with one click of the button.
Provisioning Do not forget also about. - This phase is used when deploying software, but the more frequently used scenario is when there is no computer resource, including hardware, or when requesting the server where it is necessary to change. This means that you need to deploy the system itself before setting up the infrastructure system and deploying business applications. Ansible has lots of Cloud Provisioning modules. This works for existing ones, a feature that is difficult to implement with a configuration management architecture. On the other hand, Ansible has flexibility and Provisioning can be done easily. As a result, we have 40 modules to manage many kinds of cloud services. Starting with S3 or Elastic Load Balancer on Amazon Web Service, you can even create isolated network in Rackspace Cloud. You may not need this function for Ansible, but many people need it. Many of our users use Ansible to simplify the way to deploy services on cloud providers.
How did you reach the way to cover all the things you have said so far? - In order to become a great configuration management system, Ansibleはたったひとつのユースケースを解決するために作られたわけではなく、また、革新的なプロセスの結果できたものではない . Ansible was created as a hybrid architecture that synthesized three from the beginning, the configuration management system, the application deployment system, and the workflow-based Orchestration system. And it is based on extensive experience on these systems. - Although there are, such as some of the automation system in previous Red Hat (Yakuchu : Mr. DeHaan previous RedHat Niida), in fact, IT automation is a problem that has not yet been resolved. The hybrid approach adopted by Ansible means that any script can be executed with Ansible and it means the model and the 1-system-at-a-time compilation architecture described in CMS. I can not take it. Starting with any bash script, you can gradually move to a wonderful model of the system topology. On the other hand, it is not easy to migrate from the configuration management system to the Orchestration system. What we made is Orchestration (Orchestrator), and it has all attached to it. - Automating any arbitrary IT workflow is part of Ansible's soul.
Of course this is not over. We 全てに対してエージェントを必要としない have adopted approach. This is implemented by implementing unique functions like SSH and (accelareted mode) SSH (using SSH for key exchange), which is a secure transport. An approach that does not require an agent is a secure push-by-default architecture for customers who are concerned about security against business that reduces demands on remote nodes and gives privileges only to necessary people There. This is the reason why Ansible is becoming popular in the area of Big Data. There is no need to think about maintenance, safety, management architecture, because it's a big bonus point. We are not interested in inventing and managing encryption and homemade safety layers. Therefore, it is the safest and reliable, using SSH that many people use for products.
Finally, we 自動化におけるコンピューターサイエンスの領域を少なくしたい . We feel that a lot of people are annoyed by the complex concept of actual applications. We 自動化ツールを忙しい人々のために作りたい have hope. Although I am a developer, I am crazy about the idea that I want to make it easier to deal with complex deployment systems. Ansible's language has been heavily influenced by workflow Orchestrator - many basic functions (currently having over 170 modules in core) - advanced, very easy (loop, condition, Using role, role dependencies etc.) It is a part that combines the basic functions and makes it a big function.
Since everything is text based, you can have a history that you can see what you have done. However, in order to operate on a confirmable system, it is necessary to use a particularly clear language. - This is the reason why Ansible uses 100% pure data format which can read diff line by line. Even if you did not write the automated part, you can read about that infrastructure's behavior and see what happens with that history. The function of Ansible 's architecture enables this. We 言語が一番大事 believe it. Because it is an interface that you touch every day.
Ansible is 多くの用途に使える自動化パイプライン it is. Source-controlled automation is made with living data-oriented perspectives in a world where you click on mouse and not in the world, 100% pure machine readable world. In addition to the hybrid architecture that we created, IT shops that are busy with the idea of Infrastructure-as-code are making it easier to handle codes. I resist this calling "hybrid DevOps", but this is my idea of infrastructure automation.
My idea is this. - Learn from all things of the tools people and teams use in their daily cycles. - And, tools and 実際に起きること will dig between. "Configuration management" and not as something like "application deployment", which take out the application on the outside of the door, if I dare say, ... すべてのものを自動化する .
With translation
Although it is a poor translation,
- Configuration management
- Provisioning
- Orchestration
It is nice to know that it is designed to be able to do all three.