简述
作为运维团队的一员，当你登录服务器第一时间是否有以下行为：
- 确定应用的启动目录、数据目录、日志目录、启动用户；
- 确定应用如何启动及是否有开机自启动或守护进程；
- 确定服务器的日常脚本目录、软件源码目录、公共目录等；
如果你存在以上行为，那说明你们的团队需要做目录管理规范了。这是为什么呢？首先明确的是我们无论做什么规范，目的都是避免差异性；其次团队中每个人的习惯不同，没有规范必将导致服务器配置差异五花八门，无形中增加了运维的难度；最后目录的规范统一可以给后续的自动化打下坚实的基础。
举个简单的例子：
有了统一的备份目录，我们只需运行一个简单的一条命令就可以实现数据的远程备份，而不用为适配各种备份目录而烦恼。
因此，目录管理常常被大家所忽略，但是做好目录管理可以让我们受益匪浅！！
思路
既然目录管理如此重要，我们应该从哪方面作为切入点呢？
下面就来谈谈我们一些看法吧。
对于目录来说，最终承载的是各种技术栈、功能组件，因此它们就成了我们目录规范的需求依据。
我们就来把这些需求来分下类。
1.开发技术栈
- Java
- Php
- Python
- 等等
2.功能组件
- 公共组件
可以理解为公共资源，如安装软件、脚本、备份等 - 基础组件
可以理解为技术栈依赖的基础工具，如jdk、tomcat等 - 业务组件
可以理解为应用相关，如应用软件包、应用日志等
通过以上两个分类，可以看出他们的包含关系为：
开发技术栈 > 功能组件 > 目录
实现
理清了技术栈、功能组件与目录的关系后，我们就可以本着“一目了然、一句到位、一清二楚的”规范风格，直接以图表的形式进行展示，而不拘泥于文字。
| 技术栈 | 功能组件 | 名称 | 目录 | 属主 | 备注 |
|---|---|---|---|---|---|
| X | 公共组件 | ||||
| 脚本 | /data/logs | app | 统一脚本目录 | ||
| 备份 | /data/backup | root | 统一备份目录 | ||
| 应用软件 | /usr/local | app | 统一软件目录 | ||
| 源码安装包 | /usr/local/src | root | 统一源码存放目录 | ||
| Java | 基础组件 | jdk | /usr/local/jdk-1.X | root | |
| supservisor | /etc/supervisor.d/{app_name}.conf | root | |||
| 业务组件 | 应用包 | /data/java_app/{app_name}/xxx.war | app | ||
| 运行时日志 | /data/java_app/{app_name}/logs | app | |||
| 运行时数据 | /data/java_app/{app_name}/data | app | |||
| Python | 基础组件 | conda | /usr/local/conda | app | |
| supservisor | /etc/supervisor.d/{app_name}.conf | root | |||
| 业务组件 | 应用 | /data/python_app/{app_name} | app | ||
| 运行时日志 | /data/python_app/{app_name}/logs | app | |||
| 运行时数据 | /data/pyhton_app/{app_name}/data | app |
通过以上表格得出，对于交付一台服务器，我们首先要搞明白以下几点：
- 开发技术栈
- 公共组件
- 基础组件
- 业务组件
只要把这些组件关系弄清了，那么如何安放目录也就不言而喻了。
总结
我们通过引入技术栈和功能组件的方式，在逻辑层面将原来揉杂在一起的系统重新分组、分类编排，这不仅有助于我们更好的进行运维管理，更重要的是为以后的自动化打下了坚实的基础。。。。。