• 有效清理 docker 所占用的空间

    2025年2月22日 作者：7forz
    暂无评论

    docker 用久了，难免会占用很多空间，有时候不知道是怎么占用的，就几十几百G了。

    要怎么找到是什么东西占用的？运行

    docker system df

    会返回像

    TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          59        8         83.21GB   77.55GB (93%)
Containers      9         8         2.344GB   0B (0%)
Local Volumes   1         1         0B        0B
Build Cache     10        0         6.38GB    5.47GB

    这样的结果。我们就可以发现是 image 和 build cache 在疯狂占用空间。

    对于 images，可以通过以下办法来删除：

    1. 删除悬空镜像 (未被任何镜像引用的中间层)

      docker image prune

      2. 删除所有未被容器使用的镜像 (包括未被标记和未被容器引用的镜像)

        docker image prune -a

        而 build cache，可以这样清理：

        docker builder prune

        后记：最近很少更新博文，我感觉最大的原因是大语言模型的普及。很多类似的技术问题，问 LLM 都能有比较好的答案，不用去阅读一些低质量的文章踩坑了。

      1. 解决 Docker PHP “Failed opening required ‘xxx.php'” 的问题

        2024年2月3日 作者：7forz
        暂无评论

        这个问题是我最近迁移本网站时遇到的。

        本网站是 Docker + PHP-FPM + nginx，迁移后，Wordpress 的 .php 访问报错：Failed opening required /xxx/wp-config.php

        很明显就是容器里没有权限。那么为什么会没权限呢？

        很久没搞这个的部署，忘得差不多了。经过重温与找资料，大概是这样解决的，不一定是完美的方案：

        原因：

        • Docker 的 PHP 运行的时候，默认是用www-data用户（并且uid=33），属于www-data用户组（且gid=33）
        • 某些系统自带了该用户与用户组（例如我网站迁移前所在的机器），某些没有自带（例如现机器）

        解决：

        1. 检查宿主机的用户、用户组是否有www-data，且 33 号的 uid/gid 是否被占用：
          # cat /etc/group
          # cat /etc/passwd
        2. 发现用户组 gid=33 被名为“tape”的用户组占用了（我的机器如此），似乎没有什么机会用到这个用户组，所以我把它的 id 改成 34：
          # groupmod -g 34 tape
        3. 创建 gid=33 的www-data用户组：
          # groupadd -g 33 www-data
        4. 创建 uid=33 的www-data用户，不创建home目录（-M），设置默认shell（-s）为nologin：
          # useradd -M -u 33 -g www-data -s /usr/sbin/nologin www-data

          至于为什么要这样创建，是为了尽可能模拟自带的www-data用户，在自带的机器上，passwd文件是这样的：
          # cat /etc/passwd | grep www-data
          www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

          而执行上述 useradd 后，passwd 是这样的，已经很像了：
          www-data:x:33:33::/home/www-data:/usr/sbin/nologin
        5. 最后，在宿主机，把缺少权限的整个目录所有权，赋予给www-data：
          # chown -R www-data:www-data some_directory

      2. 用 cron 表达式表示“每月的第几个星期几”

        2023年12月7日 作者：7forz
        暂无评论

        这个需求不是很常用，但需要用时，在网上不是很好搜索到，故在此记录。

        例如，要表示“每月的第二个星期六的12:34:00”，是这样写：

        0 34 12 ? * SAT#2

        注意，这个不是标准的形式，不是所有所有程序都接受这样的格式。一般程序都会有校验功能，可以检查下次执行的时间来进行确认。（第一是”?”表示不指定不一定支持，第二是”SAT”不一定支持，第三是”#2″更不一定支持）

      3. K8S 之就绪探针（Readiness Probe）

        2022年11月6日 作者：7forz
        暂无评论

        一个 Pod 创建之后，Service 马上就能选择它，并且请求也有可能转发到这个 Pod。然而，Pod 的启动很可能是需要时间的，在启动、加载、预热的过程中，如果有请求转发进来，这个请求很可能会失败。

        K8S 处理这个问题的办法是引入了就绪探针（Readiness Probe），readiness 这个词的词根不是“read”，而是“ready”，就是说这个 Pod ready 了没有。如果没 ready，请求就不转发给它；ready 之后，就可以转发给它。

        综合运用 Liveness Probe 和 Readiness Probe，可以让服务的自愈、启动、重启、升级更得心应手。

        就绪探针怎么判断 Pod 是否就绪？和存活探针（Liveness Probe）一样，常用的有 httpGet 和 exec 两种方式。

        httpGet

        顾名思义，K8S 通过发送 HTTP GET 请求，判断 Pod 是否就绪。若该请求收到 HTTP 2xx~3xx 状态码均判断为成功。下面是例子：

        apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: container-0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
            scheme: HTTP           # 还可以是HTTPS
          initialDelaySeconds: 60  # 容器启动后要等待多少秒后探针才开始，默认是0秒，最小值是0
          timeoutSeconds: 10       # 探测超时的阈值。默认值是1秒。最小值是1
          periodSeconds: 30        # 每次执行探测的时间间隔（单位是秒）。默认是10秒。最小值 1
          successThreshold: 1      # 视为成功的最小连续成功次数。默认值是1。存活和启动探测的该值必须是1。最小值是1
          failureThreshold: 3      # 视为失败的最小连续失败次数。默认值是3。最小值是1

        exec

        还可以通过 linux 命令的方式来判断，若 error code = 0，则表明命令正常。

        apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

        上面这个例子中，每 5s 会cat /tmp/healthy一次，30s 后该文件被删除，cat /tmp/healthy就会失败。

        相关参考

        1. K8S官方文档 除了 httpGet 和 exec，还有基于 TCP 端口和 gRPC 的探测方式
        2. https://support.huaweicloud.com/devg-cci/cci_05_0026.html

      4. Docker 部署 Nginx+MariaDB(MySQL)+PHP 记录，与对应 docker-compose 实现

        2020年2月23日 作者：7forz
        暂无评论

        Docker 火了这么多年，我也要学习体验一下。就在阿里云的服务器上部署一个 Nginx+MariaDB+PHP 环境吧。

        安装

        不同系统的安装方法见官方文档，包括了 Linux 的几个发行版和 Windows、MacOS 的详细步骤。我在 Linux 系统上安装。装完记得运行systemctl enable docker把 docker 调成自动启动。

        Docker Hub

        Docker 的各种 images 会发布在 Docker Hub，要善用这个网站来搜索想要的资源。

        网络

        在创建 docker 容器（container）之前，先考虑一下网络的架构。我打算创建 3 个容器：nginx、mariadb、php，其中，需要暴露的端口只有 nginx 容器的 80 (443) 端口。根据这篇文档中的：

        User-defined bridge networks are best when you need multiple containers to communicate on the same Docker host.

        我应该选择 bridge 网络，bridge 的具体的使用见此文档。在宿主机上运行

        docker network create --driver bridge my_bridge

        创建一个名称为 my_bridge 的bridge。

        Nginx

        先把 Nginx image 拉下来：docker pull nginx，默认会拉 latest 这个 tag （tags 可以在 Docker Hub 先搜索 nginx 然后点进去找到）。

        接下来创建容器：

        docker run --name my_nginx --network my_bridge -p 80:80 -v /var/www/php_env:/usr/share/nginx/html -e TZ="Asia/Shanghai" -d --restart always nginx

        参数解释：（详情见文档）

        --name my_nginx           容器命名为my_nginx
--network my_bridge       连接到my_bridge网络
-p 80:80                  把容器的80端口(后)暴露为宿主机的80端口(前)
-v /var/www/php_env:/usr/share/nginx/html   把宿主机的目录(前)mount到容器的指定路径
-e TZ="Asia/Shanghai"     设置环境变量
-d                        在后台运行
--restart always          自动启动、重启
nginx                     image名称

        如无意外，浏览器可以访问http://服务器IP的网页了。

        阅读更多…