This is the seventh day of my August challenge.

The paper

As a member of the operation and maintenance team, when you log in to the server, do you have any of the following behaviors:

  • Determine the application startup directory, data directory, log directory, and startup user.
  • Determine how the application starts and whether there is a startup or daemon process;
  • Determine the server’s daily script directory, software source directory, public directory, etc.

If you have any of these behaviors, then your team needs to do directory management practices. Why is that? First of all, it is clear that whatever norms we do, the purpose is to avoid differences; Secondly, everyone in the team has different habits, and no specification will inevitably lead to various server configurations, which virtually increases the difficulty of operation and maintenance. The specification of the final catalogue can lay a solid foundation for subsequent automation.

Take a simple example: with a unified backup directory, we only need to run a simple command to achieve remote backup data, without having to adapt to various backup directories.

Therefore, directory management is often ignored by everyone, but do a good job in directory management can let us benefit!

Train of thought

Since directory management is so important, where should we start? Let’s talk about some of our views.

In the case of directories, it is ultimately the stacks of technology and functional components that are the basis for our requirements for directory specifications. Let’s categorize these requirements. 1. Develop technology stack

  • Java
  • Php
  • Python
  • , etc.

2. Functional components

  • Common components

It can be regarded as public resources, such as installation software, scripts, and backups

  • Based on the component

Can be understood as the basic tools that the technology stack depends on, such as JDK, Tomcat, etc

  • The business component

The value can be related to applications, such as application software packages and application logs

Through the above two categories, it can be seen that their inclusion relationship is: development technology stack > functional components > catalog

implementation

After sorting out the relationship between the technology stack, functional components and the catalog, we can display directly in the form of charts in the spirit of “clear at a glance, one sentence in place, clear” standard style, rather than stick to the text.

Technology stack Functional components The name of the directory owner note
X Common components
The script /data/logs app Unified Script Directory
The backup /data/backup root Unified Backup directory
Application software /usr/local app Unified Software Directory
Source installation package /usr/local/src root Unified source directory
Java Based on the component jdk /usr/local/jdk-1.X root
supservisor /etc/supervisor.d/{app_name}.conf root
The business component Application package /data/java_app/{app_name}/xxx.war app
Runtime log /data/java_app/{app_name}/logs app
Runtime data /data/java_app/{app_name}/data app
Python Based on the component conda /usr/local/conda app
supservisor /etc/supervisor.d/{app_name}.conf root
The business component application /data/python_app/{app_name} app
Runtime log /data/python_app/{app_name}/logs app
Runtime data /data/pyhton_app/{app_name}/data app

According to the above table, to deliver a server, we first need to understand the following points:

  • Development technology stack
  • Common components
  • Based on the component
  • The business component

Once these component relationships are understood, the location of directories is self-evident.

conclusion

By introducing technology stack and functional components, we can logically regroup and classify the previously mixed systems, which not only helps us to carry out better operation and maintenance management, but also lays a solid foundation for future automation.