Docker（一）：初识Docker、安装并快速上手实践，逐帧过！！！

引言

在软件开发的征途中，环境配置的“玄学问题”、依赖冲突的“版本地狱”以及虚拟机臃肿的“资源黑洞”，曾是无数开发者深夜调试的噩梦。无论是微服务架构的复杂性，还是跨平台算法（如无人机SLAM）的部署挑战，传统开发模式在效率与一致性上的短板愈发凸显。Docker的诞生，如同一把锋利的瑞士军刀，以容器化技术为核心，直击环境隔离、资源浪费与交付混乱的痛点——它通过轻量级容器替代笨重的虚拟机，用“一次构建，处处运行”的镜像标准化交付，彻底重构了开发、测试与部署的协作链条。本文将以“极简理论+高频实战”的风格，从环境配置的实操陷阱到无人机SLAM算法的容器化案例，带您穿透概念迷雾，在10分钟内完成从安装验证到首个容器运行的完整闭环，助您无缝踏入容器化开发的新纪元。

最后，如果大家喜欢我的创作风格，请大家多多关注up主，你们的支持就是我创作最大的动力！如果各位观众老爷觉得我哪些地方需要改进，请一定在评论区告诉我，马上改！在此感谢大家了。

各位观众老爷，本文通俗易懂，快速熟悉Docker，收藏本文，关注up不迷路，后续将持续分享Docker纯干货（请观众老爷放心，绝对又干又通俗易懂）。请多多关注、收藏、评论，评论区等你～～～

---

---

正 文

---

一、为什么需要Docker？（干货无废话）

传统开发环境在项目协作、部署和维护中普遍存在以下问题，这些问题催生了Docker等容器化技术的出现。Docker通过容器化技术重新定义了软件开发和部署的流程，解决了传统虚拟化技术的局限性。

1.1 传统开发环境的痛点

1.1.1 环境不一致性问题

（一）问题场景：

• 开发人员在本地编写代码时环境（如 Windows + Python 3.10 + MySQL 8.0 ）运行正常，但测试和生产环境（如 Linux + Python 3.8 + MySQL 5.7 ）可能因操作系统、软件版本、依赖库差异导致程序崩溃。
• 经典案例：“在我机器上能跑啊！”（It works on my machine!），团队成员因环境差异陷入调试泥潭。

（二）Docker的解决方案：

• 通过 镜像（Image） 将应用代码、运行时环境、系统工具、依赖库等打包成一个标准化的文件，确保从开发到生产的 全流程环境一致性 。
• 例如：开发者在本地构建一个包含 Python 3.10 和 MySQL 8.0 的镜像，测试和运维可直接使用该镜像部署，完全避免环境差异。
  
  

1.1.2 依赖冲突与重复配置的困扰

（一）问题场景：

• 同一服务器需运行多个应用时，不同应用可能依赖同一软件的不同版本（如 Java 8 vs Java 11）。
• 传统方式需手动隔离环境（如虚拟环境 venv 或 nvm），配置复杂且易出错。
• 重复配置环境浪费大量时间（如为每个新成员安装相同的开发工具链）。

（二）Docker的解决方案：

• 利用容器（Container）的隔离性，每个应用运行在独立的容器中，依赖互不干扰。

• 通过 Dockerfile 定义环境配置，实现 一键构建、重复使用 。例如：

  FROM python:3.10-slim
  COPY requirements.txt .
  RUN pip install -r requirements.txt
  COPY . /app
  WORKDIR /app
  CMD ["python", "app.py"]
  

  一行命令 docker build 即可生成标准化环境，无需手动安装依赖。什么是 Dockerfile ，怎么使用它，后面会持续讲解，关注up不迷路！！！
  
  

1.1.3 虚拟机资源占用高、启动慢的局限性（特指 Windows 环境）

（一）问题场景：

• 虚拟机（VM）需为每个实例分配完整操作系统（Guest OS），占用大量CPU、内存和磁盘资源（通常以GB为单位）。

• 虚拟机启动缓慢（分钟级），难以支持微服务架构下快速扩缩容的需求。

• 开发和测试环境中，频繁启停虚拟机效率极低。

（二）Docker的解决方案：

• 容器与主机共享操作系统内核（如Linux内核），无需额外虚拟化硬件，资源占用极低（通常为MB级）。

• 容器启动速度达到秒级，完美适配CI/CD流水线、微服务动态扩缩容等场景。

• 资源利用率对比示例：

  指标	虚拟机	Docker容器
  资源占用	1-10 GB	10-100 MB
  启动时间	1-5 分钟	0.1-2 秒
  并发实例数量	有限（资源限制）	高（轻量级）

• 不同环境下Docker的对比：

  场景	Windows + Linux容器	Ubuntu/Linux + 容器
  是否需要虚拟机	是（Hyper-V/WSL2）	否（直接使用主机内核）
  资源占用	较高（需运行Linux内核）	极低（仅容器进程隔离）
  启动速度	较快（依赖WSL2优化）	极快（秒级）
  典型用途	开发、测试跨平台应用	生产环境、高密度部署

注释：

1. Docker的轻量化优势在Linux环境中体现最彻底，而在Windows上运行Docker时，仍需权衡虚拟化层的开销（尽管已大幅优化）。这也是为何生产环境通常优先选择Linux部署Docker容器的重要原因。如何安装win和Ubuntu双系统，请看 Ubuntu教学系列（一）：安装win11+Ubuntu双系统并配置Ubuntu常用软件 。

2. 传统开发环境的三大痛点——环境不一致、依赖冲突、虚拟机效率低下——直接影响了软件交付的速度和质量。Docker通过容器化技术，以轻量级、标准化、可移植的镜像和容器，实现了开发、测试、生产环境的一致性，解决了依赖冲突，并显著提升了资源利用率和部署效率。
   
   

1.2 Docker带来的变革

1.2.1 轻量级容器 vs 传统虚拟化技术

（一）传统虚拟化（虚拟机）的架构：

• 依赖Hypervisor（如VMware、VirtualBox）虚拟化硬件资源，每个虚拟机需要运行完整的Guest OS（如Ubuntu、Windows Server）。

• 资源消耗高：每个虚拟机独占分配的内存、磁盘空间（通常GB级），且Guest OS启动需加载内核和系统服务。

• 启动速度慢：从开机到应用就绪通常需要1-5分钟。

（二）Docker容器的架构：

• 基于Linux内核的容器化技术（如cgroups资源隔离、namespace进程隔离），直接共享主机操作系统内核。

• 轻量级：容器仅包含应用及其依赖（如代码、运行时、库文件），资源占用通常为MB级。

• 快速启动：容器本质是隔离的进程，启动时间仅需毫秒到秒级。
  
  

1.2.2 “一次构建，到处运行” 的核心价值 （这个功能真的绝绝子！）

（一）传统部署的痛点：

• 应用需针对不同环境（开发、测试、生产）重复配置，且依赖手动调整，易出错。

• 跨平台兼容性问题（如Windows开发，Linux部署）。

（二）Docker的解决方案：

• 镜像（Image）标准化：

  • 通过Dockerfile定义构建步骤，将代码、依赖、环境配置打包为镜像。

  • 示例：

    FROM node:18-alpine       # 基础镜像（含Node.js运行时）
    WORKDIR /app
    COPY package*.json ./
    RUN npm install          # 安装依赖
    COPY . .                 # 复制代码
    EXPOSE 3000
    CMD ["npm", "start"]     # 启动命令
    

  • 构建命令：docker build -t my-app .，生成可在任何Docker环境中运行的镜像。

• 跨平台运行：

  • 镜像可在支持Docker的任意平台（Linux、Windows、Mac、云服务器）运行，无需修改配置。

  • 例如：本地开发完成后，直接推送镜像到镜像仓库（如Docker Hub、阿里云ACR），生产环境通过 docker pull 拉取并运行。

（三）核心价值体现：

• 环境一致性：开发、测试、生产环境使用完全相同的镜像，彻底告别“在我机器上能跑”的问题。

• 简化部署流程：运维无需手动安装依赖，只需运行容器即可。
  
  

1.2.3 标准化交付与快速水平扩展的优势

（一）标准化交付：

• 镜像作为交付单元：

  • 应用以镜像形式交付，包含所有运行时依赖，确保环境一致性。
  • 支持版本化管理（如my-app:v1.0），便于回滚和追踪问题。

• 镜像仓库（Registry）：

  • 集中存储和管理镜像（如Docker Hub、Harbor私有仓库）。
  • 团队协作时，开发者只需拉取镜像即可复现环境，无需共享复杂的环境配置文档。

（二）快速水平扩展：

• 动态扩缩容：

  • 容器启动速度快，结合编排工具（如Kubernetes、Docker Swarm），可根据负载自动扩缩实例数量。
  • 示例：电商大促时，秒级扩容100个容器实例应对流量高峰，结束后自动释放资源。

• 微服务友好：

  • 每个微服务独立容器化，故障隔离性强，更新时不影响其他服务。
  • 结合CI/CD流水线，实现自动化构建、测试和部署。
    
    

1.3 真实场景应用案例（无人机SLAM算法方向）

1.3.1 多传感器配置的标准化开发环境

（一）背景知识：

SLAM算法通常依赖多传感器融合（如摄像头、LiDAR、IMU、GPS），不同开发者本地环境配置差异（如ROS版本、OpenCV版本、PCL库版本）易导致代码运行不一致。

（二）Docker的解决方案：

• 封装传感器驱动的统一镜像：

  • 使用Dockerfile定义包含ROS Noetic、OpenCV 4.5、PCL 1.12和硬件驱动的基础镜像：

    FROM ubuntu:20.04
    RUN apt-get update && apt-get install -y \
        ros-noetic-desktop-full \
        libopencv-dev=4.5.5+dfsg-1ubuntu1 \
        libpcl-dev=1.12.1+dfsg-1 \
        # 安装IMU驱动（如InvenSense MPU6050）
        i2c-tools libi2c-dev
    WORKDIR /slam_ws
    COPY ./slam_algorithm /slam_ws/src
    RUN catkin_make  # 编译ROS工作空间
    CMD ["roslaunch", "slam_node", "drone_slam.launch"]
    

  • 开发者只需克隆代码仓库，运行docker build即可复现一致的传感器数据处理环境。

• 避免驱动冲突：如Ubuntu 18.04与20.04的ROS版本差异问题。

• 快速验证算法：新成员无需手动安装ROS和驱动，直接通过容器运行SLAM节点。
  
  

1.3.2 跨平台SLAM算法的快速验证

（一）背景知识：

无人机可能搭载不同硬件平台（如NVIDIA Jetson、Intel NUC、树莓派），SLAM算法需在不同架构（ARM/x86）和算力条件下测试性能。

（二）Docker的解决方案：

• 多架构镜像构建与分发：

  • 使用docker buildx构建跨平台镜像（支持ARM64/x86_64）：

    docker buildx create --use
    docker buildx build --platform linux/amd64,linux/arm64 -t my-slam-algo:v1.0 .
    

  • 在Jetson（ARM）和服务器（x86）上直接运行同一镜像，测试算法在边缘设备上的实时性。

• 资源限制模拟：

  • 通过容器限制CPU和内存，模拟低算力场景：

    docker run --cpus 2 --memory 4g my-slam-algo:v1.0
    

• 硬件兼容性测试：无需购置多台设备，快速验证算法在Jetson上的运行帧率（如是否满足30FPS实时性要求）。

• 资源优化依据：通过容器监控（docker stats）分析算法在不同资源配额下的内存占用和CPU利用率。
  
  

1.3.3 SLAM算法的持续集成与仿真测试

（一）背景知识：

SLAM算法需在Gazebo仿真环境中验证定位精度（如轨迹误差、地图重建质量），传统手动测试效率低且难以覆盖多场景。

（二）Docker的解决方案：

• 自动化仿真测试流水线：

  • 在CI/CD工具（如GitLab CI）中启动容器化仿真环境：

    stages:
      - test
    slam_simulation_test:
      stage: test
      image: my-gazebo-slam-env:v2.0  # 预装Gazebo、ROS、评估工具
      script:
        - roslaunch gazebo_drones drone_city.launch  # 启动城市仿真场景
        - rosrun slam_evaluation evaluate_trajectory.py  # 自动计算轨迹误差
      artifacts:
        paths:
          - ./trajectory_error_report.csv
    

• 多场景批量测试：

  • 并行启动多个容器，分别加载不同仿真场景（如室内、森林、城市）：

    docker run -d my-gazebo-slam-env:v2.0 indoor_scenario
    docker run -d my-gazebo-slam-env:v2.0 forest_scenario
    

• 回归测试自动化：每次代码提交自动运行仿真，生成精度报告（如ATE绝对轨迹误差）。

• 多场景覆盖：快速验证算法在光照变化、动态障碍物等复杂环境下的鲁棒性。
  
  

二、Docker核心概念快速解读（了解即可）

Docker 的核心架构围绕三个简单但关键的概念展开：镜像（Image）、容器（Container） 和 仓库（Registry）。它们的关系类似于“模板-实例-存储”，共同支撑容器化技术的运行与协作。其架构设计基于 Client-Server 模式，结合 Linux 内核的 Namespace 和 Cgroups 技术，实现高效的容器化能力。

2.1 三大基础组件

2.1.1. 镜像 Image ：只读的 “模板”

（一）核心特性

• 定义：镜像是静态的、分层的只读文件，包含运行应用所需的一切：代码、运行时环境、系统工具和依赖库。

• 类比：类似“软件安装包”（如 .iso 文件），是容器运行的基础模板。

• 分层结构：

  • 每一层对应一个操作指令（如安装依赖、复制文件）。
  • 分层设计提高复用性：不同镜像可共享基础层（如 Ubuntu 系统层）。

（二）生命周期

• 构建：通过 Dockerfile 定义镜像内容（如从基础系统层叠加应用层）。

• 存储：镜像以只读方式存储在本地或仓库中。

• 使用：镜像不可直接修改，需通过重新构建生成新版本。
  
  

2.1.2 容器 Container ：镜像的 “运行实例”

（一）核心特性

• 定义：容器是镜像的动态实例，像一个轻量化的独立进程，拥有隔离的运行环境（文件系统、网络、进程空间）。

• 类比：类似“运行中的虚拟机”，但更轻量（秒级启动，MB级资源占用）。

• 生命周期：

  • 创建：从镜像启动一个容器（如 docker run）。
  • 运行：执行容器内的应用逻辑（如启动 Web 服务）。
  • 停止/删除：容器停止后资源释放，数据默认不保留（需挂载存储卷）。

（二）与镜像的关系

• 镜像 → 容器：镜像提供静态模板，容器是动态实例。

• 多实例支持：一个镜像可同时启动多个容器（如微服务多副本）。

• 对比表格：镜像 vs 容器

  特性	镜像 Image	容器 Container
  状态	静态（只读）	动态（可运行）
  存储	分层文件（不可修改）	临时文件系统（默认不保留数据）
  用途	提供运行模板	执行具体任务
  生命周期	长期存储，多版本管理	临时运行，随用随启

2.1.3. 仓库 Registry ：镜像的 “应用商店”

（一）核心特性

• 定义：仓库是镜像的集中存储和分发平台，支持版本管理和团队协作。

• 类型：

  仓库类型	示例	用途
  公共仓库	Docker Hub	存储公开镜像（如 nginx）
  私有仓库	Harbor、阿里云 ACR	企业内部镜像托管与权限控制

（二）核心功能

• 推送（Push）：将本地镜像上传至仓库（如 docker push）。
• 拉取（Pull）：从仓库下载镜像到本地（如 docker pull）。
• 版本管理：通过标签（Tag）区分镜像版本（如 v1.0、latest）。

注释：

这里有一个概念需要各位观众老爷进行区分：Docker Registry 和 Code Repository。可能很多人，很早就听到过 仓库 这个名词，最出名的莫过于 Github ，但是两者之间是由明显的区别，千万不要混淆！！！

GitHub 不属于 Docker 的仓库（Registry）范畴，而是属于代码仓库（Code Repository），两者的核心用途和存储内容完全不同：

• 分类对比

  类型	Docker 仓库（Registry）	GitHub
  存储内容	Docker 镜像（二进制文件）	源代码、文档等文本文件
  核心用途	分发和运行容器化应用	代码版本控制、协作开发
  典型代表	Docker Hub、Harbor、阿里云 ACR	GitHub、GitLab、Gitee
  操作对象	镜像（通过 docker pull/push）	代码（通过 git clone/push）
  依赖关系	用于容器运行时（如 Docker 引擎）	用于开发阶段（如代码编写、合并）

• 为什么容易混淆？

  • 名称相似性：两者都含“仓库”一词，但英文中分别对应 Registry（镜像仓库）和 Repository（代码仓库）。

  • 协作关联性：在实际开发中，二者常结合使用：代码存在 GitHub 中（管理源代码）。通过 CI/CD 从代码构建 Docker 镜像，推送到 Docker 仓库（如 Docker Hub）。最终从 Docker 仓库拉取镜像运行容器。
    
    

2.1.4 三者的协作关系

（一）流程图

+---------------+          +------------------+              +----------------+  
| 镜像（Image）  | → 运行 → | 容器（Container） | ← 拉取/推送 ← | 仓库（Registry |  
|   静态模板     |          |     动态实例      |              |   存储与分发    |  
+---------------+          +-------------------+              +----------------+  

（二）协作示例

1. 开发阶段：通过 Dockerfile 构建镜像（如 my-app:1.0）。
2. 测试阶段：从镜像启动容器，验证功能。
3. 部署阶段：将镜像推送到仓库，生产环境拉取并运行容器。

一句话总结

• 镜像是“模板”，容器是“运行中的程序”，仓库是“存储模板的商店”。
• 三者协作实现“一次构建，随处运行”的核心价值。
  
  

2.2 架构设计解析

2.2.1 Client-Server 模式的工作流程

（一）架构组成

1. 客户端（Client）：用户通过命令行工具（如 docker）或 API 发起操作（如 docker run）。
2. 守护进程（Daemon）：后台服务（dockerd），负责接收客户端指令并管理容器、镜像等核心资源。
3. REST API：客户端与守护进程通过 HTTP API 通信（默认使用 Unix Socket 或 TCP）。

（二）工作流程

（三）示例：当用户运行 docker run nginx 时，

1. 客户端将指令发送给 Daemon。
2. Daemon 检查本地是否存在 nginx 镜像，若不存在则从仓库拉取。
3. Daemon 调用容器运行时（如 containerd）创建容器进程。
4. 返回容器运行状态给客户端。
   
   

2.2.2 Docker Daemon 的核心职责

Daemon 是 Docker 的“大脑”，主要功能包括：

职责	说明
镜像管理	拉取、构建、存储镜像，处理分层文件系统。
容器生命周期管理	创建、启动、停止、删除容器，管理容器进程。
网络管理	创建虚拟网络（如 bridge）、分配容器 IP、配置端口映射。
存储管理	管理数据卷（Volume）和绑定挂载（Bind Mount），实现数据持久化。
安全控制	通过用户命名空间隔离权限，限制容器对宿主机的访问。

2.2.3 命名空间（Namespace）与控制组（Cgroups）技术浅析

• 命名空间（Namespace）

  • 核心作用：实现资源隔离，让每个容器拥有独立的“视图”。

  • 隔离维度：

    命名空间类型	隔离内容	容器中的应用场景
    PID	进程 ID	容器内进程无法看到宿主机其他进程
    Network	网络设备、IP、端口	容器拥有独立 IP 和端口映射
    Mount	文件系统挂载点	容器内文件系统与宿主机隔离
    UTS	主机名和域名	容器可自定义主机名（如 my-app）
    IPC	进程间通信（消息队列等）	容器间通信隔离
    User	用户和用户组 ID	容器内用户权限与宿主机分离

• 控制组（Cgroups）

  • 核心作用：限制和监控容器资源使用（CPU、内存、磁盘 I/O 等）。

  • 关键功能：

    功能	说明
    资源限制	限制容器最大内存使用（如 2GB）、CPU 配额（如使用 1 核的 50%）。
    优先级分配	为容器分配 CPU 或磁盘 I/O 的优先级（如高优先级容器优先获取资源）。
    资源统计	监控容器的实际资源消耗（如 docker stats 显示的内存和 CPU 使用率）。
    进程控制	冻结或终止超限的容器（如内存耗尽时触发 OOM Killer）。

2.3 关键术语关系图

2.3.1 镜像→容器→仓库的转化关系

2.3.2 容器生命周期示意图

三、10分钟快速上手实践

以下是在 Ubuntu 24.04.2 系统中安装 Docker 的标准化步骤，建议安装在Ubuntu系统中，而不是使用虚拟机。如何安装Ubuntu系统，请参考 Ubuntu教学系列（一）：安装win11+Ubuntu双系统并配置Ubuntu常用软件 。

3.1 环境准备 — 安装、验证、卸载

3.1.1 传统安装方法（手动安装）

Step 1： 卸载旧版本（如有）

sudo apt remove docker docker-engine docker.io containerd runc
sudo apt autoremove

Step 2： 安装依赖工具

# 确保系统已安装 apt 工具链和 HTTPS 支持
sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

Step 3： 添加 Docker 官方 GPG 密钥

# 添加 Docker 的官方软件源签名密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Step 4： 添加 Docker APT 仓库

将 Docker 仓库添加到 APT 源列表
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Step 5： 安装 Docker 引擎

# 更新包索引并安装 Docker 核心组件
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Step 6： 验证安装

# 检查版本
docker --version  # 输出示例：Docker version 24.0.7, build afdd53b

# 查看系统信息
sudo docker info  # 显示 Docker 引擎状态、容器/镜像数量等

3.1.2 一键安装（鱼香ROS） 强烈推荐这种安装方式！

本条指令来源于鱼香ROS社区，相比于上述手动安装则要方便很多，属于一键式操作！

wget http://fishros.com/install -O fishros && . fishros

可能会在这个界面卡顿一会，等待即可，不要着急，喝口水，莫慌 ～～～

当出现 请输入[ ]内的数字以选择：，请输入 8 即可。

3.1.3 卸载 Docker

若需完全卸载 Docker，执行：

sudo apt purge docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

3.2 首个容器体验

3.2.1 运行官方 HelloWorld 容器

sudo docker run hello-world

操作解析：

1. 检查本地镜像：Docker 会先在本地查找名为 hello-world 的镜像。
2. 拉取镜像：若本地不存在，则从默认仓库（Docker Hub）自动下载该镜像。
3. 创建并运行容器：基于镜像启动一个临时容器，执行预定义的任务（输出欢迎信息）。
4. 自动停止：任务完成后，容器自动停止并保留记录。

终端输出示例：

Unable to find image 'hello-world:latest' locally  
latest: Pulling from library/hello-world  
2db29710123e: Pull complete  
Digest: sha256:aa0cc8055b82dc2509bed2e19b275c8f463506616377219d9642231e5353380a  
Status: Downloaded newer image for hello-world:latest  

Hello from Docker!  
This message shows that your installation appears to be working correctly.  
...（后续为详细信息）

注释： 相信大家运行后会报错，我发拉取 / 不存在该容器，这是因为docker官方已经关闭中国大陆这边的服务请求。为解决这个问题，必须要进行 换源 ！

这个章节我们主要目的还是以熟悉docker操作为主，下一篇文章马上为大家讲解这部分内容。由于目前很多的源都具有时效性（也就是说，今天可以用，明天能不能还可以用就不一定了），希望大家能够关注up主，收藏本文和下一篇文章，我也会定期给大家更新。

3.2.2 解读终端输出的欢迎信息

输出内容分为几个关键部分：

输出段落	含义
Unable to find image...	本地没有 hello-world 镜像，开始从 Docker Hub 拉取。
Pull complete	镜像下载完成，层（Layer）已存储到本地。
Hello from Docker!	容器运行后输出的预设信息，证明 Docker 安装成功。
后续说明性文字	解释 Docker 的工作流程： 1. 客户端发送指令给守护进程。 2. 守护进程拉取镜像并运行容器。 3. 容器执行任务后停止。

3.3.3 查看本地镜像列表

docker images

输出示例：

REPOSITORY     TAG       IMAGE ID       CREATED        SIZE  
hello-world    latest    feb5d9fea6a5   1 year ago     13.3kB  

字段解析：

字段名	说明
REPOSITORY	镜像名称（通常为 仓库名/镜像名 格式）
TAG	版本标签（默认 latest）
IMAGE ID	镜像唯一标识（哈希值缩写）
CREATED	镜像创建时间
SIZE	镜像占用的磁盘空间

关键点：

• hello-world 镜像非常小（仅 13.3kB），因为它仅包含一个简单的可执行文件。
• 若之前运行过其他镜像（如 nginx），此处会列出所有本地存储的镜像。

---

结 束 语

---

能够看到这里的观众老爷，无疑是对up的最大肯定和支持，在此恳求各位观众老爷能够多多点赞、收藏和关注（强烈推荐大家关注一下up主和新建的这个合集“Docker”）。在这个合集中，未来将持续给大家分享关于Ubuntu系统生态中的多种常见开发实用操作。未来也将继续分享Docker、conda、ROS等等各种实用干货。感谢大家支持！

我也除了更新刚刚新开的“Docker”合集，也会继续更新“Ubuntu系统教学系列”合集，欢迎大家继续关注。各位观众老爷的支持，就是我创作的最大动力！！！

---

往期回顾 — 专栏 “Docker” 和 专栏 “Ubuntu系统教学系列”

往期专栏： Ubuntu系统教学系列

本期专栏： Docker