Introduction

最近在服务器上装了 Hermes Agent 它里面的 llm-wiki skill 引起了我的注意，当我将自己所有记录的笔记全部喂给了 llm-wiki 我发现事情开始变得不一样了。 初识 我们与 AI 交互的开始都源于一份小心试探的信任。当我把笔记上传到服务器，并告诉 Hermes Agent 去分析我的笔记时我并不知道会带来什么样的结果。但我内心确实是期待它能给我带来一丝惊喜。 当 Hermes Agent 告诉我笔记已导入完成时，我问他“当前我的知识库里有哪些内容？”，它给了我一个概括性的答复让我确定它已经把我笔记的内容完整的导入到了 llm-wiki 目录中。它也第一次了解了那么跟我深度绑定的信息。 当他回答完我的问题后提示我导入的数据保留了原有的结构，没有提炼成知识库的结构信息并给了我一个整理的方向。 随后我让他整理了知识库至此我的笔记已经完全集成到了llm-wiki。 能力初探 我让它通过知识库说说它对我的了解，它的回答让我觉得它在我工作的侧面对我是相当了解的。它知道我的主力开发系统，知道我使用的编辑器、知道我喜欢容器化等等等等，下面是我摘自它的回答片段： 你是一个重度 Linux / Neovim / 容器化用户，知识库里 Linux、Neovim、Docker、Podman 的内容很多。 我感觉你的开发环境画像大概是： Linux 桌面为主 偏 Arch 系发行版 喜欢 Neovim / LazyVim / NvChad 重视中文输入法、字体、Wayland/Electron/Wine 兼容性 倾向把本地开发环境容器化 对 Docker 和 Podman 都有实践经验 对 Traefik / Nginx / GitLab CI/CD 有实际部署经验 我看了它对我的描述，我觉得准确度相当的高。我曾经研究过 RAG 技术方案，就使用感受而言，我觉得 llm-wiki 以极低接入和使用门槛实现了这么高效的知识提取真的是相当厉害了。我对这种使用简单产品向来十分迷恋。 深入探索 我又提问“根据你对我的理解，你觉得我在职业上应该怎么走向下一个阶段”，它的回答让我觉得也许我们任何事情都可以先问问 AI 了。...

这些年在我个人的开发电脑上用过很多的发行版，基于 Debian 的 （Ubuntu , Linux Mint ）, 基于 Red Hat Enterprise Linux （ CentOS，Fedora），基于 Arch 的（EndeavourOS、Manjaro）,还有我们国产优秀发行版 deepin。 作为个人开发使用的发行版我比较看重的点是能否更快的使用最新的软件版本和内核版本，能否充分利用硬件性能以及能否使用最新的 Linux 技术。 基于以上原因我把发行版锁定在 Arch 或基于 Arch 的发行版。Arch 的滚动更新，能够让我一直使用最新软件版本，也能第一时间体验 最新的 Linux 系统内核的新特性。 我是通过 Manjaro 进入了 Arch 的世界，它对新手非常友好，简单的安装方式、优秀的兼容性帮我平滑的度过了新手期，它也是我使用时间最长的发行版。 后来为了体验更加原汁原味的 Arch ，我安装了 EndeavourOS，EndeavourOS 比 Manjaro 更加的轻量化，软件包的发布也要比 Manjaro 要领先一些。EndeavourOS 整体安装和使用和 Manjaro 差不多，但兼容性上较 Manjaro 要差一些，这些兼容性问题通常并致命不影响正常的使用。 一次偶然的机会我接触到了 CachyOS ，我感觉它就是我想要找的发行版了，他所做的一切很符合我对操作系统的需求。 简单的安装方式 CachyOS 和 Manjaro 、EndeavourOS 一样有着图形化的安装方式，我们可以很方便的把系统安装到我们的电脑中。即使新手也可以很容易的使用 CachyOS。 CachyOS 集成了丰富的 Desktop Environments 除了常见的 KDE、GNOME 、FCE 还有很多平铺的 DE 如 i3、Hyprlad，CachyOS 集成的 DE 一共有 17 种之多，这可以让你用一种很纯净的方式把 DE 集成到系统中。...

最近我把本地的容器管理引擎切换到了 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....

最近在公司搭建最新版本的 Laravel 开发环境，对 docker 部署进行了进一步的优化，我们之前的项目是把定时任务 Cron 和 API 在同一个容器里启动的，这显然不太符合容器的最佳实践，借着这次框架搭建的契机，我决定优化一下这个问题。 环境如下: Laravel : 12 PHP : 8. 4 我们把项目跑在两个容器里，一个是 API 的容器，另一个是 Supervisor 的容器，把 Cron 和 Jobs 放在放在 Supervisor 里执行。 这样就能避免维护过多的容器。在后期做 CI/CD 也会更加方便。 Supervisor 使用和 PHP 一样的 Dockerfile 因为 Supervisor 会用到 PHP 环境来起 Laravel 的 Jobs。 整体方案就是这样来做的，比较简单, 文末我会放一个 git 仓库地址，感兴趣的可以可以进一步了解，接下来讲讲一些细节。 Cron 的配置我们放在了 Dockerfile 里来配置，当然你也可以放在 entrypoint.sh 里来做。 RUN echo "* * * * * /usr/local/bin/php /var/www/artisan schedule:run >> /var/log/cron.log 2>&1" | crontab - 我们的 docker compose 配置如下：...