简介这份面向数据平台运维与开发者的 OpenMetadata Docker 安装手册聚焦在 CentOS 7 环境下部署开源元数据管理平台帮助读者处理容器化安装、服务编排与初始登录配置等问题适合具备一定 Linux 与 Docker 基础的技术人员参考。资源包仅含 1 个 doc 文档体积约 693KB内容覆盖基础环境准备、Docker 与 docker-compose 安装、docker-compose.yml 获取与参数修改以及服务启动和 8585 端口首页访问等关键环节。目前已有 1353 人学习反映出元数据管理落地场景的关注度。文档还提示镜像拉取失败、MySQL 密码与主机端口调整、管理员账号登录等注意点可作为部署 OpenMetadata 的操作底稿和排错参考便于按章节核对环境与配置减少版本差异带来的安装阻碍。1. 装完 docker ps 全 Up8585 还是打不开这类假成功最耗人照着 openMetadata docker 安装手册走完六步docker-compose up --detach打印一堆 Starteddocker ps里 mysql、elasticsearch、server 全是 Up浏览器打开http://ip:8585转圈到超时——每一步都执行过了就是进不去。这种进程活着但服务不通的假成功比直接报错难受得多报错至少告诉你哪一行错了假成功只会让你反复怀疑自己是不是漏敲了什么。下面把这条安装链上最容易断的四处拆开docker 装不上、compose 装不上、镜像拉不下来、容器起来页面不通。每一处都给现象、给根因、给能直接复制的命令顺带说清楚为什么这么改。刚上手第一遍的人和装到一半卡住的人都能对照着往下走。2. docker 装不上源、依赖、守护进程三个必查点CentOS 7 上跑这套安装第一条yum-config-manager --add-repo之后翻车的概率不低。docker 本身的安装步骤就那么几行但它依赖外部的仓库可达性、系统里已有的容器运行时、以及内核参数任何一处不对都会在最不起眼的地方断掉。这一章按报错出现的先后顺序排遇到哪条对哪条。2.1 yum makecache 报 Cannot find a valid baseurl 或一片 404现象很典型添加完仓库文件yum makecache刷出一堆[Errno 14] HTTP Error 404 - Not Found最后收尾一句Cannot find a valid baseurl for repo: docker-ce-stable。也可能直接提示Could not resolve host。少数机器上还会顺带抱怨fast这个参数已废弃这个不影响结果。根因拆开看是三种。第一种最常见repo 文件里的$releasever变量解析成了空字符串。CentOS 7.9 正常应该解析成7但如果/etc/yum/vars/releasever被别的脚本动过或者系统是从更老的版本一路升上来的拼出来的 URL 就变成.../centos//x86_64/stable中间双斜杠服务器自然 404。第二种是你用的镜像站没有同步 docker-ce 这个仓库或者路径层级和官方不一样。第三种就是纯 DNS 问题。先看再改别急着删文件重来# 1. 看清 repo 文件里实际写死的地址和变量 cat /etc/yum.repos.d/docker-ce.repo # 2. 把地址里所有 $releasever 直接钉成 7绕开变量解析 sed -i s|\$releasever|7|g /etc/yum.repos.d/docker-ce.repo # 3. 清缓存重刷最后用 repolist 确认仓库真的可读 yum clean all yum makecache yum repolist enabled | grep -i dockersed用|当分隔符是因为$releasever前后经常跟着斜杠用/做分隔符会打架。yum clean all这一步必须做旧的元数据不删改完地址刷出来的还是旧结果。repolist enabled只看启用的仓库输出里出现docker-ce-stable且后面有包数量才说明源真的通了。如果添加仓库时用的是--add-repo加一个地址建议把地址先提取成变量方便替换成公司内网的镜像站# MIRROR 换成你所在环境能访问的仓库地址 MIRRORhttps://mirrors.example.com/docker-ce/linux/centos yum-config-manager --add-repo $MIRROR/docker-ce.repo2.2 yum install docker-ce 报 No package docker-ce available仓库刷出来了repolist里也有 docker-ce安装时却提示No package docker-ce available或者报container-selinux 2.9 is needed by docker-ce-...、conflicts with podman。这一类基本都是依赖闭不上。docker-ce 依赖container-selinux这个包在 CentOS 7 上是 extras 源提供的如果 extras 被禁用或者被换成了不可用的源依赖就永远找不到。另一种情况是机器上之前装过 podman、buildah、runc它们和container-selinux的版本互相锁死yum 解不开这个结。# 看看包到底在不在可用列表里先排除源的问题 yum list available --showduplicates | grep -i docker-ce # 冲突通常出在 container-selinux 和 podman 上先卸干净 yum remove -y podman buildah runc container-selinux # --nobest 允许降级个别包让 yum 自己找一条能装通的路 yum install -y docker-ce docker-ce-cli containerd.io --nobest--nobest是这套组合里最关键的一个参数。默认行为是 yum 尝试把所有包都拉到最新版依赖闭合不了就整体失败报错还看不出是哪两个包打架。加上它之后yum 会在版本空间里自己搜一条可行解代价是某个包可能不是最新的。CentOS 7 这种已经停止维护的系统上新版 containerd.io 对老内核的支持越来越差--nobest几乎是标配。装之前顺手确认一下内核uname -r # 3.10 以上基本没问题魔改内核要先升级2.3 docker -v 有版本docker info 报 Cannot connect to the Docker daemondocker -v正常输出Docker version 2x.x.x紧跟着docker info就报Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?。另一种变体是Got permission denied while trying to connect to the Docker daemon socket。第一种是守护进程真没起或者起了又挂。手动装完 docker-ce 之后systemctl start不会自动执行很多人装完直接敲docker ps就在这儿卡住。第二种是进程活着但当前用户不在 docker 组没权限读写那个 socket。# 1. 先看服务状态和最近 50 行日志daemon.json 写错会在这里现形 systemctl status docker -l journalctl -u docker --no-pager -n 50 # 2. 起服务并设开机自启 systemctl start docker systemctl enable docker # 3. 权限类报错把当前用户加进 docker 组 sudo usermod -aG docker $USER newgrp docker # 4. 验证 docker info | head -20usermod -aG的-a是追加不加会把用户从其他附加组里踢出去这个坑踩过一次就记住了。newgrp docker只对当前 shell 立即生效已经开着的其他会话要重新登录才会拿到新组。生产环境上不建议图省事chmod 777 /var/run/docker.sock那等于把 root 权限发给机器上每一个用户。还有一种情况是服务起不来但systemctl status只给一行Job for docker.service failed。多半是/etc/docker/daemon.json里有语法错误比如结尾多了一个逗号。JSON 不容错一个逗号就能让守护进程拒绝启动# 先做 JSON 语法校验通过了再重启 python3 -m json.tool /etc/docker/daemon.json systemctl restart dockerjson.tool解析失败时会直接抛出异常并指到出错行比翻 journalctl 快得多。养成改完配置先校验再重启的习惯能省掉大量改了没效果的困惑。3. docker-compose 装不上pip 编译、命令找不到、版本对不上docker-compose 这一环最容易出问题因为它捆绑了 Python 生态。CentOS 7 自带 Python 3.6.8这个版本 2021 年底就停止维护了而 PyPI 上的新包早就把它拉黑。手册里那条pip install docker-compose今天直接跑十有八九装不上而且每次报错的原因还不一样。3.1 pip install 卡在 Building wheel for PyYAML 或报 gcc failed现象是命令跑到一半开始编译几分钟后报error: command gcc failed with exit status 1或者更早一点提示Building wheel for PyYAML (setup.py) ... error。新版本还会直接甩一句ERROR: Could not find a version that satisfies the requirement docker-compose一个候选版本都没有。根因有两层。PyYAML 从 6.x 开始不再为 cp36 提供预编译 wheel只能源码编译缺 gcc、python3-devel、libffi-devel 里的任何一个都会在编译阶段失败而且每次缺的东西不同报错也长得不一样。另一层是 docker-compose 2.x 的setup.py里写死了python_requires 3.8pip 在 3.6 环境里筛候选版本时直接一个都留不下所以才会出现连版本都找不到的怪象。处理思路是锁版本加补编译链两条一起做才有效# 编译依赖一次补齐缺一个都会在后面报不同的错 yum install -y gcc gcc-c make python3-devel libffi-devel openssl-devel # 锁 1.29.2这是最后一个完整支持 Python 3.6 的稳定版 python3 -m pip install --upgrade pip python3 -m pip install docker-compose1.29.21.29.2这个精确锁版本是重点不加的话 pip 会去挑最新版然后报一个和真实原因毫不相干的找不到版本。内网环境连不上公共 PyPI就把索引地址换掉python3 -m pip install docker-compose1.29.2 \ -i https://your-pypi-mirror/simple \ --trusted-host your-pypi-mirror-i指定索引地址可以换成公司内网的源。--trusted-host只是给 http 源放行如果内网源本身是 https这个参数可以去掉。装完做一次双重验证python3 -V # 期望输出 3.6.8 docker-compose version # 期望输出 1.29.2docker-compose version不带横杠是 compose 自己的子命令--version也认两者输出格式略有差别看哪个都行。3.2 装完提示 docker-compose: command not foundpip 明明打印了Successfully installed docker-compose-1.29.2紧跟着敲命令却是-bash: docker-compose: command not found。这个错看着邪门其实是 PATH 问题。pip 装包时会把可执行脚本扔到某个 bin 目录。root 执行时落点是/usr/local/bin这个通常已经在 PATH 里非 root 或者加了--user落点是~/.local/bin这个目录默认不在 PATH 里。于是就出现了装了但用不了。# 1. 让 pip 自己告诉你包在哪、脚本落在哪 python3 -m pip show -f docker-compose | grep -E Location|bin/ # 2. 实在找不到就全盘搜一下 find / -name docker-compose -type f 2/dev/null # 3. 看看 PATH 里到底有哪些目录 echo $PATH | tr : \n确认落点之后补齐 PATH# 对所有用户生效追加到全局 profile echo export PATH$PATH:/usr/local/bin:$HOME/.local/bin /etc/profile source /etc/profile还有一种更隐蔽的情况机器上装了多个 Python系统自带的 3.6 加自己编译的 3.9pip3和python3指向的不是同一个解释器包装进了 3.9 的 site-packages脚本入口也在 3.9 的 bin 目录下而 PATH 里优先命中的是 3.6 的 bin。# 确认 pip 和 python3 是不是同一个解释器 which python3 pip3 python3 -m pip --version养成用python3 -m pip install而不是裸pip install的习惯装到哪个解释器一目本文还有配套的精品资源点击获取