Python运维开发学习（一）

is 运算符

a = [1, 2, 3]
b = [1, 2, 3]

print(a is b)  # 输出 False

c = a
print(c is a)  # 输出 True

这是因为在 Python 中，变量实际上是对象的引用。当你创建一个列表并将其赋值给变量 a 时，Python 实际上会创建一个新对象（即该列表）并将变量 a 设置为指向该对象的引用。同样地，当你将变量 b 设置为对另一个具有相同元素的新列表的引用时，Python 实际上会创建一个新对象并将变量 b 设置为指向该对象的引用。因此，a 和 b 引用两个不同的对象，它们具有相同的值但位于不同的内存位置，因此 a is b 返回 False。

当你将变量 c 设置为 a 的引用时，它实际上是将 c 设置为指向与 a 相同的对象，因此 c is a 返回 True。也就是说，c 和 a 都是指向相同的列表对象的引用。

Python中的容器类型

可以分为三类：

序列类型：序列类型包括列表(list)、元组(tuple)和字符串(str)等有序且可重复的容器类型。序列中的元素是按照顺序排列并且可以通过索引进行访问。

集合类型：集合类型包括集合(set)和不可变集合(frozenset)等无序且不可重复的容器类型。集合中的元素是无序的，因此不能通过索引进行访问，但是可以使用一些集合操作进行处理。

独立的容器类型：这些容器类型既不属于序列类型也不属于集合类型。常见的独立容器类型包括字典(dict)、defaultdict、Counter、deque等。这些容器类型的特点都是不同于序列和集合，而且它们之间的功能也各不相同。

需要注意的是，虽然这三种容器类型在某些方面可能会有一些相似之处，但是它们的本质区别还是比较明显的，因此在使用时需要根据具体情况选择适当的容器类型。

元组和列表可以包含任意类型的对象，包括其他元组、列表和集合等可变对象；而集合中的元素必须是可哈希的，即不可变的基本类型（如整数、浮点数、字符串等）或者元组（元组中的元素也必须是可哈希的）。怎么理解？

在Python中，可哈希对象是指在其生命周期中不可改变其哈希值的对象。哈希值是通过一个称为哈希函数的算法从对象的内容计算得出的整数值。Python中的不可变类型（例如数字、字符串和元组）都是可哈希的，而可变类型（例如列表和字典）则是不可哈希的。

由于集合是一种基于哈希表实现的数据结构，因此它要求集合中的元素必须是可哈希的，以便能够对其进行快速查找和操作。因此，集合中的元素必须是不可变的基本类型（如整数、浮点数、字符串等），或者是元组并且元组中的元素也必须是可哈希的。

相比之下，列表和元组并没有这样的限制，它们可以包含任何类型的对象，包括其他列表、元组和集合等可变对象。这是因为列表和元组不需要支持快速的哈希查找，因此它们可以包含任意类型的元素。

需要注意的是，如果一个元组或者列表包含了可变对象，那么虽然该元组或者列表本身是不可变的，但是其中的可变对象仍然可以被修改。这意味着你可以通过修改元组或列表中的可变对象来改变其内容。

元组和列表都支持迭代操作，而集合也可以被迭代（遍历顺序不确定）

Python 中，迭代顺序是由每个对象的内部实现决定的。因此，当你迭代一个元组或列表时，Python 会按照元素在序列中出现的顺序依次遍历它们；而当你迭代一个集合时，则不能保证遍历顺序与元素添加顺序相同。这是因为集合的内部实现方式不同于元组和列表，集合是使用哈希表来存储元素的，哈希表是一种无序的数据结构。

# 遍历元组
my_tuple = (1, 2, 3)
for item in my_tuple:
    print(item)

# 遍历列表
my_list = [4, 5, 6]
for item in my_list:
    print(item)

# 遍历集合
my_set = {7, 8, 9}
for item in my_set:
    print(item)

分别打印出了 1、2、3 和 4、5、6。但是集合的遍历顺序是不确定的，可能打印出 8、7、9 或者是 9、7、8 等等。

因此，在编写程序时，如果需要按照特定的顺序来访问元素，则应该使用列表或元组；而如果只需要遍历元素，无需关心它们的顺序，则可以使用集合。

何时使用元组列表，何时使用集合

在需要频繁进行元素添加、删除、修改操作时，应该使用列表或者元组；在需要快速查找元素的情况下，应该使用集合。

在 Python 中，列表和元组是序列类型，它们都可以存储多个元素，并且支持对元素进行索引、切片、迭代等操作。而集合则是一种无序的容器类型，其中不允许有重复的元素，同时支持快速的成员资格（membership）测试。

在内部实现上，列表和元组都是使用**数组（array）来存储元素，其中每个元素的大小相同；而集合则是使用哈希表（hash table）**来存储元素，这使得集合能够快速地查询某个元素是否存在，但也导致了添加、删除元素的效率较低。

因此，在处理大量数据时，如果需要频繁进行元素添加、删除、修改操作，则应该使用列表或者元组。这是因为，与集合相比，列表和元组的内部实现更加简单，添加、删除、修改操作都可以通过直接操作指定索引来完成，因此效率更高。另外，由于列表和元组是按照元素在序列中出现的顺序依次存储的，因此它们也适用于需要保持元素插入顺序的场景。

而在需要快速查找元素的情况下，应该使用集合。这是因为，集合的哈希表实现可以快速判断某个元素是否存在于集合中，而不必遍历整个集合，因此成员资格测试的效率很高。另外，由于集合不允许有重复元素的存在，可以在一定程度上保证数据的唯一性，这对于一些需要去重的场景也非常方便。

数据结构角度：
列表的内部实现采用了动态数组（dynamic array）的数据结构，这使得它可以在 O(1) 的时间复杂度下进行末尾添加和查询操作。而对于插入和删除操作，虽然需要移动一些元素来腾出空间或填补空缺，但由于数组的访问速度很快，因此仍然能够实现较高效率的操作。同时，Python 还为列表提供了类似 pop()、remove() 等方法来进行删除操作，这些方法都是经过优化的，也可以在较短的时间内完成操作。

相比之下，集合的插入、删除操作速度可能会较慢，因为它的内部实现是基于哈希表（hash table）的，需要进行哈希计算和重建等操作，而这些操作的时间复杂度要比列表的插入、删除操作更高。但是，由于哈希表的优势在于成员资格测试的查找速度非常快，因此集合适用于需要快速查找元素的场景。

所以，总体上来说，列表的插入、删除等操作速度是较快的，而集合的查找速度最快。但在具体场景中，应该根据实际需求来选择使用哪种数据结构。

让 Docker 镜像更简单

可以从以下几个方面入手：

选择基础镜像时要考虑大小和安全性。建议使用官方的基础镜像或者社区认可的基础镜像，这些镜像通常比较小且具有良好的安全性。尽量避免使用过于庞大的镜像作为基础镜像，以减小镜像的大小。

在编写 Dockerfile 文件时，尽量遵循“最小化原则”，即只安装必要的软件包和依赖项。可以通过多阶段构建（multi-stage build）来减小 Docker 镜像的大小，这样可以在一个阶段中构建应用程序，并在另一个阶段中将其拷贝到最终的镜像中。

在镜像中只包含必要的文件和目录。可以使用 .dockerignore 文件来忽略掉不需要包含在镜像中的文件和目录，这样可以减小镜像的大小。

尽量避免在容器内运行多个进程。在 Docker 中，推荐每个容器只运行一个进程，并将其作为容器的 ENTRYPOINT 或 CMD 命令。这样可以避免容器中出现过多的进程，降低容器的复杂度和资源消耗。

定期清理不必要的容器和镜像。可以使用 docker system prune 命令来清理无用的容器、镜像和卷等资源，以释放磁盘空间。

总之，要让 Docker 镜像更简单，需要从多个方面考虑，并遵循最小化原则，尽可能减小镜像的大小，降低容器的复杂度和资源消耗。

使用多阶段构建（multi-stage build）

多阶段构建是指将构建过程拆分成多个阶段，每个阶段都有自己的基础镜像，并且在每个阶段中仅安装必要的软件包和依赖项。这样，在最终的阶段中，只需要将应用程序和其依赖项复制到基础镜像中，就可以得到一个更加轻量级的 Docker 镜像了。

以下是一个使用多阶段构建的示例 Dockerfile：

# 第一个阶段：构建应用程序
FROM golang:alpine AS builder
WORKDIR /app
COPY main.go .
RUN go build -o myapp

# 第二个阶段：将应用程序拷贝到最终的镜像中
FROM alpine
RUN apk update && apk add ca-certificates
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

在上面的 Dockerfile 中，我们定义了两个阶段。第一个阶段使用 golang:alpine 作为基础镜像，并在其中构建应用程序。该阶段仅安装了 Go 编译器，并且在构建完成后，不会包含任何多余的文件或依赖项。

第二个阶段使用 alpine 作为基础镜像，并在其中安装了必要的运行时依赖项。然后，通过 COPY --from=builder /app/myapp . 命令将应用程序从第一个阶段拷贝到最终的镜像中。这样，我们就得到了一个轻量级的 Docker 镜像，其中只包含了必要的文件和依赖项。

总之，多阶段构建可以帮助我们在 Dockerfile 文件中遵循“最小化原则”，只安装必要的软件包和依赖项，从而减小 Docker 镜像的大小。

.dockerignore 文件

.dockerignore 文件与 .gitignore 文件类似，它定义了哪些文件和目录不应该被包含在镜像中。在构建镜像时，Docker 引擎会自动读取 .dockerignore 文件，并排除其中指定的文件和目录。

以下是一个示例 .dockerignore 文件：

# 忽略所有 .log 和 .tmp 文件
*.log
*.tmp

# 忽略 node_modules 目录以及其中的所有内容
node_modules/

# 忽略 README.md 文件
README.md

在上面的示例中，我们定义了三个规则来排除不必要的文件和目录。第一条规则排除所有 .log 和 .tmp 后缀的文件，第二条规则排除 node_modules/ 目录及其所有子目录和文件，第三条规则排除 README.md 文件。

通过使用 .dockerignore 文件，我们可以避免不必要的文件和目录被包含在 Docker 镜像中，从而减小镜像的大小，提高镜像构建和传输的效率。

需要注意的是，.dockerignore 文件不会影响宿主机文件系统上的文件和目录，而只在 Docker 构建过程中起作用。

推荐将每个容器作为一个独立的应用程序运行，并将它们作为容器的 ENTRYPOINT 或 CMD 命令。

这样可以确保每个容器只运行一个主进程，并且容器内的资源分配和管理更加清晰明了。

例如，下面是一个简单的 Dockerfile 文件的示例：

FROM node:14-alpine

WORKDIR /app

COPY package.json .
RUN npm install
COPY . .

# 将 node 命令作为容器的 ENTRYPOINT 命令
ENTRYPOINT ["node", "app.js"]

我们定义了一个基于 Node.js 的 Docker 镜像，在其中运行了一个简单的 Node.js 应用程序。通过将 node 命令作为容器的 ENTRYPOINT 命令，我们确保容器只运行一个 Node.js 进程，而不会出现其他多余的进程。

值得注意的是，虽然在 Docker 中建议每个容器只运行一个主进程，但并不意味着不能在容器中运行后台进程或服务。事实上，Docker 支持在容器中运行多个服务或进程，只要这些进程都与容器的主进程相关，并且能够正常地协同工作即可。

总之，在 Docker 中，我们应该尽量避免在容器内运行多个进程，保持每个容器只运行一个主进程的原则，这样可以确保容器的简单性和可维护性，并且降低容器的资源消耗。

docker system prune

# 清理所有未被使用的资源
$ docker system prune

# 清理指定类型的资源
$ docker system prune --volumes    # 清理数据卷
$ docker system prune --images     # 清理镜像
$ docker system prune --containers # 清理容器

使用 docker system prune 命令会清理掉所有未被使用的资源，包括一些可能还在使用中的资源。因此，在执行该命令之前，应该先检查一下哪些资源是需要保留的，并确保没有误删重要数据。

总之，定期清理不必要的容器和镜像等资源可以释放磁盘空间并提高系统性能。使用 docker system prune 命令可以帮助我们快速清理掉不需要的资源，但同时也需要注意慎重操作，避免误删重要数据。