A must-see tutorial for learning DevOps from zero basics, taking you 10 minutes to quickly get started with DevOps

[DevOps] is a very popular concept recently. It is embarrassing to say hello to people without talking about DevOps when talking about IT process construction.

But what exactly is DevOps, and can it be used? how to use? What kind of situation is called a successful DevOps landing?

For the answers to these questions, although there are overwhelming articles and tutorials on the Internet, they are generally explained in terms of theory or methodology, and there are also implementation experiences in large factories.

Personally, I feel that the stone of other mountains here is difficult to attack jade. In the end, you still have to think about the origin of DevOps and consider the actual situation of your own enterprise.

Table of contents

  • what is devops
  • The concept of devops is proposed

  • Monolithic Architecture + Waterfall Mode

  • Distributed Architecture + Agile Development Mode
  • Microservice Architecture + DevOps

  • Deep understanding of devops

  • How devops are practiced
  • Devops implementation related tools

  • Devops platform building tool

1. What is devops

DevOps Wikipedia defines DevOps (a combination of Development and Operations) as a culture, movement or practice that values ​​communication and cooperation between “software developers (Dev)” and “IT operations technicians (Ops).” By automating the process of “software delivery” and “architectural changes”, it makes building, testing, and releasing software faster, more frequent, and more reliable.

Here is the definition of Wikipedia. I don’t expect you to understand it all at once. First, there is a concept to understand.

Second, the concept of devops is proposed

2.1. Monolithic Architecture + Waterfall Mode

Monolithic Application Architecture

Waterfall Development Model

Taking the e-commerce system as an example, the single application architecture is LNMP. At this time, only DEV has no OPS. DEV is a full stack, just like the demo we played in college. After the project is developed, find a server to install the environment, and put the jar package. scp to the remote server, put it on it and start the service.

At this time, service monitoring is also simple. If there is a problem with the service, go directly to the online to see the running log. In order to free up your hands to monitor the service, the developer will write some scripts to analyze the log. There are few servers and the deployment is simple. Usually, the operation and maintenance can be completed by development. Work does not require special operation and maintenance for deployment, so the development mode is very simple, and it can be developed directly in accordance with the waterfall method.

2.2. Distributed Architecture + Agile Development Mode

Distributed Architecture
Agile development model

As the business volume grows larger and larger, and one machine can’t handle it, then add machines, single machine becomes multi-machine, and the business architecture also begins to add general basic services such as nginx, cdn, cache, etc., the business will definitely increase People, it involves multi-person collaborative development, multi-person multi-machine mode.

Multi-person collaborative development problems:

Let’s talk about the problem of multi-person collaborative development first. When there are more people, in order to better divide the labor, most of the projects will be split, and each person is responsible for focusing on one part, which feels a bit contracted. The core concept of agile development is that since we cannot Fully understand what the real needs of users are, continuously disassemble a big goal, turn it into small deliverable goals, and then continue to develop in small steps through continuous iteration.

In addition, a project is very large. In order to ensure the quality of the project, the testing process cannot be reduced. In order to speed up the development and increase the development efficiency, the QA work is best performed alternately with the development. The testing process needs to be injected into the entire development from the back. In the link, each deliverable is a set of available functions, and the content of the development delivery is continuously verified. In this way, the controllability of developing products is also stronger. When meeting sb Party A, let him check the project results in stages to prevent painting chickens from turning into ducks.

Multiple Machine Problems:

Let’s talk about the multi-machine problem. Before, when the machine structure was very simple, development could do the operation and maintenance work. Even if a few servers were added, it would be a script to publish the JAR package to these machines at the same time. It seems to be quite simple, but There will be a problem that two people go online at the same time and the deployment will be covered, so everyone may go to the group to shout, “I’m going to go online, don’t go online yet”, but it is conceivable that this is also very inefficient.

The company’s business is very large. Like a large company, there are thousands of servers at every turn, so special operation and maintenance intervention is required. On the one hand, because of the development division of labor, everyone focuses on their own affairs and will not be so careful about maintenance. On the other hand It is because the learning cost of operation and maintenance has indeed increased, and the quality of developers is uneven. If everyone can access the server, it is estimated that leaders will have nightmares every night. But this time is not DEVOPS, but DEV+OPS. At this time, the main responsibilities of Ops are: hardware maintenance, network equipment maintenance, DBA, basic service maintenance, data monitoring, etc. The operation and maintenance personnel are good at writing various deployment and monitoring scripts. Reduce the repetitive work of machinery, and the development model has become an agile development model.

The inherently antagonistic issues of the Dev and Ops roles:

To join the operation and maintenance, it is necessary to coordinate the cooperation of the personnel. The fate of the operation and maintenance is to maintain stability, and they hate changes; the vocation of the development is to continuously push the code online, make code changes, and replace iterations. These two types of work are inherently opposite. .

Many big companies have that kind of thing. When developers want to go online, they need to submit various approvals, sign and sign at various levels. How many people’s enthusiasm for going online is chilled by the cold “the release period has not yet reached the window”. Therefore, agile development solves the problem of collaborative development and multi-machine deployment development, but it does not solve the contradiction between internal personnel. If this contradiction is left in the company, development and operation and maintenance may be in a ‘life and death situation’ at any time.

2.3. Microservice Architecture + DEVOPS

Microservice Architecture 

DEVOPS 

The wiki defines microservices: Microservices is a style of software architecture based on Small Building Blocks focused on a single responsibility and function, using a modular approach to compose complex For large applications, each functional block communicates with each other using a language-independent (Language-Independent/Language agnostic) API set.

The above is my definition of microservices from the wiki, pay attention to a few key words: software architectural style, small functional blocks, modularity, language independence.

First, when the company grows to the size of BAT, it will recruit a lot of people, JAVA, PHP, GO technology stacks will be available, and the technology stacks need to be coordinated;

Second, projects tend to become very large in the later stage, and all of them are converted into one project. The most direct consequence is that the project becomes very large, and the launch time of the online project becomes longer. A bug may cause the entire business line to collapse. The consequence is that the project becomes more and more difficult to maintain, it is almost impossible to add a change to a thing, and it is more and more difficult to refactor, which affects the whole body.

Therefore, splitting and decoupling is the ultimate way out. The project is divided into small services and deployed separately. Taking the e-commerce project as an example, the entire project is divided into user services, commodity services, order services, and points services.. …. Each service is deployed separately and interacts with each other by calling each other, and some basic services such as uploading pictures, sending SMS and other basic things that are required by many services can be abstracted into a separate service, that is The ‘middle-office service’ that has been advocated very strongly in the past few years.

Split deployment gave birth to DEVOPS. Let’s look at the development mode DEVOPS under this architecture. The online work that needs to be done for operation and maintenance is mainly to deploy the code to the corresponding machine. There are so many services in microservices, each larger There are not many hundreds of services in the company, and it is possible to develop a service at any time. If you still follow the original script deployment method, you may not even be able to find any script in the end. Moreover, if each service is launched, it needs the approval of the operation and maintenance, and the development is too humble. It is estimated that it is necessary to ask the operation and maintenance to agree to release it every day, and the operation and maintenance will be very annoying.

Then why can’t some machines be deployed remotely, specially used for code management and online work, and the rules for online are defined by the operation and maintenance in advance, and the development only needs to access this server according to his rules for their own code synthesis and Publish, go online by yourself, and never solve things that can be done automatically with code. This is what every developer is thinking about. The things that need to be done for operation and maintenance are gradually deposited on each platform, such as monitoring, there are special monitoring components and visualization, basic services such as servers, CDN, load balancing and other basic services can be outsourced to cloud service providers, and logs also have special The log tool, link tracking also has special components and visualizations, as well as gateways, etc. Gradually, as long as these are configured, development can also do part of the operation and maintenance work, after all, development is the person who understands the code best, where If there is a problem, look at the monitoring log, and you can locate the problem as quickly as possible, so the DEVOPS development model was born, and development is also operation and maintenance.

three,Deep understanding of devops

We know that a software from scratch to final delivery roughly includes the following stages: product planning, development coding, construction, QA testing, release, deployment and maintenance.

At first, when everyone mentioned DEVOPS, they all referred to ‘development, operation and maintenance integration’, as shown below:

Now what everyone is talking about DevOps has been expanded to the concept of “end-to-end”, as shown below:

Among the three pillars of DevOps are People, Process and Platform. which is

People + Process = Culture

Process + Platform = Tool

Platform + People = Empowerment

4. DevOps practices

Several current issues are mentioned above:

The business/code complexity is high, any modification cannot be evaluated, and the risk of failure is high. Gradually degenerate into relying on documents to standardize
    the environment at each stage, requiring a lot of labor costs to maintain
    the contradiction between the speed and stability of demand development

Then consider what methods and tools DevOps provides to solve these problems, stealing a picture from the Internet is a collection of tools at each stage (invasion and deletion)

After reading it, it is simply a head bag, so I have to sort it out.

When introducing a new tool or method, there is always a criterion for judging whether it is due to the current method and tool according to the digital criterion. For the direction of R&D efficiency, there are the following indicators for reference:

  • Deployment frequency: Refers to how often applications and services deploy code to the production environment.
  • Change lead time: Refers to the length of time the code takes from submission to successfully running in production.
  • Service recovery time: Refers to the time from when online applications and services fail to resume operation.
  • Change failure rate: refers to the proportion of applications and services that fail to be deployed in the production environment or cause service degradation after deployment.

In other words, we just want to find ways to improve these indicators.

Or from the perspective of software engineering, we can divide the evolution to DevOps into the following stages:

  • Continuous integration, unified management of code, continuous construction, continuous output of development to testing.
  • Continuous release, continuous testing, and continuous output to product release
  • Continuous deployment/delivery to complete the continuous output of the product to the production environment

In other words, I think that in the process of improving efficiency (whether it is DevOps or not), it is possible to improve these indicators in a targeted manner, and gradually evolve to the next stage. In this process comes a targeted selection of tools. Using tools is all about automating process steps and avoiding reliance on humans.

  1. Development automation, mainly from configuration management, code hosting (Git), code review (GitHub), code static inspection (sonar), unit testing (JUnit), and Jenkins tools to improve.
  2. Test automation, introducing automated testing
  3. Operation and maintenance automation, the introduction of environment monitoring (Portainer), log collection and other tools

The strategy is to find bottlenecks and solve them. Find the manual part, consider tools to replace manual operations, and it’s a process that goes back and forth.

Five, devops implementation related tools

It goes without saying that everyone involved before and after the development process is the product prototype, UI design in the early stage, then front-end and back-end code development, QA testing, and final deployment. The following figure is a partial flow chart:

The focus here is to look at the devops platform building tools. There are many tools and components, and a hundred schools of thought contend. Most of the ones I listed here are used by my company, and most companies are using them.

5.1, devops platform construction tool

Project Management (PM): jira. Operations can go up to ask questions, and you can see the complete workflow of each problem, pending solutions, etc.;

Code management: gitlab. Jenkins or K8S can integrate gitlab for code management, online, rollback, etc.;

Continuous Integration CI (Continuous Integration): gitlab ci. As soon as developers submit new code, build, (unit) test it. Based on the test results, we can determine whether the new code and the original code are properly integrated.

Continuous Delivery CD (Continuous Delivery): gitlab cd. After the unit tests are complete, the code can be deployed to a database-connected Staging environment for more tests. If there is no problem with the code, you can continue to manually deploy to the production environment.

Mirror warehouse: VMware Harbor, private server nexus.

Container: Docker.

Orchestration: K8S.

Service Governance: Consul.

Scripting language: Python.

Log management: Cat+Sentry, another commonly used one is ELK.

System monitoring: Prometheus.

Load Balancer: Nginx.

Gateway: Kong, zuul.

Link tracing: Zipkin.

Product and UI diagram: Blue Lake.

Internal company documentation: Confluence.

Alarm: push to the work group.

With this complete set of process mechanisms, the entire development process involves personnel who can coordinate work without hindrance. The development comes to the company every day, first look at jira, look at the online log, and check the monitoring log if there is a problem. The operation classmates reported problems and went to JIRA without rushing, shouting in the anxious group, looking directly at the blue lake for product and UI pictures, and monitoring the market with attention to operation and maintenance.

If you want to master DevOps from scratch, you can take a look at this set of DevOps tutorials I recorded , I hope it will be helpful to everyone!

If you find it helpful, you can give me a thumbs up and favorite. If you write something wrong or unclear, you are welcome to point it out in the comment area, thank you!

Leave a Comment

Your email address will not be published. Required fields are marked *