The coverage of DevOps is very wide, because of the fiery concept, and many articles and technologies are putting the DevOps hat on their heads, which puzzles many people. In fact, if DevOps' knowledge system is decomposed from the top level, there are only two: methodology and tool chain. Methodology, because many ideas of
DevOps are born out of agile, so all the agile ideas, practices and methods you can understand can be used as part of the DevOps knowledge system. I will write a separate article about this part of the follow-up. Today I want to talk to you about
DevOps tool chain.
Some time ago I saw someone sorting out such a DevOps tool chain periodic table. To be honest, when I was in school, I was the most annoying to read the periodic table of elements. Looking at this gadget, I just wanted to vomit Ha, it's a very good thing, it's just a spit.)
In short, you only need 3 core infrastructures to implement DevOps toolchain:
– SCM configuration management system
– Automation
– Cloud (or scalable, self-service, virtualized system)
SCM configuration management system
Configuration management is the lowest-level infrastructure of
DevOps. Whether it is Configuration As Code or Infrastructure As Code, it emphasizes the use of management code to manage the environment. Versioning the environment is important for both rapid creation and stable repeated creation of these DevOps. Basic requirements are the most important foundation.
Listed in the second column on the left side of the periodic table are various configuration management systems, such as: GIT, SVN, Mercurial, GitHub, Bitbucket, etc. For the implementation of DevOps, an important consideration for choosing which SCM is the integration of these tools with other tools in the subsequent Automation and Cloud links. As the star Git in the past two years, all this is not a problem, of course, the best choice.
The content placed in the SCM can be further divided into 2 levels, namely
AppCode: is your application code
EnvCode: It is the environment-related code. This part of the content can be further refined into environment configuration (Config) and configuration data (ConfigData).
Environment configuration: These are basically fixed environment configurations for the current application
Environmental data: data that needs to be adjusted according to the situation at the time of deployment, such as: configuration file, address of development / test / production environment, etc.
Automation automation system
Needless to say, the role of automation in DevOps, this part of the main line is generally realized by various types of Build systems, such as: Jekins, Team City, Travis CI, CC and so on. But these are not enough. In order to complete the migration of the application from the development environment to the production environment, we must also deal with many operations such as compilation, automated testing, dependency recovery, container construction, packaging, orchestration, so we need to configure such as: Junit , Xunit, FitNesse, Selenium, NuGet, NPM, JMeter and many other tools to achieve; but these tools are only to achieve a certain part of the function in the automation system, generally driven by the Build system, and depends on the SCM Provide various codes to achieve.
To be honest, the standardization of various
DevOps deployment tools is not very good. Basically, if you use a certain tool, you will be bound. Although the DMTF has proposed this standard for some time, some mainstream tools still have limited support for it. , Such as: Puppet and Chef, etc. For users, familiar with a certain tool is not willing to replace other, so I am skeptical about the prospect of DMTF. This is a game. For users, it is always better to have a standard than not. It is always a good thing to know more.
Cloud
The emergence of
virtualization and cloud computing should be an important factor in the development of DevOps. Without the flexibility and self-service features provided by the cloud, many DevOps concepts can only stay on paper.
For DevOps implementation, we need to understand the APIs provided by various clouds, because both the automation system and the output of the previous SCM will eventually need to call these APIs to complete the final application deployment.
There is a lot of content in this part, so I will not expand it.
The reason for writing this article is very simple. I think there are too many things that need to be sorted out. If there is something wrong, I hope you can correct me. I hope this article can at least help you find the starting point for understanding the DevOps tool chain, form your own knowledge system, and gradually expand.
