Docker、Kubernetes与AWS中控机是什么？

pp-周子晗（努力赶上课程进度版）2025-11-04 8:19

**本文摘要：**本文系统阐述了如何通过Docker、Kubernetes和AWS中控机构建现代云原生部署体系。文章以实际工作中遇到的"配置麻烦"问题为切入点，通过生动的比喻揭示了三大核心组件的本质：Docker 作为"标准化集装箱"，通过镜像分层和容器化技术解决了环境一致性问题；Kubernetes(k8s) 作为"智慧城市总控中心"，通过Pod、Deployment、Service等核心概念实现容器编排和集群管理； AWS中控机 则扮演"安全大门"角色，借助Systems Manager实现零端口安全访问。

三者形成完整技术栈：开发者在本地通过Docker打包应用→通过AWS中控机安全接入集群→使用kubectl操作Kubernetes进行部署→Kubernetes调度Node节点运行Docker容器。这种架构不仅解决了配置管理难题。

文章还提供了详尽的命令速查手册，涵盖Docker镜像构建、kubectl集群管理和AWS中控机登录等实操内容，形成从理论到实践的完整知识体系。
导师给我布置了一个任务：改造RTC后端服务中充斥着类似于if (env == "xxx_online")这类硬编码配置的"技术债"。正是这个任务，让我深入学习了现代云原生基础设施的三大支柱------Docker、Kubernetes和AWS中控机。本文将完整记录我的学习旅程，揭示它们如何共同解决从开发到生产的全链路挑战。

目录

开篇：一个配置管理问题引发的思考

[第一部分：Docker ------ 软件的"标准化集装箱"](#第一部分：Docker —— 软件的"标准化集装箱")

为什么需要Docker？从货运革命说起

Docker核心概念深度解析

[1. Docker镜像：集装箱的"设计蓝图"](#1. Docker镜像：集装箱的"设计蓝图")

[2. Docker容器：运行的"集装箱实例"](#2. Docker容器：运行的"集装箱实例")

Docker如何解决"配置"？

[第二部分：Kubernetes (kubectl) ------ 数据中心的"智慧城市总控中心"](#第二部分：Kubernetes (kubectl) —— 数据中心的"智慧城市总控中心")

从单机到集群：为什么需要编排？

Kubernetes架构深度解析

[1. 控制平面：城市的"政府大脑"](#1. 控制平面：城市的"政府大脑")

[2. 数据平面：城市的"基础设施"](#2. 数据平面：城市的"基础设施")

Kubernetes核心资源对象详解

Pod：最小的部署单元

Deployment：应用的"期望状态管理器"

Service：稳定的网络端点

ConfigMap和Secret：配置与敏感信息管理

kubectl：Kubernetes的"遥控器"

[第三部分：AWS中控机 ------ 通往云资源的安全大门](#第三部分：AWS中控机 —— 通往云资源的安全大门)

为什么需要中控机？从网络安全说起

AWS中控机架构深度解析

[1. 中控机实例：安全的访问枢纽](#1. 中控机实例：安全的访问枢纽)

[2. Systems Manager Session Manager：无端口访问](#2. Systems Manager Session Manager：无端口访问)

[第四部分：协同作战 ------ 从代码到集群的完美旅程](#第四部分：协同作战 —— 从代码到集群的完美旅程)

阶段一：应用打包（Docker）

阶段二：部署定义（Kubernetes）

阶段三：安全部署（AWS中控机）

阶段四：监控与维护

第五部分：完整命令速查手册

Docker常用命令

[Kubernetes (kubectl) 常用命令](#Kubernetes (kubectl) 常用命令)

AWS中控机常用命令

总结：云原生部署的思维转变

[1. 从"宠物"到"牲畜"的转变](#1. 从"宠物"到"牲畜"的转变)

[2. 声明式 vs 命令式](#2. 声明式 vs 命令式)

[3. 基础设施即代码](#3. 基础设施即代码)

[4. 安全左移](#4. 安全左移)

回到最初的任务

CI/CD流水线详解

[1. 基本概念](#1. 基本概念)

[2. 典型工作流程](#2. 典型工作流程)

[3. 关键技术组件](#3. 关键技术组件)

[4. 优势价值](#4. 优势价值)

[5. 实施建议](#5. 实施建议)

[6. 应用场景示例](#6. 应用场景示例)

开篇：一个配置管理问题引发的思考

在我接手的Platform和Signal服务中，充斥着大量这样的代码：

javascript 复制代码 
// 代码中随处可见的环境判断
if (environment === 'xxx_online') {
  databaseUrl = 'mysql://prod-host:3306/app';
  redisConfig = { host: 'redis-prod' };
} else if (environment === 'xxx_test') {
  databaseUrl = 'mysql://test-host:3306/app';
  redisConfig = { host: 'redis-test' };
} else if (environment === 'local_dev') {
  // ... 还有更多环境
}

这种模式的痛点显而易见，但更重要的是，它揭示了软件开发中的根本性挑战：

  1. 环境一致性：如何确保应用在开发、测试、生产环境中行为一致？

  2. 部署标准化：如何将复杂的部署流程转化为可重复、可靠的过程？

  3. 安全访问：如何在保证安全的前提下，高效地管理和调试分布式系统？

  4. 配置管理：如何优雅地管理不同环境的配置，避免硬编码和人为错误？

这个看似简单的配置重构任务，实际上是指向现代软件部署最佳实践的一扇窗口。而Docker、Kubernetes和AWS中控机正是解决这些问题的"黄金三剑客"。

第一部分：Docker ------ 软件的"标准化集装箱"

为什么需要Docker？从货运革命说起

在没有集装箱的时代，全球货运效率低下、成本高昂。货物形状大小不一，装卸过程繁琐，且在运输过程中极易损坏。1956年，马尔科姆·麦克莱恩发明的标准化集装箱彻底改变了这一局面。
软件部署也经历过同样的混乱时期。开发者在本地环境调试通过的应用，到了测试或生产环境就会出现各种奇怪问题，这就是经典的"在我本地是好的啊！"现象。

Docker就是软件世界的"标准化集装箱解决方案"。

Docker核心概念深度解析

1. Docker镜像：集装箱的"设计蓝图"

Docker镜像是一个只读的模板，包含了运行应用所需的一切：代码、运行时、系统工具、系统库和设置。

镜像分层机制是Docker的精髓所在：

  • 每个Docker镜像由多个只读层组成

  • 层与层之间相互独立，可以复用

  • 写时复制机制确保高效存储和快速启动

javascript 复制代码 
# Dockerfile示例：为Node.js应用构建镜像
FROM node:18-alpine        # 基础层：轻量级Linux + Node.js环境
WORKDIR /app               # 创建工作目录层
COPY package*.json ./      # 添加依赖文件层
RUN npm install            # 安装依赖层
COPY . .                   # 添加应用代码层
EXPOSE 8080                # 元数据层
CMD ["node", "server.js"]  # 启动指令层

执行docker build -t my-app:latest .后，这些层会被依次构建并缓存，后续构建时会跳过未变化的层，极大提升构建效率。

2. Docker容器：运行的"集装箱实例"

容器是镜像的运行实例，是一个轻量级、隔离的沙箱环境。

容器与虚拟机的本质区别：

  • 虚拟机：虚拟化硬件，每个VM包含完整的操作系统

  • 容器：虚拟化操作系统，共享主机内核，仅包含应用及其依赖

这种架构差异使得容器具有显著优势：

  • 启动速度：秒级 vs 分钟级

  • 资源占用：MB级 vs GB级

  • 性能损耗：几乎无损耗 vs 明显损耗

Docker如何解决"配置"？

Docker提供了优雅的解决方案：

方案一：构建时固化配置

bash 复制代码 
# 为不同环境构建不同的镜像
ARG ENV
COPY config/config_${ENV}.json /app/config.json

# 构建命令
docker build --build-arg ENV=xxx_online -t platform:xxx_online .
docker build --build-arg ENV=xxx_test -t platform:xxx_test .

方案二：运行时注入配置

bash 复制代码 
# 通过环境变量或挂载卷动态配置
docker run -e XX_HOST=prod-db -v ./config:/app/config platform:latest

这两种方案都实现了配置与代码的分离，让环境特定的配置在构建或运行时决定，而非硬编码在代码中。

第二部分：Kubernetes (kubectl) ------ 数据中心的"智慧城市总控中心"

从单机到集群：为什么需要编排？

当你的应用从单体架构演进为微服务架构，从单实例部署扩展到多实例部署时，会面临新的挑战：

  • 服务发现：实例之间如何相互发现和通信？

  • 负载均衡：如何将请求合理地分发到多个实例？

  • 弹性伸缩：如何根据负载自动调整实例数量？

  • 故障恢复：实例故障时如何自动替换？

  • 滚动更新：如何实现零停机部署？

Kubernetes就是为解决这些分布式系统挑战而生的容器编排平台。

Kubernetes架构深度解析

1. 控制平面：城市的"政府大脑"

控制平面负责全局决策和集群管理，包含以下核心组件：

  • API Server：集群的"前台"，所有交互的入口点

  • etcd：集群的"数据库"，存储所有状态数据

  • Scheduler："调度中心"，决定Pod在哪个Node运行

  • Controller Manager："管理部门"，确保集群状态符合预期

2. 数据平面：城市的"基础设施"

数据平面由多个Node（ worker节点）组成，每个Node包含：

  • Kubelet：节点"管家"，与管理平面通信并管理容器

  • Container Runtime：容器"执行引擎"（如Docker）

  • Kube Proxy：网络"路由器"，处理服务发现和负载均衡

Kubernetes核心资源对象详解

Pod：最小的部署单元

Pod是Kubernetes中最小的可部署单元，代表一个或多个容器的组合。

javascript 复制代码 
yaml
apiVersion: v1
kind: Pod
metadata:
  name: platform-pod
  labels:
    app: platform
spec:
  containers:
  - name: platform-container
    image: platform:v1.2
    ports:
    - containerPort: 8080
Deployment：应用的"期望状态管理器"

Deployment定义了Pod的期望状态，并确保实际状态与之匹配。

javascript 复制代码 
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: platform-deployment
spec:
  replicas: 3  # 期望3个副本
  selector:
    matchLabels:
      app: platform
  template:
    metadata:
      labels:
        app: platform
    spec:
      containers:
      - name: platform
        image: platform:v1.2
        ports:
        - containerPort: 8080
Service：稳定的网络端点

Service为Pod集合提供稳定的网络身份和负载均衡。

javascript 复制代码 
yaml
apiVersion: v1
kind: Service
metadata:
  name: platform-service
spec:
  selector:
    app: platform  # 选择所有标签为app=platform的Pod
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer  # 使用云提供商的负载均衡器
ConfigMap和Secret：配置与敏感信息管理

ConfigMap和Secret实现了配置与应用的彻底解耦。

yaml

javascript 复制代码 
yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
data:
  config.json: |
    {
      "database": {
        "host": "mysql-service"
      },
      "redis": {
        "host": "redis-service"
      }
    }

kubectl：Kubernetes的"遥控器"

kubectl是Kubernetes的命令行工具，名称来源于Kube-c-tl（Kubernetes Control Tool）。

常用命令分类：

  • 查询类：get、describe、logs

  • 操作类：apply、delete、scale、exec

  • 调试类：port-forward、top、debug

第三部分：AWS中控机 ------ 通往云资源的安全大门

为什么需要中控机？从网络安全说起

在生产环境中，最佳实践是将关键资源（如数据库、Kubernetes集群）部署在私有子网中，不直接暴露在公网。这就产生了一个矛盾：如何安全地访问这些内部资源？

传统SSH直连方案的问题：

  • 需要开放22端口，增加攻击面

  • 密钥管理复杂，容易泄露

  • 缺乏集中审计和权限控制

AWS中控机（跳板机）结合Systems Manager Session Manager提供了现代化的解决方案。

AWS中控机架构深度解析

1. 中控机实例：安全的访问枢纽

中控机是一台特殊配置的Amazon EC2（弹性计算云）实例，通常具有以下特性：

  • 部署在公有子网，可访问互联网

  • 配置了访问私有子网的安全组规则

  • 安装了必要的管理工具（kubectl、docker等）

  • 通过IAM角色获得最小权限原则的访问权限

IAM角色的定义

IAM（Identity and Access Management）角色是云计算服务（如AWS、Azure、GCP）中一种安全实体，用于授予特定权限。与用户或组不同，角色没有长期凭证（如密码或密钥），而是通过临时安全令牌动态分配权限。角色可被用户、服务或外部账户"扮演"，适用于跨服务或跨账户的安全访问。

IAM角色的核心特性

临时凭证机制 ：角色通过STS（安全令牌服务）生成临时凭证，有效期有限，降低长期密钥泄露风险。
跨账户授权 ：允许一个账户中的资源访问另一个账户的资源，无需共享永久凭证。
服务间委派：例如AWS Lambda执行时自动获取角色权限，无需手动管理密钥。

IAM角色的典型应用场景

EC2实例访问S3 ：为EC2绑定角色，使其具备读写S3存储桶的权限，无需在实例中存储AWS密钥。
跨账户协作 ：企业主账户为子账户分配角色，限制子账户仅能操作特定资源。
联邦身份集成：通过角色将企业AD用户映射到云权限，实现单点登录（SSO）。

2. Systems Manager Session Manager：无端口访问

Session Manager的工作原理：

  1. 出向连接：EC2实例上的SSM Agent主动与AWS SSM服务建立加密长连接

  2. 会话代理：用户通过CLI或控制台发起连接请求到SSM服务

  3. 反向隧道：SSM服务通过既有连接将用户会话代理到目标实例

安全优势：

  • 零入站端口：无需在安全组开放任何入站端口

  • IAM集中管控：基于AWS IAM进行细粒度权限控制

  • 完整审计：所有会话记录自动保存到CloudWatch和S3

第四部分：协同作战 ------ 从代码到集群的完美旅程

现在，让我们看看Docker、Kubernetes和AWS中控机如何协同工作，完成一次完整的服务部署。以下是这个过程的完整流程图：

阶段一：应用打包（Docker）

  1. 编写Dockerfile：定义应用运行环境

  2. 构建镜像 ：执行docker build生成标准化镜像

  3. 推送镜像 ：执行docker push上传到镜像仓库

javascript 复制代码 
# 多阶段构建优化镜像大小
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 8080
CMD ["node", "server.js"]

阶段二：部署定义（Kubernetes）

  1. 编写部署清单：定义Deployment、Service、ConfigMap等资源

  2. 配置管理：将环境配置从代码中抽离到ConfigMap

javascript 复制代码 
yaml

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: platform
spec:
  replicas: 3
  selector:
    matchLabels:
      app: platform
  template:
    metadata:
      labels:
        app: platform
    spec:
      containers:
      - name: platform
        image: my-registry/platform:v1.2
        ports:
        - containerPort: 8080
        env:
        - name: NODE_ENV
          value: production
        volumeMounts:
        - name: config-volume
          mountPath: /app/config
      volumes:
      - name: config-volume
        configMap:
          name: platform-config
javascript 复制代码 
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
data:
  config.json: |
    {
      "database": {
        "host": "mysql-service.prod.svc.cluster.local"
      },
      "redis": {
        "host": "redis-service.prod.svc.cluster.local"
      }
    }

阶段三：安全部署（AWS中控机）

  1. 安全登录 ：通过aws-con登录到中控机

  2. 执行部署 ：在中控机上运行kubectl apply

  3. 验证状态：检查Pod状态和服务日志

bash 复制代码 
# 1. 登录中控机
aws-con -i i-01bc6980fbf9574d0

# 2. 应用Kubernetes配置
kubectl apply -f deployment.yaml
kubectl apply -f configmap.yaml
kubectl apply -f service.yaml

# 3. 检查部署状态
kubectl get pods -l app=platform
kubectl rollout status deployment/platform

# 4. 查看服务日志
kubectl logs -l app=platform --tail=50

# 5. 端口转发用于本地测试
kubectl port-forward svc/platform-service 8080:80

阶段四：监控与维护

  1. 日常监控：通过中控机访问Kubernetes Dashboard或使用监控工具

  2. 故障排查：登录到具体Node检查容器状态

  3. 日志分析：通过kubectl或集中式日志系统查看应用日志

bash 复制代码 
# 查看Pod详细状态
kubectl describe pod <pod-name>

# 进入Pod容器调试
kubectl exec -it <pod-name> -- /bin/sh

# 查看节点资源使用情况
kubectl top nodes

# 查看服务端点
kubectl get endpoints platform-service

第五部分：完整命令速查手册

Docker常用命令

bash 复制代码 
# 镜像管理
docker build -t my-app:latest .          # 构建镜像
docker images                            # 列出镜像
docker push my-registry/my-app:latest    # 推送镜像
docker pull my-registry/my-app:latest    # 拉取镜像

# 容器管理
docker run -p 8080:8080 my-app:latest    # 运行容器
docker ps                                # 查看运行中容器
docker logs <container-id>               # 查看容器日志
docker exec -it <container-id> /bin/sh   # 进入容器
docker stop <container-id>               # 停止容器

Kubernetes (kubectl) 常用命令

bash 复制代码 
# 基础查询
kubectl get pods -A                      # 查看所有Pod
kubectl get services -A                  # 查看所有Service
kubectl get deployments -A               # 查看所有Deployment
kubectl get nodes                        # 查看集群节点

# 详细诊断
kubectl describe pod <pod-name>          # 查看Pod详情
kubectl logs <pod-name>                  # 查看Pod日志
kubectl logs -f <pod-name>               # 实时日志
kubectl exec -it <pod-name> -- /bin/sh   # 进入Pod

# 部署管理
kubectl apply -f deployment.yaml         # 部署应用
kubectl delete -f deployment.yaml        # 删除部署
kubectl scale deployment --replicas=5    # 扩缩容

# 调试工具
kubectl port-forward svc/<service> 8080:80  # 端口转发
kubectl top nodes                        # 节点资源监控
kubectl top pods                         # Pod资源监控

AWS中控机常用命令

bash 复制代码 
# 登录中控机
aws-con -i <instance-id>                 # 登录指定实例
aws-con -u <instance-id>                 # 更新凭证后登录

# 在中控机内部操作
ssh <internal-ip>                        # SSH到内部服务器
kubectl get pods                         # 操作Kubernetes集群
docker ps                                # 查看节点容器状态

# 网络诊断
ping <internal-host>                     # 测试网络连通性
nslookup <service-name>                  # DNS解析测试
telnet <host> <port>                     # 端口连通性测试

总结：云原生部署的思维转变

通过这次从"配置"到云原生的学习旅程，我深刻理解了现代软件部署的思维转变：

1. 从"宠物"到"牲畜"的转变

  • 传统思维：服务器像"宠物"，有名字，精心照料，出问题时尝试修复

  • 云原生思维：服务器像"牲畜"，有编号，出现问题直接替换

2. 声明式 vs 命令式

  • 命令式：关注"如何做"（执行一系列命令来部署）

  • 声明式：关注"做什么"（描述期望状态，让系统自动实现）

3. 基础设施即代码

将服务器、网络、配置等都定义为代码，实现版本控制、代码审查和自动化部署。

4. 安全左移

将安全考虑提前到设计和开发阶段，而非事后补救。

回到最初的任务

现在，对于导师布置的配置重构任务，我有了更完整的解决方案：

  1. 使用ConfigMap管理环境配置，彻底消除代码中的环境判断

  2. 为不同环境创建不同的Kubernetes命名空间和配置

  3. 通过CI/CD流水线自动构建镜像并部署

CI/CD流水线详解
  1. 基本概念

CI/CD（持续集成/持续交付）是一种现代软件开发实践，通过自动化流程将代码变更快速、可靠地交付到生产环境。它包含两个核心环节：

  • 持续集成（CI）：开发人员频繁将代码变更合并到共享仓库后，自动触发构建和测试流程

  • 持续交付/持续部署（CD）：将经过验证的代码自动部署到不同环境（测试/预生产/生产）

  1. 典型工作流程

  2. 代码提交阶段：

    • 开发人员在本地完成功能开发

    • 通过Git等版本控制系统提交代码到共享仓库（如GitHub/GitLab）

  3. 持续集成阶段：

    • 代码仓库自动触发CI流程（通常通过webhook）

    • 执行静态代码分析（如SonarQube）

    • 运行单元测试和集成测试

    • 构建软件包/容器镜像（如生成Docker镜像）

  4. 持续交付阶段：

    • 将构建产物部署到测试环境

    • 执行自动化验收测试

    • 人工确认（如需要）后触发生产环境部署

  5. 持续部署阶段（可选）：

    • 自动部署到生产环境

    • 执行监控和回滚机制

  6. 关键技术组件

  • 版本控制系统：Git、SVN等

  • 构建工具：Maven、Gradle、npm等

  • CI服务器：Jenkins、GitLab CI、GitHub Actions等

  • 容器化技术：Docker、Kubernetes

  • 配置管理工具：Ansible、Terraform

  • 监控工具：Prometheus、Grafana

  1. 优势价值

  • 质量提升：通过自动化测试及早发现问题

  • 交付加速：缩短从开发到部署的周期

  • 风险降低：小批量变更减少部署风险

  • 团队协作：促进开发、测试和运维协作

  1. 实施建议

  2. 从简单流程开始，逐步扩展

  3. 建立完善的自动化测试套件

  4. 使用基础设施即代码（IaC）管理环境

  5. 监控关键指标（构建成功率、部署频率等）

  6. 定期优化流水线性能

  7. 应用场景示例

  • Web应用开发：每次代码提交触发自动化测试，通过后自动部署到测试环境

  • 微服务架构：各服务独立构建部署，通过API契约测试确保兼容性

  • 移动应用：自动构建不同平台的安装包，执行设备兼容性测试

通过实施CI/CD流水线，团队可以实现更高效、可靠的软件交付流程，适应现代快速迭代的开发需求。

4. 利用AWS中控机安全地管理和监控部署状态

这套完整的云原生方案，不仅解决了眼前的配置管理问题，更为未来的微服务治理、可观测性、自动化运维奠定了坚实基础。

这次学习让我明白，现代软件工程不仅仅是编写代码，更是构建一个可靠、可扩展、可维护的完整系统。Docker、Kubernetes和AWS中控机正是这个系统的基础支柱，掌握它们是在云原生时代构建高质量软件的必备能力。

结语：

随着这篇博客接近尾声，我衷心希望我所分享的内容能为你带来一些启发和帮助。学习和理解的过程往往充满挑战，但正是这些挑战让我们不断成长和进步。我在准备这篇文章时，也深刻体会到了学习与分享的乐趣。

在此，我要特别感谢每一位阅读到这里的你。是你的关注和支持，给予了我持续写作和分享的动力。我深知，无论我在某个领域有多少见解，都离不开大家的鼓励与指正。因此，如果你在阅读过程中有任何疑问、建议或是发现了文章中的不足之处，都欢迎你慷慨赐教。

你的每一条反馈都是我前进路上的宝贵财富。同时，我也非常期待能够得到你的点赞、收藏，关注这将是对我莫大的支持和鼓励。当然，我更期待的是能够持续为你带来有价值的内容。

相关推荐
AWS官方合作商7 小时前
AWS云计算入门指南：从零到一，详解核心服务与免费套餐
云计算·aws
王道长服务器 | 亚马逊云7 小时前
AWS + 飞天CMS：高性能内容站的云端搭建方案
服务器·搜索引擎·aws
曾经的三心草11 小时前
最新版本组件的docker下载-Seata
运维·docker·容器
不爱笑的良田13 小时前
从零开始的云原生之旅（十一）：压测实战：验证弹性伸缩效果
云原生·容器·kubernetes·go·压力测试·k6
梁正雄13 小时前
15、Docker swarm-2-安装与存储
运维·docker·容器
Wang's Blog17 小时前
Nestjs框架: 微服务容器化部署与网络通信解决方案
docker·微服务·云原生·架构·nestjs
脚踏实地的大梦想家17 小时前
【Docker】P2 Docker 命令：从Nginx部署到镜像分享的全流程指南
java·nginx·docker
weixin_3077791317 小时前
基于AWS多区域部署的高可用性与灾难恢复架构设计
云计算·aws
我先去打把游戏先18 小时前
ESP32开发指南(基于IDF):连接AWS，乐鑫官方esp-aws-iot-master例程实验、跑通
开发语言·笔记·单片机·物联网·学习·云计算·aws
热门推荐
01GitHub 镜像站点02《大数据技术原理与应用》实验报告三 熟悉HBase常用操作03UV安装并设置国内源04综合整理：pdf预览显示：你尝试预览的文件可能对你的计算机有害。如果你信任此文件以及其来源，请打开此文件以看其内容，如何解决以正常预览文件05BongoCat - 跨平台键盘猫动画工具06Linux下V2Ray安装配置指南07jdk21下载、安装（Windows、Linux、macOS）08NVIDIA显卡驱动、CUDA、cuDNN 和 TensorRT 版本匹配指南09npm使用国内淘宝镜像的方法10GitLab 零基础入门指南：从安装到项目管理全流程