4.1 登录与检索词条：login、logout、search

4.1 登录与检索词条：login、logout、search

本节摘要：docker login 管身份，docker search 管找货，docker logout 管退场。本节给全这一组词条的语法与义项：凭据存在哪、为什么明文目录值得警惕、检索结果怎么按官方标记与星级过滤。这是仓库部的第一站：先有身份，再谈进出。

早期用 Docker 的人大概都遇到过同样的困惑：pull 公共镜像不需要登录，push 却被拒——仓库的"只进要票"规则由此展开。本节把身份与检索这两件进出港前的准备动作讲透，它们决定你后面能不能推、推到哪、推的东西从哪挑。

词条卡：docker login

docker login [OPTIONS] [SERVER]
​

义项：

使用现场：交互登录与凭据落点

$ docker login
Login with your Docker ID to push and pull images from Docker Hub.
Username: ops-dev
Password:
WARNING! Your password will be stored unencrypted in:
/root/.docker/config.json
Configure a credential helper to remove this warning.
Login Succeeded
​

看那行 WARNING：密码以 base64 形式躺在 config.json 里，不算加密。看看实际内容：

$ cat /root/.docker/config.json
{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "b3BzLWRldjpxWW?"（解码即得用户名与密码）
    },
    "registry.local:5000": {
      "auth": "b3BzOnByaXZhdGU="
    }
  }
}
​

auths 下每个键对应一个已登录仓库——多仓库并存互不干扰，这解释了为什么推私有仓库前必须先对它 login。安全上的正确姿势是脚本里改用 --password-stdin：

$ echo "$REG_TOKEN" | docker login registry.local:5000 -u ops --password-stdin
Login Succeeded
​

密码经管道进命令，不留在 shell 历史也不落明文文件。CI 流水线里这是一律要求；交互终端上则更推荐装凭据助手，让 config.json 只存指针。登出不用的仓库是同一条命令的反向：docker logout registry.local:5000。

词条卡：docker search

docker search [OPTIONS] TERM
​

义项：

使用现场：给项目挑一个基础镜像

$ docker search redis --filter is-official=true --format 'table {{.Name}}\t{{.Description}}\t{{.Stars}}'
NAME         DESCRIPTION                      STARS
redis        Redis is an open source key-v…   12580
​

去掉过滤器再看全景，差别立现：

$ docker search redis --limit 8
NAME                DESCRIPTION                     STARS   OFFICIAL
redis               Redis is an open source key-…   12580   [OK]
bitnami/redis       Bitnami container image for …   972
grokzen/redis-clu…  Redis cluster 3.0/4.0/5.x/6.…   89
rediscommander      Web management UI for Redis     289
​

选型读法有固定套路：OFFICIAL 列为 [OK] 的镜像由软件官方或 Docker 官方维护，基础组件（redis、nginx、debian）优先取这类；第三方高分镜像（如 bitnami/redis）胜在配置与多架构支持，企业里也常用，但要认准发布方；星数极低又看不出维护者的，哪怕功能对口也别进生产。检索只回答"值不值得试"，最终判断还要 pull 下来看 history 与标签（贰部词条），以及到镜像的发布页核对更新频率与安全通告。

⚠️ 常见坑：search 只检索默认仓库的公共镜像——自建仓库与多数第三方仓库不在检索范围。私有镜像的"查找"靠的是团队内部的命名约定与文档，不是这条命令。

身份、检索与后续词条的衔接

login 解决"你有资格推吗"，search 解决"货架上有什么"。下一节把港口本身搬回家：自建 registry 的完整现场。到时你会发现 login 对私有仓库同样是第一道手续，而 push 与 pull 的输出会频繁出现本节见过的仓库地址形态（域名加端口），提前混个脸熟。

常见追问：login 成功了，pull 私有镜像怎么还被拒？

多半是地址对不上号：login 时给的地址（含端口）必须与引用名里的地址逐字一致——registry.local:5000 与 registry.local 在 auths 里是两个互不相干的账户。次常见是登录态被同机的 logout 清掉或凭据过期，重登即可。与其猜，不如打开 config.json 看 auths 下有没有那个地址的键，现场一节见过它长什么样。

本节要点回顾

• login 按仓库分账：config.json 的 auths 键位对应已登录仓库，多仓库并存。
• 明文凭据是风险点：交互登录有 WARNING，脚本一律 --password-stdin，长期方案是凭据助手。
• search 的选型两板斧：is-official 保血统，stars 看口碑，小众镜像止步于测试。
• 检索范围只限默认仓库：私有镜像靠文档与命名约定管理。
• logout 是退场手续：共享机器上用完即登出，别把身份留给下一位。

身份与货源就绪，下一节自己起一座仓库：registry 现场见。