pg_service.conf：你团队遗忘的魔法

pg_service.conf你团队遗忘的魔法摘要本文介绍pg_service.conf这是一个简单的 INI 格式配置文件允许开发者为 PostgreSQL 定义命名的连接配置文件无需记忆复杂的连接字符串并通过配置文件中的统一服务别名实现无缝的环境切换。原文链接说实话我是个老派玩家。我的 IDE 是 vim。我的 PostgreSQL 客户端是 psql。我已经用了快 20 年了仍然认为它是最好的 PostgreSQL 客户端。我可能有偏见。当我加入一个新团队时我注意到一件事没人用 psql。大家都通过 IDE 连接。公平地说IDE 确实保存了连接配置文件。点击就进去了我理解。但我用的是 vim。所以我需要别的东西。这就是pg_service.conf。连接字符串的问题连接 PostgreSQL 时你需要记住一堆东西主机、端口、数据库名称和用户。这是四个容易出错的地方。更有趣的是PostgreSQL 中的数据库名称很少是同事们谈论时用的名字。他们说prod。实际的数据库叫mycompany_production_v2。祝你好运能记住这个。pg_service.conf 是什么它是一个简单的 INI 格式文件你可以在其中定义命名的连接配置文件。像这样[prod] hostdb.mycompany.com port5432 dbnamemycompany_production_v2 userlaetitia [staging] hostdb-staging.mycompany.com port5432 dbnamemycompany_staging userlaetitia就这样。现在连接时你只需要psqlserviceprod你用团队交流的方式来命名服务。不再需要人类名字和技术名字之间的 mental mapping。文件放在哪里两个选择每用户~/.pg_service.conf或$PGSERVICEFILE指向的位置系统级pg_service.conf在pg_config --sysconfdir返回的目录中如果同一服务名同时存在于两个文件中用户文件优先于系统级文件。如果你被困在 Windows 上而且在大公司里有时你没有选择用户文件位于%APPDATA%\postgresql\.pg_service.conf。它的作用方式相同。每个环境一个文件这里就变得非常有趣了。你可以每个环境一个文件。技巧在每个文件中使用相同的服务名称。我的~/.pg_service_prod.conf和我的~/.pg_service_staging.conf都有一个[db1]、一个[db2]、一个[reporting]。别名与我团队对这些数据库的称呼相匹配。只有连接细节不同。所以psql servicedb1始终意味着同样的事情。你连接到哪个db1取决于加载的是哪个文件。不需要编辑。不会出错。我更近一步。我们通过 AWS 连接到数据库这意味着需要身份验证、导出凭证然后连接。我把这一切包装成一个脚本接受两个参数环境和数据库别名。./connect.sh staging db1脚本处理 AWS 身份验证将PGSERVICEFILE设置到正确的文件然后调用psql servicedb1。一个命令。搞定。而且因为别名在文件间是一致的脚本保持简单。密码怎么办不要把密码放在服务文件里。真的。pg_service.conf的最佳搭档是.pgpass。它是另一个文件Linux/Mac 上是~/.pgpass你可以在其中存储密码按主机、端口、数据库和用户匹配。PostgreSQL 自动读取它。文件必须有0600权限否则 PostgreSQL 会拒绝使用它。这两个文件一起给你无密码连接而不会把任何敏感信息存储在可能不小心分享的文件中。最佳用例入职将系统级的pg_service.conf放入你的版本控制。当新成员加入团队时他们克隆仓库将文件复制到正确位置设置他们的.pgpass他们第一天就能连接到每个环境。没有嘿能把连接详情发给我吗的 Slack 消息。没有复制粘贴错误。没有把错误的主机放在错误的脚本里。还有一件事我说 psql 是最好的 PostgreSQL 客户端。我维护了整个网站来证明这一点psql-tips.org。如果你还不信去看看。如果 PostgreSQL 命令行工具的不一致性让你有点抓狂不同的标志、psql、pg_dump、pg_restore之间不兼容的语法……我也为此构建了一个 bash 包装器PG Lord of the Ring。一个工具统治它们全部。