Ansible 是一个自动化部署脚本，通过它可以让很多的 server 执行一系列相同的任务，是大规模集群管理的利器。虽然已经用了好久了，但是之前都没有记录一些使用的技巧。最近终于还是好好的记录了一些，免得自己以后忘得干干净净。
我们创建一个新的机器第一次登陆的时候会显示如下的东西：
$ ssh root@xxx
The authenticity of host 'xxxx (xxxxx)' can't be established.
ECDSA key fingerprint is SHA256:xxxx.
Are you sure you want to continue connecting (yes/no)? 如果管理的机器很多，每次都要去确认一下肯定是要了命了。为了避免这种 popup 的问题有如下两种方式：
设置环境变量 ANSIBLE_HOST_KEY_CHECKING=False
在 ~/.ansible.cfg 或者 playbook 同目录下的配置文件增加
[defaults]
host_key_checking = FalseHow to ignore ansible SSH authenticity checking? - Stack Overflow
ansible-playbook -v \
-i inventory \
-u ubuntu --become \
--private-key=~/.ssh/k8s.pem \
nvidia-docker.ymlansible-playbook ... -vvvv ...Ansible 里面有一个很重要的概念叫做 role：一个 role 完成一个特定的任务，比如安装 docker、比如安装 nginx，之所以这么拆分当然是为了更好的重用：有些 role 是很多机器都需要的，细粒度的 role 就可以很好的组合在一起使用。比如在安装 kubernetes 集群时所有的机器都需要事先安装 docker，给所有的机器都添加 docker 的 role 即可。
ansible 有一个 galaxy 有点像是 ansible 版的 github，它一方面提供了 role 的统一格式，另一方面提供了一个放置通用 role 的平台，方便大家去那里直接下载自己所需要的 role。
ansible-galaxy 提供了命令用来创建一个官方的 role 项目：
ansible-galaxy init [your role name]前文提到 role 可以被复用。那么这里就是其复用的方法了。首先准备一个 roles.yml 文件：
---
- src: https://github.com/xxx.git
- src: https://github.com/xxx.git其中每一项是需要使用的 role 的 git 地址。
然后执行以下命令就可以将指定的 roles 下载到 roles 文件夹下使用了。
ansible-galaxy install -r roles.yml -p roles --force一些重要的变量是不能保存在 ansible role 脚本里面的，需要在运行的时候传入。这种场景下 --extra-vars 参数就登场了。
ansible-playbook --extra-vars="@extravars.json" ...其中 extravars.json 是一个 json 文件，通过 @ 符号就可以传入。
有的时候发现原有的 ansible playbook 有瑕疵需要重新更改参数什么的，这个时候如果更新了 ansible playbook 再重新跑一遍实在不方便。这个时候就需要这种 ad-hoc command。
ansible cpu-worker -i inventory -m copy -a 'src=/etc/hosts dest=/tmp/hosts' -u ubuntu --private-key=xxx如上所示，和 ansible-playbook 一致 -i 后面是 inventory，-u 后面是 username，然后具体使用的 module 在 -m 后面提供，额外的参数用 -a 后面提供。
好久没有写博客，久到在刚想到写一篇博客的时候要打开哪个编辑器都楞了一下。今天介绍一下两个小工具 husky（对，哈士奇，2哈）和 prettier。我认为他们的出现减轻了软件开发流程中一些痛点。
在之前的工作中，我们尝试通过在 git 的 pre-receive 阶段嵌入一系列的 ci 流程处理代码以提供给开发者们 "just push" 的开发流程（当然这个想法是完完全全源自 heroku 的）。这个流程将原先的 "push -> wait for verify -> new correct commit -> repush" 的流程转变为 "push -> fail -> correct -> repush"：如果没有在 "pre-receive" 阶段设置门禁的话，坏的提交会被同步到中心仓库后在进行检测；而设置门禁之后坏的 commit 会被拒绝在本地，本地只能将 ci 可以通过的代码提交到中心仓库。但是将所有东西都通过 push 验证很显然是慢了一些：这就像表单的前端验证和后端验证一样，虽然后端验证永远必不可少但是它增加了服务器的负担并且延长了反馈周期。
这时候 husky 就要派上用场了。husky 其实就是一个为 git 客户端增加 hook 的工具。将其安装到所在仓库的过程中它会自动在 .git/ 目录下增加相应的钩子实现在 pre-commit 阶段就执行一系列流程保证每一个 commit 的正确性。部分在 cd commit stage 执行的命令可以挪动到本地执行，比如 lint 检查、比如单元测试。当然，pre-commit 阶段执行的命令当然要保证其速度不要太慢，每次 commit 都等很久也不是什么好的体验。
多少年来开发者在使用 tab 还是 space 的问题上真是花费了不少的时间，美剧硅谷里主角还因为 tab 和别人闹了一集，可见大家对代码格式化的重视程度-_-。记得我在上一个项目里看到有小哥把我的代码强行刷成他满意的格式的 commit 也非常不满。仅仅修改格式的 commit 是毫无必要的，它没有对软件本身的行为做任何的修改，而夹带了修改格式的 commit 更是令人抓狂的，给 review 的同学也带来了不小的负担（在一坨提交里仔仔细细看了半天发现神马也没变！！尼玛！！）。
golang 取了个巧，语言自带官方格式，你们终于不吵了吧。虽然会有时候看 golang 的格式化结果略微有点麻烦（就是 struct 对 json type 的制表符对齐的要求），但是也没有哪里是让人无法忍受的丑。如果其他的语言也以类似的方式制定一个官方格式是不是就会将此事平息下去呢。当然，我们可以在制定这个官方格式的时候吵架，只要官方格式不会三天两头的更新那在实际项目中为这种不必要的分歧导致浪费大把时间了。
在我看来 prettier 就是这么一个 "类官方格式" 了。不过目前它还只是支持 js 体系下的格式化，其他语言由于这样那样的问题还要再等等。
大家对有个公认的格式这件事还是非常认可的，项目出现一年，Github star 破 2.1w，并且像 facebook 这样的大公司已经在内部逐渐铺开使用了。
最后，通过 husky 为 prettier 在 pre-commit 加个钩子，这体验就更完美了：不论你家的格式是什么样子，只要你想提交，就必须格式化成 prettier 要求的样子，这样就没有那种因为格式变动出现的无聊的 diff 了。集成的流程基本是以下这个样子：
添加 prettier 依赖
yarn add prettier --dev --exact测试格式化是否工作
yarn prettier -- --write src/index.js在 commit 时执行 prettier
yarn add pretty-quick husky --dev修改 package.json 添加 pre-commit 钩子
{
"scripts": {
"precommit": "pretty-quick --staged"
}
}其实官方文档也有，但是官方文档可耻的写错了...第二步命令少了 -- 的命令。
最后的最后，放一段 prettier 格式化的 react 代码，我还是对其默认的格式非常满意的。
class Badges extends React.Component {
componentDidMount() {
let { user, loadBadges } = this.props;
loadBadges(user.username);
}
render() {
let { badges } = this.props;
return (
<div style={{ marginTop: "50px" }}>
<h1>已经获得的成就</h1>
<Row
gutter={16}
type="flex"
justify="center"
align="top"
style={{ marginTop: "20px", paddingBottom: "10px" }}
>
{badges.map(badge => (
<Col
lg={6}
md={6}
sm={8}
xs={12}
style={{ marginBottom: "1em" }}
key={badge.project.id}
>
<ProjectBadge badge={badge} />
</Col>
))}
</Row>
</div>
);
}
}虽然全局变量是一个不好的实践，但是很多时候处于方便性的考虑，还是在某些场景需要使用。这里就讲解一下在 react + webpack 场景下如何不提前引入就可以到处使用的全局变量的一个好的方案。
首先，其实对于前端应用原本是跑在浏览器里的，我们自然会想到用 window.global_var 的方式去定义全局变量。但是这种方式有一个问题：如果我们有自己的一些组件展示视图（比如 storybook）以及一些组件测试的话，仅仅在 index.js 定义的这种全局变量需要在每一个展示体系下都去定义，而这些体系可未必有 window。
第二种方法是采用 webpack 的 ProvidePlugin 让 webpack 打包时自动发现关键的全局变量并自动的引入。它是一种隐性的全局变量。代码如下所示：
module.exports = {
resolve: {
extensions: ['.js', '.json'],
alias: {
Config: path.resolve(__dirname, '../src/utils/Config')
}
},
plugins: [
new ExtractTextPlugin("styles.css"),
new webpack.ProvidePlugin({
Config: "Config"
}),
],
module: {
}
};resolve.alias 为一个引入定义一个 shortcut。plugins 中通过 webpack.ProvidePlugin 定义相应的变量即可注意，这里 resolve.alias 引入不支持 export default 的语法，只支持 export 以及 module.exports 的写法。