容器

最近我把本地的容器管理引擎切换到了 Podman,本篇文章来讲讲我为什么从 Docker 切换到 Podman。 兼容 Docker Podman 对 Docker 的兼容非常好，Podman CLI 和 Docker CLI 命令几乎一致，这样就大大降低了切换成本，你甚至可以把 Podman CLI 就当作 Docker CLI 来用。 无守护进程 Docker 有一个守护进程 dockerd 负责管理容器、镜像和网络，Docker CLI 所有的指令都是通过 dockerd 来实际执行的。 Podman 却没有这样一个守护进程来处理，Podman CLI 会启动一个 conmon 进程来管理容器的生命周期，启动 conmon 后 Podman CLI 退出了，只有 conmon 带着它管理的容器作为系统进程保留了下来。 这种无守护进程的模式带来了很多好处： 我的系统不用一直启动一个 dockerd 守护进程，减少了系统资源的占用。 不会因为 dockerd 的异常退出导致所有容器崩溃 支持 rootless Podman 支持以普通用户运行而 docker 默认情况下是以 root 用户来运行的。当发生容器逃逸时 Docker 能拿到 root 权限而 Podman 会将影响范围限制到用户层面，降低了风险的影响范围。 更方便的网络设计 Podman rootless 默认使用的是 slirp4netns 它仅能给单容器提供网络服务，不能提供容期间的通讯，如果想容器间进行通讯就只能通过物理机映射端口或者把容器加入到同一个 pod 进行通讯了。 ...

目前我们公司已经深度的使用 Docker 来部署项目，在推进 Docker 落地的过程中，如何将 Docker 的配置文件更好的融入项目一直是困扰着我们的问题。 刚开始我们把 Docker 配置文件全部一股脑地放在项目里, 使编程架构和部署架构给混在了一起，如果开发和部署是一拨人倒还好，如果开发和部署是分开的两个工种，这种方式会造成一定程度的混乱。 以我们 Laravel 项目目录结构为例 . ├── app ├── artisan ├── bootstrap ├── composer.json ├── composer.lock ├── config ├── database ├── docker ├── docker-compose.yml ├── Dockerfile ├── .editorconfig ├── .env.example ├── .git ├── .gitattributes ├── .gitignore ├── .gitlab-ci.yml ├── package.json ├── .php-cs-fixer.cache ├── phpunit.xml ├── public ├── README.md ├── resources ├── rolling-update.sh ├── routes ├── storage ├── tests ├── vendor └── vite.config.js ...

Traefik 是一个用于反向代理的软件，如果你没有听说过，可以把它看作 Nignx 也是可以的。 Traefik 相比与 Nginx 更适合容器化部署： 只需要配置下容器的标签，Traefik 就可以自动发现新服务的加入，并根据标签绑定对应的域名 支持 TLS 证书自动申请（Let’s Encrypt） 支持 TCP/UDP 协议的转发 支持动态配置，可以在服务运行的状态下进行 Service、Router、Middleware 的增/删/改 Traefik 在项目最初部署阶段，会让整个部署更聚焦。以前用 Nginx 部署，你除了需要把容器启动起来，还需要配置 Nignx 将对应服务的域名反向代理到容器导出的端口上。 Traefik 将这个绑定域名的步骤放在了 docker compose 编写的阶段只需给容器加一个标签即可。项目上线时启动容器，Traefik 根据标签的配置把域名绑定到对应的容器上。 Traefik 可以通过 docker network 容器进行通讯，这意味着容器服务的端口无须再导出到物理机，Traefik 通过 docker network 就可以找到对应的容器处理请求。 Traefik 整个流程如下（中间件非必须，可有可无）： 入口点(Entrypoints) -> 路由(Routers) -> [中间件(Middleware)] -> 服务(Service) -> Server Traefik 的配置分为两个：程序配置和路由配置。程序配置通过 traefik.yml 文件进行配置。traefik.yml 提供了路由配置的解析引擎（Providers）。 traefik.yml 配置示例如下： log: level: INFO accessLog: {} api: dashboard: true insecure: true entryPoints: # 入口点配置 web: address: ":80" providers: docker: # 通过 docker label 的方式进行路由配置 endpoint: "unix:///var/run/docker.sock" exposedByDefault: false watch: true network: traefik_webgateway // docker network 用于 traefik 与容器进行通讯 接下来说说 Traefik 一些核心概念： ...

由于本地项目比较多，且对于环境要求各不相同，导致电脑上要装多个环境才能满足项目的运行。以我常用的 PHP 开发为例，需要 PHP 7.1 、PHP 7.3、PHP 8.1 、PHP 8.3，在这些项目中 compose 如何寻找到正确的 PHP 版本来安装依赖也是一个比较难以解决的问题。 为了不再受此困扰，我决定用容器来解决我面临的问题。开发环境容器化还有一个考虑就是容器本身对 CI/CD 比较友好，我们在测试和线上环境已经开始转向容器化部署，如果本地也进行容器化，编写好的 Dockfile 可以复用到后面的部署流程。 我的方案是为每个项目编写一个 docker-compose.yml 当我开始进入某个项目的开发工作时。只要打开对应的项目通过 docker-compose.yml 启动容器就可以启动对应项目的开发环境进行开发了。 容器化给我带来了哪些好处： 纯净的物理机：我不需要在物理机上安装各种各样的环境 低负载开发： 只有运行开发的相关环境，其他不相关的服务都不会在后台运行 部署和开发一致： 由于都是 Docker 部署，不会因为环境问题导致本地开发没问题线上出错的情况 专注于开发本身 ：免去了多种环境下互相兼容下的管理工作，专注于开发本身。 在容器话的过程中，我也遇到了一些问题，在这里记录一下，供诸君参考。 一些问题 首先遇到的问题就是依赖缓存的问题，比如一个 GO 的项目，因为 GO 的环境是在容器里，这样每次启动项目都要重新下载一次依赖，浪费时间也没有必要，于是我就将 mod 依赖下载目录通过挂载卷映射到我本机上。 如此依赖就解决了每次启动容器，都要重新安装依赖的问题，这样做还有一个额外的好处就是我其他的 GO 项目也也可以把 mod 依赖下载路径映射到相同的位置，这样就能实现下载依赖的复用，也能避免过多的磁盘占用。 如果你是前端项目使用 pnpm 管理工具，也可以参考上述思路解决 npm 包的依赖复用问题。 遇到的另一个问题就是 Windows 环境下，文件读写性能不足的问题。Windows 用户在开发环境容器化是需要注意一下，如果你的项目运行需要大量的文件读取，会导致项目启动异常慢，这个是 Windows 下面使用容器的硬伤，目前无解。Linux 和 MacOS 并不会出现此类问题。 工具推荐 如果你用 Visual Studio Code 进行开发，可以安装一个 Docker 的扩展，通过设置 Docker: Compose Down 和 Docker: Compose Up 两个快捷键实现快速的启动和停止项目。 ...

Laravel 是 PHP 里非常重要的一个框架，对于一个 PHPer 来讲，就算你没有用过 Laravel 也一定听说过它。 同事用 Laravel 开发了一个项目，需要部署一个测试环境，由于服务器的 PHP 环境不满足他项目的要求，所以需要多加一个 PHP 环境。 为了减少对原有系统的影响和更快的安装，我们决定用 Docker 来部署新项目的 PHP 环境。 本以为整个流程会无比的丝滑，但是在推进的过程中遇到了一些问题，也就有了这篇文章记录一下当时的经历，同时也为后续遇到类似问题的同仁提供解决思路。 整个部署方案如下： Dockerfile 很快就编写好了，本地测试能够成功的构建出 Docker Image。到此一切都很顺利，后续只需要把 Dockerfile 上传到服务器在服务器上把镜像构建出来，用 Nginx 解析一下就大功告成了。 当把代码上传到服务器，开始构建 Docker Image 时，问题出现了。在执行 apt update 的时候出现了下面的错误。 The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 本地构建好好的，怎么上线就出现问题了呢？简单的用搜索引擎搜索了一下，找了几篇带有"亲测"字样的文章进行验证，却都失败了。 后来我想既然这样问问 GPT 吧，看看它有没有什么高见。GPT 告诉我时因为服务器证书问题导致的，这里我就产生了一个疑问，我构建 Dcoker Image 执行 apt update 应该是在 Docker 环境里执行的呀，为什么会跟服务器证书有关系呢？ 于是我继续追问，它给出了自己的解释，让我开始质疑自己了。 ...