Amazon EKS Pod Identity 是 AWS 对 EKS 原有的 IAM roles for service accounts (IRSA) 功能的补充，通过新增的 EKS Pod Identity 功能， 用户可以用更简便的方式实现为 Pod 安全的授予 AWS API 访问权限， 并且所有的配置管理操作都可以通过 AWS API 或者控制台完成。

使用方法

1. 新建个 IAM role，信任实体如下

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

分配策略比如:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::artifacts"
        }
    ]
}

2. EKS 集群需要安装 eks-pod-identity-agent 组件（支持通过控制台安装）。

aws eks create-addon \
--cluster-name <CLUSTER_NAME> \
--addon-name eks-pod-identity-agent \
--addon-version v1.x.x-eksbuild.1

3. 创建 K8s Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

4. 然后，需要配置应用 Pod 所使用的 Service Account 与 AWS IAM 角色之间的关联关系， 允许使用该 Service Account 的应用扮演特定的 IAM 角色（支持通过控制台配置）。

aws eks create-pod-identity-association \
  --cluster-name <CLUSTER_NAME> \
  --namespace <NAMESPACE> \
  --service-account <SERVICE_ACCOUNT_NAME> \
  --role-arn <IAM_ROLE_ARN>

5. 最关键的，应用 Pod 需要更新使用最新的支持 EKS Pod Identity 特性的 AWS SDK 比如应用 Pod 是 Java开发的，需要调用 S3 API，那么需要更新 pom.xml 文件，添加 AWS SDK,AWS SDK 中有一套获取凭证的默认搜索逻辑 或者显示调用 EKS Pod Identity 依赖的Container credential provide

6. 运行应用 Pod, 我们来创建一个简单的应用 Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-service-account
      containers:
      - name: my-app
        image: public.ecr.aws/aws-cli/aws-cli:2.32.12
        command:
          - sh
          - '-c'
          - while true; do sleep 3600; done

7. 测试,发现有S3桶内容返回,如果把 s3:ListBucket action 拿掉则报错, 测试通过

kubectl exec -it deployment/my-app -- aws s3 ls s3://artifacts/

工作流程

1. 当用户/Controller 向 apiserver 提交 Pod 时，会触发 eks-pod-identity-webhook 的 mutating webhook 流程。

2. eks-pod-identity-webhook 的 mutating webhook 流程会为 Pod 挂载 service account oidc token 文件以及配置环境变量 (AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE, AWS_CONTAINER_CREDENTIALS_FULL_URI ）。

通过 kubectl describe pod my-app-77f6749799-f26hf 可以看到

    Environment:
      AWS_STS_REGIONAL_ENDPOINTS:              regional
      AWS_DEFAULT_REGION:                      eu-west-1
      AWS_REGION:                              eu-west-1
      AWS_CONTAINER_CREDENTIALS_FULL_URI:      http://169.254.170.23/v1/credentials
      AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-jtjst (ro)
      /var/run/secrets/pods.eks.amazonaws.com/serviceaccount from eks-pod-identity-token (ro)

打印 service account oidc token 文件，kubectl exec -it deployment/my-app -- cat /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token 是 JWT 格式的,找一个在线解密 https://www.jwt.io/ 获得

## header

{
  "alg": "RS256",
  "kid": "167335cb436b4080252a64e070f6d3153f896845"
}

## payload
iss (Issuer)：签发者
sub (Subject)：主题
aud (Audience)：接收者
exp (Expiration time)：过期时间
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号

{
  "aud": [
    "pods.eks.amazonaws.com"
  ],
  "exp": 1765334133,
  "iat": 1765252458,
  "iss": "https://oidc.eks.eu-west-1.amazonaws.com/id/43E064763DAXXXXD18392C7FC9CBEA3A",
  "jti": "5e081212-fdf6-425c-9b32-c9a372112fd9",
  "kubernetes.io": {
    "namespace": "default",
    "node": {
      "name": "ip-172-31-77-99.eu-west-1.compute.internal",
      "uid": "797b365b-3491-47a6-a222-ba5acf3276d8"
    },
    "pod": {
      "name": "my-app-77f6749799-f26hf",
      "uid": "8768b78a-298a-4bf5-95b4-07a181ccbc2a"
    },
    "serviceaccount": {
      "name": "my-service-account",
      "uid": "92a8c128-7c32-4199-be85-1f2669cf7914"
    }
  },
  "nbf": 1765252458,
  "sub": "system:serviceaccount:default:my-service-account"
}

3. Pod 容器内的应用使用的 AWS SDK 将使用通过环境变量 AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE 获取的 service account oidc token 访问环境变量 AWS_CONTAINER_CREDENTIALS_FULL_URI 指向的地址 （http://169.254.170.23/v1/credentials）获取 AWS sts token。

curl $AWS_CONTAINER_CREDENTIALS_FULL_URI -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" 2>/dev/null | jq

{
  "AccessKeyId": "ASXXXXXXXXXXXXX",
  "SecretAccessKey": "zEuXXXXXXXX",
  "Token": "IQoJb3JpXXXXXXX",
  "AccountId": "5XXXXXXXXXXX",
  "Expiration": "2025-12-09T09:54:37Z"
}

等效写法

TOKEN=`kubectl exec -it deployment/my-app -- cat  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token`
aws eks-auth assume-role-for-pod-identity --cluster-name cluter-name --token $TOKEN

{
    "subject": {
        "namespace": "default",
        "serviceAccount": "my-service-account"
    },
    "audience": "pods.eks.amazonaws.com",
    "podIdentityAssociation": {
        "associationArn": "arn:aws:eks:eu-west-1:47111xxxxx:podidentityassociation/cluster-name/a-avrgufuj****",
        "associationId": "a-avrgufuj****"
    },
    "assumedRoleUser": {
        "arn": "arn:aws:sts::47111xxxxx:assumed-role/my-role/cluter-name-c-my-app-77f-8c3ec6dc-97****",
        "assumeRoleId": "AROAW****:eks-cluster-eks-c-my-app-77f-8c3ec6dc-97****"
    },
    "credentials": {
        "sessionToken": "IQoJb3JpZ2luX2VjEO///////////wEaCWV1LX****",
        "accessKeyId": "ASIAW****",
        "expiration": "2025-12-09T20:23:17+08:00"
    }
}

4. AWS_CONTAINER_CREDENTIALS_FULL_URI 的值为 http://169.254.170.23/v1/credentials。 这个地址是固定的,是 EKS Pod Identity Agent 提供的本地 HTTP 端点。

• 169.254.170.23: EKS Pod Identity Agent 的固定端点
• 169.254.169.254: EC2 IMDS (Instance Metadata Service) 的固定端点

EKS Pod Identity Agent 作为 DaemonSet 运行在每个节点上,通过以下方式提供服务:

• HostNetwork 模式: Agent 使用主机网络
• 本地监听: 在节点上监听 169.254.170.23:80
• 所有 Pod 可访问: 节点上的所有 Pod 都可以访问这个 IP

eks-pod-identity-agent 收到请求后，将使用传递过来的 oidc token 访问 EKS 新增的 AssumeRoleForPodIdentity API 获取所需的 AWS sts token，然后将获取到的 sts token 返回给客户端。

5. 应用调用的 AWS SDK 使用获取到的 sts token 访问应用所需的 AWS 云产品 API。

简单描述：

• Pod 读取 JWT 令牌文件 (/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token)
• AWS SDK 将令牌发送到 http://169.254.170.23/v1/credentials
• EKS Pod Identity Agent 验证令牌并调用 AWS STS
• 返回临时 AWS 凭证 (AccessKeyId, SecretAccessKey, SessionToken)

参考

https://mozillazg.com/2023/12/security-deep-dive-into-aws-eks-pod-identity-feature.html

https://securitylabs.datadoghq.com/articles/eks-pod-identity-deep-dive/

AWS S3 讲解

  ├── 1. S3 基础概念
  │   ├── 什么是 S3
  │   ├── 核心组件：Bucket + Object
  │   └── 适用场景
  │
  ├── 2. 存储类别 (Storage Classes)
  │   ├── Standard (标准)
  │   ├── Intelligent-Tiering (智能分层)
  │   ├── Glacier (归档)
  │   └── 成本优化对比
  │
  ├── 3. 核心功能
  │   ├── Versioning (版本控制)
  │   ├── Lifecycle (生命周期)
  │   ├── Encryption (加密)
  │   └── Static Website Hosting
  │
  ├── 4. 访问控制
  │   ├── Bucket Policy
  │   ├── IAM Policies
  │   ├── ACLs
  │   └── Block Public Access
  │
  ├── 5. 数据保护
  │   ├── Replication (复制)
  │   ├── Object Lock (对象锁定)
  │   └── 备份策略
  │
  └── 6. 最佳实践
      ├── 命名规范
      ├── 安全性
      └── 成本优化

详细大纲

1. 什么是 Amazon S3？

• 对象存储服务：不同于块存储/文件存储
• 特点：无限容量、高持久性(11个9)、高可用
• 核心概念：
  • Bucket（桶）：容器，类似文件夹顶级目录
  • Object（对象）：文件 + 元数据 + 唯一键值

2. 存储类别对比

3. 关键功能

版本控制 (Versioning)

• 保留对象多个版本
• 防止误删除、覆盖

生命周期策略 (Lifecycle)

• 自动将对象转移到低成本存储类
• 自动删除过期对象

静态网站托管

• 直接托管 HTML/CSS/JS
• 配合 CloudFront CDN

4. 访问控制模型

安全层级（由外到内）

1. Block Public Access → 阻止公开访问

2. Bucket Policy → JSON 策略控制

3. IAM Policy → 用户/角色权限

4. ACL → 细粒度控制（较少用）

5. 数据保护

• 跨区域复制 (CRR)：多区域灾备
• 同区域复制 (SRR)：合规/低延迟
• S3 Object Lock：WORM 保护，防删除

6. 定价模式

• 存储费：按 GB/月
• 请求费：PUT/GET/DELETE
• 数据传出：出桶才收费
• S3 Glacier 检索费：注意隐藏成本

讲解建议

1. 开场：用生活类比（Bucket = 仓库，Object = 箱子）
2. 重点：存储类别选择 + 成本优化 + 安全性
3. 互动：展示 AWS Console 实际操作
4. 结尾：常见坑点 + 最佳实践清单

实际开发建议

• 优先使用 :=：在函数内部，:= 更简洁
• 包级别变量用 var：全局变量必须用 var 声明
• 需要零值初始化时用 var：如 var count int (自动为0)
• 明确指定类型时用 var：如 var pi float32 = 3.14

为什么结构体作为函数参数，前面要加 *

1. 减少内存开销 如果不加 *，函数调用时会复制整个结构体，占用额外内存。 使用 * 可以传递结构体的地址，避免复制，提高性能，尤其是结构体较大时。
2. 修改原始结构体 如果函数需要修改结构体的字段值，必须使用指针才能生效。 不使用指针（即传值方式），函数内部对结构体的修改不会影响原始结构体。
3. 一致性 在 Go 中，方法可以有指针接收者（func (f *Family)）或值接收者（func (f Family)）。 如果你希望无论调用者是结构体变量还是指针，都能统一处理，通常会使用指针接收者。

下面两个写法等价吗

type Person struct {
	Name string
	Age  int
}

// 方法 - 表示这是 Person 的行为
func (p Person) say() {
  fmt.Println("hello world")
}

// 函数 - 表示这是一个独立的操作
func say(p Person) {
  fmt.Println("hello world")
}

// 方法调用 - 面向对象风格
person.say()

// 函数调用 - 函数式风格  
say(person)

any

any 是 interface{} 的别名，Go 1.18+ 引入 any 类型，它表示任何类型，包括 nil。

我对技术比较有热情。对CI/CD，容器化，云原生，微服务架构，自动化都有一定的了解。

目前在某传统行业外企担任 DevOps Specialist，10余年开发+运维经验

对文章有疑问的，欢迎加v讨论问题，也欢迎提issue

关于本站

• 2025.12.12 统一图床地址
• 2024.06.15 支持生成RSS
• 2023.12.31 从vuepress转移到vitepress，更快的构建速度

animate API

官网解释 animate api

$(selector).animate({params},[speed],[easing],[fn]);

• params: 一组包含作为动画属性和终值的样式属性和及其值的集合
• speed: 可以填三种预定速度之一的字符串("slow" 600ms,"normal" 400ms, "fast" 200ms)或者直接填毫秒数值，默认400
• easing: 要使用的擦除效果的名称(需要插件支持). 默认jQuery提供"linear" 和 "swing".
• fn: 在动画完成时执行的函数，每个元素执行一次

例子，点击按钮让这个元素偏移一定像素

$("button").click(function(){
  $("div").animate({left:'250px'});
});

slideUp 等二次封装的方法

其中，jQuery还提供了方便的方法,其实是语法糖,对animate方法的二次封装

hide，show分别修改元素的display属性为none和block

slideUp(收缩高度),slideDown(还原高度),本质是随时间修改元素的高度

fadeIn(淡入), fadeOut(淡出)，本质是随时间修改元素的opacity属性

详细的例子可以见w3school

jQuery自带效果有限，可以使用 jQuery Easing Plugin 另外jQuery UI 提供了更多的特效，如颤动，心跳，爆炸等

animate 队列

jQuery的animate还支持队列，逐帧播放

$("button").click(function(){
  var div=$("div");
  div.animate({left:'100px'},"slow");
  div.animate({fontSize:'3em'},"slow");
});

loop 循环播放

借助animate API最后一个callback参数，可以轻松实现无尽播放动画的效果。

<iframe height="265" style="width: 100%;" scrolling="no" title="jquery animation loop" src="https://codepen.io/mafeifan/embed/ExPJpRo?height=265&theme-id=light&default-tab=html,result" frameborder="no" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href='https://codepen.io/mafeifan/pen/ExPJpRo'>jquery animation loop</a> by finley
  (<a href='https://codepen.io/mafeifan'>@mafeifan</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

使用场景

1. 不支持loop
2. 不支持滚动条滚动播放

This page demonstrates usage of some of the runtime APIs provided by VitePress.

The main useData() API can be used to access site, theme, and page data for the current page. It works in both .md and .vue files:

<script setup>
import { useData } from 'vitepress'

const { theme, page, frontmatter } = useData()
</script>

## Results

### Theme Data
<pre>{{ theme }}</pre>

### Page Data
<pre>{{ page }}</pre>

### Page Frontmatter
<pre>{{ frontmatter }}</pre>

Results

Theme Data

{{ theme }}

Page Data

{{ page }}

Page Frontmatter

{{ frontmatter }}

More

Check out the documentation for the full list of runtime APIs.

隔叶黄莺 Yanbin Blog

Java 全栈知识体系

小傅哥 bugstack 虫洞栈

Go语言文档合集

小林 x 图解计算机基础

This page demonstrates some of the built-in markdown extensions provided by VitePress.

Syntax Highlighting

VitePress provides Syntax Highlighting powered by Shiki, with additional features like line-highlighting:

Input

```js{4}
export default {
  data () {
    return {
      msg: 'Highlighted!'
    }
  }
}
```

<ul>
  <li v-for="todo in todos" :key="todo.id">
    {{ todo.text }}
  </li>
</ul>

Output

export default {
  data () {
    return {
      msg: 'Highlighted!'
    }
  }
}

Custom Containers

Input

::: info
This is an info box.
:::

::: tip
This is a tip.
:::

::: warning
This is a warning.
:::

::: danger
This is a dangerous warning.
:::

::: details
This is a details block.
:::

Output

console.log('Hello, VitePress!')

iframe

More

Check out the documentation for the full list of markdown extensions.

使用 ChatGPT有几种方法

1. 登录 openai.com，注册账号，然后点击左上角的“Log in”按钮，登录账号。

• 优点：简单，技术门栏低，目前ChatGPT3.5是免费的
• 缺点：需要开代理，国内无法直接使用

2. 使用 ChatGPT API

• 优点：更安全，需要一定的技术能力和开发能力
• 缺点：ChatGPT API是需要付费

OpenRouter是一个开源的API代理服务，可以免费使用ChatGPT的API，支持自定义接口，模型等，关键你可以一个key同时调用多个模型

前提

• Visa信用卡
• 谷歌账号
• 已经部署了ChatGPTNextWeb，或支持自定义接口

1. 打开 https://openrouter.ai 使用 google 账号登录
2. 点顶部的 Credits 绑定信用卡，这里我充值 10 美元，注意 openrouter 会额外收一定的手续费

3. 进到 https://openrouter.ai/keys 页面，点 create key，起个名字

最好也填上 Credit Limit, 这里我填5，超过5美元后就会自动停用

最终我们拿到 sk 开头的key

4. 进到已经部署了ChatGPTNextWeb的配置页面

• 接口地址: https://openrouter.ai/api
• API Key: 填写 OpenRouter sk 开头的key

切换模型，验证是否生效

https://dev.amazoncloud.cn/experience/cloudlab?id=65fd7f888f852201f9704488

Titan Text G1 - Express 就是垃圾，根本不能用

aws bedrock-runtime invoke-model \
--model-id meta.llama2-13b-chat-v1 \
--body "{\"prompt\":\"[INST]Find the issue in this code below. Explain your reason\\nimport torch\\ntorch.device(\\\"cuda:0\\\" if torch.cuda.is_available() else \\\"cpu\\\")\\ndef run_som_func(a, b):\\nc = c*2\\nc=a+b\\nprint(c)\\nreturn c ^ 2\\nI get an error saying variable referred before[/INST]\",\"max_gen_len\":512,\"temperature\":0.5,\"top_p\":0.9}" \
--cli-binary-format raw-in-base64-out \
--region us-east-1 \
invoke-model-output.txt

curl 'https://dev-media.amazoncloud.cn/doc/workshop.zip' --output workshop.zip
unzip workshop.zip
pip3 install -r bedrock/workshop/setup/requirements.txt -U

# add code for labs/api/bedrock_api.py

python bedrock/workshop/labs/api/bedrock_api.py

streamlit run bedrock/workshop/labs/text/text_app.py --server.port 8080

streamlit run bedrock/workshop/labs/streaming/streaming_app.py --server.port 8080

LangChain

LangChain可以抽象出使用Boto3客户端的许多细节，尤其是当你想专注于文本输入和文本输出时。

Bedrock Access Gateway

把 OpenAI API 的调用转发到 Amazon Bedrock，从而获得包括 Claude3 在内的多种 LLM 的优秀能力

参考

https://docs.dify.ai/v/zh-hans/getting-started/readme/model-providers

AWS 要授权给他人访问指定资源有哪几种方式呢？

• 在自己帐号下创建一个用户，把 Access Key ID 和 Secret Access Key 告诉别人。可为该用户限定权限，但任何获得那两个 Key 的人都能使用该用户。不够安全。
• 创建一个 IAM Role, 并指定谁(帐号或 Role) 能以该 Role 的身份来访问。被 Assume 的 Role 可限定权限和会话有效期。

所以，用 Assume Role 的方式具有更高的安全可控性，还不用维护 Access Key ID 和 Secret Access Key。

比如在构建和部署时通常是有一个特定的 Account, 然后 Assume 到别的 IAM Role 去操作资源。

本文将详细介绍在帐号 A 创建一个 IAM Role(标注为 R) 并分配一些权限，然后允许另一个帐号 B 以 IAM Role - R 的身份来访问帐号 A 下的资源。

IAM Role 将用 awscli 来创建，Assume Role 的过程用 awscli 和 boto3 Python 代码两种方式来演示。

已知两个账号A，B

~/.aws/credentials 添加好key

[a]
aws_access_key_id=AKIA5*****USBKPN4DIH
aws_secret_access_key=OdUsUew**********MEgoC8*****9LCvbqkaCQQS

[b]
aws_access_key_id=AKIA*****2USOGAHFVAU
aws_secret_access_key=b2nXQ**********7EuBO*****5ngKM3Msg2CLqma

帐号 A 下创建 IAM Role

aws s3 ls --profile a

# 或者用环境变量，这是更推荐的方式
export AWS_DEFAULT_PROFILE=a

# 查看账户A下的S3资源
aws s3 ls

# 在账号A下创建 test-assumed-role
aws iam create-role --role-name test-assumed-role --assume-role-policy-document file://role-trust-policy.json

# 给新建的 test-assumed-role 加上 S3 的只读权限
aws iam attach-role-policy --role-name test-assumed-role --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

帐号 B Assume 帐号 A 的 role

export AWS_DEFAULT_PROFILE=b
# 924612875556是账户A的account id
# 这句话的意思是用，将账户B切换为账户A
aws sts assume-role --role-arn arn:aws:iam::924612875556:role/test-assumed-role --role-session-name awscli-session

返回内容:

{
    "Credentials": {
        "AccessKeyId": "ASIA*******O5OOFMMB",
        "SecretAccessKey": "qLR4rNZ*******PPJAIBx22plNN8oWIRtp2bbq",
        "SessionToken": "IQoJb3JpZ2luX2VjEPb//////////wEaDmFwLW5v*******xIkcwRQIgCKgl/h9gP4430qtSRfnp*******VddkekMUcN2ECIQC06q/7vYhcVMj7jujstIVzBhecnYQgB3bZf0l5qaxjzyqbAggwEAEaDDkyNDYxMjg3NTU1NiIMKP1BdAa6NQhoo2FYKvgBy5B1tyKn0GPz7DwG+YWxdfc9+ayNwzulKsF895wLpzuC9Hkyd2+KL22PgcaAOHV+PU3CPicDS8xTlanAQZvlPQy3egXv+JNOwlrJaVmyKuNbtzGCpYlBFs9TnC1sD+Uz0MGtXPh3GLhoZZ9gHt7fktDwohoz5+fbA+6zXUvO4xmFAicoYy7PCSM1v8weQ+oXqMAFREJ3Pd3Zs3y5adQYK100+reEJ1uvMIIdk3KSKYsF3T8ZByU+MdP+YBSgilfaY/YVgXExUp0B2dwWMRRh95FSdmmIfAtqSrt/0mXhah5zxTaoVxbPUT68A6Fj4Gecw+3iZiIeM2MwycSrlgY6nQGlo4fNrVvHEgw8yBFPE6wiY+jAi1vLNplxJ1WN59OMK+0rfdyBO91JFeoOEiQNXzbZJSorI2SuEUi3dVgVotvGwCMYsOYByM4zyJa9tdsjXTKX6UL2CdHyGKm6y5QK1DhXhl9mtEMqNqEWoQN4LkgGHv/4fzJLoFqKO2cC+VZDQ40AofaTVEsKaJjU3zt3NCUa+Ltq5qyfyTkHxoky",
        "Expiration": "2022-07-10T15:29:29+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA5ORZY2USEASI2XI4F:awscli-session",
        "Arn": "arn:aws:sts::924612875556:assumed-role/test-assumed-role/awscli-session"
    }
}

这时候得到一组新的 AccessKeyId, SecretAccessKey 和 SessionToken，可以在 ~/.aws/credentials 中配置一个新的 profile C, 然后 export AWS_DEFAULT_PROFILE=C 来使用。 或都用 export 分别导出三个环境变量 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, 和 AWS_SESSION_TOKEN, 分别对应前面的三个值。

$ export AWS_ACCESS_KEY_ID=<Credentials.AccessKeyId>
$ export AWS_SECRET_ACCESS_KEY=<Credentials.SecretAccessKey>
$ export AWS_SESSION_TOKEN=<Credentials.SessionToken>

aws s3 ls --profile c

# 想访问超出 test-assumed-role 之外的权限将被提示 Access Denied
aws s3 cp Desktop/jump-server.sh s3://blog.finleyma.ml --profile ty-assume
upload failed: Desktop/jump-server.sh to s3://blog.finleyma.ml/jump-server.sh An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

# 查看当前所使用的角色
aws sts get-caller-identity --profile c

{
    "UserId": "AROA5ORZY2USEASI2XI4F:awscli-session",
    "Account": "924612875556",
    "Arn": "arn:aws:sts::924612875556:assumed-role/test-assumed-role/awscli-session"
}

用 Python 的 boto3 包实现

帐号 B 登陆，调用 boto3 的 sts.assume_role() 函数切换到帐号 A 下的 IAM Role test-assumed-role，之后的操作就限定到 test-assumed-role 的约束中了。

import boto3
 
aws_credentials_b = {
    'region_name': 'us-east-1',
    'aws_access_key_id':'PNKDIESJGWAURFEWDLLT',
    'aws_secret_access_key':'TdTMlDUSKecRadKeMlNIBEmIkRjmZOSvtnhgQDZc',
    'aws_session_token':'IQoJb3JpZ2luX2VjEDYabEbMG5J2lzlv......IEQisSAwzmnkv7LNf+'
}
 
 
sts=boto3.client('sts', **aws_credentials_b)
 
stsresponse = sts.assume_role(
    RoleArn="arn:aws:iam::123456789011:role/test-assumed-role", # under account A
    RoleSessionName='assumed'
)
 
aws_credentials_assumed_role = {
    'region_name':'us-east-1',
    'aws_access_key_id':stsresponse["Credentials"]["AccessKeyId"],
    'aws_secret_access_key':stsresponse["Credentials"]["SecretAccessKey"],
    'aws_session_token':stsresponse["Credentials"]["SessionToken"]
}
 
 
boto3.setup_default_session(**aws_credentials_assumed_role)
 
s3 = boto3.client('s3')
buckets_of_a = [bucket['Name'] for bucket in s3.list_buckets()['Buckets']]

当然，使用 Python 的话可以进一步封装，比如默认以帐号 B 登陆，然后执行一个函数 switch_role(role_arn) 后，后续的 boto3 client 就全部变成了 assumed role 的角色了

import boto3
 
def switch_role(assume_role_arn):
    sts=boto3.client('sts')
    sts_res = sts.assume_role(RoleArn=assume_role_arn, RoleSessionName='new_session')
 
    new_credentials = {'aws' + re.sub('([A-Z]+)', r'_\1', key).lower(): value
                       for (key, value) in sts_res["Credentials"].items() if key != 'Expiration'}
 
    boto3.setup_default_session(**new_credentials)
    
switch_role('arn:aws:iam::123456789011:role/test-assumed-role')
 
s3 = boto3.client('s3')
buckets_of_a = [bucket['Name'] for bucket in s3.list_buckets()['Buckets']]

把 sts_res['Credentials'] 转换为 session 要求的格式是简化，但是要注意以后 assume_role() 响应格式的变化有可能影响到程序的正常执行。

参考

https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

https://yanbin.blog/how-to-assume-aws-iam-role/

https://blog.51cto.com/wzlinux/2462544

有时候我们在云上部署一套高可用的系统往往需要创建很多资源，以在AWS部署一个Web服务为例：

• 2台EC2
• ALB(负载均衡)
• RDS(弹性数据库)
• Route53(域名解析)
• CloudFront(CDN)
• S3(管理静态资源)
• IAM(用户管理)
• SES(电子邮件服务)
• CloudWatch(监控)

光这么多资源，如果在页面上手动创建配置即便是再熟练，也会很累。 还有其他缺点： 手动部署，容易出错 无法进行版本化控制 需要专人部署，人员无法复用

如果使用CloudFormation，我们可以把这些资源都放在一个模板里，然后通过CloudFormation控制台来创建或者更新这些资源。

什么是CloudFormation

所谓堆栈资源，表示一种依赖关系，比如要使用ALB资源，那么就需要实例资源。使用实例要先创建安全组。 堆栈资源最终是一个资源集合。

CloudFormation模板

CloudFormation 模板是 JSON 或 YAML 格式的文本文件。 以下面为例。 表示创建一个EC2实例，指定了实例的AMI，类型，密钥对名称和数据卷。然后需要一个EIP来关联它。

AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template
Resources:
  MyEC2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
      ImageId: "ami-0ff8a91507f77f867"
      AvailabilityZone: "ap-northeast-1a"
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        - DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20
  MyEIP:
    Type: AWS::EC2::EIP
    Properties:
      # !Ref 等价 Fn::Ref
      InstanceId: !Ref MyEC2Instance

一个标准的模板由下面的部分组成，只有Resources是必需的

---
# 可选
AWSTemplateFormatVersion: "version date"

# 可选
Description:
  String

# 可选
# Designer 添加的信息，或者注释
# CloudFormation 不会转换、修改或编辑在 Metadata 区段中包含的任何信息
Metadata:
  template metadata

# 可选
Parameters:
  # set of parameters
  KeyName:
    Type: "AWS::EC2::KeyPair::KeyName"
    Description:
      "Name of an existing EC2 KeyPair to enable SSH access to the instances"
    Default:
      "my-awesome-key-name"
  SecurityGroupIDs:
    Type: "List<AWS::EC2::SecurityGroup::Id>"
    Description:
      "Name of an existing security group"
    Default:
      "sg-1a2b3cd4"
  EnvType:
    Type: "String"
    Description:
      "The type of environment"
    AllowableValues:
      - "test"
      - "prod"
      - "staging"
    Default:
      "test"  
# 可选
Rules:
  set of rules

# 可选
# 创建一个名为InstanceType的映射，在美东区我们使用m1.small，美西区使用m1.nano
Mappings:
  InstanceType:
    us-east-1:
      Type: "m1.small"
    us-west-1:
      Type: "m1.nano"
  SubnetMap:
    us-east-1:
      SubnetID: "subnet-12345678"
    us-west-1:
      SubnetID: "subnet-7654321"

# 可选
# 比如测试环境用安全组A，正式环境用B
Conditions:
  set of conditions

# 可选
Transform:
  set of transforms

# 必需
Resources:
  set of resources

# 可选
# 比如输出新创建的IP是什么
Outputs:
  # set of outputs
  KeyName
    Description: "This is the EIP for EC2"
    Value:
      Ref: MyEIP

AWS比较牛逼的是提供了AWS CloudFormation Designer可视化工具来拖拖拽拽资源生成模板。

并且官方提供了很多示例模板，你可以直接拿来改改就能用。

实战

如果已经有模板，可以直接上传到S3，然后填S3地址读取

参考

https://github.com/awslabs/aws-cloudformation-templates

https://docs.aws.amazon.com/zh_cn/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html

https://github.com/cloudtools/troposphere

下面是 user data 被执行时需知晓的一些知识

• 是脚本时必须以 #! 开始，俗称 Shebang, 如 #!/bin/bash
• user data 是以 root 身份执行，所以不要用 sudo, 当然创建的目录或文件的 owner 也是 root，需要 ec2-user 用* 户访问的话需要 chmod 修改文件权限，或者直接用 chown ec2-user:ec2-user -R abc 修改文件的所有者()
• 脚本不能交互，有交互时必须想办法跳过用户输入，如 apt install -y xzy, 带个 -y 标记
• 如果脚本中需访问 AWS 资源，权限由 Instance Profile 所指定的 IAM role 决定
• user data 中的脚本会被存储在 /var/lib/cloud/instances/<instance-id>/user-data.txt 文件中，因此也* 可以从这里验证 user data 是否设置正确。或者在 EC2 实例上访问 http://169.254.169.254/latest/* user-data 也能看到 user data 的内容。并且在 EC2 实例初始化后不被删除，所以以此实例为基础来创建一个新的 * AMI 需把它删除了
• user data 的大小限制为 16 KB, 指 base64 编码前的大小
• cloud-init 的输出日志在 /var/log/cloud-init-output.log, 它会捕获 cloud-init 控制台的输出内容

user data 的内容通常在创建好实例后，还得等一会才完全生效，马上用 SSH 登陆新创建后的实例一般还看不到效果，有可能得等分把钟。

脚本的内容会存储在 EC2 实例上，但它执行的控制台输出却没地方找，如果脚本执行过程中有问题就难以诊断了，这里有个办法可记录下 user data 中脚本执行的控制台输出，需在 user data 中加上一行，最后把调试也打开

#!/bin/bash -ex
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
apt update
......

对，你没有看错，上面的 exec > >(... 两个大括号之间有空格

这样就能在实例的 /var/log/user-data.log 中看到所有 user data 中脚本执行的控制台输出了，错在哪一步也就能有的放矢的修正。

如何修改Userdata

1. 首先把实例停止
2. 在实例仍被选中的情况下，依次选择操作、实例设置和编辑用户数据。
3. 启动实例

参考

https://aws.amazon.com/cn/premiumsupport/knowledge-center/execute-user-data-ec2/

https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change

1. IAM > roles > create role
2. custom trust policy > copy + paste

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "ecs-tasks.amazonaws.com"},
      "Action": "sts:AssumeRole"
  }]
}

3. Add permission > Create Policy
4. JSON > replace YOUR_REGION_HERE & YOUR_ACCOUNT_ID_HERE & CLUSTER_NAME > copy + paste

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ssmmessages:CreateControlChannel",
      "ssmmessages:CreateDataChannel",
      "ssmmessages:OpenControlChannel",
      "ssmmessages:OpenDataChannel"
    ],
    "Resource": "*"
  },
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:DescribeLogStreams",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:YOUR_REGION_HERE:YOUR_ACCOUNT_ID_HERE:log-group:/aws/ecs/CLUSTER_NAME:*"
    }
  ]
}

5. Give it a name
6. go back to Add permissions > search by name > check > Next
7. Give a role name > create role

ECS new task

1. go back to ECS > go to task definition and create a new revision
2. select your new role for "Task role" (different than "Task execution role") > update Task definition
3. go to your service > update > ensure revision is set to latest > finish update of the service
4. current task and it should auto provision your new task with its new role.
5. try again

Commands I used to exec in

Option1

enables execute command

CLUSTER_NAME=node-red
REGION=cn-north-1
SERVICE_NAME=service-nodered
CONTAINER=nodered

aws ecs update-service --cluster $CLUSTER_NAME --service $SERVICE_NAME --region $REGION --enable-execute-command --force-new-deployment

adds ARN to environment for easier cli. Does assume only 1 task running for the service, otherwise just manually go to ECS and grab arn and set them for your cli

TASK_ARN=$(aws ecs list-tasks --cluster CLUSTER_NAME --service SERVICE_NAME --region REGION --output text --query 'taskArns[0]')

TASK_ARN=arn:aws-cn:ecs:cn-north-1:777702137755:task/node-red/417a6af0a8c447f9a57d8e49ba7cc84c

adds ARN to environment for easier cli. Does assume only 1 task running for the service, otherwise just manually go to ECS and grab arn and set them for your cli

aws ecs describe-tasks --cluster CLUSTER_NAME --region REGION --tasks $TASK_ARN

exec in aws ecs execute-command --region $REGION --cluster $CLUSTER_NAME --task $TASK_ARN --container $CONTAINER --command "sh" --interactive

Option2

if you are using Jetbrains IDE, install plugin https://docs.aws.amazon.com/toolkit-for-jetbrains/latest/userguide/welcome.html

this plugin will help you to enables execute command and exec in

参考

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html

https://github.com/aws/aws-cli/issues/6242#issuecomment-1079214960

https://issuecloser.com/blog/debugging-node-js-applications-running-on-ecs-fargate

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MyListBucket",
      "Effect": "Allow",
      "Action": "S3:ListBucket",
      "Resource": [
        "arn:aws:s3:::com.demo.file"
      ],
      "Condition": {"StringEquals":  {"aws:username": "Bob"}}
    }
  ]
}

1. 同一Condition名称不能出现两次，要合并

https://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html

• IAM User 可以属于某个 IAM Group，甚至可以属于多个 Group
• IAM User 无法属于某个 IAM Role，必须透过”切换”的方式，在 AWS 中称为 “Assume Role”，而”切换”这个操作需要有权限才行

Assume Role 基本上是一种 Action("Action": "sts:AssumeRole")，因为 Assume Role 这个行为是从 AWS Security Token Service 中取得一个暂时的 token，藉此取得该 Role 所事先定义好的权限。(sts:AssumeRole Action & IAM Role 的对应关係可以从[此 AWS 官网文件]（https://docs.aws.amazon.com/zh_cn/service-authorization/latest/reference/list_awssecuritytokenservice.html#awssecuritytokenservice-actions-as-permissions）找到)

assuming role

切换角色

参考

https://godleon.github.io/blog/AWS/learn-AWS-IAM-2-policy/

• 不需要部署 or 管理 server

• 会根据需求自动的 scale out/in

• 不需要为 idle 资源支付费用

• 天生就具备的 HA & fault tolerance 等特性

目前 AWS 提供的 serverless service 其实很多，下图是目前比较常见的几个：

但要如何判断 AWS service 是否为 serverless? 只要评估一下上一个 section 提到的四个原则，如果都满足，表示这个服务属于 serverless(例如：Lambda、SNS、SQS)，只要有一项不满足，则该服务不属于 serverless(例如：EC2、Kinesis)

Lambda

文件中提到可设定 Lambda Function 执行时使用的 memory 范围在 128MB ~ 10,240MB(10GB) 之间

比较需要注意的是，Lambda function 执行时 的vCPU core 的数量是根据 memory 的设定大小来决定，如果在设定最大 10GB memory 的情况下，可以取得最大 6 vCPU core；简单来说，就是 memory 设定越大，执行速度会越快，当然费用也会越高

实际上就是只有 memory & timeout 设定可以调整而已

包含的产品多余牛毛

很多国外用户都在使用AWS的产品，著名的有S3，EC2，所有有必要了解一下。

这里介绍最基础的产品，VPC(Virtual Private Cloud)，虚拟私有云。

先看下一些基础概念

地域 Region

AWS 在世界各地有很多数据中心，一个 Region 就是多个数据中心的集群

目前在中国大陆地区有北京和宁夏两个 Region

可用区 AZ（Availability Zone）

每个 Region 中包含数个独立的，物理分隔开的 AZ（Availability Zone），每个 AZ 有独立的供电，制冷，安保。

同一 Region 内 AZ 之间由高带宽，极低延时的光纤网络相连，数据以加密形式传输。

ap-northeast-1 是 region 名称

ap-northeast-1a,ap-northeast-1c,ap-northeast-1d 是 AZ

你可以理解为北京Region cn-north-1，朝阳区有个AZ:cn-north-1c，海淀区有个AZ:cn-north-1d 同一Region下的AZ之间由高速网络连接，重要的数据可以放到多AZ里，假如朝阳区机房停电或失火，通过配置流量和数据可以使用海淀区的。 这就是简单的容灾备份。

虚拟私有网络 VPC

VPC（Amazon Virtual Private Cloud）是用户在 Region 中自定义的虚拟网络，是一个整体概念。

用户可以在一个 Region 中创建多个 VPC。

我们可以在 VPC 中选择 IP 网段，创建 Subnet，指定 Route Table，控制 ACL（Access Control list），设置网关等。

多业务系统隔离

如果在一个地域的多个业务系统需要通过VPC进行严格隔离，例如，生产环境和测试环境，那么也需要使用多个VPC。

同样可以通过使用高速通道、VPN网关、云企业网等产品实现同地域VPC间互通。

多地域部署系统

VPC是地域级别的资源，不支持跨地域部署。当有多地域部署系统的需求时，必须使用多个VPC。 可以通过使用高速通道、VPN网关、云企业网等产品实现跨地域VPC间互通。

当 VPC 创建完成后主路由表 和 Main network ACL 会自动创建。

用户可以在公有云上创建一个或者多个VPC，比如，一个大公司里每个部门分配一个VPC。对于需要连通的部门创建VPC连接。

IP段用CIDR表示

CIDR

无类别域间路由（Classless Inter-Domain Routing、CIDR）是一个用于给用户分配IP地址以及在互联网上有效地路由IP数据包的对IP地址进行归类的方法。

遵从CIDR规则的地址有一个后缀说明前缀的位数，例如：192.168.0.0/16。这使得对日益缺乏的IPv4地址的使用更加有效。

也就是说，创建子网时要考虑你需要的资源数

Subnet

子网是 VPC 中的 IP 地址范围。在创建 VPC 之后，可以在每个可用区中添加一个或多个子网。

我们一般创建两种子网 Private Subnet 和 Public Subnet。

简单来说，不能直接访问 internet 互联网的 Subnet 就是 Private Subnet，能直接访问 internet 的就是 Public Subnet。

当然 Private Subnet 也可以通过 NAT 的方式访问 internet

当我们在一个 VPC 中创建 Subnet 时需要给 Subnet 选择一个 AZ（Availability Zone），一个 Subnet 只能选择建在一个 AZ 中。

实战

实现图上的功能，创建两个子网

• 一个是 Public Subnet，可以访问因特网，另一个是 Private Subnet
• 一个是 Private Subnet，不能访问因特网

创建VPC

IPv4 CIDR: 192.168.0.0/16

name: finley-vpc

创建互联网网关

name: finley-internet-gateway

并attach到finley-vpc上

创建三个子网

分别为 public, private, public&private（私网通过NAT访问公网）

| subnet id | IPV4 CIDR | AZ | 用途 | :-----| :---- | :---- | | finley-public | 192.168.0.0/24 | ap-northeast-1a | 部署web服务器 | finley-private| 192.168.2.0/24 | ap-northeast-1d | 部署数据库 | finley-private&public | 192.168.1.0/24| ap-northeast-1c| 部署应用程序

创建两个路由表

路由表包含一组称为路由的规则，用于确定来自子网或网关的网络流量定向到何处。

路由表必须属于某VPC

一个公有子网，一个私有子网但可通过NAT访问公网

name: finley-public

编辑路由表

# 第一条表示到192.168.*.*的请求会发送至VPC中
192.168.0.0/16	local

# 第二条表示到其它IP的请求会发送至IGW
0.0.0.0/0	igw-0d1092780f692f46f

编辑子网关联

创建第二个路由

name: finley-private

编辑子网关联，选择finley-private&public

创建EC2

创建两个EC2，一个名为finley-public-ec2，一个finley-private-ec2

VPC选择finley-vpc

申请弹性IP，得到公网IP：52.197.152.165 并关联给 finley-public-ec2

EIP（Elastic IP）是AWS提供的静态公共IP，可以从internet上访问到。实例即便被删除IP也会保留

SSH ssh -i "aws-ty-2022.pem" [email protected] 登录实例

aws-ty-2022.pem 私钥是之前申请过的

检查网络配置，安装nginx或httpd，浏览器打开52.197.152.165，访问成功

ubuntu@ip-192-168-0-93:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
        inet 192.168.0.93  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::4c3:76ff:feef:971  prefixlen 64  scopeid 0x20<link>
        ether 06:c3:76:ef:09:71  txqueuelen 1000  (Ethernet)
        RX packets 2795  bytes 2887062 (2.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1519  bytes 178671 (178.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions

finley-private-ec2 只有一个私网地址，由于我们选择private子网

会得到一个私网地址，如192.168.2.197，即使有公网IP，也无法通过互联网访问

可以通过finley-public-ec2登录这个私有子网的实例

# 在本机执行
## 上传私钥到public ec2
scp ~/.ssh/aws.pem 52.197.152.165:~
## 登录public ec2
ssh -i ~/.ssh/aws.pem 52.197.152.165
# 在 public ec2 上执行
chmod 400 aws.pem
## 登录private-ec2
ssh -i ~/.ssh/aws.pem 192.168.2.197
# 进到私网实例，确实无法访问互联网
wget www.baidu.com

通过NAT网关使私有子网访问互联网

注意NAT是按小时收费的，用完及时释放

NAT 网关是一种网络地址转换 (NAT) 服务。可以使用 NAT 网关，以便私有子网中的实例可以连接到 VPC 外部的服务，但外部服务无法启动与这些实例的连接。

路由器将互联网流量从私有子网中的实例发送到 NAT 网关。NAT 网关通过使用自身的弹性 IP 地址作为源 IP 地址，将流量发送到互联网网关。

创建 NAT网关

NAT网关要创建在公有子网当中， 选择一个公有子网，创建成功后等待状态变为可用

参考：计算机网络

修改路由表，等状态变为available

此时finley-private-ec2可以访问互联网了，是通过NAT关联的IP

通过终端节点让私有网络访问aws服务(S3)

VPC 终端节点使您能够在 Virtual Private Cloud (VPC) 与支持的服务和之间建立连接，而无需使用互联网网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。

因此，VPC 不会对公有 Internet 公开。

实现私有地址访问公有服务，这里我们让私有子网中的实例访问S3服务，首先创建终端节点

实际上是添加了一条路由表信息

访问S3并下载文件成功

VPC peering 对等连接

VPC 对等连接是两个 VPC 之间的网络连接

可以在自己的 VPC 之间创建 VPC 对等连接，或者在自己的 VPC 与其他AWS账户中的 VPC 之间创建连接

VPC 可位于不同区域内（也称为区域间 VPC 对等连接）。

例如，如果您有多个AWS账户，则可以通过在这些账户中的 VPC 间建立对等连接来创建文件共享网络。

您还可以使用 VPC 对等连接来允许其他 VPC 访问您某个 VPC 中的资源。

总结

• 首先我们选择Region，随后所有创建的内容都是存在此Region中
• 创建VPC，一个虚拟网络，在里面设置IP段，VPC是一个逻辑结构，并不和AZ（Availability Zone）直接相关
• 在VPC中创建Subnet，需指定IP段，并且指定所在的AZ，一个Subnet只能指定一个AZ，一个AZ可以容纳多个Subnet
• VPC中Subnet默认是可以相互访问的
• 新建的Subnet默认就是Private Subnet
• IGW(Internet gate way)是一个独立的组件配置在VPC上，使得VPC可以访问internet
• 在Private Subnet中配置了到IGW的路由后，就变成Public Subnet
• Public Subnet中的EC2还要再配置一个Public IP或者EIP就可以访问Internet
• 如果EC2可以访问internet，其关联的Security Group入站规则如果允许从internet访问，那么这个EC2就可以从internet中直接访问到
• 实践中我们把应用程序，数据库放在Private Subnet中，阻止从internet访问。把堡垒机和ALB（Application Load balancer）放在Public Subnet，允许从internet访问
• 配置了NAT路由的Private Subnet中EC2可以访问internet，但不能被internet访问到,因为这个EC2并没有IP，流量是通过NAT转换了，NAT有IP
• NAT gateway需要一个EIP（Elastic IP）并且把NAT配置在Public Subnet中
• 有时候Private Subnet中的EC2虽然不能访问外部internet，也需要访问特定服务如S3，RDS，这时候可以创建End Point
• 创建End Point需要选择Service种类，VPC,路由表，实际上会在选择的路由表上添加一条记录，前缀是vpce-
• 每个Subnet都必须关联一个路由表，创建的每个Subnet都会自动关联 VPC 的主路由表
• 创建Security Group时，只需指定VPC。之后可以把SG与EC2， RDS, VPC Endpoint相关连，用来控制这些服务的出入站IP和端口
• 所有 IPv4 流量 (0.0.0.0/0)，IPv6 流量 (::/0)

参考

https://aws.amazon.com/cn/vpc/faqs/

https://help.aliyun.com/document_detail/54095.html

https://docs.aws.amazon.com/zh_cn/vpc/latest/userguide/VPC_Subnets.html

https://www.bilibili.com/video/BV1wk4y1r7gX

https://www.iloveaws.cn/3707.html

https://zh.wikipedia.org/zh-hans/无类别域间路由

创建EC2

# https://docs.aws.amazon.com/zh_cn/zh_cn/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-rules.html

# 防止用户选择错误内容参数

# 每个模板规则由两个属性组成：

# 规则条件（可选）— 确定规则的生效时间。

# 断言（必选）— 描述用户可为特定参数指定的值。

AWSTemplateFormatVersion: "2010-09-09"

Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: 't2.micro'
      AvailabilityZone: 'ap-northeast-1a'
      KeyName: 'aws-ty-2022'
      ImageId: ami-03d79d440297083e3
      UserData:
        # 内部函数 Fn::Sub 将输入字符串中的变量替换为您指定的值
        Fn::Base64: |
          #!/bin/bash
          yum update -y

          timedatectl set-timezone "Asia/Shanghai"
          
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "/tmp/awscliv2.zip"
          unzip /tmp/awscliv2.zip -d /tmp/awslicv2
          /tmp/awslicv2/aws/install

          curl -sL https://rpm.nodesource.com/setup_14.x | bash -
          yum install -y gcc-c++ make 
          yum install -y nodejs
          
      Tags:
        - Key: Name
          # Jack---Jones
          Value: !Join ['-', ['Jack', '-', 'Jones']]

安装 kinesis agent

yum install -y aws-kinesis-agent

https://docs.aws.amazon.com/zh_cn/firehose/latest/dev/writing-with-agents.html

配置firehose

# 配置凭证
cat /etc/sysconfig/aws-kinesis-agent

# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=
# AWS_DEFAULT_REGION=

cd /etc/aws-kinesis/
cat agent.json

{
  "cloudwatch.emitMetrics": true,
  "kinesis.endpoint": "",
  "firehose.endpoint": "",

  "flows": [
    {
      "filePattern": "/tmp/app.log*",
      "kinesisStream": "yourkinesisstream",
      "partitionKeyOption": "RANDOM"
    },
    {
      "filePattern": "/var/log/kinesis-log*",
      "deliveryStream": "yourdeliverystream"
    }
  ]
}


# 修改为：

{
  "cloudwatch.emitMetrics": true,
  "kinesis.endpoint": "",
  "firehose.endpoint": "firehose.cn-north-1.amazonaws.com.cn",

  "flows": [
    {
      "filePattern": "/var/log/kinesis-log/*.log",
      # Delivery stream 的名称
      "kinesisStream": "KDS-S3-LogGenerator"
    }
  ]
}

重启服务并查看日志

service aws-kinesis-agent restart
tail -f /var/log/aws-kinesis-agent/aws-kinesis-agent.log

生成日志

mkdir -p /var/log/kinesis-log

参考

https://aws.amazon.com/cn/kinesis/data-firehose/faqs/?nc=sn&loc=5

生成日志程序

const LOG_LINE_COUNT = 5
// 名称，分类，年龄，语言，平台，是否免费
const gameList = [
  ["马里奥","动作","全年龄","日语", "Switch", 0]
  ["GTA5","暴力","18","英语", "Steam", 0]
  ["FIFA22","体育","9","英语", "Steam", 0]
  ["FIFA22","体育","9","英语", "Steam", 0]
]

function sleep(ms) {
  return new Promise(resolve => {
    setTimeout(resolve, ms)
  })
}

function *myGenerator() {
  let index = 1;
  while(true) {
    yield index++;
  }
}

const logGenerator = async() => {
  
}


logGenerator()

2022-05-29 22:10:51.123, "马里奥","动作","全年龄","日语", "Switch", 0
2022-05-29 22:10:51.243, "GTA5","暴力","18","英语", "Steam", 0
2022-05-29 22:10:51.312, "FIFA22","体育","9","英语", "Steam", 0
2022-05-29 22:10:51.567, "FIFA22","体育","9","英语", "Steam",
2022-05-29 22:10:51.123, "马里奥","动作","全年龄","日语", "Switch", 0
2022-05-29 22:10:51.243, "GTA5","暴力","18","英语", "Steam", 0
2022-05-29 22:10:51.312, "FIFA22","体育","9","英语", "Steam", 00

logdate timestamp,
name string,
category string,
age string,
lang string,
platform string,
isfree tinyint

CREATE EXTERNAL TABLE IF NOT EXISTS `my_db`.`log-game` (
  `logdate` timestamp,
  `name` string,
  `category` string,
  `age` string,
  `lang` string,
  `platform` string,
  `isfree` tinyint
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe' 
WITH SERDEPROPERTIES (
  'serialization.format' = ',',
  'field.delim' = ','
) LOCATION 's3://finley-athena-logs/'
TBLPROPERTIES ('has_encrypted_data'='false');

注意引号

3. 进到 管理控制台，选择启动虚拟机

选择ES2，创建一台服务器实例

注意勾选“仅免费套餐”，这里选择的是比较新的Ubuntu Server 18.04

4. 配置选1核1G就行，直接点击“审核和启动”
5. 没有密钥对的话，先生成一个，会下载一个pem格式的文件，保存好，待会儿登录服务器要用到
6. 如果是Windows系统，下载 MobaXterm 软件，根据提示连接主机

或者配置ssh config

Host aws-seoul
    HostName ec2-170-82-55.ap-northeast-2.compute.amazonaws.com
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/aws-seoul.pem

7. 登录成功

8. 依次执行下面的命令，会让你设置密码，端口和加密方式(默认)

sudo wget --no-check-certificate https://raw.githubusercontent.com/teddysun/shadowsocks_install/master/shadowsocks-go.sh
sudo chmod +x shadowsocks-go.sh
sudo ./shadowsocks-go.sh 2>&1 | tee shadowsocks-go.log

安装成功后记录好信息 打开酸酸乳客户端，填入信息

9. 连接成功！

10. 如果无法连接，在AWS后台添加安全组，编辑入站规则，端口填写刚SSR设置的端口 在EC2控制面板，进入到了实例的安全组设置中。 在左下部点击 “入站” 标签页，并点击编辑。点击 “添加规则”，添加的规则中“类型”“协议” 都不需要改动。“端口范围”这里填上我们前面设置的端口，“来源”下拉框中选择“任何位置”。

11. 接下来还需要给服务器申请一个固定IP。点击弹性IP -> 分配新地址 -> 操作 -> 关联地址 。选择自己的实例并关联。

参考：https://www.cnblogs.com/MingyaoZheng-blog/p/9786306.html

例如，当前安全组、来自同一 VPC 的安全组或对等 VPC 的安全组。 这允许基于与指定安全组关联的资源的私有 IP 地址的流量。这并不会将指定安全组的规则添加到当前安全组。

图形化工具：

• Windows平台： http://s3browser.com/

连接 bucket

• mac平台

推荐Transmit

命令行工具(awscli)：

• Windows平台：

https://s3.amazonaws.com/aws-cli/AWSCLI64.msi

• Mac平台：

参考： https://github.com/aws/aws-cli

sudo easy_install pip
sudo pip install awscli --ignore-installed six
# 根据提示输入 Origin, AccessKey, AccessSecret
aws configure

AWS Cli 操作文档：https://docs.aws.amazon.com/cli/latest/reference/s3/cp.html

开放访问权限

默认情况下文件对象和上传的文件不能公共下载的，比如访问 https://s3-us-west-1.amazonaws.com/yourbucketname/README.md 会提示 access deny。 如果需要对某目录下的文件开发公共访问权限，可以这么干， 打开 策略生成器

点击 generate policy,复制 json配置内容，粘贴到存储桶策略中

https://www.youtube.com/playlist?list=PLEiEAq2VkUULlNtIFhEQHo8gacvme35rz

https://www.bilibili.com/video/BV1vW411G75e

有用文档

• 国际区和中国区产品差异
• 全球边缘网络

假设镜像源站点为：https://example.com/static，请求的对象 key 为：images/logo.png， 那么回源地址为：https://example.com/static/images/logo.png。

搜索 [https://hexo-blog.pek3b.qingstor.com] 替换为 [https://hexo-blog.pek3b.qingstor.com]

https://pek3b.qingstor.com/hexo-blog/upload_images/71414-ee2cca876c285107.png?imageMogr2/auto-orient/strip|imageView2/2/w/1240

替换为

https://pek3b.qingstor.com/hexo-blog/20200720101157e0cb75757.jpg

股票名词

可转债

新人必读，说清可转债及买卖操作

工具及网站

工具及网站

之所以敢跟你聊它，是因为它几乎零风险，手续费低，收益率又比余额宝高，在一些特殊的时间点上还可能有很高的年化收益率，是我们普通人类的好朋友。

逆回购是个什么东西呢？它的全称是「债券质押式逆回购」。

简单来说，就是你在证券账户里借给别人一笔超短期贷款。谁把你的钱借走了你是不知道的，但他会用他所持有的合格债券来作为抵押。

在借款时间到期后，他会把本金和利息一起还给你，打回你账上。

在A股市场上，逆回购产品是可以像普通股票一样交易的。你需要的就是开有股票账户，以及账户里至少有1000.10元。

其中1000元是逆回购的最小参与金额，1毛钱是参与这笔逆回购的手续费。

一笔逆回购的收益是这么计算的：收益=交易金额*收益率*计息天数/365-手续费。手续费很低，最低是万分之零点一，最高也就是万分之三。

上交所有9个逆回购品种，分别是1天、2天、3天、4天、7天、14天、28天、91天、182天的逆回购，每一个都有自己独立的交易代码； 深交所有11个品种，比上交所多了63天和273天的2个品种。它们的名称和交易代码我放在文稿里，你可以备用。

你借出去的钱什么时候能回来呢？逆回购资金的到账日是T+N+0，提现日是T+N+1。N就是逆回购天数。

你逆回购1天，那么当天卖出，下一个交易日的开盘前，资金回到你的账户里，你可以进行股票交易，但是不能提现，要再过一天才能提现转出到自己的银行卡上。

上交所和深交所的逆回购产品参与门槛还不太一样，上交所的资金起点是10万，深交所是1000块，上交所产品的参与门槛高，参与人数也就比深交所要少。

所以同样期限的产品，上交所的利率有时会更高一些。比方说，同样在我写稿子这一天，11月23日，上交所的1天期逆回购产品GC001的收盘价格是2.595元，这就是年华收益率2.595%的意思；深交所的1天期逆回购产品R-001的收盘价格是1.99，年华收益率1.99%。怎么说呢，丰俭由人吧。

如果你账户里有笔1万块的闲钱想要借出去一天，你可以在交易日的15点半之前，在你的股票交易软件上输入131810，这就是R-001的交易代码，然后选择「卖出」10手，1000块一手，这笔钱就算借出去了。如果明天也是交易日的话，明天你就不用另外再进行反向操作了，在股市开盘之前，这笔钱就会连本带息回到你的账户上，不影响你明天买股票。

同样道理，你也可以卖出其他不同出借天数的逆回购产品。

你可能注意到刚才我说了一个奇怪的词，「卖出」。我们什么都没有，为什么不是买入这个逆回购品种呢？

话说到这儿，我为了给你解释为什么是「卖出」，捎带也要向你解释一下「逆回购」这个别扭的词。借钱就说借钱，为什么要用「逆回购」这个别扭的词呢？回购个什么？我来试着粗暴地解释一下：

在金融领域，「回购」这个词其实大家是跟着中央银行用的。央行发行的最基础产品是现金。所以，当央行想要收紧流动性，从商业银行收回现金这种产品的时候，这个操作就叫「正回购」，也就是相当于央行作为出品方要把现金这种产品买回来。那「逆回购」呢？就是把更多的现金产品投放到市场上。

所以我们只要记住，回购这个词的对象是「现金」。正回购就是回购现金，逆回购就是卖出现金，就可以了。

那正回购、逆回购里，央行和商业银行买卖现金这种产品的时候，双方用什么付账呢？暂时不付账，先欠着，但需要一个抵押品，这个抵押品通常是国债或者其他的合格债券。

拿一笔7天期限的逆回购来说，比如央行放出100亿现金给商业银行，银行你就要给我抵押品，这个抵押品通常就是国债。

7天后到期了，商业银行要把从我这儿拿走的100亿现金还回来，同时再加一笔利息。央行再把你押在我这儿的国债解除抵押，咱们就两清了。

这是央行的玩法。而我们普通人类虽然没有那么大的资金量，在股票交易平台上也是可以小规模体会一下当央行的感觉的，我们在放贷的时候，相当于也是在把现金卖给借款人，也是在给市场释放流动性。

一般来说，一笔逆回购交易，涉及三方参与者：

第一个是逆回购方，就是我们这样，手里有闲置现金，想要让它增值的人；

第二个是正回购方，也就是借款人，他手里有债券，现在着急用现金，想抵押债券来借钱。

多说一句，想做正回购的准入门槛是很高的，个人的话名下金融资产不能低于300万。还需要跟证券公司签特别的委托协议，今天我们就先不谈了。

第三个参与者，是监管和中介平台，在A股市场上就是上海证券交易所和深圳证券交易所。借款人的债券就抵押在交易所对应的电子平台上。

这个作为抵押品的债券，通常是国债或者企业的信用债，这些债券根据自己不同的信用等级，会折算成交易所承认的「标准券」。

有了这个抵押品，逆回购就几乎没有风险了。哪怕借款人真还不出钱，你的本息也是国家清算机构先垫付给你，然后它再去找借款人算账的。

那我为什么要选在新年前后提醒你特别注意这个品种呢？这是因为，在月底、年末、长假前后这种特殊时点上，市场的资金容易相对紧张，逆回购的年化收益率就会明显走高。

拿今年来说，10月9日也就是国庆节长假刚过，R-001的年化利率一开盘就冲到了6.2%，这背后一定是有借款人很急很缺钱，所以把利率开到了非常高。

我往回翻了翻数据，发现R-001在2016年2月27日的时候，年化收益率到过40%。

那什么时间的收益率会比较高呢？前面说了，在一年里，月末、年末、长假前后，因为这些时间点是银行要面对准备金率考核、或者企业要短期拆借的时候，市场上钱荒，所以每到这个时候，你就可以瞄一眼逆回购产品们。

如果你已经拿定主意在具体某一天里操作逆回购呢，那你也要注意了，一般上午的时间收益率会比下午高，因为急缺钱的借款人上午就把钱借走了。所以啊，具体到今年年底，要是12月31日是最后一个交易日，我建议你30号就开始留意一下逆回购的利率价格，如果合适的话就可以出手了。拿2019年的12月30日来说，深交所的1天逆回购产品R-001的最高年化收益率到了3.52%。

但你倒也不至于把茅台股票给卖了去操作逆回购，这个不值当的，把闲钱放进去就可以了。对我们普通人类来说，逆回购保本保收益，收益通常来说比余额宝高一点。

另外，长期投资也没必要考虑逆回购，用它来做1到7天的短期现金管理就可以了。逆回购的特殊吸引力主要是来自特殊时间点的收益率飙高，但在普通岁月里，逆回购的年化利率也就是2%到3%之间，吸引力不算大。

总之，周末或者假期之前的一两天，要是你的股票账户里有闲钱，可以把它扔进逆回购里去。对了，逆回购的交易时间比A股要长半小时，下午3点半才结束，所以平时股票收盘之后，你也可以把闲钱扔进去。熟悉逆回购的同学，肯定知道我还有好多细节和技巧没有来得及一一解释清楚，比如怎么选操作时间的收益率最大呀等等，所以也请各位学霸把你的秘笈敲在留言里，造福一下刚刚听说这个产品的同学。

购买方法如下，依然用东方财富举例，在「天天宝」下面就可以看到「国债逆回购」的选项，进去之后可以看到「沪市」和「深市」两个选项，门槛不同，一个是 10 万，一个是 1 千，酌情选择就好（选收益率高的）。

在这里，我们可以看到在12月12日 28天期的收益率达到了 5.1%，因为刚好跨过了年末这个关口，所以收益率也是不错的。

重点再强调一遍，每逢月末、季度末和年末，一定要看一下「国债逆回购」常常有惊喜哦。

在书房2017年5月的《看得懂与看不懂》一文中，我曾写道：「当你能够回答下面四个问题时，就代表看懂了这家企业」：

• ①这家公司靠销售什么商品和服务获取利润？
• ②它的客户为何从它这里采购，而不选其他机构的商品或者服务？
• ③资本的天性是逐利。眼看这家公司坐享丰厚利润，为什么其他资本没有提供更高性价比的商品或服务，抢占了它的市场份额，或逼迫它降低利润空间呢？ （更高性价比，即可以是同样质量/数量+更低价格，也可以是同样价格+更高质量/数量）
• ④假设同行挟巨资，或者其他产业巨头挟巨资参与竞争，该公司能否保住乃至继续扩张自己的市场份额？ 其实这四个问题就是很多高人喜欢说的“商业模式”，老唐只是把它说的简单粗暴，显得稍微不那么高大上了

当我们能够回答以上四个问题后，就可以⑤给企业估值了。也就是说在我看来，研究一家企业的框架，就是上述①②③④⑤。 不管从哪个角度切入具体某家企业，总之万变不离其宗，就是想办法回答上述五个问题。

接下来，老唐以福寿园这只刚刚接触过的企业为例，分享一下从接触一家企业到得出研究结论，应该做的工作和大体的步骤，供朋友们参考。 需要提醒的是，老唐也是刚刚接触这家企业的财报，且由于手边琐事影响，到今天为止连财报都还没有看完。

所以，本系列主要谈框架和方法，是示范老唐本人所用的捕鱼之法（且不见得有多高明），不是介绍这条鱼。 尤其是文章中，完全可能包含老唐错误或片面的认识——烦请发现者直率指正，谢谢！ 请千万不要将本系列文章理解为老唐建议在此位置买入福寿园，切记切记

利益声明：截止此刻，老唐本人及本人控制的账户，持有福寿园的数量为0。

一般来说，老唐喜欢投过去已经被证明能够赚到丰厚利润，且经过分析后，认为未来将继续赚到更丰厚利润的企业，不喜欢那些「虽然现在不赚钱，但是未来可能非常美好」的梦想窒息类企业。

因此，我通常用ROE作为筛选企业的第一项标准。

ROE是净利润与账面净资产的比值，它代表企业对掌控的资源的运用能力。

高的ROE说明企业利用当前掌控资源，获取了远超社会无风险收益率的回报水平。

高ROE是投资者的路标和指示牌。它的作用是指引我们去发现某种没有被记录在资产负债表、却能给公司带来收入的「经济商誉」资产。 具备高经济商誉的企业，往往都有某种竞争优势企业，值得投资的概率很大。

——注意，这个观点，老唐在2018年3月以《Roe指标的正确应用》和《Roe指标的正确应用（续）》为题，发表在书房。

这角度是老唐原创。以我的阅读经历，我从未见过（或至少没有在中文世界里见过）其他人做过如此阐述。

以福寿园2019年年报为例，公司净资产46亿（为行文简单，数据四舍五入，下同），当年净利润7.4亿，roe≈16%。 归母净资产40亿，归母净利5.8亿，归母roe≈15%。

还不错，但也不算特别出彩。

同时我们会发现少数股东权益5.4亿，带来约1.6亿少数股东损益，对于少数股东而言，roe≈1.6/5.4≈30%。

这意味着要么有关联人掏公司腰包，要么是少数股东带有某种没有体现在财报上的特殊资源。究竟是什么，暂且存疑。

老唐在《手把手教你读财报》32页第一行写过：

「经验丰富的投资者，首先看的报表一定是资产负债表。实际上，他们也许会翻阅利润表和现金流量表来相互印证，但最终总是聚焦在资产负债表上。」 长期跟踪书房的朋友们都知道，几乎分析任何企业，老唐都会首先搞出一份简化的资产负债表，福寿园也不例外。 福寿园2019年度资产负债表简化处理结果（单位人民币亿元）：

读过《手把手教你读财报》的朋友，看到这份简化报表后，头脑里至少应该反映出以下企业特征：

• ①企业几乎没有有息负债；
• ②企业即占用上游资金，也占用下游资金，在产业链上相对强势；
• ③应收账款的数额很少，企业销售主要是预收或现款现货；
• ④公司有大量现金沉淀，账面类现金资产超过净资产的一半；
• ⑤商誉显示，企业发生过一次或多次溢价收购。

备注：当年营收18.5亿，有1亿应收账款。 在阅读过程会发现，这少量的应收款，是因为火化机销售、园林和景观设计以及向地方民政主管部门提供服务所产生的。 创造公司年度营业利润97%的墓地业务，几乎不产生应收账款。 沿着这五个要点展开思考，顺理成章地就会产生以下问题：

①企业的主营业务是卖墓穴，类似于房地产卖房子。为什么房地产企业普遍高负债，高杠杆运营，而福寿园却近于无杠杆状态运营。 它们之间存在什么样的差异？ ②净资产回报率超过15%，盈利几乎全部为现金的生意，为什么要保留大量资金在手，且几乎完全不借款。 是什么制约着公司利用更多资本去获取更多利润的能力？ ③企业为什么通过溢价收购来扩张，收购的出价是否有损害小股东利益的情况？ 在上市公司下属非全资子公司中占少数股份的合作伙伴，凭什么可以得到比上市公司股东更高的回报率？ 接下来就可以带着问题去阅读财报全文了，解开上述疑问的过程，就是我们通常所谈到的“企业研究”。 后文我不再一一引用原文和出处了，直接说我从财报阅读过程中的思考，大体考虑分为供应端、需求端、行业竞争、政策风险、发展空间、管理层风险以及估值前要做的工作七个角度展开。 不过，大家都知道，我写东西是兴趣驱动，不保证有兴趣和时间写完。也不保证一定从这七个角度，或只从这七个角度写。大家有多少看多少吧 从供应端看，这门生意和房地产似乎很像，都是从政府手中拿地、然后加工，卖给客户。

但按照我粗读财报的印象，它和房地产生意至少有以下五大区别： 第一，土地权属。 房地产行业是从政府手中买下土地50到70年的使用权，投入资金建房，然后将土地使用权和房屋一起卖给客户，结束。 未来若可以通过缴费延长土地使用权，由客户本人缴费，土地也归属于客户本人。 绝大部分城市商品房，客户支付的购房款，名义上是购“房”款，实际上主要款项是购买房子脚下的土地（以清水房论，房屋的建安成本大多介于800~3000之间，地区差异不大）。 严格的说，收钱卖掉房子后，房地产公司和这块地、地上的房产及其中的居住者，已经切断联系、分道扬镳了。 福寿园是从政府手中获得土地使用权，建墓穴，然后将墓穴的使用权租用给顾客。 注意土地使用权并没有转让给客户。客户购买的墓穴是不附带土地证的。 未来如果可以通过缴费或其他方式延长土地使用权，由福寿园缴费，土地继续属于福寿园。 如果同样用房子来类比说明的话，福寿园的客户相当于只是一次性交清了20年房租及物业费。 房子和脚下的土地，法律上的所有权依然属于开发商（福寿园）。

第二，后续黏性。 正因为上述土地权属问题，无论是躺在墓穴里的逝者还是其后人，将长期的、无可选择地与福寿园保持紧密的联系和商业往来。 如果未来不再续交租金的话，房东（福寿园）是有权力将租客（骨灰盒）驱逐，并将房子重新租给其他房客的。 （几十年后放弃缴费并失联的相关风险和处理方式，后面发展空间部分再聊）。 虽然房地产开发商一般也同时提供物业服务，但房地产行业的物业服务，本质上讲是任何主体都可以提供的，是红海里近于无差别的竞争。 而且物业管理工作琐碎复杂，对人力资源需求很大，很难有巨大的利润空间。 所以截至目前为止，房地产企业的物业部门，更侧重于为房屋销售服务，本身并没有什么利润甚至是赔钱的（当做销售费用看待）。 福寿园提供墓穴租用后，后续的物业服务只能由福寿园提供。 总体来说，墓园的维护工作，变量很少（享受服务的基本不再诞生新要求），大体标准化且极少有紧急事件发生，总体满意度常常超预期。 对此类物业服务费用，通常顾客是在办理“入住”手续时，就一次性预缴10~20年的费用。 这笔费用少则数百元/年，多则数千元/年，看似不高。但由于墓穴通常占地就1~3个平方，每平米收费标准常常是住宅物业标准的数倍甚至数十倍。 该款项中的少部分由监管部门监管使用，专项用于墓园管理，大部分收下就是利润。 第三，囤地待涨。 房地产行业的囤地行为，是政府层面打击的。 比如2020年9月成都市高新区财政局就下过一份文件，禁止高新区内金融机构向李嘉诚旗下的和记黄埔成都公司及其项目提供新增融资、贷款，禁止区内金融机构向和记黄埔进行重大资产重组提供帮助，原因是该公司存在捂地、捂盘等不良行为。 墓园的捂地行为几乎是政府要求的。 几乎所有的地区都有限制顾客购买墓穴资格的相关政策，例如去世后才能买，年龄超过70或80才能买，重病才能买，一人去世提前预留其他家庭成员墓穴才能买等等。 总之原则就是：只有在被证明有需要的时候，才允许购买，尽可能地禁止提前购买，同时也禁止转让。 而墓园土地（标准用语殡葬用地），是政府一次性划拨或出售给墓园经营者的，这就必然导致一种房地产行业里被禁止的获利模式，在墓园却是合理合法的，那就是：捂地。 而且奇妙的是，墓园土地可以超出土地使用权最后期限销售。 比如福寿园有些墓地的使用权已经卖超（意思就是假设土地使用权截止日期是2020年12月31日，但公司可以今天把墓穴卖给顾客，且将管理费用收到2040年），但政府相关部门出具书面函件确认不违规。 基本可以确定，未来土地到期后，适当续费就可以继续使用（续费的标准问题，我们放在政策风险部分谈）。 正因为这样，福寿园的土地大部分是未开发状态（即捂地）。 毕竟伴随着收入水平的提高，未来墓穴的价格几乎可以预期必然上涨（此处投资者可以做公司上市以来，各个墓园平均墓穴售价的数据统计和走势图）。 成本不变、售价上涨，无疑会给公司带来更多利润。 捂地也是福寿园账面ROE不够高的原因。 举个简化的例子说，就是公司买下100单位土地，成本全部计入ROE的分母。 产生的利润主要有一明一暗两块，明的是当年销售出去的5份土地带来的，记录在利润表里，是计算ROE的分子。 暗的是手中所捂的95份土地当年的增值，不记录在利润表里，不作为ROE的分子。 扩张过程中，不断有资本从产生利息收入的货币基金或金融资产，沉淀为只产生暗收益的墓地资产。正是这个原因，导致即使在超高毛利率的销售数据下，ROE看上去却并不怎么诱人。 第四，土地的主要获取方式。 房地产行业竞争者众多，土地拍卖是各地方政府主要财源，政策监管严格，地价高昂。 殡葬用地是受限制用地，是在当地民政部门和国土部门在按照死亡人数预期，规划出合适的数量后，划拨或者挂牌出让。 地方政府和媒体对于该类土地的关注度不够，接受划拨或者参与竞争的同行很少，土地基本上无需高价获得。 今天我们登陆自然资源部不动产登记中心旗下的中国土地市场网，查询殡葬用地，我们会发现绝大部分依然是划拨方式，拍卖和挂牌出让占比至今仍然极小。

正因为划拨方式为主，所以市场参与者基本上就是现有的业内人士。 说透彻一点，就是围绕在民政部门周围，长期与殡葬行业相关的小利益团体。 其他投资主体，根本无法预期能否获得经营原材料（殡葬用地），不可能提前进入这个行业去等地。结果就是真有地的时候，也很难及时参与竞争。 由于土地的划拨方式，加上殡葬用地主要以不适宜从事其他用途土地为主，所以大部分土地低廉的超乎想象。 比如我们点开上面截图的链接，看最近的土地划拨价格（只有部分划拨土地披露成交价格）： 10月17日这块地，4.0481公顷（1公顷=15亩=1万平米）。位于新疆和田市外约75公里处，价格81620元，折合每亩1345元，每平米2元钱（你没有看错单位，就是2元钱/平米）。 但若是拍卖，成交价格立刻就不一样了。 还是上图，第一个拍卖出让的平阳县那块地5.3263公顷（53263平米=80亩），位于浙江温州市外约50公里处，成交价格4887万元，折合61万/亩或917.5元/㎡。付款要求为2020年11月11日付一半，2020年12月12日付一半。 当然，地价还受区域购买力和土地等级差异影响，但两地的墓穴价格差异不可能夸张到数百倍。区域购买力和土地等级解释不了大部分价差，只能归结为拿地模式的差异。 第五、土地供应量。 房地产的土地供应是源源不断的。政府在不断拓展城市空间，不断将生地变成适合房地产开发的熟地。 不仅如此，每一块土地的开发行为本身，实际上也在催熟隔壁地块的供应。 任何房地产商的每一份投入和努力，吸引到买房和入住客户的同时，也抬高着隔壁地块的价格，并给自己招来竞争对手。 这也是老唐五六年前于某论坛分享过的困惑，2017年6月27日的《生人勿近诞生记》一文引用过： 老唐对地产一直不感兴趣，原因是很多年前，一个做地产的熟人，曾经这样吐苦水：

3000万买一块地，求爷爷告奶奶地走通各个环节，起早贪黑担惊受怕的八个杯子五个盖，总算把房子修起来卖的七七八八了，一算账能赚好几千万。

但赚了钱，不能就这么回家抱娃吧，还得买地继续滚啊。隔壁去一看，本钱加上利润，也就勉强购买隔壁差不多大一块地。

这搞房地产的，终极形态到底是什么样子呢？

现金买地—建房换现金—现金买地—建房换现金—现金买地……周而复始。最终留给股东的，不知道是一堆现金，还是一大片荒地？

如果始终不产生或者很少产生现金流，投资者的回报，必须寄期望于牛市来临，这很难让我夜夜安枕。

殡葬用地不同。 每个地区人口的年度死亡人数，是有基本稳定的历史统计数据的。未来的预期，也可以根据年龄结构和平均寿命做大致准确的计算。 政府会根据这个计算，在土地规划中，规划出未来N年需要的殡葬用地，通过划拨或出售的方式释放，此时土地成本被提前锁定。 然后在该规划基本满足需求的时间跨度里，该城市很难再释放新的殡葬土地。 墓园经营者的每一分投入，除了提高自己所捂土地的附加值外，不会给自己增加竞争压力。 所以，从土地供应量角度看行业格局，墓园和房地产行业的原材料供应有天壤之别，这也决定了两者的经营方式有着巨大的差别。 当然，这并不意味着彻底杜绝竞争。 毕竟农村荒地、同区域其他墓园，甚至包括一些灵骨塔、庙宇、道观、商品房或小产权房屋以及天葬海葬不葬等多种方式，都有可能成为曲线的行业竞争对手。

MoneyWiz

投资者关系互动平台

深交所

问财

基金

蛋卷指数选基金

每张可转债的背后都对应的一家在A股上市的公司的股票，这个股票就叫做正股，比如深南转债对应的正股是深南电路。如果现在深南电路的股价是10元，则10元就是正股价，公司可以和股民约定，比如半年以后，可以拿着股民购买的可转债以12元每股的价格换成股票，这个12就是转股价，当然股民也可以选择不换股票，一年后直接拿连本带息。

这里面会有几个结果：

1. 一年后公司股价涨到15元，超过了转股价，股民依然可以以12元的价格把可转债兑换成股票，这样股民赚到了15-12=3的差价

2. 一年后公司股价跌到了5元，这时候显然没人去转换，因为换了就亏了，此时股民可以拿着不动，就等到期

所以可转债既有债券的属性，也有股票的属性，所以有人说可转债相当于保本的股票

解读

发行可转债必须公开一些信息，挑些不容易理解的解读下：

1. 可转债的利息一般第一年最低，越往后越高，一般是6年，如上图第一年利息0.5%，最后一年3%，为了吸引投资者，大多数的转债都会在到期日前被收回。

2. 转股溢价率：转股价/ 正股价 -1 是衡量可转债是否值得买的重要指标，一般来说，越低越好，最好是负数，这样上涨的概率会更大

3. 债券评级，3A是最高级，安全性高，但收益水平也比较低

需要考虑的问题

1. 作为债券，他的利息很低，一般1%的利息非常低，抵不过通货膨胀，换成股票赚差价是上选
2. 上市公司还不起可转债怎么办？目前监管还是比较严格的，发债公司一般是优质公司，历史上没有发生过违约的可转债

注意事项

阅读募集说明书看清条款

转股价格的向下修正条款 如果正股价持续在转股价85%以下10到15天，上市公司有权下调转股价 目的：刺激股民买可转债 坏处：转股过多，可能会摊薄股东权益 这个是上市公司的权利，不是强制性的

强制赎回条款 一个非常美妙的条款 正股价维持在转股价130%(具体数值根据募集说明书)以上15个交易日，公司将以债券面值加应计利息的价格赎回可转债。 此时，可转债的持有人已经至少赚了30%的利润了

上市公司的终极目的是让全部股民全部转股，从债主变为股东，这样上市公司就不用还钱了，为达到此目的，需要正股价远高于转股价

有中国特色的赎回条款 回售期内的正股价持续低于转股价70%达30天，上市公司必须以债券面值加上应技利息的价格赎回可转债，大概101-103元 这个是义务，强制执行，为了保护股民，相当于硬性保底

四大要素

1. 下调转股价和回售条款都是为了熊市准备的
2. 强制赎回是为了牛市和反弹准备的
3. 在牛市，正股价上涨，可转债的价格也会跟着上涨，不管你是卖出可转债还是转股继续持有股票，都可以享受收益。
4. 在熊市，正股价下跌，可转债可以向下修正转股价，且战且退，一旦市场出现反弹，可以强制赎回条款来获得利益

实操

以东方财富APP为例，需要开户。 点新债申购

查看可购买的可转债

选择一个可转债，点申购，输入申购数量，默认10000，点确定，等待即可，一般1-2天就有结果，中签会收到短信通知，告诉你中签数量，比如这里我中了10张中投国债，需要交纳1000，只要保证可用资金里有就行了。

申购流程及常见问题

参考

• https://www.bilibili.com/video/BV1vJ411Y7FK
• https://xueqiu.com/1374409802/95650556?tdsourcetag=s_pctim_aiomsg
• https://zqhd.eastmoney.com/Html/other/tradeshare/bond/html/subguide.html

总的来说，两个方案各有利弊，基金账户方便，比较适合小资金，股票账户交易快速、费用低，比较适合大资金。我建议按照资金多少来决定，如果资金比较少（50 万以下）可以选择基金账户，如果资金量比较大推荐用股票账户。

基金账户 App 在申购、提现上有金额限制，想要完成大笔交易需要重复很多次；股票账户则没有限制，交易几百万也就分分钟；

股票账户的交易规则，必须以 100 份为单位购买，对小资金不友好，不能自由选择金额；

资金量越大，对佣金越敏感，以 50 万为例，股票账户（0.03% 佣金）和基金账户（0.12% 佣金）的手续费差异可以达到 450 元，如果资金更多的话，影响也会等比放大。

需要将需要部署到集群，但流水线环境不方便直接访问目标K8s集群，可以在K8s里安装runner

然后runner注册到gitlab站点，完成部署操作

GitLab Runner Helm Chart

helm repo add gitlab https://charts.gitlab.io
# 根据 gitlab 站点版本，挑选合适的 helm chart 版本
helm search repo -l gitlab/gitlab-runner
# 下载并解压
helm pull --untar gitlab/gitlab-runner --version=0.64.3
cd gitlab-runner
# 创建一个新的values文件，用来覆盖默认配置
vi values-nfm-dev.yaml

内容如下：

gitlabUrl: https://gitlab.xxxx.cn/
runnerToken: "glrt-HVu1xxxxxyd"
tags: "aws,eit-nfm-dev,executor-k8s"

rbac:
  create: true
  clusterWideAccess: true
  serviceAccountName: gitlab-runner
  ## Define list of rules to be added to the rbac role permissions.
  ## Each rule supports the keys:
  ## - apiGroups: default "" (indicates the core API group) if missing or empty.
  ## - resources: default "*" if missing or empty.
  ## - verbs: default "*" if missing or empty.
  ##
  ## Read more about the recommended rules on the following link
  ##
  ## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#configure-runner-api-permissions
  ##
  rules:
    - resources: ["configmaps", "pods", "pods/attach", "secrets", "services"]
      verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]
    - apiGroups: ['', 'apps', 'networking.k8s.io']
      resources: ["*"]
      verbs: ["*"]
      # resources: ["deployments","services", "secrets","configmaps", "pods","pods/exec","nodes"]
      # verbs: ["list", "create", "patch", "delete"]

runners:
  # runner configuration, where the multi line string is evaluated as a
  # template so you can specify helm values inside of it.
  #
  # tpl: https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-tpl-function
  # runner configuration: https://docs.gitlab.com/runner/configuration/advanced-configuration.html
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        service_account = "{{ .Release.Name }}"
        image = "public.ecr.aws/docker/library/node:lts-alpine"
        privileged = true
        allow_privilege_escalation = true 
        helper_image = "public.ecr.aws/gitlab/gitlab-runner-helper:alpine3.19-x86_64-latest"

安装 runner,

• values-nfm.yaml 要放在后面这样可以覆盖values.yaml
• upgrade --install 如果不存在就安装，存在就更新

helm upgrade --install --namespace gitlab-runner --create-namespace -f ./gitlab-runner/values.yaml -f ./gitlab-runner/values-nfm.yaml gitlab-runner ./gitlab-runner
k get pod -n gitlab-runner

典型的流水线例子如下：

stages: 
  - create-image
build-image-job:
  stage: create-image
  image: docker
  services:
    - docker:dind
  script:
    - echo $CI_REGISTRY_PASSWORD | docker Login -U $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
    - docker build -t $$CI_REGISTRY_IMAGE/myapp:1.2-
    - docker push $$CI_REGISTRY_IMAGE/myapp:1.2-
    - docker images

为什么非得定义 services 呢？

这里先从Docker的 C/S 架构讲起

Docker 的 C/S（客户端/服务器）架构

Docker 采用典型的 C/S（客户端/服务器）架构

┌─────────────────┐      REST API       ┌─────────────────────────────┐
│   Docker 客户端  │<─────────────────── │      Docker 服务器           │
│   (docker CLI)  │    HTTP/UNIX Socket │     (Docker Daemon)         │
└─────────────────┘                     │   ┌─────────────────────┐   │
                                        │   │  Containers         │   │
                                        │   │  Images             │   │
                                        │   │  Networks           │   │
                                        │   │  Volumes            │   │
                                        │   └─────────────────────┘   │
                                        └─────────────────────────────┘

组件说明

客户端 (Client)

• Docker CLI (docker 命令)
• Docker API 客户端
• Docker Compose
• 其他第三方工具
• 服务器 (Server)

服务端 Docker daemon (dockerd)

• 容器运行时 (containerd)
• 存储驱动
• 网络驱动
• 插件系统

工作流程

1. 用户输入 docker 命令
2. Docker CLI 解析命令
3. 通过 API 发送请求到 daemon
4. Daemon 处理请求
5. 返回结果给客户端

示例：运行容器:

docker run nginx

│
├─► 1. CLI 解析命令
│
├─► 2. 发送 API 请求到 daemon
│
├─► 3. Daemon 检查本地是否有镜像
│
├─► 4. 如无镜像则从仓库拉取
│
├─► 5. 创建并启动容器
│
└─► 6. 返回容器 ID 给客户端

客户端环境变量

# 指定 Docker daemon 地址
DOCKER_HOST=tcp://remote-host:2375

# 指定 TLS 设置
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/path/to/certs

优势

• 客户端和服务器可以分开部署
• 支持远程管理
• 便于第三方集成
• 支持 TLS 加密
• 可以通过 API 开发自定义工具

常见使用场景

本地开发:

docker ps

远程管理:

# 通过 TCP 连接远程 daemon
docker -H tcp://remote:2375 ps

进一步

深入了解镜像 docker 和 docker:dind 的具体区别

打开 https://hub.docker.com/_/docker 仔细阅读

发现 docker镜像 docker:28, docker:dind, docker:28-dind 是等价的

而 docker:cli, docker:28-cli 也是等价的，只不过 tag 不一样

进一步查看他们的 Dockerfile: docker:dind 和 docker:cli 直接扔给 Gemini 帮忙分析对比，对于 Docker28 版本的 Dockerfile 得出以下结论：

docker:cli

• docker:cli 是基于 alpine:3.21
• docker:cli 安装的有 docker 命令行工具, buildx插件,docker-compose插件

docker:dind

• docker:dind 是基于 docker:cli, 包含了 docker:cli 的所有功能,并在此基础上增加了运行 Docker daemon 所需的额外组件
• 额外组件有 git, iptables(IPv4 防火墙), ip6tables(IPv6 防火墙), openssl(SSL 支持), xz, zfs, pigz, e2fsprogs 等文件系统工具
• 额外组件还有 dockerd (Docker daemon), containerd, ctr, runc 这些容器运行时工具
• 暴露端口 EXPOSE 2375 2376 # Docker daemon API 端口
• 特有的存储卷, VOLUME /var/lib/docker # Docker 持久化存储

使用场景

• docker:cli:

  • 适用于只需要执行 Docker 命令的场景
  • 需要连接外部 Docker daemon

• docker:dind:

  • 适用于需要完整 Docker 环境的场景
  • 可以独立运行容器
  • CI/CD 环境中的容器构建

网络配置

• docker:cli:
  • 无特殊网络要求
• docker:dind:
  • 需要暴露 Docker daemon 端口
  • 需要配置网络隔离

参考

https://docs.gitlab.com/ci/services/

https://docs.docker.com/reference/cli/dockerd/

动态名称

script:
    # 动态生成时间戳
    - export TIMESTAMP=$(date +'%Y%m%d%H%M%S')
    # 动态生成文件名
    - export ARTIFACT_NAME="${CI_JOB_NAME}-${TIMESTAMP}"
artifacts:
    # 使用动态生成的制品名称
    # 不生效，实际是 default.zip
    name: $ARTIFACT_NAME
    paths:
      - "/target"

参考：https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1664

cache

Use separate caches for protected branches

By default, protected and non-protected branches do not share the cache. However, you can change this behavior.

so we run pipeline on cmss-web2321 branch, the cache url will be like http://minio.minio:9000/gitlab-runner/gitlab-cache/runner/-z_CiEf6/project/441/cmss-web-non_protected but on feature branch, the cache url will become to http://minio.minio:9000/gitlab-runner/gitlab-cache/runner/-z_CiEf6/project/441/cmss-web-non_protected

you can have all branches (protected and unprotected) use the same cache.

Clear the Use separate caches for protected branches checkbox.

script

use !reference to combine script

stages:
  - demo

.setup:
  script:
    - echo creating environment

.teardown:
  after_script:
    - echo deleting environment

demo-reference:
  stage: demo
  script:
    - !reference [.setup, script]
    - echo running my own command
  after_script:
    - !reference [.teardown, after_script]

output result:

creating environment
echo running my own command
deleting environment

限制分支创建

• 只有 maintainers 才能合并代码到 develop 分支
• 只有 开发者才能合并代码到 feature 开头的分支

使用 $CI_JOB_TOKEN

project1

create_artifacts:
  stage: demo
  when: manual
  artifacts:
    paths:
    - newfile.txt
    expire_in: 1 week
  script:
    - CHILD_PROJECT_ID=493
    - CHILD_REF_BRANCH_NAME=feature/cicd
    - echo "CI_JOB_ID:$CI_JOB_ID" >> newfile.txt
    - echo "CI_PIPELINE_ID:$CI_PIPELINE_ID" >> newfile.txt
    # 触发下游项目流水线, 并传递 PROJECT_ID 和 JOB_ID
    - curl --request POST --form "token=$CI_JOB_TOKEN"  --form "variables[PARENT_JOB_ID]=$CI_JOB_ID" --form "variables[PARENT_PROJECT_ID]=$CI_PROJECT_ID" --form ref=${CHILD_REF_BRANCH_NAME} "${CI_SERVER_HOST}/api/v4/projects/${CHILD_PROJECT_ID}/trigger/pipeline"

project2

download_upstream_artifacts:
  # variables:
  #   CI_DEBUG_TRACE: "true"
  stage: downstream_job
  # download upstream pipeline artifacts:
  needs:
    - pipeline: $PARENT_PIPELINE_ID
      job: create_artifacts
  # 限制仅通过父流水线触发时运行
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
  script:
    - git config --global user.name "gitlab-ci"
    - git config --global user.email "[email protected]"
    - git config --global --add safe.directory "*"
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - ssh-keyscan ${CI_SERVER_HOST} >> ~/.ssh/known_hosts && chmod 644 ~/.ssh/known_hosts
    - cat "$SSH_PRIVATE_KEY" >  ~/.ssh/gitlab && chmod 500 ~/.ssh/gitlab
    - cat "$SSH_CONFIG" >  ~/.ssh/config

    - echo $PARENT_PROJECT_ID
    - echo $PARENT_JOB_ID
    # 下载 artifacts
    # 会产生问题，因为 project1的流水线是先触发downstream才上传artifacts,有时间差问题，这个时候有可能取不到artifacts
    # 解决方法：将artifacts存到外部存储，不使用 artifact
    - curl --location --output artifacts.zip "${CI_SERVER_HOST}/api/v4/projects/${PARENT_PROJECT_ID}/jobs/${PARENT_JOB_ID}/artifacts?job_token=$CI_JOB_TOKEN"
    - unzip -o artifacts.zip

优化，支持传递 artifacts

project1

create_artifacts:
  stage: demo
  when: manual
  artifacts:
    paths:
    - newfile.txt
    expire_in: 1 week
  script:
    - CHILD_PROJECT_ID=493
    - CHILD_REF_BRANCH_NAME=feature/cicd
    - echo "CI_JOB_ID:$CI_JOB_ID" >> newfile.txt
    - echo "CI_PIPELINE_ID:$CI_PIPELINE_ID" >> newfile.txt

trigger_downstream:
  stage: deploy
  trigger: 
    include:
      - project: path_to/downstream/repo_name   # Path to the project to trigger a pipeline in
        ref: 'feature/cicd'
        file: '.gitlab-ci.yml'

1. 创建密钥对，比如本地执行 ssh-keygen -t ed25519 -C "Keypair for FSD"'
2. 公钥做为部署key，存放到gitlab项目中
3. 在项目中setting-cicd中定义一个类型为file的CICD变量，命名为SSH_PRIVATE_KEY
4. 在 gitlab-ci.yml中使用这个文件变量

default:
  tags: [ mnf, basic, global ]
  image: $DEFAULT_IMAGE
  before_script:
    - git config --global user.name "gitlab-ci"
    - git config --global user.email "[email protected]"
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - ssh-keyscan ${CI_SERVER_HOST} >> ~/.ssh/known_hosts && chmod 644 ~/.ssh/known_hosts
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - git checkout $CI_COMMIT_REF_NAME
    - git submodule update --init
    - git remote set-url origin git@$CI_SERVER_HOST:$CI_PROJECT_PATH.git

We want to sync a private repo(https://github.com/mafeifan/vue-press.git) to gitlab

go to https://github.com/settings/tokens to generate a Personal access tokens (classic)

only check scope repo

remember the token: which like ghp_QabT1sLA*****d839uR1alj5S

you can make a test on your local

GITHUB_TOKEN=ghp_QabT1sLA*****j5S
git clone https://ghp_QabT1sLA*****j5S:[email protected]/mafeifan/vue-press.git

2. Create an empty project on gitlab

then go to Settings - repository - Mirroring repositories

fill in the below content in form

• Git repository URL: https://github.com/mafeifan/vue-press.git
• Authentication method: Username and Password
• Username: x-oauth-basic
• Password: ghp_QabT1sLA*****j5S

Alternative way

Not to use mirror feature, Use gitlab pipeline to sync code automatically

we need to generate a gitlab token to access gitlab repo

sync-code-from-github:
  image: public.ecr.aws/bitnami/git:2
  stage: sync
  services: []
  when: manual
  script: |
    set -x
    # define $GITHUB_TOKEN and $GITLAB_TOKEN in gitlab pipeline variables first
    git clone https://$GITHUB_TOKEN:[email protected]/mafeifan/vue-press.git
    cd vue-press
    ls
    GITLAB_USERNAME=gitlab
    git remote add gitlab https://$GITLAB_USERNAME:$GITLAB_TOKEN@gitlab.cn/cndevops/vue-press.git
    git push gitlab master

使用者在初次踏进 GitLab CI 的世界时，通常按着官方文件一步步照做，多半不会遇到什么问题。唯独有一项东西有可能让新手产生较大的疑惑，那就是该如何选择 Executor。

目前在官方文件上已经有提供了一份 Compatibility chart 帮助使用者选择 Executor。

GitLab Runner 与 Executor 的关系 首先，让我们先来解释 GitLab、GitLab Runner 与 Executor 的关系。

让我们拆开来说明，先从 GitLab 与 GitLab Runner 的关系开始。

如上图所示，我们都知道 GitLab Runner 是用来帮助我们执行 CI Job 的工人，而 GitLab 就是这些工人的老板。老板（GitLab）会去查看需求单（.gitlab-ci.yml）建立一张又一张有先后顺序的工单（CI Pipeline），而每一位工人（Runner）则是每隔固定的时间就去询问老板（GitLab）现在有分配给自己的工作（CI Job）吗？现在自己应该做哪一项工作？工人拿到工作后开始执行，并且在执行过程中将处理进度即时填写在工单上。

到这里为止，大部分的人都不太会有什么问题，让我们接着说明 GitLab Runner 与 Executor 的关系。

前面我们将 GitLab 与 GitLab Runner 比喻为老板与工人，那么 Executor 是什么？是工人的工具吗？从我的角度来看，Executor 反而更像是工人的「完成工作的方式」或「工作的环境」。

举例来说，就像我们都曾听过的都市传说，据说在国外有某知名企业的工程师，偷偷将自己的编程开发工作远程外包给印度工程师完成，借此实现上班摸鱼打混还能取得高绩效表扬的神奇故事。当然，偷偷把正职工作私下外包是不正确的行为，但在这个故事中，这就是这位工程师「完成工作的方式」；同理，用口头命令别人做事、自己亲力亲为的传统方法、善用自动化工具或高科技工具辅助、远程连接工作⋯⋯这些都是不同的「完成工作的方式」。

按照上面的比喻，根据您选择的 Executor，决定了 Runner 将会采用何种「方式」以及在哪个「工作环境」中来完成 CI Job。

因此我们可以理解，这意味着身为老板的我们，很可能需要雇佣多位不同的工人。举例来说，炒菜煮饭这种工作，我们就会安排给在厨房工作的厨师；闯入民宅开保险箱这种工作，我们就会安排给RPG游戏中的勇者。根据不同的CI Job，我们有可能需要准备设置了不同Executor的Runner来应对。

目前可选择的Executor

了解Runner与Executor的关系后，接着来认识目前GitLab Runner可选择的Executor有哪些。

【小提醒】目前GitLab官方已表示不会再增加更多的Executor，并且为了保留弹性与扩展性，改为提供Custom这项Executor，如果现有的Executor不能满足你的需求，那就自己定制处理吧！

目前可选择的Executor如下：

• Shell：即是Runner直接在自己的Local环境执行CI Job，因此如果你的CI Job要执行各种指令，例如make、npm、composer⋯⋯，则需要事先确定在此Runner的Local环境是否已具备执行CI Job所需的一切相关程序和依赖。
• SSH：Runner会通过SSH连接上目标主机，并且在目标主机上执行CI Job。因此你要提供Runner足以SSH连接目标主机的账号密码或SSH Key，也要提供足够的用户权限。当然目标主机上也要事先处理好执行CI Job所需的一切相关程序和依赖。
• Parallels：每次要执行CI Job时，Runner会先通过Parallels建立一个干净的VM，然后通过SSH登录此VM并在其中执行CI Job。所以同样的用来建立VM的Image是先要准备好执行CI Job所需的一切相依程式与套件，这样Runner建立好的环境才能正确地执行CI Job。另外，当然架设Runner的主机上，记得要安装好Parallels。
• VirtualBox：同上，只是改成用VirtualBox建立干净的VM。同样架设Runner的主机上，记得要安装好VirtualBox。
• Docker：Runner会通过Docker建立干净的Container，并且在Container内执行CI Job。因此架设Runner的主机上，记得要安装好Docker，另外在规划CI Pipeline时也要记得先准备能顺利执行CI Job的各种Docker image。在CI Pipeline中采用Container已是十分普遍的做法，建议大家可以优先评估Docker executor是否适合你的工作场景。
• Docker Machine：延续上一个 Executor，此种 Executor 一样会通过 Container 来执行 CI Job，但差别在于这次你原本的 Runner 将不再是一般的工人了，它已经摇身一变成为工头，每当有工作（CI Job）分派下来，工头就会去自行招募工人（auto-scaling）来执行工作。因此倘若在短时间内有大量的工作需要执行，工头就会去招募大量的工人迅速地将工作们全部搞定。需要注意的是因为招募工人需要一些时间，故有时此种 Executor 在启动时会需要多花费一些时间。
• Kubernetes：延续前两个与 Container 相关的 Executor，这次直接进入超级工头 K8s 的世界。与前两种 Executor 类似，但这次 Runner 操控的不是小小的 Docker engine 了，而是改为操控 K8s。此种 Executor 让 Runner 可以透过 K8s API 控制分配给 Runner 使用的 K8s Cluster 相关资源。每当有 CI Job 指派给 Runner 时，Runner 就会透过 K8s 先建立一个干净的 Pod，接着在其中执行 CI Job。当然使用此种 Executor 依然记得先准备好能顺利执行 CI Job 的各种 Container image。
• Custom：如果上面这七种 Executor 都不能让你满意，那就只好请客官您自行动手啦！Custom Executor 即是 GitLab 提供给使用者自行定制 Executor 的管道。

该选择哪一种 Executor？

简单来说就是根据你的需要来选择 Executor！

如果你的团队已经很熟悉 Container 技术，不论是开发、测试及 Production 环境都已全面拥抱 Container，那当然选择 Docker executor 是再正常不过了。更不用说如果 Production 环境已经采用 K8s，那么 CI/CD Pipeline 想必也离不开 K8s 的魔掌，Runner 势必会选用 Kubernetes executor。（但还是别忘了凡事都有例外。）

假如只有开发环境拥抱 Container，但实际上测试机与 Production 环境还是采用实体服务器或 VM，这时你可能就会准备多个 Runner 并搭配多种 Executor。例如 Build、Unit Testing 或某些自动化测试的 CI Job 让 Docker executor 去处理；而像是 Performance testing 则用 VirtualBox executor 开一台干净的 VM 并部署程序来执行测试。

又或者，你的公司有非常多项目正在同步进行中，同时需要执行的 CI Job 时多时少，那么可以 auto-scaling 的 Docker Machine executor 也许会是一个可以考虑的选择。事实上 gitlab.com 提供给大家免费使用的 Shared Runner，就有采用 Docker Machine executor。

再举例，假如有某个 CI Job 只能在某台主机上执行，也许是为了搭配实体服务器的某个硬件装置、也许是基于安全性或凭证的缘故，在这种情况下很可能你会用到 SSH executor，或甚至是在该主机上安装 Runner 并设置为 Shell executor，让特定的 CI Job 只能在该 Runner 主机上执行。

最后，也有可能你因为刚好身处在一个完全没有 Container 知识与技能的团队，所以才只好选择 Shell、SSH、VirtualBox 这些不需要碰到 Container 的 Executor。

【小提醒】由于 SSH、VirtualBox、Parallels 这三种 Executor，Runner 都是先连上别的主机或 VM 之后才执行 CI Job 的内容，因此都不能享受到 GitLab Runner 的 caching feature。

（官网文件也有特别提醒这件事。）

结语

GitLab Runner 及 Executor 与 CI/CD Pipeline 的规划密切相关，在实务上我们经常会准备多种 Runner 因应不同的情境，也许是类似下面这样常态准备 3 台 Runner。

• Docker executor｜供一般的 CI Job 使用。
• Docker Machine executor｜供 CI Job 大爆发堵车时使用。
• SSH 或 Shell executor｜供 Production Deploy 或某些有较高安全性考量

前提

先阅读文档

https://github.com/sameersbn/docker-gitlab

https://www.damagehead.com/docker-gitlab/

测试环境下最简单的方式是使用 docker-compose

Amazon Linux 2023 下载安装docker

EC2 基本信息

• 系统: Amazon Linux 2023
• 磁盘: 100G
• 规格: t3.large 2核8G

sudo bash
cd ~
yum install docker -y
systemctl start docker
# 测试 docker
docker run hello-world

curl -SL https://github.com/docker/compose/releases/download/v2.29.6/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
/usr/local/bin/docker-compose /usr/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
# 测试 docker-compose
docker-compose

安装 gitlab

准备下面的yaml文件，执行 docker-compose up

浏览器打开http：//localhost:10080并使用默认用户名和密码登录：

• username: root
• password: 5iveL!fe

docker-compose.yml

version: '2.3'

services:
  redis:
    restart: always
    image: redis:6.2
    command:
    - --loglevel warning
    volumes:
    - redis-data:/data:Z

  postgresql:
    restart: always
    image: sameersbn/postgresql:14-20230628
    volumes:
    - postgresql-data:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm,btree_gist

  gitlab:
    restart: always
    image: sameersbn/gitlab:17.5.0
    depends_on:
    - redis
    - postgresql
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - gitlab-data:/home/git/data:Z
    healthcheck:
      test: ["CMD", "/usr/local/sbin/healthcheck"]
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 5m
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Chongqing
    - GITLAB_TIMEZONE=Chongqing

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=localhost
    - GITLAB_PORT=10080
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=
    - GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alphanumeric-string

    - GITLAB_ROOT_PASSWORD=
    - GITLAB_ROOT_EMAIL=

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=false

    - [email protected]
    - [email protected]
    - [email protected]

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00

    - SMTP_ENABLED=false
    - SMTP_DOMAIN=www.example.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - [email protected]
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login

    - IMAP_ENABLED=false
    - IMAP_HOST=imap.gmail.com
    - IMAP_PORT=993
    - [email protected]
    - IMAP_PASS=password
    - IMAP_SSL=true
    - IMAP_STARTTLS=false

    - OAUTH_ENABLED=false
    - OAUTH_AUTO_SIGN_IN_WITH_PROVIDER=
    - OAUTH_ALLOW_SSO=
    - OAUTH_BLOCK_AUTO_CREATED_USERS=true
    - OAUTH_AUTO_LINK_LDAP_USER=false
    - OAUTH_AUTO_LINK_SAML_USER=false
    - OAUTH_EXTERNAL_PROVIDERS=

    - OAUTH_CAS3_LABEL=cas3
    - OAUTH_CAS3_SERVER=
    - OAUTH_CAS3_DISABLE_SSL_VERIFICATION=false
    - OAUTH_CAS3_LOGIN_URL=/cas/login
    - OAUTH_CAS3_VALIDATE_URL=/cas/p3/serviceValidate
    - OAUTH_CAS3_LOGOUT_URL=/cas/logout

    - OAUTH_GOOGLE_API_KEY=
    - OAUTH_GOOGLE_APP_SECRET=
    - OAUTH_GOOGLE_RESTRICT_DOMAIN=

    - OAUTH_FACEBOOK_API_KEY=
    - OAUTH_FACEBOOK_APP_SECRET=

    - OAUTH_TWITTER_API_KEY=
    - OAUTH_TWITTER_APP_SECRET=

    - OAUTH_GITHUB_API_KEY=
    - OAUTH_GITHUB_APP_SECRET=
    - OAUTH_GITHUB_URL=
    - OAUTH_GITHUB_VERIFY_SSL=

    - OAUTH_GITLAB_API_KEY=
    - OAUTH_GITLAB_APP_SECRET=

    - OAUTH_BITBUCKET_API_KEY=
    - OAUTH_BITBUCKET_APP_SECRET=
    - OAUTH_BITBUCKET_URL=

    - OAUTH_SAML_ASSERTION_CONSUMER_SERVICE_URL=
    - OAUTH_SAML_IDP_CERT_FINGERPRINT=
    - OAUTH_SAML_IDP_SSO_TARGET_URL=
    - OAUTH_SAML_ISSUER=
    - OAUTH_SAML_LABEL="Our SAML Provider"
    - OAUTH_SAML_NAME_IDENTIFIER_FORMAT=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    - OAUTH_SAML_GROUPS_ATTRIBUTE=
    - OAUTH_SAML_EXTERNAL_GROUPS=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_EMAIL=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_USERNAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_FIRST_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_LAST_NAME=

    - OAUTH_CROWD_SERVER_URL=
    - OAUTH_CROWD_APP_NAME=
    - OAUTH_CROWD_APP_PASSWORD=

    - OAUTH_AUTH0_CLIENT_ID=
    - OAUTH_AUTH0_CLIENT_SECRET=
    - OAUTH_AUTH0_DOMAIN=
    - OAUTH_AUTH0_SCOPE=
 
    - OAUTH_AZURE_API_KEY=
    - OAUTH_AZURE_API_SECRET=
    - OAUTH_AZURE_TENANT_ID=

volumes:
  redis-data:
  postgresql-data:
  gitlab-data:

生产建议

postgresql 和 redis 不要和 gitlab 运行在同一台服务器，最好使用独立数据库，避免单点故障

通过 IP:10080 访问 gitlab 站点不太优雅，也不方便识记 我们给 gitlab 站点绑定个域名并且带上SSL证书

申请免费SSL证书

由于我的 mafeifan.com 域名解析是托管在腾讯云, 可以在腾讯云的SSL证书服务里购买免费的域名证书

时长只有3个月

选择 nginx 类型，下载得到 gitlab.mafeifan.com_nginx.zip

登录服务器安装nginx

sudo yum install nginx -y
# 创建一个专门存放证书的目录
sudo mkdir -p /etc/nginx/my_certs

将证书放到指定目录

• /etc/nginx/my_certs/gitlab.mafeifan.com_bundle.crt
• /etc/nginx/my_certs/gitlab.mafeifan.com.key

新建nginx配置文件 /etc/nginx/conf.d/gitlab.mafeifan.com-80-443.conf 内容如下：

server {
    listen 80;
    server_name gitlab.mafeifan.com;
    rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443;
  server_name gitlab.mafeifan.com;
  ssl on;
  ssl_certificate /etc/nginx/my_certs/gitlab.mafeifan.com_bundle.crt;
  ssl_certificate_key /etc/nginx/my_certs/gitlab.mafeifan.com.key;
  ssl_session_timeout 5m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
  ssl_prefer_server_ciphers on;
  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_pass http://127.0.0.1:10080;
  }
}

修改docker-compose.yml

GITLAB_HTTPS=true
SSL_SELF_SIGNED=false

GITLAB_HOST=gitlab.mafeifan.com
GITLAB_PORT=443

重启

docker-compose down && docker-compose up -d

问题

1. gitlab 提供了一个 WebIDE 在线编辑代码的编辑器,发生了地址错误的情况

根据文档，把地址改为 https://gitlab.mafeifan.com/-/ide/oauth_redirect

参考文档

https://help.aliyun.com/document_detail/36576.html

- [email protected]
- [email protected]
- [email protected]

- SMTP_ENABLED=true
- SMTP_DOMAIN=www.aliyun.com
- SMTP_HOST=smtp.qiye.aliyun.com
- SMTP_PORT=465
- [email protected]
- SMTP_PASS=xxxxxxx
- SMTP_STARTTLS=false
- SMTP_TLS=true  
- SMTP_AUTHENTICATION=login

问题

https://github.com/sameersbn/docker-gitlab/issues/2334

问题

特别说明

1. 极狐GitLab工作流是极狐GitLab团队内部的DevOps工作流，也是极狐GitLab面向企业推荐的参考工作流。本文将基于极狐GitLab企业版（专业版或旗舰版），参照极狐GitLab工作流，通过一个示例项目完整演示DevOps的全流程，覆盖权限管理、组织管理、需求管理、开发管理，并形成闭环。
2. 由于DevOps是一项工程实践，需要结合企业的组织架构、业务流程、技术栈与工具链、人员能力进行落地。以上内容每家企业均存在较大差异，甚至同一家企业不同团队或不同时期也存在差异。故本文旨在向企业提供一个参考工作流，帮助企业快速了解极狐GitLab相关能力，也可用于改进企业内部的DevOps流程。
3. 本文可面向企业DevOps工程师或熟悉DevOps的研发、运维团队成员及Leader。阅读以下内容需要至少了解Git的使用方式（代码推拉）、版本控制与分支策略、软件测试、CI/CD、制品库、容器技术（Docker）、监控运维等基础知识。需熟悉GitLab基本功能，如史诗议题、合并请求、GitLab CI脚本、GitLab Runner类型与部署方式。本文不会对上述内容进行深度展开，如果您对以上内容尚不熟悉，本文中的内容可能会对您造成较大困扰，建议您通过极狐GitLab原厂培训服务快速掌握极狐GitLab和DevOps的基础知识。
4. 以下内容可在 https://presales-demo.jihulab.com/mycompany/project-x 中查看配套的demo示例

[TOC]

1 权限管理

1.1 用户角色

极狐GitLab内置6种用户角色，可根据不同的场景、用户职能进行分配。

1.2 自定义角色[旗舰版]

极狐GitLab支持自定义角色，属于旗舰版功能，该功能正在持续完善。

2. 组织管理

2.1 群组

极狐GitLab的群组类似文件夹，可以包含多个项目（代码库），群组可以嵌套，类似文件夹、子文件夹。

群组可作为部门组织管理代码库，也可作为虚拟项目组织管理代码库。

操作步骤：

1. 创建一级群组项目X
2. 在群组项目X下创建一个项目（代码库）子项目A，创建两个子群组子项目B、子项目C。
3. 在子群组子项目B、子项目C中创建项目（代码库）模块A、模块B、模块C

不同开发语言划分组织的参考经验：

1. 若使用Java、Python等语言，能实现模块化开发，能通过流水线独立部署，或能打包成jar、pip等制品，通过包管理器向其他项目提供引用，这类项目建议参考子项目B、子项目C，分成子群组和多个代码库来管理。
2. 若使用C/CPP语言，没有太好的包管理工具，模块之间依靠完整源码编译，这类项目建议参考子项目A，将整个C/CPP项目放到一个项目（代码库）中，通过文件夹来区分模块。

2.2 项目

极狐GitLab的项目就是指代码库，隶属于群组。

群组、项目与角色关系：

• 可将用户在群组级别进行角色授权，该用户具备该群组以及该群组的所有子群组、所有项目（代码库）的权限，即继承权限。
• 可将用户在项目级别进行角色授权，该用户只具备该项目（代码库）的权限。

2.3 范围标记[专业版]

极狐GitLab使用Label标记来给后续需求管理中使用到的史诗、议题赋予一些意义，可以理解为自定义字段。

操作步骤：

1. 在群组项目X左侧边栏“管理——标记”中新建以下标记，这些标记可以在该群组以及该群组的所有子群组、所有项目（代码库）中使用。
2. 管理员也可以参考文档在GitLab全局设置标记，GitLab中所有的群组、项目都可使用。
3. 创建一组类型标记，用于标识议题的类型是“功能”还是“缺陷”。其中::是用于设置范围标签，该标签是一组键值对，具有排他性。如下面例子中，某个议题同一时间只能具备其中一个type标记，即type要么是bug，要么是feature。

type::bug
type::feature

4. 创建一组状态标记，用于标识议题的状态是“待处理”、“进行中”还是“已完成”。

status::todo
status::doing
status::done

5. 创建一组优先级标记，用于标识议题的优先级是“高”、“中”还是“低”。

priority::high
priority::mid
priority::low

2.4 群组/实例模板[专业版]

极狐GitLab支持使用模板来为后续需求管理中使用到的议题设置一些格式化内容，用来提高工作规范性和效率。

操作步骤：

1. 在群组项目X中创建一个项目（代码库）模板，创建两个文件.gitlab/issue_templates/feature.md、.gitlab/issue_templates/bug.md，用于作为“功能”和“缺陷”的标准模板

内容如下：

bug.md

### 步骤
1.
2.
3.

### 结果


### 期望


### 环境
- 机型：
- 版本：

/label ~"type::bug" ~"priority::low" ~"status::todo"

feature.md

### 用户故事
作为 [角色]，我 [想要实现/达到什么目的]，[从而获得怎样的价值/解决什么问题]。

### 客户用例
1.
2.
3.

### 设计文档
1. 产品原型图见: xxxxxx
2. 产品设计图见: xxxxxx

/label ~"type::feature" ~"status::todo"

2. 在群组项目X的“设置——通用——模板”中，选择项目模板作为该群组的默认模板，该模板可以在该群组以及该群组的所有子群组、所有项目（代码库）中使用。
3. 管理员也可以参考文档在GitLab全局设置模板，GitLab中所有的群组、项目都可使用。

3. 需求管理

说明：若您已经使用Jira、PingCode、Ones、LigaAI等国内外主流项目管理工具、或使用自研、定制开发的项目管理工具，以下内容仅供参考。您也可以直接跳到第4章了解开发管理的相关内容，在该章节中也会介绍极狐GitLab如何与这些第三方项目管理系统做集成，并打通整个流程。 若您没有使用线上化的项目管理工具，还在使用电子文档、聊天工具来进行需求管理，则建议您详细阅读以下内容。

3.1 史诗[专业版]

极狐GitLab使用Epic史诗来管理相对比较宏大的业务目标或原始需求，他一般由项目经理、产品经理负责创建并维护。 史诗是建立在群组上的。

操作步骤：

1. 在群组项目X的“计划——史诗”中，创建两个史诗，并设置大致的时间计划
2. 具备群组项目X角色权限的用户都可以看到所有的史诗内容。
3. 史诗将在后续阶段被拆分、细化、形成具体的研发任务，也就是议题，史诗和议题是父子关系。

3.2 子史诗[旗舰版]

如果一项史诗任务过于复杂，可能还需拆分成多个依然比较宏大的史诗，这里就可以使用到子史诗

3.3 路线图 roadmap[专业版]

路线图是针对史诗的排期展示。设置史诗的时间计划后，项目经理、产品经理可以查看路线图。 操作步骤：

1. 在群组项目X的“计划——路线图”中，通过甘特图来展示所有史诗的排期和进度。
2. 史诗的进度依赖于与它关联的议题，如一个史诗关联了4个议题，其中2个议题已完成（已关闭），那么进度就是50%。
3. 如果有子史诗，路线图中可会显示子史诗、史诗的排期和进度。

3.4 里程碑 Epic

史诗和路线图是项目经理、产品经理对一些原始需求的大致排期。当某些原始需求已经有近期明确的开发计划后，应创建里程碑。

里程碑标识近期一段时间明确的开发计划，如一次版本发布、一次敏捷迭代等。

操作步骤：

1. 在群组项目X的“计划——里程碑”中，创建两个里程碑，通过版本号进行命名，并设置里程碑的时间。
2. 里程碑将关联一些具体的、细化的开发任务或者需要处理的缺陷，也就是下文中的议题。

3.4.1 燃起图、燃尽图[专业版]

当里程碑中的议题根据第3.5章节被创建，随后根据第4章节完成开发、集成、部署，最后议题被手动关闭或根据4.4.5.5在合并请求被执行后自动关闭，意味着这个功能开发完成。

议题在里程碑中会实时显示状态，并通过燃起图、燃尽图来展示整个里程碑的进展，也可以在里程碑结束后帮助团队回顾或用于帮助团队评估下一个里程碑的工作计划。

3.5 议题 issue

极狐GitLab使用Issue议题来管理需求任务、Bug缺陷。它一般由产品经理创建并由研发人员维护。

3.5.1 议题管理

议题是建立在项目（代码库）上的，它可以与史诗进行关联，也可以与史诗无关，即只与该项目（代码库）相关。 操作步骤：

1. 拥有群组项目X角色权限的项目管理人员，可以查看该群组所有项目（代码库）的议题。

2. 仅拥有项目（代码库）的开发人员，只可以查看与他工作相关的议题。
3. 所以创建议题应明确该议题与哪一个项目（代码库）相关，如果议题创建到错误的项目（代码库）中，可以参考文档将议题移动到正确的项目中。

3.5.2 需求议题

用议题管理需求任务。

操作步骤：

1. 在群组项目X下的项目（代码库）子项目A的“计划——议题”中创建议题
2. 选择之前创建的名为feature的模板来列出开发任务的描述格式。
3. 将该议题关联到史诗“监控模块开发”，关联到里程碑“1.0.0”。
4. 添加了其他几个议题，并与史诗、里程碑进行关联
5. 添加了一个议题，只关联里程碑，不关联史诗。

3.5.3 缺陷议题

用议题管理缺陷，与管理开发任务没有什么不同，只是用Lable来标识这个议题是缺陷Bug。

1. 另外缺陷议题一般不与史诗进行关联，只与各项目（代码库）相关。若项目为多模块模式进行开发，测试人员无法判断该缺陷属于哪个项目（代码库），可以向最终提测的应用项目（代码库）提交缺陷，研发团队内部定位后再通过移动议题将缺陷议题转移到对应的项目中。
2. 通过选择之前创建的名为bug的模板来列出缺陷Bug的描述格式。
3. 缺陷议题（缺陷）可以与需求议题（功能）进行关联。

3.6 议题权重[专业版]

在敏捷开发中，一般使用故事点、评估点来估算用户故事。在极狐GitLab中可使用权重来实现该功能。

操作步骤：

1. 进入指定的议题，给议题设置权重。
2. 在群组项目X的里程碑中，可查看该里程碑关联的议题的总权重。

3.7 工时统计

在瀑布开发中，或者对工时统计有要求的场景中，一般需要在开发前填写估算工时，开发结束后填写实际工时，用于做排期和分析。在极狐GitLab中可使用工时来实现该功能。

操作步骤：

1. 进入指定的议题，给议题设置预估工时。
2. 在议题处理过程中，可以多次给议题设置实际工时，如每天进行填写，最后实际工时将会累加。
3. 在议题中可以查看时间追踪报告，看到实际工时的说明和累加历史。 在群组项目X的里程碑中，可查看该里程碑关联的议题的总工时统计。

3.8 议题看板 issue board[专业版]

极狐GitLab支持灵活的自定义看板，来对议题进行管理、协作。

3.8.1 任务看板

操作步骤：

1. 在群组项目X“计划——议题看板”中编辑“Development”看板。
2. 设置里程碑=1.0.0、标记=type::feature，即看板中只包含里程碑为1.0.0且类型为feature的议题。
3. 创建列表，将标记为status::todo、status::doing、status::done的列表分别加入看板。
4. 议题可在列表之间拖动。
5. 后续只需要编辑看板的里程碑，即可用于不同里程碑周期下的任务看板管理。

3.8.2 缺陷看板

操作步骤：

1. 在群组项目X“计划——议题看板”中创建“Bug”看板。
2. 设置里程碑=1.0.0、标记=type::bug，即看板中只包含里程碑为1.0.0且类型为bug的议题。
3. 参考任务看板，创建列表并进行管理。

3.9 指派议题[专业版]

将议题指派给一个或多个开发人员，用于分配开发任务、或处理Bug缺陷。

操作步骤：

1. 进入指定的议题，给议题设置指派人。
2. 被指派的人员可以收到邮件通知，并可在“代办事项列表”中进行展示和跟踪。

4 开发管理

4.1 创建分支

4.1.1 分支策略

极狐GitLab推荐的分支策略GitLab Flow提供了3种子模型来匹配不同的业务场景。

本文以第三种子模型，也就是多版本并行开发场景为例，它的完整分支模型如下：

1. 新功能的开发应创建一个新的feature分支，如feature/monitor-temperature，并创建从feature/monitor-temperature分支到main分支的合并请求。开发人员在该分支下开发，开发完成后通过流水线实现自动编译、打包、单元测试、质量扫描并发布到测试环境。测试人员进行该模块的功能测试，测试完成并通过评审后将该分支合并到main分支。合并结束后自动删除feature/monitor-temperature分支。
2. Bug的修复应创建一个新的fix分支，如fix/tag-version-diff，并创建从fix/tag-version-diff分支到main分支的合并请求。开发人员在该分支下修复Bug，开发完成后通过流水线实现自动编译、打包、单元测试、质量扫描并发布到测试环境。测试人员进行该模块的功能测试，测试完成并通过评审后将该分支合并到main分支。合并结束后自动删除fix/tag-version-diff分支。
3. 每个功能、每个Bug都应创建新分支，并在新分支中独立开发，应避免多个功能、Bug在同一个feature分支或fix分支中开发，这样会导致管理混乱、难以回滚、容易冲突、不利于评审。
4. 创建release分支来管理版本，同一时间可能维护多个版本，如release/13.0.0分支、release/14.0.0分支、release/15.0.0分支。
5. 当需要发版时，从main分支向release/15.0.0分支发起合并请求。
6. 基于release分支编译、构建、打包，发布到测试环境，测试人员进行集成测试。
7. 当release分支发现有功能缺失或者存在缺陷，还应参照第1、2步的内容，创建feature或fix分支来开发新功能或修复缺陷，再向main分支合并。合并通过后使用cherry-pick拣选功能将这个合并请求拣选到指定的release分支，如release/13.0.0、release/14.0.0、release/15.0.0。
8. 直到release分支测试无误后，在release分支上打标签tag来标识一个新的小版本，如15.0.1。
9. 可以在打标签tag时触发流水线，基于tag编译、构建、打包，然后发布到生产环境。

需要注意，分支策略因研发流程而异，企业应该根据实际情况调整，但建议在企业在项目中尽可能推行统一的分支策略，以便于管理。

4.1.2 分支命名规则[专业版]

当确定分支策略后，应通过极狐GitLab推送规则来对分支命名进行校验，确保开发人员创建分支时能严格遵守分支策略，避免管理混乱。

操作步骤：

1. 在子项目A“设置——仓库——推送规则”中配置分支名称校验规则(cherry-pick|feature|fix|release)\/*。
2. 可参考文档和文档，在GitLab实例级别或群组级别设置推送规则，这些推送规则仅对GitLab实例或群组中新创建的项目生效。
3. 当创建的分支名称不符合校验规则，则提示无法创建分支

4.1.3 手动创建分支

在指定项目，如子项目A“代码——分支”中，新建分支feature/monitor-temperature，用来开发#2号需求“获取温度数据”

可在指定项目，如子项目A“代码——分支”查看并切换分支

创建合并请求，从feature/monitor-temperature合并到main。

4.1.4 基于议题创建分支[专业版]

极狐GitLab也支持基于议题快速创建分支和合并请求。

操作步骤：

1. 在指定议题中，下拉“创建合并请求”，选择“创建合并请求和分支”，填写“分支名称”，即可快速创建分支和合并请求。

4.2 保护分支

当确定分支策略后，还应确保研发人员只能在开发分支如feature、 fix分支进行代码提交，应拒绝开发人员直接向主干分支如main分支或发版分支如release分支提交代码。开发分支和主干分支、发版分支之间必须通过合并请求，走评审或确认机制传递代码，避免管理混乱、引起冲突。在极狐GitLab中可以通过保护分支来达到以上目的。

4.2.1 角色级保护

基于用户角色设置保护分支，可能会导致管理失控。因为Maintainer角色具备的权限较多，除了基本的管理权限外，还能给项目设置新的人员及角色权限，即引入更多的Maintainer角色，无法满足企业合规管理的需求。

操作步骤：

1. 在指定项目，如子项目A“设置——仓库——受保护分支”中，新建保护分支，输入release*来匹配所有的release分支，包括后续创建的release分支也自动匹配为受保护分支。

2. 由于GitLab项目中main分支是默认分支，所以本身已经是受保护分支。

3. 调整受保护分支，允许Maintainer角色可以合并，No One可以推送，即只有Maintainer角色通过确认合并请求，才能向受保护的main分支release*分支传递代码。

4.2.2 用户级保护[专业版]

基于用户设置保护分支，可将合并、推送权限进行细粒度控制，仅允许一个人或几个人具备合并、推送权限，可有效规避代码越权提交，管理失控等问题。

1. 与“角色级保护”设置一样，可在“允许合并”、“允许推送和合并”处选择具体的用户，支持多选。

4.2.3 群组保护分支[专业版]

极狐GitLab支持在群组级别设置保护分支，将对该群组的所有项目（代码库）生效，且在项目中不能修改、覆盖群组级别的保护分支。

4.3 分支开发

4.3.1 代码推送规则[专业版]

在开发分支下提交代码，应遵循统一、规范的提交格式，否则容易导致管理混乱，降低协同效率。如下图：

• 左图是不规范的代码提交，意义不清、描述重复。
• 右图是知名项目Angular.js的代码提交，遵循统一的提交规范类型（范围）: 描述 （需求编号），该规范也被称为Angular规范，是业内使用比较普遍的提交规范 极狐GitLab推送规则可以对代码提交的格式、文件类型、文件大小以及提交人的身份进行校验，确保入库的代码符合企业统一的规范，为研发协同以及后续的代码评审打下良好的基础。 操作步骤：

1. 在子项目A“设置——仓库——推送规则”中配置推送规则。
2. 勾选“拒绝未经验证的用户 Reject unverified users”，即验证开发人员本地git配置的user.email是不是当前执行代码推送的GitLab用户的已验证的邮箱。
3. 勾选“拒绝不一致的用户名 Reject inconsistent user name”，即验证开发人员本地git配置的user.name是不是当前执行代码推送的GitLab用户的用户名。
4. 设置“提交信息中的要求表达式”为(feat|fix|doc|style|refactor|pref|test|ci|revert):.+，您也可以自定义其他表达式。若提交信息格式不符合正则表达式，则拒绝推送。
5. 根据需要设置“禁止的文件名”，如(jar|exe|tar.gz|tar|zip)$。推送文件中若包含这些文件类型，则拒绝推送。
6. 根据需要设置“最大文件大小”，如20。单个推送文件若超过该大小，则拒绝推送，除非使用LFS来进行推送。
7. 可参考文档，在GitLab实例级别或群组级别设置推送规则，这些推送规则仅对GitLab实例或群组中新创建的项目生效。

4.3.2 代码开发与推送

在4.1章节中，新建了分支feature/monitor-temperature，用来开发#2号需求“获取温度数据”。现在可以模拟代码开发和提交推送过程。

1. 将子项目A的代码克隆到本地。
2. 在本地将子项目A的代码切换到feature/monitor-temperature分支。
3. 新增一些代码文件，如README.MD，并向文件中写入一些内容。
4. 本地提交代码，代码提交格式应遵循4.3.1章节推送规则的规范，如feat: #2 获取温度数据。
5. 重复3-4步骤，直到功能开发完成。
6. 向GitLab推送代码，在GitLab指定项目，如子项目A“代码——提交”可切换分支并查看不同分支的提交记录。

4.3.3 代码提交关联GitLab议题

在4.3.1和4.3.2章节中，除了要求代码提交应遵循一些统一格式外，还可以将代码提交与需求任务、Bug缺陷进行关联，实现需求管理和代码开发的双向追溯。 将代码提交与GitLab议题关联，可参考以下步骤。 操作步骤：

1. 在代码提交时，只需将议题ID号写入提交记录中，如feat: #2 获取温度数据，其中#2就是需求“获取温度数据”的议题ID号。需注意代码提交仅能关联该代码所属项目（代码库）中的议题，不能关联其他项目（代码库）中的议题。
2. 可以修改推送规则，如^(feat|fix|doc|style|refactor|test|revert|ci): #[0-9]{1,4}.*$，这样可强制研发人员每次提交代码时都填写对应的议题ID号。
3. 代码提交追溯需求、缺陷：在代码提交记录中，点击议题ID号，则会跳转到对应的议题
4. 需求、缺陷追溯代码提交：在议题中也可查看该议题关联的代码提交记录

4.3.4 代码提交关联第三方项目管理系统

如果您已经使用Jira、PingCode、Ones、LigaAI等国内外主流项目管理工具，极狐GitLab的代码提交也可以关联这些主流第三方系统的任务ID，实现双向追溯。目前已经支持的有：

以Jira为例，实现的效果如下：

1. 可以修改推送规则，如^(feat|fix|doc|style|refactor|test|revert|ci): JIRA\-\d+ .+，其中JIRA是Jira议题的前缀，不同Jira项目的前缀不同，需要替换。这样可强制研发人员每次提交代码时都填写Jira的议题ID号。
2. 代码提交追溯需求、缺陷：在代码提交记录中，点击议题ID号，则会跳转到对应的议题。
3. 需求、缺陷追溯代码提交：在Jira议题中也可查看该议题关联的代码提交记录。
4. 更多功能，请参见文档

4.4 持续集成、持续部署

代码推送到极狐GitLab后，应触发流水线实现自动化的编译、打包、部署。

4.4.1 配置流水线

自动编译、构建、打包、单元测试、质量扫描、部署、发布都依赖于流水线的配置和编排，只有先配置好流水线才能再后续的开发过程中实现上述功能。

为降低流程复杂度，请参考4.2章节，临时关闭main分支的保护，用来配置、调试流水线（调试结束后开启保护分支）。需注意实际项目中不推荐直接修改main分支文件，依然是通过feature分支配置、调试流水线，再合并到main分支。

4.4.1.1 环境变量管理

如果需要将打包后的程序直接上传/部署到其他环境里，需要将不同环境的服务器的信息存储到GitLab环境变量中，并且确保GitLab Runner所在的服务器与上传/部署的目标服务器网络互通。

在本示例中，我们计划通过scp命令将软件包上传到不同环境的服务器中，那么在GitLab里，存储的变量可以为

# 生产环境的用户名、IP、PORT、路径
USERNAME_PROD: ubuntu
IP_PROD: 192.168.0.1
PORT_PROD: 22
PATH_PROD: /wwwroot/

# 测试环境的用户名、IP、PORT、路径
USERNAME_TEST: ubuntu
IP_TEST: 172.16.0.1
PORT_TEST: 22
PATH_TEST: /wwwroot/

操作步骤：

1. 在子项目A的“设置——CICD——变量”中，添加上述变量。
2. 为了防止这些变量在流水线中被echo命令打印出来导致信息泄露，可以在设置变量时勾选“隐藏变量”。
3. 环境变量也可以设置在群组和实例级别，对群组和全局生效。

4.4.1.2 编译、打包、部署

进行这一步操作之前，需要根据不同语言、不同框架的代码项目，需要准备好编译服务器并安装好编译程序所需的环境，或准备好用于编译程序的Docker镜像。安装好GitLab Runner（如果您使用GitLab SaaS），然后参考以下内容基于GitLab CI关键字编写流水线脚本。

以一个C++的项目为例，通过指定的GitLab Runner完成自动编译、打包，根据流水线的触发条件来将软件包部署到指定的环境，如通过tag触发的流水线将软件包部署到生产环境（tag表示正式发版）同时将软件包上传到GitLab的制品库（软件包库），通过其他分支触发的流水线将软件包部署到测试环境。

操作步骤：

1. 在子项目A的“构建——流水线编辑器”中，点击“配置流水线”。

2. 流水线脚本内容如下：

stages:
  - build
  - upload
  - deploy

# 编译任务，使用docker类型Runner
build-job:
  stage: build
  # 编译环境镜像
  image: srzzumix/googletest
  script:
    # 编译打包
    - mkdir build
    - cd build
    - cmake ..
    - make
  artifacts:
    when: always
    paths:
      # 暂存打包程序，供upload-job使用
      - build/libsqrt.so

# 上传任务，使用docker类型Runner
upload-job:
  stage: upload
  image: alpine/curl
  rules:
    # 如果是从tag触发，即生产版本，则执行上传到制品库任务
    - if: '$CI_COMMIT_TAG  =~ /^v?\d+\.\d+\.\d+$/'
  script:
    # 上传到软件包库
    - 'curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file ./build/libsqrt.so "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/release/$CI_COMMIT_TAG/libsqrt.so"'

# 部署任务，使用shell类型Runner
deploy-job:
  stage: deploy
  tags: 
    - deploy_jump_server 
  # 用分支名称区分环境
  environment: $CI_COMMIT_REF_NAME
  script:
  # 如果是从tag触发，使用生产环境变量，否则使用测试环境变量
    - |
      if echo "$CI_COMMIT_TAG" | grep -Eq '^v?[0-9]+\.[0-9]+\.[0-9]+$'; then
          USERNAME=$USERNAME_PROD
          IP=$IP_PROD
          PORT=$PORT_PROD
          PATH=$PATH_PROD
          echo '生产环境'
      else
          USERNAME=$USERNAME_TEST
          IP=$IP_TEST
          PORT=$PORT_TEST
          PATH=$PATH_TEST
          echo '测试环境'
      fi
    # 通过scp命令传输到对应环境
    #- scp -r ./build/libsqrt.so $USERNAME@$IP:@PATH -P $PORT
    - echo "Deployment Complete!"

需注意执行deploy-job的Runner需与部署环境网络互通，上述示例使用scp命令执行部署，还需参考以下方式配置该Runner到部署服务器的SSH Key：

• 基于Shell类型Runner配置SSH Key
• 基于Docker类型Runner配置SSH Key

3. 可在子项目A的“构建——流水线”中查看流水线运行状态和结果。

4. 如果部署任务成功执行，可以看到对应的软件包库已经上传/部署到目标环境（此处应是测试环境）的服务器中，如果部署失败，应结合deploy-job的日志进行排查。

4.4.1.3 单元测试

极狐GitLab支持与单元测试框架集成，不同语言、不同测试框架的集成方式见文档。 以上文C++的代码项目为例

操作步骤：

1. 使用GoogleTest作为单元测试框架。
2. 编写测试脚本，如sqrt_test.cpp
3. 修改.gitlab-ci.yml，增加以下内容

stages:
  - build
  - test # 增加test阶段
  - upload
  - deploy
  
# 编译任务
build-job:
  stage: build
  # 编译环境镜像
  image: srzzumix/googletest
  script:
    # 编译打包
    - mkdir build
    - cd build
    - cmake ..
    - make
    # 运行单元测试
    - ./sqrt_unittest --gtest_output="xml:report.xml"
    # 生成覆盖率
    - apt update
    - apt install -y pip
    - pip install gcovr --break-system-packages
    - gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root ${CI_PROJECT_DIR}
  coverage: /^\s*lines:\s*\d+.\d+\%/
  artifacts:
    when: always
    paths:
      # 暂存打包程序，供upload-job使用
      - build/libsqrt.so
    reports:
      # 单测报告
      junit: build/report.xml
      # 单测覆盖率报告
      coverage_report:
        coverage_format: cobertura
        path: build/coverage.xml

4. 如果配置正确，可在子项目A的“构建——流水线”中看到流水线的状态为成功。进入流水线，可看到单元测试的报告

4.4.1.4 质量扫描[专业版]

极狐GitLab支持开箱即用的代码质量扫描，使用该功能需要Docker或K8S类型的Runner，且Runner需开启Docker-in-Docker模式，以Docker类型的Runner为例：

1. 进入Runner的Docker容器。
2. 修改/etc/gitlab-runner/config.toml：

[[runners]]
  url = xxxx
  token = xxxx
  executor = "docker"
  [runners.docker]
    tls_verify = xxx
    image = xxx
    # 仅修改privileged为true
    privileged = true
    disable_cache = xxx
    volumes = xxx

配置好Runner后，可以开启代码质量扫描，以上文C++的代码项目为例：

操作步骤：

1. 在子项目A代码库根目录创建文件.codeclimate.yml，内容如下：

plugins:
  cppcheck:
    enabled: true

2. 修改.gitlab-ci.yml，增加以下内容:

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml
  
code_quality:
    image: registry.gitlab.cn/gitlab-cn/docker:20.10.12
    services:
      - name: 'registry.gitlab.cn/gitlab-cn/docker:20.10.12-dind'
        command: ['--tls=false', '--host=tcp://0.0.0.0:2375']
        alias: docker
    variables:
      CODECLIMATE_PREFIX: "registry.gitlab.cn/"

3.如果配置正确，可在子项目A的“构建——流水线”中看到流水线的状态为成功。进入流水线，可看到质量扫描的报告

4.4.1.5 安全扫描[旗舰版]

极狐GitLab旗舰版内置SAST、SCA、DAST、密钥检测、模糊测试等7种类型的安全扫描工具，覆盖软件全生命周期，配置简单，开箱即用。使用该功能需要Docker或K8S类型的Runner。

1. 在子项目A的“构建——流水线编辑器”中添加以下内容，以开启其中的4种静态安全扫描能力：

stages:
  - test

include:
  # 静态应用测试
  - template: Security/SAST.gitlab-ci.yml
  # 依赖扫描与许可证检测
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  # 密钥检测
  - template: Security/Secret-Detection.gitlab-ci.yml

variables:
  # 安全扫描日志，有助于排查错误
  SECURE_LOG_LEVEL: debug

如果是扫描Maven项目，且需要自定义settings.xml文件，可参考4.4.1.1为该项目或群组创建环境变量，如名称为“MVN_SETTING”，类型为“文件”，内容为settings.xml文件中的内容

然后在流水线脚本中增加以下内容：

variables:
  # 安全扫描日志，有助于排查错误
  SECURE_LOG_LEVEL: debug
  # 使用自定义MVN Settings
  MAVEN_CLI_OPTS: "-s $MVN_SETTING"

3. 如果配置正确，可在子项目A的“构建——流水线”中看到流水线的状态为成功。进入流水线，可看到安全扫描和许可证报告

4.4.1.6 安全策略[旗舰版]

您也可以参考文档，在群组级别设置安全扫描策略，该群组的所有项目将会强制执行这个安全扫描策略，可实现安全扫描的批量设置、强制执行，并且无需修改项目自身的流水线脚本，减少侵入性。

4.4.2 单元测试

操作步骤：

1. 接着4.3.2分支开发的内容，在子项目A的feature/monitor-temperature分支增加一些单元测试的用例，用来体现差异。

#include "sqrt.h"
#include "gtest/gtest.h"

TEST(SquareRootTest, PositiveNos) // normal cases
{ 
    ASSERT_EQ(6, squareRoot(36.0));
    ASSERT_EQ(18.0, squareRoot(324.0));
    ASSERT_EQ(25.4, squareRoot(645.16));
    ASSERT_EQ(0, squareRoot(0.0));
}

// 增加测试用例
TEST(SquareRootTest, NegativeNos) // extreme cases
{
    ASSERT_EQ(-1.0, squareRoot(-15.0));
    ASSERT_EQ(-1.0, squareRoot(-0.2));
}

int main(int argc, char **argv) 
{
    testing::GTEST_FLAG(output) = "xml:report.xml";
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

2. 提交代码后，自动触发feature/monitor-temperature分支的流水线，等流水线执行完成，可在流水线中查看单元测试报告。

3. 也可在4.1.3或4.1.4章节中创建的feature/monitor-temperature到main的合并请求中查看单元测试报告以及单元测试覆盖率。

4.4.3 质量扫描[专业版]

操作步骤：

1. 在子项目A的feature/monitor-temperature分支人为引入一些代码质量问题。

#include "sqrt.h"
#include <iostream>
#include <cmath>
 
double squareRoot(const double a) 
{

    double b = sqrt(a);
    if(b != b) return -1.0;// NaN check
    else return sqrt(a);
}

// 人为引入代码质量问题
void decrease_code_quality() {
    // introduce an out-of-bounds error to check code quality report
    char a[10];
    a[10] = 0;

    return;
}

2. 提交代码后，自动触发feature/monitor-temperature分支的流水线，等流水线执行完成，可在流水线中查看feature/monitor-temperature分支的全量代码质量报告。

3. 也可在4.1.3或4.1.4章节中创建的feature/monitor-temperature到main的合并请求中查看feature/monitor-temperature分支新引入的代码质量报告。

4. 如果您使用极狐GitLab旗舰版，还可以在合并请求的变更页面查看代码质量问题，详见文档。

4.4.3 质量扫描[专业版]

操作步骤：

1. 在子项目A的feature/monitor-temperature分支人为引入一些代码质量问题。

#include "sqrt.h"
#include <iostream>
#include <cmath>
 
double squareRoot(const double a) 
{

    double b = sqrt(a);
    if(b != b) return -1.0;// NaN check
    else return sqrt(a);
}

// 人为引入代码质量问题
void decrease_code_quality() {
    // introduce an out-of-bounds error to check code quality report
    char a[10];
    a[10] = 0;

    return;
}

2. 提交代码后，自动触发feature/monitor-temperature分支的流水线，等流水线执行完成，可在流水线中查看feature/monitor-temperature分支的全量代码质量报告。

3. 也可在4.1.3或4.1.4章节中创建的feature/monitor-temperature到main的合并请求中查看feature/monitor-temperature分支新引入的代码质量报告。

4. 如果您使用极狐GitLab旗舰版，还可以在合并请求的变更页面查看代码质量问题。

4.4.4 安全扫描[旗舰版]

扫描报告可通过以下途径查看

• 漏洞报告：指定项目“安全——漏洞报告”，显示默认分支如main/master的全量漏洞报告：
• 依赖列表：指定项目“安全——依赖列表”，显示默认分支如main/master的全量依赖列表：
• 流水线安全报告：指定项目“流水线——安全/许可证”，显示当前分支的全量漏洞报告和许可证合规
• 合并请求安全报告：指定项目“合并请求——安全扫描/许可证”，显示源分支相较于目标分支的增量漏洞报告和许可证合规

4.4.5 代码评审

加速代码评审是提高软件交付效能最有效的途径之一。处于高效代码评审的团队，其软件交付效能有着50%的提升。 ——《2023 加速度 DevOps 全球状态报告》

如果您已参考4.1.3或4.1.4章节创建feature/monitor-temperature到main的合并请求，参考4.3章节推送了一些代码，参考4.4.1章节配置好流水线，那么此时您可以在合并请求中开展代码评审工作。 极狐GitLab专业版提供以下几种评审机制，可以帮助企业更好的开展代码评审工作。

4.4.5.1 合并请求批准[专业版]

多人多规则、自定义的流程化审批机制。

操作步骤：

1. 在指定项目，如子项目A的“设置——合并请求——合并请求批准”中，“添加批准规则”。
2. 添加一个“规则名称”为测试组的规则，“目标分支”为所有受保护的分支，“需要核准”为1，“添加审核人”中选择需要参与评审的测试人员。这条规则意思是所有向main、release分支发起的合并请求，都需要指定的测试人员参与评审，其中只要有1个人通过评审，则这条规则就算通过。
3. 添加一个“规则名称”为开发组的规则，“目标分支”为main，“需要核准”为1，“添加审核人”中选择需要参与评审的开发人员。这条规则意思是所有向main分支发起的合并请求，都需要指定的开发人员参与评审，其中只要有1个人通过评审，则这条规则就算通过。
4. 考虑到代码提交人也可能是代码评审人，为了防止代码提交人自己给自己评审，可以：

• 勾选“阻止合并请求的创建者批准”。即如果评审人是合并请求的发起人，那么他不能参与评审。
• 勾选“阻止添加提交的用户批准”。即如果评审人是合并请求中代码的提交人，那么他不能参与评审。
• 选择“添加提交时：删除所有批准”。即评审过程中，如果有人评审通过，但开发人员提交了新的代码，则将所有通过的评审删除，应重新评审。

5. 合并请求批准设置后仅对新发起的合并请求生效。为了验证效果，可以先将之前创建的合并请求删除，再重新创建从feature/monitor-temperature到main的合并请求，即可在合并请求中看到需要评审人批准后，才能进行后续的合并动作。

评审人可以点击“批准”或“撤销批准”，来决定评审是否通过。评审人给出通过意见后，“核准”列会显示数据变化，“已核准人”列会显示对应的评审人。

4.4.5.2 代码所有者CodeOwner[专业版]

针对不同的文件夹、文件类型、文件名称设置负责人。当这些文件内容发生变化时，自动将对应的负责人纳入合并请求的代码评审流程。

CodeOwner可以有效防止在协同开发的过程中，因为研发人员无意或有意修改他人的代码，但又未通知到相关人员，最终导致代码冲突、程序异常甚至引起一些生产事故的问题。

操作步骤：

1. 在指定项目，如子项目A的默认分支，如main分支中创建名为CODEOWNERS的文件，或者通过feature分支创建文件然后合并到main分支。
2. CODEOWNERS文件的格式内容如下：

# 指定文件的负责人，@user1、@user2为GitLab的用户账号
file.md @user1
path/file.md @user1 @user2

# 指定文件类型的负责人
*.cpp @user1 @user2

# 指定文件路径的负责人
docs/ @user1
model/db/ @user2

# 将群组作为负责人，groupx、group-x/subgroup-y为群组路径
file.md @group-x @group-x/subgroup-y

3. 在子项目A的“设置——仓库——受保护分支”中，开启需要代码所有者参与评审的分支

4. 同合并请求批准一样，在合并请求中可以看到如果有人改了代码负责人的代码，那么这个负责人会被自动纳入代码评审流程。

4.4.5.3 单元测试覆盖率降低触发评审[专业版]

当合并请求的源分支（如feature/monitor-temperature）的单元测试覆盖率相较于目标分支（如main分支）降低时，触发评审。可以将代码的单元测试覆盖率始终维持在一个标准水平，从而提高代码的质量和可靠性。

操作步骤：

1. 在子项目A的“设置——合并请求——合并请求批准”中启用覆盖率检查。
2. 同合并请求批准一样，配置“目标分支”、“需要核准”、“添加核准人”。
3. 同合并请求批准一样，新的规则只对新的合并请求生效，删除并重新创建合并请求后可以看到该规则已生效

4.4.5.4 安全门禁[旗舰版]

根据漏洞类型、级别、数量、状态设置安全门禁，当合并请求中安全扫描报告不符合安全门禁设置的要求时触发强制评审。可以帮助研发人员在开发阶段发现潜在的安全风险，并要求他们在代码合并前处理这些安全漏洞，或者通过安全负责人的审批后才允许合并。快速、多类型的安全扫描加上安全门禁可以帮助企业更好的落地安全左移。

操作步骤：

1. 在子项目A的“安全——策略——新建策略——扫描结果策略”。
2. 根据需求自定义安全门禁策略和审核人。
3. 当合并请求中，源分支相较于目标分支的增量漏洞报告不满足安全门禁策略的要求，则无法进行代码合并，只有当开发人员解决相关漏洞问题，或通过审核人特批才能正常合并代码，从而实现安全卡点。

4.4.5.5 合并请求关闭GitLab议题

可以在合并请求中关联GitLab议题，当合并请求被执行合并后，该议题的状态自动变成关闭状态，即表示完成该议题。

操作步骤：

1. 在指定的合并请求的描述中，添加Closes #1、Closes #4, #6这种关键字加议题ID的格式内容

2. 合并请求执行合并后，对应的议题变成已关闭状态。

4.4.6 测试验证

如4.1.1所提到的，测试人员开展工作可能分为两个阶段：

4.4.6.1 功能测试

在单个任务开发阶段，即单个feature分支或单个fix分支开发完成后，需向main分支发起合并请求。在代码合并前，代码已部署到测试环境，测试人员可以在测试环境通过自动化工具或手动测试验证这个单一个功能是否正常，并参与这个功能的代码评审。若发现缺陷Bug，则可拒绝代码合并，同时给出意见反馈，开发人员重新提交代码进行修复；若功能都正常，则可在合并请求中给出通过批准，随后可执行代码合并。 当一个里程碑的所有功能开发完成后，基于main分支创建release分支，并进入集成测试阶段。

操作步骤：

1. 基于main分支创建release分支，如release/1.0.0。

4.4.6.2 集成测试

在集成测试阶段，基于main分支创建release分支，release分支包含了多个feature分支集成后的代码，从release分支触发代码构建，发布到测试环境进行集成测试。如果测试人员在这个阶段发现缺陷，那么可参考3.5.3提交缺陷议题，创建新的feature或fix分支来开发新功能或修复缺陷，再向main分支合并（功能测试阶段）。合并通过后使用cherry-pick拣选功能将这个合并请求拣选到release分支（集成测试阶段）。如果通过这个阶段的测试，则可以进入后续的交付、部署阶段。 操作步骤：

1. 在子项目A创建一个新的fix分支，如fix/tag-version-diff。
2. 在fix/tag-version-diff分支下修改一些代码，模拟测试人员在集成测试中发现了一些缺陷，需要修复。
3. 参考4.4.4章节，将fix/tag-version-diff合并到main分支。
4. 在子项目A的“代码——提交”中，找到已从fix分支合并到main分支的代码提交，点击进入。
5. 将该合并请求拣选到release/1.0.0分支。

4.4.7 交付、部署

4.4.7.1 测试环境交付

在集成测试阶段，也就是基于release分支触发流水线，可以看到：

1. 在测试环境的服务器中，也能看到这个软件包被scp命令拷贝到了服务器中，这是deploy-job实现的功能。本示例仅在deploy-job中打印“测试环境”字符。

4.4.7.2 生产环境交付

集成测试通过，就可以准备发布正式版本。

操作步骤：

1. 在子项目A“代码——标签”中新建标签（tag）。
2. 填写“标签名称”，如1.0.1，“创建自”通过集成测试的release分支，即release/1.0.0分支
3. 在生产环境的服务器中，也能看到这个软件包被scp命令拷贝到了服务器中，这是deploy-job实现的功能。本示例仅在deploy-job中打印“生产环境”字符。
4. 在子项目A“部署——软件包库”中，已经有生产环境的安装包了，这是upload-job实现的功能。

5. 监控反馈

当软件已经完成交付、部署，那么就进入了运维阶段，企业可以结合自己的实际情况采用不同的监控手段来了解软件的运行情况。 当软件发生故障时，运维人员、测试人员、开发人员再将问题进行定位，按照第3章节的步骤，创建新的需求或缺陷议题，并开始下一轮开发工作。

至此，极狐GitLab工作流已经完全跑通，并形成了闭环，感谢您的阅读。

main分支

只存线上的代码，只有确定可以上线时的才合并到main上，并且在main的基础上打Tag。

develop分支

初次创建develop时，需要从main分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。

feature分支

用于开发功能的分支，必须从最新的develop分支代码拉取。分支命名基本上是feature/xxxxx（和功能相关的名字或JIRA Ticket ID带描述）。

不强制提交到远程仓库，可以本地创建。比如，某开发人员开发登录功能，开发人员从develop分支的最新代码创建新分支命名为feature/login，然后切换到这个新分支开始开发。

开发完成后，测试差不多完成，合并到develop分支。

TODO: 只要有代码合并到develop就要出发自动化测试

release分支

当develop分支已经有了本次上线的所有代码的时候，并且以通过全部测试的时候，可以从develop分支创建release分支了，release分支是为发布新的产品版本而设计的。

通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。

比如，此次1.0版本所有的功能版本都已经合并到了develop上，并且所有测试都已经通过了测试，那就创建新的release分支release/v1.0。切换到新分支，修改最新的版本号等，不允许大的更改。

hotfix分支

当线上出现bug需要紧急修复时，从当前main分支派生hotfix分支。

修改线上bug，修改完成后合并回develop和main分支。

比如，在线上v1.0登录功能出现问题，我从main拉取代码创建新的分支hotfix/v1.0_login，修改完成后合并到main和develop上。

tag

上线合并到main以后,保留版本历史记录,从main创建tag版本

分支生命周期

场景说明

正常的业务需求流程

当接收到正常的业务需求时，需要约定一个大的发布版本（一次迭代）以及这个发布版本包含的多个jira任务，一个发布版本必须在一个时间点上发布；如果jira上的任务粒度太大，则需要拆分细化成更小的jira子任务（工作量在1~2人日为准，最好控制在一天以内）。

以develop为基准创建一个分支，分支名称为“feature-jira编号-开发人员姓名全拼”，如“feature-ONC-21-zhangsan”，jira任务ONC-21的所有开发工作都在feature-ONC-21-zhangsan，所有开发过程的commit message需要填写具体的开发内容。

开发及单元测试工作完成后创建merge request合并到develop分支，合并请求消息同样需要复制jira的内容描述以及具体的开发内容。

开发人员的自测工作基于合并后的develop分支代码进行，如果这个发布版本所有jira任务全部自测通过后，基于测试通过的develop分支创建一个release分支，分支名称为“release-版本号”，如“release-ctrip1.0”，测试人员基于release分支进行测试。

测试人员继续在新建的release分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到develop分支；如果验证通过则准备生产上线，

生产上线时将release代码合并到main分支，并打tag，tag名称为“tag-版本号”，从release打包上线。

紧急bug修复流程

当发现线上bug需要紧急修复时（开发人员需要确保bug修复已经在jira录入），需要以main分支为基准创建一个hotfix分支，分支名称为“hotfix-jira编号-开发人员姓名全拼”；

bug修复代码直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。测试人员直接在hotfix分支测试测试

通过后，开发人员同时请求合并到main分支,release分支,develop分支，合并请求消息同样需要复制jira的任务描述以及具体的开发内容。

生产上线时将hotfix代码合并到main分支，并打tag，tag名称为“tag-版本号-jira编号”，从release打包上线。

高优先级开发任务流程

如果在其他发布版本或迭代在开发中，而优先级更高的迭代需要同时进行，则需要特别注意。在创建feature分支时，要确保develop分支和main分支时一致的没有被未上线甚至未测试的代码污染过的，如果是则直接以develop分支为基准创建新的分支，命名规范如同正常的业务需求流程； 如果develop分支上已经有其他未上线分支的代码且该分支代码上线优先级较低，则不能以develop分支为基准创建分支，需要以main分支为基准创建分支。

当更高优先级feature功能开发和自测完成后，需要上测试环境，这时，需要以main分支为基准创建一个release分支，release分支名称为“release-版本号”，所有较高优先级的feature分支合并到高优先级的release分支上，并在该分支进行测试。

release分支测试通过后，合并到main分支准备上生产，同时release合并到develop分支；main分支生产上线后打tag，tag名称为“tag-版本号”。

前提

先阅读文档

https://github.com/sameersbn/docker-gitlab

https://www.damagehead.com/docker-gitlab/

测试环境下最简单的方式是使用 docker-compose

准备下面的yaml文件，执行 docker-compose up

浏览器打开http：//localhost：10080并使用默认用户名和密码登录：

• username: root
• password: 5iveL!fe

docker-compose.yml

version: '2.3'

services:
  redis:
    restart: always
    image: redis:6.2
    command:
    - --loglevel warning
    volumes:
    - redis-data:/data:Z

  postgresql:
    restart: always
    image: sameersbn/postgresql:14-20230628
    volumes:
    - postgresql-data:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm,btree_gist

  gitlab:
    restart: always
    image: sameersbn/gitlab:17.5.0
    depends_on:
    - redis
    - postgresql
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - gitlab-data:/home/git/data:Z
    healthcheck:
      test: ["CMD", "/usr/local/sbin/healthcheck"]
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 5m
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Shanghai
    - GITLAB_TIMEZONE=Shanghai

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=localhost
    - GITLAB_PORT=10080
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=
    - GITLAB_SECRETS_DB_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_SECRET_KEY_BASE=long-and-random-alphanumeric-string
    - GITLAB_SECRETS_OTP_KEY_BASE=long-and-random-alphanumeric-string

    - GITLAB_ROOT_PASSWORD=
    - GITLAB_ROOT_EMAIL=

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=false

    - [email protected]
    - [email protected]
    - [email protected]

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00

    - SMTP_ENABLED=false
    - SMTP_DOMAIN=www.example.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - [email protected]
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login

    - IMAP_ENABLED=false
    - IMAP_HOST=imap.gmail.com
    - IMAP_PORT=993
    - [email protected]
    - IMAP_PASS=password
    - IMAP_SSL=true
    - IMAP_STARTTLS=false

    - OAUTH_ENABLED=false
    - OAUTH_AUTO_SIGN_IN_WITH_PROVIDER=
    - OAUTH_ALLOW_SSO=
    - OAUTH_BLOCK_AUTO_CREATED_USERS=true
    - OAUTH_AUTO_LINK_LDAP_USER=false
    - OAUTH_AUTO_LINK_SAML_USER=false
    - OAUTH_EXTERNAL_PROVIDERS=

    - OAUTH_CAS3_LABEL=cas3
    - OAUTH_CAS3_SERVER=
    - OAUTH_CAS3_DISABLE_SSL_VERIFICATION=false
    - OAUTH_CAS3_LOGIN_URL=/cas/login
    - OAUTH_CAS3_VALIDATE_URL=/cas/p3/serviceValidate
    - OAUTH_CAS3_LOGOUT_URL=/cas/logout

    - OAUTH_GOOGLE_API_KEY=
    - OAUTH_GOOGLE_APP_SECRET=
    - OAUTH_GOOGLE_RESTRICT_DOMAIN=

    - OAUTH_FACEBOOK_API_KEY=
    - OAUTH_FACEBOOK_APP_SECRET=

    - OAUTH_TWITTER_API_KEY=
    - OAUTH_TWITTER_APP_SECRET=

    - OAUTH_GITHUB_API_KEY=
    - OAUTH_GITHUB_APP_SECRET=
    - OAUTH_GITHUB_URL=
    - OAUTH_GITHUB_VERIFY_SSL=

    - OAUTH_GITLAB_API_KEY=
    - OAUTH_GITLAB_APP_SECRET=

    - OAUTH_BITBUCKET_API_KEY=
    - OAUTH_BITBUCKET_APP_SECRET=
    - OAUTH_BITBUCKET_URL=

    - OAUTH_SAML_ASSERTION_CONSUMER_SERVICE_URL=
    - OAUTH_SAML_IDP_CERT_FINGERPRINT=
    - OAUTH_SAML_IDP_SSO_TARGET_URL=
    - OAUTH_SAML_ISSUER=
    - OAUTH_SAML_LABEL="Our SAML Provider"
    - OAUTH_SAML_NAME_IDENTIFIER_FORMAT=urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    - OAUTH_SAML_GROUPS_ATTRIBUTE=
    - OAUTH_SAML_EXTERNAL_GROUPS=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_EMAIL=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_USERNAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_FIRST_NAME=
    - OAUTH_SAML_ATTRIBUTE_STATEMENTS_LAST_NAME=

    - OAUTH_CROWD_SERVER_URL=
    - OAUTH_CROWD_APP_NAME=
    - OAUTH_CROWD_APP_PASSWORD=

    - OAUTH_AUTH0_CLIENT_ID=
    - OAUTH_AUTH0_CLIENT_SECRET=
    - OAUTH_AUTH0_DOMAIN=
    - OAUTH_AUTH0_SCOPE=
 
    - OAUTH_AZURE_API_KEY=
    - OAUTH_AZURE_API_SECRET=
    - OAUTH_AZURE_TENANT_ID=

volumes:
  redis-data:
  postgresql-data:
  gitlab-data: