1. 项目概述：为什么我们需要一个私有的 Helm Chart 仓库？

在 Kubernetes 生态里混迹多年的老手，对 Helm 这个“包管理器”一定不陌生。它让部署复杂的应用从“手搓 YAML 地狱”变成了相对优雅的“一键安装”。但当你和团队真正开始大规模使用 Helm 时，一个现实问题很快就会浮出水面：我们自己开发的 Chart 包，放哪儿？

Docker 有 Harbor、Nexus 可以当私有镜像仓库，那 Helm Chart 呢？总不能每次都 helm install 一个本地目录，或者把 .tgz 包用邮件传来传去吧？这既不安全，也毫无版本管理和协作可言。于是，一个私有的、集中的 Helm Chart 仓库就成了刚需。而 ChartMuseum ，就是社区里最成熟、最轻量、也最受认可的那个开源解决方案。

简单来说，ChartMuseum 就是一个专门用来存储、管理和分发 Helm Chart 的 Web 服务器。你可以把它理解为一个“Helm Chart 的专属网盘”，它提供了标准的 Helm 仓库 API，你的 Helm 客户端（ helm 命令行工具）可以像访问 https://charts.helm.sh/stable 这样的官方仓库一样，无缝地访问你的私有 ChartMuseum 服务，进行 helm repo add , helm search , helm pull , helm install 等一系列操作。

对于任何已经或计划将 Helm 作为标准应用交付工具的团队，无论是为了代码安全（不想把业务 Chart 公开到公共仓库）、提升部署效率（内部 Chart 秒级拉取），还是实现 CI/CD 流水线的自动化（构建完镜像，自动打包并推送 Chart），搭建一个 ChartMuseum 都是迈向成熟云原生实践的关键一步。接下来，我就结合自己多次在生产环境部署和运维 ChartMuseum 的经验，从头到尾拆解一遍。

2. 核心架构与部署方案选型

在动手之前，我们得先搞清楚 ChartMuseum 是怎么工作的，以及有哪些部署方式可选。这决定了后续的运维复杂度和扩展性。

2.1 ChartMuseum 的核心工作原理

ChartMuseum 本身是一个用 Go 语言编写的无状态 HTTP 服务。它的核心职责很简单：

  1. 提供仓库索引 ：响应 GET /index.yaml 请求，返回一个包含所有 Chart 元信息（名称、版本、描述、维护者等）的索引文件。Helm 客户端 helm repo update 本质上就是拉取这个文件。
  2. 存储 Chart 包 ：接受 POST /api/charts 请求，上传一个 .tgz 格式的 Chart 包。
  3. 提供 Chart 包下载 ：响应 GET /charts/<chartname>-<version>.tgz 请求，返回对应的 Chart 包文件。

它的巧妙之处在于， ChartMuseum 自身并不直接管理文件的存储 ，而是将存储逻辑抽象成了“存储后端”。它支持多种后端：

  • 本地文件系统 ：最简单，Chart 文件就存在运行 ChartMuseum 的服务器磁盘上。
  • Amazon S3 / 兼容 S3 的对象存储 ：如阿里云 OSS、腾讯云 COS、MinIO 等。这是生产环境最推荐的方式。
  • Google Cloud Storage
  • Microsoft Azure Blob Storage
  • 阿里云 OSS (原生支持)
  • OpenStack Object Storage

这种设计使得 ChartMuseum 非常轻量和灵活。你只需要关心服务本身，而数据的持久化、高可用、扩容则由成熟的对象存储服务来保障。

2.2 部署方案深度对比与选型理由

通常我们有三种主流部署方式：二进制部署、Docker 容器部署、Kubernetes 中部署。选择哪种，取决于你的技术栈和运维习惯。

方案一：二进制直接部署

  • 操作 ：从 GitHub Release 页面下载对应平台的二进制文件，直接运行。
  • 优点 ：极致简单，无需容器环境，适合快速测试或在传统虚拟机中验证。
  • 缺点 ：需要自行处理进程守护、日志收集、监控告警，升级麻烦。 不推荐用于生产环境 。
  • 命令示例 ： 
    wget https://github.com/helm/chartmuseum/releases/download/v0.15.0/chartmuseum-0.15.0-linux-amd64.tar.gz
tar -xzf chartmuseum-0.15.0-linux-amd64.tar.gz
./chartmuseum-0.15.0-linux-amd64/chartmuseum \
    --port=8080 \
    --storage="local" \
    --storage-local-rootdir="./chart-storage"

方案二：Docker 容器部署

  • 操作 ：使用官方 Docker 镜像 chartmuseum/chartmuseum:latest ，通过 docker run 或 docker-compose 启动。
  • 优点 ：封装性好，环境一致，易于版本管理和分发。配合 docker-compose 可以方便地定义依赖（如数据库，如果需要的话）和配置。
  • 缺点 ：仍需自行管理容器的生命周期、数据卷（如果使用本地存储）和网络。
  • 这是中小团队从测试过渡到生产的常见选择 。一个典型的 docker-compose.yml 可能长这样： 
    version: '3.8'
services:
  chartmuseum:
    image: chartmuseum/chartmuseum:v0.15.0
    container_name: chartmuseum
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - STORAGE=local
      - STORAGE_LOCAL_ROOTDIR=/charts
      - DEBUG=true # 仅调试时开启
      - DISABLE_API=false
    volumes:
      - ./chart-storage:/charts # 将本地目录挂载为存储目录
    command: --port=8080

方案三：Kubernetes 中部署 (Helm Chart 部署 ChartMuseum)

  • 操作 ：使用 ChartMuseum 官方维护的 Helm Chart 来部署它自己。这有点“自举”的味道，但非常云原生。
  • 优点 ：
    • 声明式配置 ：所有配置通过 values.yaml 管理，清晰易维护。
    • 完整的 K8s 生态集成 ：天然享受 Kubernetes 的 Service、Ingress、ConfigMap、Secret、PersistentVolumeClaim、HorizontalPodAutoscaler 等能力。
    • 高可用与弹性伸缩 ：轻松配置多副本，配合 HPA 实现自动扩缩容。
    • 无缝 CI/CD ：与集群内的其他 CI/CD 工具（如 Jenkins、Argo CD）集成更顺畅。
  • 缺点 ：需要具备一定的 Kubernetes 运维能力。
  • 这是生产环境，尤其是中大型 Kubernetes 集群的推荐方案 。它能让你的 Chart 仓库和你的应用部署环境处于同一技术栈，管理起来最统一。

注意 ：无论选择哪种部署方案， 强烈建议将存储后端设置为对象存储（如 S3/OSS） ，而不是本地存储或 PVC。因为 ChartMuseum 是无状态的，将数据存在对象存储，可以轻松实现服务实例的多副本、故障恢复和迁移，真正实现高可用。本地存储或 PVC 会将 Pod 与节点绑定，失去灵活性。

3. 生产级 Kubernetes 部署全流程实操

这里，我们详细走一遍最推荐的方案三：在 Kubernetes 集群中使用 Helm 部署 ChartMuseum，并配置阿里云 OSS 作为后端存储。假设你已经有一个可用的 K8s 集群和 Helm 客户端。

3.1 前置准备与依赖检查

  1. Kubernetes 集群 ：版本 1.16+ 为宜。确保 kubectl 可以正常连接。
  2. Helm 客户端 ：版本 3.x。安装方法略。
  3. 对象存储服务 ：以阿里云 OSS 为例。你需要提前创建一个 Bucket（例如 my-company-helm-charts ），并准备好具有该 Bucket 读写权限的 AccessKey ID 和 AccessKey Secret。
  4. 添加 ChartMuseum 的 Helm 仓库 ： 
    helm repo add chartmuseum https://chartmuseum.github.io/chartmuseum
helm repo update

3.2 定制化 values.yaml 配置文件

我们不直接使用默认配置，而是创建一个自定义的 values.yaml 文件。这是生产部署的核心。 

# custom-values.yaml
# 基础配置
env:
  open:
    # 禁用 API（如果不需要通过 API 删除 Chart 等操作，建议禁用以增强安全）
    DISABLE_API: false
    # 存储后端类型，这里使用阿里云 OSS
    STORAGE: aliyun
    # OSS Bucket 名称
    STORAGE_ALIYUN_BUCKET: "my-company-helm-charts"
    # OSS 区域端点
    STORAGE_ALIYUN_ENDPOINT: "oss-cn-hangzhou.aliyuncs.com"
    # OSS 前缀，相当于在 Bucket 里创建一个目录来存放 Chart
    STORAGE_ALIYUN_PREFIX: "stable/"
    # 是否开启 HTTPS（强烈建议开启）
    STORAGE_ALIYUN_SSL: true

# 通过 Secret 注入敏感信息（AccessKey）
# 先通过 kubectl 创建 Secret: kubectl create secret generic chartmuseum-oss-secret --from-literal=access-key-id='your-ak' --from-literal=secret-access-key='your-sk'
existingSecret: chartmuseum-oss-secret
existingSecretKeyAccessKeyId: access-key-id
existingSecretKeySecretAccessKey: secret-access-key

# 服务配置
service:
  type: ClusterIP # 生产环境通常用 ClusterIP，通过 Ingress 暴露
  port: 8080

# Ingress 配置（假设使用 nginx-ingress）
ingress:
  enabled: true
  className: "nginx"
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # 如果你使用 cert-manager 自动签发 TLS 证书
  hosts:
    - host: charts.mycompany.com # 你的私有仓库域名
      paths:
        - path: /
          pathType: Prefix
  tls:
    - hosts:
        - charts.mycompany.com
      secretName: chartmuseum-tls # TLS 证书的 Secret 名称

# 资源限制与持久化（注意：这里持久化的是缓存等，Chart 数据已在 OSS）
persistence:
  enabled: true
  accessMode: ReadWriteOnce
  size: 10Gi

# 自动伸缩配置（根据实际负载调整）
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 70
  targetMemoryUtilizationPercentage: 80

# 镜像配置（建议固定版本，避免自动升级导致意外）
image:
  repository: chartmuseum/chartmuseum
  tag: v0.15.0
  pullPolicy: IfNotPresent

关键配置解读：

  • STORAGE_ALIYUN_PREFIX ：这个参数非常有用。它允许你在一个 Bucket 内为不同环境（如 stable/ , dev/ , test/ ）或不同团队创建逻辑隔离的仓库。ChartMuseum 会将其视为根目录。
  • existingSecret ： 绝对不要 将 AccessKey 明文写在 values.yaml 或任何版本控制的文件中。务必使用 Kubernetes Secret 来管理。
  • ingress ：通过 Ingress 暴露服务，并配置 HTTPS，这是生产环境的标准做法。
  • autoscaling ：配置 HPA，让服务能够应对访问压力。

3.3 执行部署与验证

  1. 创建 Secret （在部署前完成）： 
    kubectl create secret generic chartmuseum-oss-secret \
  --namespace=helm-infra \ # 建议创建一个独立的命名空间，如 helm-infra
  --from-literal=access-key-id='你的AccessKey ID' \
  --from-literal=secret-access-key='你的AccessKey Secret'
  2. 使用 Helm 安装 ： 
    # 创建命名空间（如果不存在）
kubectl create namespace helm-infra

# 安装 ChartMuseum
helm upgrade --install chartmuseum chartmuseum/chartmuseum \
  --namespace helm-infra \
  -f custom-values.yaml \
  --version 3.9.1 # 指定 Chart 版本，保持稳定
  3. 验证部署 ： 
    # 查看 Pod 状态
kubectl -n helm-infra get pods -l app.kubernetes.io/instance=chartmuseum

# 查看 Service 和 Ingress
kubectl -n helm-infra get svc,ingress

# 测试仓库可访问性（从集群内一个临时Pod测试）
kubectl run -it --rm --image=alpine:latest test-curl -- /bin/sh
# 进入容器后执行
apk add --no-cache curl
curl -I https://charts.mycompany.com/index.yaml # 应该返回 200 OK
  4. 本地 Helm 客户端添加仓库 ： 
    helm repo add my-private-repo https://charts.mycompany.com
helm repo update
# 搜索一下，此时应该是空的
helm search repo my-private-repo

如果一切顺利，你的私有 Helm Chart 仓库就已经在 Kubernetes 集群中运行起来了，并且数据安全地存储在阿里云 OSS 上。

4. 日常使用、运维与最佳实践

仓库搭好了，怎么用起来？怎么管好它？这部分才是体现经验的干货。

4.1 Chart 的上传、管理与生命周期

上传 Chart ： 你不能直接用 helm push 命令，那是针对 Helm Hub（现在是 Artifact Hub）或某些特定插件的。ChartMuseum 的标准上传方式是使用 curl 或配套的 helm-push 插件（已废弃，不推荐）。

推荐使用 cm-push 脚本或直接 curl ：

  1. 使用 curl （最通用） ： 

    # 先打包你的 Chart
helm package ./my-awesome-chart/

# 会生成一个 my-awesome-chart-0.1.0.tgz 文件
# 使用 curl 上传
curl --data-binary "@my-awesome-chart-0.1.0.tgz" https://charts.mycompany.com/api/charts
# 如果需要认证（如果开启了 Basic Auth）
curl -u "username:password" --data-binary "@my-awesome-chart-0.1.0.tgz" https://charts.mycompany.com/api/charts

    成功会返回 JSON： {"saved": true} 。

  2. 集成到 CI/CD 流水线 ： 这是 ChartMuseum 价值最大化的地方。通常在你的 GitLab CI、Jenkins Pipeline 或 GitHub Actions 中，在构建完应用镜像后，添加一个步骤来打包和上传 Chart。 

    # GitHub Actions 示例片段
- name: Package and Push Helm Chart
  run: |
    helm dependency update ./chart
    helm package ./chart
    curl -u "${{ secrets.HELM_REPO_USER }}:${{ secrets.HELM_REPO_PASSWORD }}" \
         --data-binary "@$(ls *.tgz)" \
         https://charts.mycompany.com/api/charts

管理 Chart（查看、删除） ： ChartMuseum 提供了简单的管理 API（如果未禁用）。

  • 列出所有 Chart ： curl https://charts.mycompany.com/api/charts
  • 列出特定 Chart 的所有版本 ： curl https://charts.mycompany.com/api/charts/my-awesome-chart
  • 删除特定版本的 Chart ： curl -X DELETE https://charts.mycompany.com/api/charts/my-awesome-chart/0.1.0

重要心得 ： Chart 的删除操作是物理删除，且不可逆 。在生产环境中，建议通过流程管控（如合并请求审批）来控制 Chart 的上传，而非频繁删除。可以考虑设置存储后端（如 OSS）的对象版本控制或生命周期规则，自动归档旧 Chart 而非直接删除。

4.2 安全加固配置

一个暴露在公网的仓库，安全是头等大事。

  1. 启用身份认证（Basic Auth） ： 这是最基本的安全措施。ChartMuseum 支持通过环境变量 BASIC_AUTH_USER 和 BASIC_AUTH_PASS 或 BASIC_AUTH_PASS_FILE 来启用 HTTP Basic 认证。 

    # 在 values.yaml 的 env.open 部分添加
env:
  open:
    BASIC_AUTH_USER: "admin"
    # 更安全的做法是从 Secret 读取
    # BASIC_AUTH_PASS_FILE: /etc/auth/password

    然后，Helm 客户端添加仓库时需要带上凭据： 

    helm repo add my-secure-repo https://charts.mycompany.com \
  --username admin \
  --password your-strong-password

    CI/CD 中则使用变量或 Secret。

  2. 配置 TLS/HTTPS ： 如前文所述，必须通过 Ingress 配置 HTTPS。你可以使用 Let‘s Encrypt 的 cert-manager 自动管理免费证书，或使用公司内部的私有 CA 证书。

  3. 网络策略（NetworkPolicy） ： 在 Kubernetes 中，使用 NetworkPolicy 限制只有特定的命名空间（如 CI/CD 运行器所在的命名空间）或 Pod 可以访问 ChartMuseum 的 Service，减少攻击面。 

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-chartmuseum-from-cicd
  namespace: helm-infra
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/instance: chartmuseum
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: cicd-namespace # 你的 CI/CD 工具所在的命名空间
      ports:
        - protocol: TCP
          port: 8080

  4. 定期更新镜像 ： 关注 ChartMuseum 项目的安全公告，定期更新到新版本镜像，修复潜在漏洞。

4.3 监控、日志与高可用保障

  1. 监控指标 ： ChartMuseum 内置了 Prometheus 指标端点（默认在 /metrics ）。你可以配置 ServiceMonitor（如果你使用 Prometheus Operator）或直接在 Prometheus 配置中抓取这些指标。关键指标包括：

    • http_requests_total ：请求总数，按方法、路径、状态码分类。
    • http_request_duration_seconds ：请求延迟分布。
    • chartmuseum_charts_served_total ：Chart 服务次数。
    • 进程的内存、CPU 使用率。

  2. 日志收集 ： 确保 ChartMuseum 的容器日志被收集到中央日志系统（如 ELK、Loki）。通过环境变量 LOG_JSON=true 可以输出结构化的 JSON 日志，便于解析。在 values.yaml 中配置： 

    env:
  open:
    LOG_JSON: true

  3. 高可用性 ：

    • 多副本 ：在 values.yaml 中设置 replicaCount: 2 （或更多），并确保你的存储后端（如 OSS）支持多客户端并发读写。
    • 就绪探针 ：Helm Chart 默认已配置。确保它工作正常，避免流量被分发给未准备好的 Pod。
    • Pod 反亲和性 ：避免所有副本调度到同一个节点，提高容灾能力。 
    affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
              - key: app.kubernetes.io/instance
                operator: In
                values:
                  - chartmuseum
          topologyKey: kubernetes.io/hostname

5. 常见问题排查与运维技巧实录

即使按照最佳实践部署，在实际运维中还是会遇到各种问题。这里记录几个我踩过的坑和解决方法。

5.1 问题一：上传 Chart 失败，返回 500 或 413 错误

  • 现象 ： curl 上传时，服务器返回 500 Internal Server Error 或 413 Request Entity Too Large 。
  • 排查思路 ：
    1. 检查 ChartMuseum Pod 日志 ： kubectl logs -f <chartmuseum-pod-name> 。这是最直接的错误信息来源。
    2. 413 错误 ：这通常是 Ingress 控制器（如 nginx-ingress）的请求体大小限制导致的。默认值可能只有 1MB。
  • 解决方案 ：
    • 对于 nginx-ingress ，需要在 Ingress 注解中增加配置： 
      # 在 custom-values.yaml 的 ingress.annotations 部分添加
annotations:
  nginx.ingress.kubernetes.io/proxy-body-size: "20m" # 根据你的 Chart 大小调整
    • 更新 Helm Release： helm upgrade chartmuseum ... -f custom-values.yaml
    • 对于其他 Ingress 控制器，查找对应的请求体大小配置项。

5.2 问题二： helm repo update 速度慢或失败

  • 现象 ：更新仓库索引耗时很长，或者偶尔超时。
  • 排查思路 ：
    1. 检查索引文件大小 ：直接访问 https://charts.mycompany.com/index.yaml ，查看文件大小。如果 Chart 数量非常多（几百上千），索引文件可能会很大（几MB甚至更大）。
    2. 检查网络延迟 ：从客户端到仓库服务器的网络是否通畅。
    3. 检查 ChartMuseum 性能 ：观察 /metrics 端点，看请求延迟是否正常。
  • 解决方案 ：
    • 启用索引缓存 ：ChartMuseum 可以将生成的 index.yaml 缓存起来，避免每次请求都重新扫描存储后端（特别是对象存储）来生成索引，这对性能提升巨大。 
      # 在 values.yaml 的 env.open 部分添加
env:
  open:
    # 使用内存缓存，默认缓存 1800 秒（30分钟）
    CHART_INDEX_CACHE: "inmemory"
    # 或者使用 Redis 作为分布式缓存（多副本时必需）
    # CHART_INDEX_CACHE: "redis"
    # REDIS_ADDR: "redis-service:6379"
    • 定期清理旧 Chart ：建立 Chart 版本保留策略。例如，只保留每个 Chart 最新的 10 个版本，自动删除更旧的。这需要结合存储后端的生命周期策略或编写定时任务脚本来实现，ChartMuseum 本身不提供此功能。
    • 考虑使用 CDN ：如果仓库对公网开放且用户分布广，可以考虑将 index.yaml 和 Chart 文件托管在 CDN 上，ChartMuseum 作为源站。这需要对存储后端和 ChartMuseum 的配置做更深入的调整。

5.3 问题三：从仓库安装 Chart 时，提示 “checksum mismatch”

  • 现象 ： helm install my-release my-private-repo/my-chart 时，报错类似 “Error: checksum mismatch”。
  • 排查思路 ： 这是 Helm 客户端计算的 Chart 包 SHA256 校验和与仓库索引文件中记录的不一致导致的。
    1. 最常见原因 ：Chart 包在上传后，在存储后端（如 OSS）被意外修改了。可能是有人手动替换了文件，或者某些同步工具导致了文件损坏。
    2. 次要原因 ：ChartMuseum 在生成索引时计算校验和出错（罕见）。
  • 解决方案 ：
    1. 重新上传该版本的 Chart ：删除有问题的版本（ curl -X DELETE ），然后重新打包并上传。确保上传过程中网络稳定。
    2. 验证存储后端的完整性 ：下载 OSS 上的 .tgz 文件，手动计算其 SHA256 值，与 index.yaml 中记录的值对比。 
      # 下载 index.yaml
curl -s https://charts.mycompany.com/index.yaml | yq eval '.entries."my-chart"[] | select(.version == "0.1.0") | .digest' -
# 计算本地文件的 sha256
shasum -a 256 my-chart-0.1.0.tgz
    3. 建立上传流程规范 ：确保 Chart 上传是自动化流水线的一部分，避免人工干预。上传后，可以在流水线中添加一个验证步骤，下载刚上传的 Chart 并尝试 helm template 来确保其完整性。

5.4 一个实用的运维技巧：使用 chartmuseum 命令行工具进行批量管理

除了 curl ，ChartMuseum 项目还提供了一个官方的命令行工具，也叫 chartmuseum 。它对于批量操作和本地测试非常方便。

  1. 安装工具 ： 
    # 以 macOS 为例
brew tap chartmuseum/tap
brew install chartmuseum
  2. 常用操作 ： 
    # 设置仓库地址和认证（可保存）
chartmuseum config set --username=admin --password=xxx https://charts.mycompany.com

# 上传单个 Chart
chartmuseum push my-chart-0.1.0.tgz

# 上传目录下所有 Chart
chartmuseum upload ./

# 列出仓库所有 Chart
chartmuseum list

# 删除指定 Chart 版本
chartmuseum delete my-chart 0.1.0
    这个工具内部也是调用 API，但它封装了认证和错误处理，用起来比手写 curl 更友好，特别适合在本地或脚本中进行一些管理操作。

搭建和维护一个稳定、高效的私有 Helm Chart 仓库，是 Kubernetes 应用管理走向成熟和自动化的重要标志。ChartMuseum 以其简洁的设计、强大的存储后端兼容性和活跃的社区，成为了完成这项任务的首选工具。从最初的单机测试，到最终在 Kubernetes 集群中结合对象存储、Ingress、HPA 和严密的网络策略运行，这个过程本身也是对云原生运维能力的一次很好锻炼。记住，关键不在于把服务跑起来，而在于理解其背后的原理，并围绕安全、性能、可观测性构建一套可持续的运维体系。当你团队的开发者能够像使用公共仓库一样，自然而然地 helm install 来自内部仓库的 Chart 时，你就会感受到这种基础设施投资带来的回报。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区