DevOps on 翟志军 Jack Zhai

An Example Implement Ansible Deployment on Github Action

Mon, 22 Apr 2024 00:00:00 +0000


- name: write secrets into json
  run: |
    echo "${{ toJSON(secrets) }}" > _github_secrets.json
- name: write github repo vars into json
  run: |
    echo "${{ toJSON(vars) }}" > _github_vars.json
- name: write ssh private key
  run: |
    echo "${{ secrets.STAG_SSH_PRIVATE_KEY }}" > ${{ github.workspace }}/.ssh_private_key.pem
    chmod 0400 ${{ github.workspace }}/.ssh_private_key.pem
- name: write ssl certificate
  run: |
    echo "${{ secrets.showmecodes_TLS_CERTIFICATES }}" > ${{ github.workspace }}/showmecodes.ai.pem
    echo "${{ secrets.showmecodes_TLS_KEY }}" > ${{ github.workspace }}/showmecodes.ai.key
- name: deploy showmecodes to stag
  uses: dawidd6/action-ansible-playbook@v2
  with:
    playbook: playbook-showmecodes.yml
    key: ${{ secrets.STAG_SSH_PRIVATE_KEY }}
    options: |
      --inventory env_vars/${{env.APP_ENV}}/hosts.yaml
      --extra-vars "app_backend_zip_path=${{ needs.init_build_version.outputs.backendArtifactName }} app_frontend_zip_path=${{ needs.init_build_version.outputs.fontendStagArtifactName }} app_version=${{ needs.init_build_version.outputs.VERSION }} ansible_ssh_private_key_file=${{ github.workspace }}/.ssh_private_key.pem showmecodes_tls_certificate_file=${{ github.workspace }}/showmecodes.ai.pem showmecodes_tls_private_key_file=${{ github.workspace }}/showmecodes.ai.key" --extra-vars=@_github_vars.json --extra-vars=@_github_secrets.json

Web前端构建之依赖版本管理最佳实践

Tue, 12 Mar 2024 00:00:00 +0000

工程化的构建在于把握细节

优秀的DevOps工程师应该具有什么特质？

Tue, 12 Mar 2024 00:00:00 +0000

这是我最近面试时遇到的一个非常好的问题：

在你的心目中，优秀的DevOps工程师应该是什么样的？

很长一段时间里，我没有想到这个问题。所以，当HR问起时，我边思考边回答。

我已经不记得原话，本文就当作从性格角度思考“优秀的DevOps工程师应该具有什么特质”。

首先，优秀的DevOps工程师，TA应该是严谨的。

一个严谨的特质的人才会主动考虑软件工程化过程中的各种可能。

其次，TA应该对手工操作产生“生理性上的不适”，即追求自动化极致。

一个再怎么严谨的人，如果是手工操作，面对复杂的线上环境的运维，TA的能力也是有限的。TA必须自动化所有能自动化的东西，并争取自动化所有的内容，TA才能有可能“驯服野兽”。

然后，TA应该是一个节约的人，即节俭。

因为浪费导致企业不必要损失，是否要避免这个损失，很多时间里是一个DevOps工程师的选择问题。

最后，TA应该是一个热爱这个领域的人。我常常忘记自己对这个领域的热爱。以致于我忘记回答。

只有热爱，才能产生自驱力，驱动TA去成长，去不断思考。即使你再严谨，你也有考虑不到的地方，只有热爱，TA才会探索到TA不知道他不知道的。

以上只是我个人的看法，欢迎一起讨论。

DevOps架构师是如何看待Github Actions的共享制品解决方案的？

Tue, 16 Jan 2024 00:00:00 +0000

只要对这一问题深入理解，所有的平台一通百通。

使用Google OSV工具扫描依赖安全漏洞

Mon, 25 Dec 2023 00:00:00 +0000

安全漏洞是软件工程化能力的试金石

2021年年底，Log4j的漏洞陆续被公开。因为该框架被大量的开源软件依赖，所以，漏洞影响面非常大。

面对这个漏洞，我们遇到的第一个问题是：如何知道我们哪些工程使用了Log4j？

在我看来，这个漏洞是企业软件工程化的一颗非常好的试金石。因为：

如何第一时间了解到这个漏洞，反应这家企业的安全能力；
如何第一时间能找到所有使用了Log4j的位置，体现了这家企业第三方软件依赖管理能力；
替换Log4j的速度，体现企业的持续集成、持续部署的能力。

Google的开源软件安全漏洞扫描工具

今天介绍的OSC-Scanner，能加强我们第1项和第2项能力。

OSV-Scanner是Google在2022年12月13日推出的一款免费的安全扫描工具。它具有以下特点：

支持多生态系统，包括：Go、PyPI、RubyGens、Linux、Maven等16个生态系统；
同时支持直接依赖的扫描和间接依赖的扫描；
采用标准的漏洞记录格式；
从当前最大的开源软件漏洞数据库（https://osv.dev/）获取信息。这也是DenpencyTrack和Flutter安全工具的漏洞数据库。

OSV-Scanner是一款命令行工具，我们可以将它集成到我们的构建工具或者CICD Pipeline中。目前它已经被集成到Scorecard中。Scorecard是一款为开发源软件的安全健康度打分的开源软件。我们可以在Github Actions中使用它：https://github.com/ossf/scorecard/tree/main?tab=readme-ov-file#scorecard-github-action

OSV-Scanner的安装

Windows：

scoop install osv-scanner

Mac Homebrew:

brew install osv-scanner

也可以直接下载二进制包：https://github.com/google/osv-scanner/releases

具体安装文档：https://google.github.io/osv-scanner/installation/

OSV-Scanner的使用

Keras是一个使用Python编写的开源人工神经网络库。我们以它为例。命令行里运行以下命令：

./osv-scanner_1.3.6_linux_amd64 --format json keras/

输出内容说明：keras存在一个“潜在内存泄漏”的漏洞。

当拿到json结果后，我们的DevOps平台就可以进行一些告警监控的操作。

后记

osv-scanner目前需要连osv.dev，才能使用。但是，已经开放实验功能，允许用户离线使用osv-scanner。这是自建DevOps平台的福音！

基于 Jenkins 的 DevOps 平台应该如何设计凭证管理

Tue, 07 May 2019 00:00:00 +0000

一种基于 Jenkins 的 DevOps 平台建设思路

ChatOps实战

Sun, 08 Oct 2017 00:00:00 +0000

ChatOps没有那么神秘，也就是正则+脚本

简单易懂Ansible系列 —— 实现ssh key主机之间复制

Sat, 19 Aug 2017 00:00:00 +0000

我们在搭建Hadoop完全分布式环境时，Hadoop的name node节点（理解为master节点）需要无密码登录到所有的data node节点。

当然，我们使用手工的方式很容易就实现了：

在name node节点上生成ssh key：ssh-keygen
将public key copy到所有的data node节点上：ssh-copy-id slave1

同时，你还必须设置~/.ssh/config，以防止登录时不停的问yes or no：

```yml
Host *
    StrictHostKeyChecking no
```

完了，还要设置这个文件的权限为400。

以上步骤当然可以手工一步步执行。但是，总有那么一些人：希望所有的操作都可以版本化，所有的操作都应该自动化。我属于这些人。

再说了，我发现在搭建Jenkins环境时，也遇到了同样的问题：需要将Jenkins master的public key加入到Jenkins agent机器中。

可以预见到将来我还会遇到类似的问题。于是，我找到一个方法来自动化以上操作。

在name node机器上执行task如下

创建用户的时候生成ssh_key：

- name: create hadoop user
  user:
    name: "{{hadoop_user}}"
    group: "{{hadoop_group}}"
    createhome: yes
    generate_ssh_key: yes
    ssh_key_bits: 2048
    ssh_key_file: .ssh/id_rsa
  tags:
    - hadoop

将id_rsa.pub拉取到ansible执行机器上

- name: fetch public key
  fetch:
    src: "/home/{{hadoop_user}}/.ssh/id_rsa.pub"
    dest: /tmp/
    flat: yes
  tags:
    - hadoop

设置StrictHostKeyChecking no 因为我们只想修改这个用户的ssh行为，所以我们的ssh的配置只是针对当前这个用户的：