正儿八经

度量DevOps四个关键指标

发表于 2021-03-01 更新于 2021-03-30 分类于工作

交代

最近看了篇Google出的关于DevOps的文章《度量DevOps四个关键指标》，在这儿做个记录。google翻译+蹩脚的自我理解，莫吐槽，将就看。

开始

通过六年的研究，DevOps研究与评估（DORA）团队确定了四个关键指标，这些指标指示了软件开发团队的绩效：

部署频率 - 成功发布产品的频率。
变更前置时间 - 变更从提交到发布所需要的时间
变更失败率 - 发布失败次数在部署中的占比
恢复服务的时间 - 从生产故障中恢复需要多长时间

变更的部署频率和变更前置时间可以衡量速度，变更失败率和恢复服务的时间可以衡量稳定性。通过衡量这些价值，并不断进行迭代来改进它们，团队可以取得更好的业务成果。

然后说了一下google cloud的做法。后面跟google cloud提供的服务有关的就不翻译文字了。

指标计算

本节讨论如何将DORA度量标准转换为系统级计算。DORA团队所做的原始研究是对真实的人进行调查，而不是收集系统数据并将指标存储到性能级别中，如下所示：

部署频率

1	一个组织成功地部署到生产环境的百分比。

部署频率是最容易收集的指标，因为它只需要一个表。但是，频率存储也是要计算的棘手元素之一。显示每日部署数量或每周获取平均部署数量将很简单明了，但指标是部署频率，而不是数量。

在“Four Keys”脚本中，当每周至少进行一次成功部署的中位数天数等于或大于三时，“部署频率”将落入“每日”时段。简而言之，要想部署频率值为“每日一次”，则必须在大多数工作日进行部署。同样，如果大多数部署都是一星期一次，则将是每周一次，然后是每月一次，依此类推。

接下来，则需要考虑是基于哪些原因及资源构成了成功的生产部署。您是否包括仅占5％流量的部署？80％？默认情况下，仪表板包括任何成功部署到任何级别的流量。

变更前置时间

1	一次提交进入生产环境所花费的时间。

“变更前置时间”度量标准需要两个重要的数据：何时发生提交和何时进行部署。这意味着对于每个部署，需要维护对应的更改的列表。使用部署表中的更改列表，每次数据的重新加入时同时获取相应的时间戳，用于计算中位数。

变更失败率

1	用于生产环境部署失败的百分比

变更失败率取决于两件事：尝试了多少次部署，多少次导致生产部署失败？

恢复服务的时间

“组织从生产故障中恢复需要多长时间”

要测量恢复服务的时间，您需要知道事件的创建时间和解决时间。还需要知道何时发生故障以及何时部署解决了该故障。与上一个指标类似，此数据可以来自任何故障管理系统。

仪表板

这个就不多说了。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

数字化

发表于 2021-02-05 更新于 2021-02-19 分类于杂记

看到DXCon一篇文章，做个记录

怎么理解数字化转型？

优化是通过把你的服务线上化，减少摩擦，提供更好的服务体验。

那数字化转型真正转的应该是什么？

数字化转型，最终转的是客户价值的创造。

通过数字化智能化的方式，使原来没有办法传递的价值，现在可以传递出去。最终的目的是创造一种模式，不管是商业模式，还是运营模式，使得能够颠覆原来没办法做到的事情，或者是原来很难做到的事情。通过数字化来达成原来不可能达成的价值创造的一种方式，最终的核心应该是要创造价值。

通过数字化来达成原来不可能达成的价值创造的一种方式，就是数字化最终的目的应该是要创造价值。

最后来句废话

我从参加工作开始几乎都是在ToB行业，刚好有两家公司就是干数字化转型的，我一开始的理解不过是从纸质媒介转到网络媒介，从线下到线上，实操经验告诉我，最终看的还是为用户创造了哪些价值，实用为主的客户你跟他扯概念鸟用没有。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

pnpm

发表于 2021-01-13 更新于 2021-02-07 分类于工作

背景

因为最近遇到一个包多版本依赖的问题，遂研究研究npm包管理…

结果发现了这个宝藏**pnpm**

https://zhuanlan.zhihu.com/p/137535779

PNPM

pnpm使用内容可寻址文件系统将磁盘上所有模块目录中的所有文件存储在磁盘上。

使用pnpm，lodash将存储在可寻址内容的存储中，因此：

如果您依赖lodash的不同版本，则仅将不同的文件添加到存储中。如果lodash有100个文件，而新版本仅对其中一个文件进行了更改，则pnpm update将仅向存储添加1个新文件。

所有文件都保存在磁盘上的单个位置。安装软件包时，它们的文件从该单个位置链接，不占用额外的磁盘空间。使用硬链接或ref链接（写时复制）执行链接。

结果，您在磁盘上节省了数GB的空间，并且安装速度大大提高了！如果您想了解有关pnpm创建的唯一node_modules结构以及为什么它可以在Node.js生态系统中正常工作的更多详细信息，请阅读这篇小文章：平坦的node_modules不是唯一的方法。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

PO和研发免干架沟通指南(1)

发表于 2020-12-29 更新于 2021-02-08 分类于工作

新产品线跑了一段时间了，这两天团队复盘了一哈，其中谈到了产品和研发沟通问题。

简单记录一下

梳理了这么一个公式

我做了xx设计(实现)

1.xx
2.xx
3.xx
能达到xx效果

1.xx
2.xx
3.xx

point来了，我分割一下
它的限制是什么

1.xx
2.xx
3.xx

导致达不到xx效果
1.xx
2.xx

切记

所以说做东西别上来先傲娇吧啦吧啦说一通，报喜不报忧，后面只会任由PO摩擦。

问题解法咋聊(1)

发表于 2020-12-19 更新于 2021-01-06 分类于工作

背景

因为团队内部经常会有问题复盘以及技术故事讨论等活动，怎么让这个讨论是有营养且找到根因，保证最终能落到具体的行动项上面。我觉得这是一门很大的学问。

不信你留心观察你参加相关会议或者讨论，你会发现弄了半天问题好像解了又好像没解，过程可能还会伴有撕逼和甩锅…，有句古语说得好：我在旁边坐，锅从天上来。

那咋聊呢

Point 1 描述问题

描述问题，切忌采用下结论的思维和话语，比如：我认为、我觉得…。

我们是为了解问题的，所以你只需要言简意赅的把问题说清楚，这个时候你是一个莫得感情的机器。

怎么言简意赅呢?

站在第三视角陈述：只说现象不说结论，时间、环境、人物、操作过程、发生的现象、造成什么影响…。

如果有必要还可以进行一个动作：过程还原

直接叙述工作过程，有问题的环节或阶段，什么人，做了什么事，当时是怎么考虑的，在这个动作后结果是什么。

Point 2 根因分析

描述之后这个时候可以说说自己的看法了：描述最终定位到的直接原因是什么

有个模板可参考

1.技术根因分析

引入环节：

产品设计是否有问题？

需求分析是否有问题？

设计环节是否有问题？

代码编写是否有问题？

其他？
流出环节：

各评审环节是否有遗漏？

是否进行研发自测？

测试场景、测试用例是否覆盖全？

是否进行了系统测试？

其他？
确定关键根因是什么：

如果有多个根因在逻辑层次上相同，则取关键的原因，根因应该是具体的、客观的、在目前组织能力下可被改进的。

2.管理根因分析

流程/制度原因：
组织因素：
执行原因：

【帮助】流程/制度方面：考虑组织管理上是否有合适的流程、指导书、管理Checklist；

组织因素方面：考虑人员分配、个人技能、培训、组织环境等原因；

执行方面：考虑计划、监控、沟通方面的原因。

这个活动一定要有被随便蹂躏的那种奔放和豁达！！！

Point 3 纠正、预防措施

分析完了之后，一定要有落地的行动项。

根本原因	措施类型	措施内容	责任人	预定完成日期
技术根因：例如，XX特性，在大规格、灵活配置等方面需求设计不充分	纠正措施	例如：对XX特性组织进行重新设计，刷新XX方案	Jack Ma	2020/11/1
	预防措施	例如：更新××技术规范、工具、checklist等等	Pony Ma	2020/11/1

敏捷

发表于 2020-12-17 更新于 2022-08-17 分类于工作

背景

前前后后经历了几个公司敏捷的做法，有些些感悟，在此表一表。

开始

首先咱们说一下为啥需要敏捷，因为敏捷的业务目标是更早的交付价值以及更灵活的应对变化。我认为这是之所以那么多公司或者团队想要实践敏捷的最大原因之一。

让我知道敏捷的公司，那是在14年我进了一家主打3D数字建模的公司，我的直接领导是公司敏捷的推崇者，当时两个研发团队也是按照敏捷走的，但是敏捷到底是个啥？当时老大给了我一本书让我自己去悟。书名好像是《Scrum敏捷软件开发》。之后大体有了个了解，至少对站会、用户故事、backlog、sprint、SM、PO等词有个概念。

那时候觉得挺新鲜因为在此之前我只知道瀑布模式。在这家公司时我对敏捷印象是最深的，因为我经历了新旧之间的碰撞，不仅是思想上的还有实操上的。因为公司还有个管评审的年长型主管A大，他刚好更偏向于瀑布模式。

正文

chapter 1 ：

先交代一些往事，当时的我，迷茫的一逼，感觉写代码不适合我，我想要转产品，当然我说的产品不是UE性质那种产品哈，我说的是正儿八经的那种产品经理，“那种”指的是：从0到1打造适合用户且用户要买单的那种产品的产品经理。

刚好我的leader就有个类似经历的人，他曾经因为在上海的一个研究所交付的产品令客户不满意，他去呆了3个月，硬生生从0到1重新根据需求设计产品，最终成功交付，当时研究所的人对他的评价是，他比我更懂我得工作。不然为啥他被现在的公司拉去当了副总？你品一品他当时只是一个研发岗。

我虽然面试的是开发岗，刚好当时负责面试的人有事出去了，他刚好遇到了就说先跟他聊一聊，当我告诉他有意向走产品的时候，由于聊的很好，他果断把我留下来当他的助手了。所以我入职是没有经过技术面试的…。

入职的title是产品助理，前期主要干的事就是看书，用Latex写公司宣传文档和摸鱼，后期就让我跟项目，主要是做项目需求。

由于我们的客户多是各种工厂所以通常位置都比较偏僻，想去泡个脚都要摩托转公交再转出租的节奏。

犹记得当时把我一个人丢到工厂的时候，那种无助…工厂里的人通常都比较务实比较直接。被怼的体无完肤到和颜悦色，中间也就是几顿酒的事….故事太多以后写小说再用。

说这些是怎么个意思呢？其实没啥意思，就是说说一些背景，任何事物都是有联系的，你再细品。

chapter 2：

接上，在工厂第一次差不多进一个月，工作内容就是梳理各个环节各个干系人的需求，并整理成文档。

感觉终于告一段落之后，速度赶回北京。然后就是评审，这个时候问题就来了，我老大觉得现有的需求可以开始准备进入研发了，遇到需求问题再澄清就行，但是评审主管就不干了，说你这需求文档需要细化的地方还有挺多，不能进入研发，所以评审没过。会后两位大佬分别拉我谈了一次，一个觉得需求不够完整（瀑布），一个觉得需求已经够了（敏捷）。那为什么双方没有达成一致呢，在我看来当时我老大推崇的敏捷没有玩好，比如A提的一点，研发是敏捷了节奏都挺快，交付周期也缩短了，但是交付结果不太好，老有返工，导致一个项目迟迟不能最终验收，这就是A不赞同的根本原因，因为连客户想要什么都没有完全搞清楚。

对应到敏捷里的内容就是，在检视和调整两块没有足够重视。也就是下面的几个会议没有开好：

Sprint 计划会议
每日 Scrum 站会
Sprint 评审会议
Sprint 回顾会议

我理解以上四个会议就是每个迭代里防止走偏的措施，但最后还是走偏了。

chapter 3：

现公司一进来就是敏捷，但是大多数时间也是走的不顺，有段时间还专门找了教练带着跑了几个月，效果也是一般般。

当时我想了想可能原因有下面几方面：

公司是家传统意义上的软件公司，前面都是瀑布模式，虽然是新产品线但是也有很多老员工，所以不管从公司还是从人来说，这个转变是需要时间且需要强有力的刺激，很明显是时间给够了但是刺激不够。我们都知道有刺激才会有反应。
大家对敏捷的理解参差不齐，很多朋友是随波逐流，且最致命的是这类朋友基本上都认为自己是懂敏捷的，但是真的懂吗，大概率不是的或者只停留在字面上的理解（我其实也是一知半解）。

敏捷应用其实在我看来是一系列的动作的组合，该套组合需是不断优化且需要组织严格遵守的，组合好之后，把该组合套在软件的开发周期里，然后一遍一遍的重复重复再重复。

另外很多人的误解是，敏捷就不用写任何文档了，在我看来不是的，必要的文档还是需要的比如设计文档。

前段时间公司大佬给够了刺激，比如重新梳理组织架构、丰富了工具、完善了开发/评审流程（必要的设计文档等）、强制执行双周迭代、双周演示会等等，我的感受是团队的流转效率是有提高的。

小结

我理解的敏捷其实是门大学问，不是只有简单的一些关键词，比如还有“以赋能和信任个人为中心的文化”这类的理念内容，持续学习中。

所以其实我没啥发言权，不过随便说说，也没谁管得着，反正是我自己的博客….。

从我的经历来看，敏捷是个好东西，但是落地也确实不容易，除了敏捷本身就代表一种变革（动作大）以外，它本身也涉及到很多关于人的因素，比如人的思维、习惯、团队文化等，但是如果因为对敏捷应用的不成功，就觉得敏捷不好用，并怀疑它的价值，不可取哈。

另外敏捷只是解决问题的一种方式，也不要把它捧得太高。

任何方法或者工具都有它所适用的上下文。

我认为敏捷是解决问题的一种方式，技术越来越多成为变现的一种手段。那当然你会问谁先行呢？思维观念要变，同时也需要给搭配上不同的手段，谁先谁后并不是主要矛盾。— DXcon

敏捷的价值观

摘自<说透敏捷>

个体和交互胜过过程和工具。
可以工作的软件胜过面面俱到的文档。
客户合作胜过合同谈判。
响应变化胜过遵循计划。
虽然右项有价值，但我们更重视左项。

一个公司或者团队要应用敏捷，不代表要全套接收，有可能只需要敏捷里的某块就可以，不信谣不传谣。

真正的敏捷应该是Be Agile而不是Do Agile。在我们强调/争执xx方法论，xx实践的时候，我们往往在做敏捷，而不是真正的敏捷了。

多说一句

团队，除了学会传统”规划、组织、领导、控制 “的管理方式之外，还需要”激励、授权、支持、交流 “，这实际上意味着，领导者(特别是CEO)把资源分配采取分布式，而不是集中制(集中在自己手里)。这对团队/组织/公司，在应对复杂、即时、阶层式问题时的灵活度、适应度增加很多。

coolshell软件公司的两种管理方式

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

AHA

发表于 2020-12-01 更新于 2021-01-07 分类于编程

[Collin Armstrong](https://unsplash.com/@brazofuerte)

背景

干研发的有个高频词语：抽象，这个词语可应用于各种场景，我今天聊的是代码抽象，在此篇就比较low逼的理解成代码复用吧，不然感觉有点虚。

为啥记录这个呢还是源于近段时间遇到的一些矛盾，重复代码该不该都抽出来，在这之前我会毫不犹豫的说应该，包括现在团队里也几乎是这样的声音，但是是不是就一定对呢？现在我觉得这个观点是不对的，因为我发现有些代码抽出来之后反倒变得越来越不可掌控。

所以我在思考克制抽象是不是也应该提出来。为了验证这个思考，遂搜了搜，别说还真有那么些大佬早就提出了这个观点。

AHA

AHA (读作”Aha!” ):Avoid Hasty Abstractions（避免草率的抽象）

读了几篇文章特别感动，尤其是Sandi Metz的 The Wrong Abstraction，特别有共鸣。

核心观点就是

宁愿复制而不是错误的抽象

具体的支撑克制抽象内容，这几篇文章说的很清楚了，我就不再来一遍了。

我就给个现实的例子

/**
 * 获取某个CI模型数据 v1.0
 * @param {object} code 模型code
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code) => {
  const meta = await request.post('/api/v1/model/ci/getCi', { code });
  // 绑定数据字典
  meta.attributes = meta.attributes.map((item) => {
    const attr = { ...item };
    if (attr.changeValue === 'dict') {
      if (!DICT.get(attr.code)) {
        rlog.error(`找不到 ${attr.code} 对应的数据字典`);
      } else {
        attr.dict = DICT.get(attr.code).items;
      }
    }
    return attr;
  });
  return meta;
};

/**
 * 获取某个CI模型数据  v2.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true) => {
  const meta = await request.post('/api/v1/model/ci/getCi', { code });
  // 获取过滤userVisible=true的属性(用户可见)
  const { attributes } = meta;
  const visibleAttributes = userVisibleFilter
    ? attributes.filter((item) => item.userVisible)
    : attributes;
  // 属性绑定数据字典
  meta.attributes = visibleAttributes.map((item) => {
    const attr = { ...item };
    if (attr.changeValue === 'dict') {
      if (!DICT.get(attr.code)) {
        console.error(`找不到 ${attr.code} 对应的数据字典`);
      } else {
        attr.dict = DICT.get(attr.code).items;
      }
    }
    return attr;
  });
  return meta;
};


/**
 *
 * 获取某个CI模型数据 
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 * @returns {object} 格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const { meta, visibleAttributes } = await formatMeta(code, userVisibleFilter);

  if (!dict) {
    meta.attributes = visibleAttributes;
    return meta;
  }

  // 属性绑定数据字典
  return bindDict(meta, visibleAttributes);
};

/**
 *
 * 获取某个CI模型数据  v3.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 * @returns {object}  格式化之后的模型对象
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const meta = await formatVisibleAttributes(code, userVisibleFilter);
  if (!dict) {
    // 属性绑定数据字典
    return bindDict(meta);
  }
  return meta;
};

/**
 *
 * 获取某个CI模型数据  v4.0
 * @param {object} code 模型code
 * @param {boolean} userVisibleFilter 是否按照模型的userVisible过滤，发现页面不过滤
 * @param {boolean} dict 是否需要绑定数据字典
 */
export const getCi = async (code, userVisibleFilter = true, dict = true) => {
  const meta = await formatVisibleAttributes(code, userVisibleFilter);
  // 属性绑定数据字典
  if (dict) {
    try {
      // 用户自建属性（数据字典）
      const userDict = await getUserDicts(code);
      return bindDict(meta, userDict);
    } catch (error) {
      rlog.error(error);
      return meta;
    }
  }
  return meta;
};

/**
 * 过滤可见属性
 * @param {string} code
 * @param {boolean} userVisibleFilter
 * @returns {object}  只包含可见属性的模型对象
 */
async function formatVisibleAttributes(code, userVisibleFilter) {
  const meta = await request.post('/api/v1/model/getCi', { code });
  if (meta) {
    let { attributes } = meta;
    if (!attributes) {
      return meta;
    }
    // 适配后端，使属性正序
    attributes = attributes.reverse();
    // 获取过滤userVisible=true的属性(用户可见)
    if (userVisibleFilter) {
      meta.attributes = attributes.filter(
        (item) => item.userVisible === 'true'
      );
    }
    return meta;
  }
  return meta;
}

如上所示

总共经历了至少4次的改动，逻辑变得越来越复杂，因为需要适配多种场景，本来我一开始抽出来，理由很简单，因为该api是一个获取底层数据的api，大多数前端的功能都需要调用该api，且都是需要有数据字典的，因为要正确的展示数据，所以我抽了一个方法。

这个时候还是很美好的，不过后续就像 The Wrong Abstraction里写的一样，各个使用方或找我或自己对该方法进行了扩展，这方法那是叫惨不忍睹啊，就这还是我重构之后的样子，没重构之前更丑。

那有人就问了，为什么就扩展了呢？

个人风格问题，该方法之前满足我得需求现在不满足了，所以我要改它，这样最简单，我可不管其它模块需不需要这个逻辑。

我也知道可能在上面加不太合适，因为加的扩展逻辑不是所有模块都需要的，但是也不是我一个人需要的，比如A、B、C、D…，A、B都需要，那为了不重复写代码，在原有方法上扩展我觉得也还行。

…

后来当我发现的时候，我就在群里发出了一个共识。

这类公共的api原则上不加个性化的扩展但是可加通用性（不影响整体数据结构且没有业务逻辑，比如：对原始数据进行数据筛选（eg:可见、不可见））的扩展，且加的时候需要与该api的最初作者对齐。

如果要扩展个性化，请自行copy一份代码再修改。

我的理由是如果再这么搞那我就不维护了爱咋咋滴………………..当然前面是意淫的咱们是一个team，和为贵。

真正的理由是维护成本会越来越高且与当初抽象的意义渐行渐远。

可能我给的例子不够有足够力量的说服力，但是我还是觉得，抽象不一定就一定时好的必须的，有些时候我们得反过来想想，任何事情都有两面性。虽然咱没有能力提出牛逼得理论和观点，但是我们可以基于大佬们提出得理论和观点，做些反思、验证…。

有句话不是说吗：站在巨人的肩膀上。这句话我理解不是说巨人的肩膀才稳，而是说能看得更远。

You Know

Duplication is far cheaper than the wrong abstraction

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

ESLint(no-prototype-builtins)

发表于 2020-11-24 分类于前端

// eslint-disable-next-line no-prototype-builtins

if (!a.hasOwnProperty(key) || !b.hasOwnProperty(key)) return 0;

no-prototype-builtins - Rules - ESLint - Pluggable JavaScript linter

Rule Details

This rule disallows calling some Object.prototype methods directly on object instances.

Examples of incorrect code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = foo.hasOwnProperty("bar");

var isPrototypeOfBar = foo.isPrototypeOf(bar);

var barIsEnumerable = foo.propertyIsEnumerable("bar");

Examples of correct code for this rule:

/*eslint no-prototype-builtins: "error"*/

var hasBarProperty = Object.prototype.hasOwnProperty.call(foo, "bar");

var isPrototypeOfBar = Object.prototype.isPrototypeOf.call(foo, bar);

var barIsEnumerable = {}.propertyIsEnumerable.call(foo, "bar");

nginx-docker

发表于 2020-11-21 分类于 docker

背景

由于事业部专门成立团队做部署平台，由于各种因素迟迟没有上线，以前的Jenkins也不能用了，但是前后端需要有环境进行联调，后端还好说每个模块本地起个服务就行，前端就尴尬了本地起服务限制太多，所以需要想办法搞个环境，遂想着悄悄咪咪（深藏功与名…）搞了个环境让大家能先跑起来不至于耽误工期。

满足以下要求：

前端更新简单
无脑一条命令搞定start\stop\restart
于生成环境尽量贴合

实操

因为生成环境是基于docker做部署，所以先弄个nginx的镜像。nginx的镜像茫茫多，不过大体都很全面，我觉得太重，所以就弄了个最简单的。

docker-compose.yml

version: '3.1'
web:
  my-nginx:
    container_name: new-monitor-nginx
    image: nginx
    restart: always
    logging:
      driver: "journald"
    volumes:
      - /home/xxx/mount/nginx.conf:/etc/nginx/nginx.conf
      - /home/xxx/mount/html:/etc/nginx/html
 
    ports:
     - "443:443"
    network_mode: "bridge"
    environment:
      - TZ=Asia/Shanghai
    ulimits:
      core: 0

Dockerfile

# 用官方的nginx镜像
FROM nginx
# ENTRYPOINT 类似于 CMD 指令，但其不会被 docker run 的命令行参数指定的指令所覆盖，用于传参。
# eg:docker run  nginx:one -c /etc/nginx/new.conf,容器内会运行nginx -c /etc/nginx/new.conf
ENTRYPOINT ["nginx", "-c"] 

#COPY 复制，从上下文目录中复制文件或者目录到容器里指定路径。
COPY nginx.conf /etc/nginx/nginx.conf
COPY html /etc/nginx/html

# RUN，在 docker build时作用
RUN rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf

# EXPOSE 声明端口，镜像服务的守护端口，以方便配置映射。
EXPOSE 8088


# VOLUME 用于挂载数据卷
VOLUME /var/log/nginx/log

#CMD 类似于 RUN 指令，在docker run 时运行。
CMD ["nginx", "-g", "daemon off;"]

构建、启动容器

docker build -t xxx
docker-compose down
sleep 10
docker-compose up -d

后续直接

1	docker restart 容器名

后续

其实最终我又把docker干掉了….因为有同事悄悄咪咪手动装了nginx，优化了一下把nginx挂到了系统服务上，同样的也是直接systemctl xxx就行了。

反正结果是好的，结合alibaba toolkit也是玩的飞快了。

干研发的不就得折腾吗，对吧。