每一次故障排查都是一笔财富，各种狗血经过不表，解决问题之后的那种满足是不可替代的。
发布系统架构图简化如下：
发布架构图
管理员通过Jenkins调用“发布程序(代号varian，以下简称varian)”，发布程序会进行一系列的初始化操作，完成后生成Docker镜像上传到Docker仓库，容器集群更新镜像，用户通过负载均衡访问我们的容器集群。
老的varian采用shell+python开发，配合Jenkins(jdk1.7)进行发布，因内部项目较多，写了很多兼容脚本，代码比较乱。
我们计划对varian进行重构，完全采用python开发，各个功能模块化，不同类型的项目用乐高的思想拼装模块部署发布，降低耦合。
并将jenkins升级到最新版本，jdk同样升级到1.8。新的varian已经开发完成，现在开始部署测试了，故事就由此开始。
为了降低对现有项目的影响决定重新部署一套新的环境，完全测试通过后将老环境废弃，直接启用新环境，新环境信息如下：
通过 Jenkins 调用varian正常部署了一个静态项目（纯html，css，js等静态资源），通过负载均衡访问容器集群（参考上边架构图），发现页面样式无法加载，浏览器按F12调出控制台发现个CSS文件返回403状态：
chrome F12调试
web服务用的nginx，脑海里迅速过了一遍什么情况下nginx会返回403：
nginx配置了白名单，client端访问的IP不在白名单内
访问的路径是个目录，而nginx配置了禁止列目录
访问的路径是个文件，但nginx服务配置的用户和用户组对文件没有读取权限
目录索引index 配置错误，例如你的目录下只有index.html，你却配置了index.shmtl或index.php等等
index index.shtml index.php;常见的有以上问题会导致nginx返回403，迅速排查了一下，发现就是权限的问题导致的，nginx配置的用户和用户组为www-data，而css文件的属主属组都是root，且其他用户没有任何权限：
这里再详细讲解下linux下的文件权限，以上边的csl.css文件为例：
-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css以空格分割
-代表这是一个文件，还会看到像d代表目录、l代表连接经过反复测试，发现我直接在linux下通过控制台执行python脚本的方式发布部署最终文件权限正常，但是同样的脚本经过Jenkins执行后权限就不对了。
控制台执行跟Jenkins执行有什么区别？账号不一样啊，遂把jenkins项目、tomcat文件都改成属主属组都为root重新执行，发现还是一样的结果。
再想想还有哪里不对，这个css文件是程序生成的，生成的文件权限不对，umask！这个词突然蹦出来，对，应该就是umask，他控制了生成新文件的权限。
简单介绍下什么是umask：
umask值用来设置用户在创建文件时的默认权限，跟设置文件权限命令chmod是相对的，总共四位，不过我们通常只用后三位，同样对应属主属组以及其他用户的权限，例如你的账号umask值为0022（可直接通过umask命令查看）。
此时你创建的文件权限默认为644（文件初始的最高权限为666，umask设置为022，那么最终的权限为：6-0,6-2,6-2=644。
当然有人说文件的权限最高是777，是的没错，但我们说的是默认权限，默认权限是由umask决定的，umask设置为000时文件的权限就是666，文件夹权限777），此时创建的目录权限为755（目录的最高权限为777，umask设置为022，那么最终的权限为7-0,7-2,7-2=755）。
查了root用户的umask、jenkins用户的umask，都为0022，没问题呀，并且登录这两个账号创建了新文件权限也都正常，就剩下一种情况了Jenkins！
Jenkins没有地方可以给配置UMASK，Jenkins跑在tomcat容器里，老版本的varian也有相似的处理逻辑一直没问题，本次升级了tomcat8，难道tomcat8更新了UMASK？半信半疑的看了下，果然！tomcat8的umask默认改成了0027，麻溜的改成了0022，问题顺利解决！
说明：本文转载自“运维咖啡吧”公众号，点击查看原文。
2021年5月14-15，GOPS 2021 · 深圳站，早鸟票限时开启~
关注微信