简介：这份资源是面向大数据运维与Hadoop集群管理学习者的Cloudera Manager 5.14.2离线安装包，专为CentOS 7环境准备，解决在无外网或受限网络下部署CM管理平台的难题。压缩包共含18362个文件，约793.9MB，以py、pyo、pyc等Python运行与字节码文件、html与js前端页面、jar依赖库、ddl建表脚本、xml与properties配置、so动态库及sh启动脚本为主，完整覆盖CM服务端、Agent、内置数据库与Web控制台所需组件。资源描述配套《Cloudera Manager在CentOS7上的安装与配置详解》，涉及系统需求、Yum仓库配置、服务端与数据库初始化、Web界面访问、集群创建、监控告警及Kerberos安全实践等环节，可帮助读者搭建并管理CDH集群。目前已有278人学习，适合具备Linux与Hadoop基础、希望掌握Cloudera平台部署与运维的中高级用户参考。
1. 离线部署 Cloudera Manager：为什么一个 tar.gz 能决定集群能不能上线
手里拿到cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz这个包的人，大概率面对的是同一个场景：生产环境没有外网，或者外网访问被严格限制，但业务又必须把一套 Hadoop 生态集群搭起来。在线安装靠 yum 源和 Cloudera 官方仓库一路 next 当然舒服，可一旦机器出不了公网，yum install cloudera-manager-server这条命令就直接卡死。这个 tar.gz 就是为这种场景准备的——它把 Cloudera Manager Server、Agent、Daemons 以及配套的 RPM 包全部打在一起，解压后本地建源，整条安装链路不依赖任何外部网络。
它解决的核心问题是「离线环境下的集群管理平面搭建」。适合两类人：一类是在隔离网络里做大数据平台交付的运维工程师，另一类是需要在测试环境快速复现一套 CM 管理集群、又不想被在线源版本漂移折腾的开发者。CM 5.14.2 对应的是 CDH 5.14.x 系列，基于 CentOS 7，整套东西不算新，但存量环境里跑的量依然很大，踩坑资料也最全。
2. 解压之前先想清楚：CM 5.14.2 的组件构成与依赖关系
2.1 这个 tar.gz 里到底装了什么
把包解开之后，目录结构通常长这样：一个cm/目录放 Cloudera Manager 自身的 RPM，一个cdh/目录放 CDH 各组件的 parcel 或 RPM，外加一些manifest.json、cloudera-manager.repo之类的元数据文件。不同来源的打包方式略有差异，但核心就三块：CM Server 的安装包、CM Agent 的安装包、以及被管理组件（Hadoop、Hive、Spark 等）的安装介质。
理解这个分层很关键。CM Server 是管理平面的大脑，负责下发配置、调度服务、收集监控指标；CM Agent 装在每个受管节点上，听 Server 的指令去起停进程、拉取 parcel；CDH 的 parcel 才是真正跑业务的运行时。很多人第一次装失败，就是把这三层的安装顺序和依赖搞混了——Server 没起来就去装 Agent，Agent 连不上 Server 又回头怀疑网络，来回折腾。
2.2 版本锁定带来的连锁约束
CM 5.14.2 不是一个孤立版本，它和 JDK、数据库、操作系统有明确的兼容矩阵。CentOS 7 上官方推荐 JDK 8，具体来说是 Oracle JDK 8u 某个区间或 OpenJDK 8。数据库方面，CM Server 自己的元数据库支持 MySQL、PostgreSQL、Oracle，生产上 MySQL 5.7 用得最多。这里有个容易翻车的点：MySQL 8.0 的默认认证插件和驱动兼容性在 CM 5.14.2 上并不好，连元数据库时经常报认证失败，所以老老实实上 MySQL 5.7 最稳。
另一个约束是 Python。CM 5.14.2 的 Agent 和部分脚本依赖 Python 2.7，CentOS 7 自带的就是 2.7，这点刚好匹配。但如果你在系统里装了 Python 3 并改了默认指向，Agent 启动脚本可能直接报语法错误。这不是 CM 的 bug，是版本锁定带来的必然结果。
2.3 离线源的组织方式
离线安装的本质是把远程 yum 源换成本地文件源。有两种常见做法：一种是用createrepo把 RPM 目录做成一个本地 repo，通过 HTTP 或 file:// 暴露；另一种是直接用 tar.gz 里自带的 repo 文件配合yum --disablerepo=* --enablerepo=local来装。前者更灵活，适合多节点；后者更简单，适合单机验证。
我一般会选第一种，因为集群规模一上来，每台机器都去挂载同一个目录不现实，起一个轻量 HTTP 服务（比如 nginx 或 python -m SimpleHTTPServer）把 repo 目录暴露出去，所有节点统一指向这个地址，后续加节点也不用改配置。
3. 从零搭一套本地源并跑通 CM Server 安装
3.1 准备工作：目录规划与依赖检查
先在作为管理节点的机器上规划好目录。我习惯把安装介质统一放在/opt/cloudera-media，本地 repo 放在/var/www/html/cm-repo，parcel 放/opt/cloudera/parcel-repo。这样分区清晰，后面排查问题时知道去哪找文件。
# 创建介质目录和 repo 目录 mkdir -p /opt/cloudera-media mkdir -p /var/www/html/cm-repo mkdir -p /opt/cloudera/parcel-repo # 解压 tar.gz 到介质目录 tar -xzvf cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz -C /opt/cloudera-media # 查看解压后的结构，确认 RPM 和 parcel 的位置 find /opt/cloudera-media -maxdepth 3 -type d | head -30这段命令做完，你应该能看到cm和cdh两个顶层目录。find那一步是为了确认打包结构，不同来源的包目录层级可能差一层，先看清楚再往下走，比盲目复制命令强。
依赖检查方面，确认几件事：java -version输出 1.8；python --version输出 2.7；systemctl status firewalld看防火墙状态（测试环境可以先关，生产环境要按需放行 7180、7182、8888 等端口）；getenforce看 SELinux，建议设成 permissive 或按文档配策略，否则 Agent 起进程时会被拦。
3.2 用 createrepo 建立本地 yum 源
把 RPM 集中到一个目录，然后生成 repodata。
# 把 CM 和 CDH 的 RPM 汇总到一个目录 find /opt/cloudera-media -name "*.rpm" -exec cp {} /var/www/html/cm-repo/ \; # 安装 createrepo 工具（如果本机有网，或者从系统盘里找） yum install -y createrepo # 生成 repodata createrepo /var/www/html/cm-repo/ # 起一个简单的 HTTP 服务暴露这个目录 cd /var/www/html && python -m SimpleHTTPServer 80 &createrepo会在目录下生成repodata/子目录，里面是 RPM 的元数据索引。yum 客户端靠这个索引来解析依赖。HTTP 服务用 Python 自带的 SimpleHTTPServer 只是图方便，生产上换成 nginx 更稳，但验证阶段够用。
然后在每台节点上配置 repo 文件：
# 在 /etc/yum.repos.d/ 下新建 local-cm.repo cat > /etc/yum.repos.d/local-cm.repo <<'EOF' [local-cm] name=Local Cloudera Manager Repo baseurl=http://<管理节点IP>/cm-repo/ enabled=1 gpgcheck=0 EOF # 清理缓存并验证源可用 yum clean all yum repolistgpgcheck=0是因为本地自建的源没有签名，测试环境可以接受。生产环境如果在意完整性校验，需要自己导入 GPG key 并开启检查。yum repolist能列出local-cm且包数量不为零，说明源配通了。
3.3 安装 CM Server 与 Agent 并初始化元数据库
源通了之后，安装本身反而简单。
# 在管理节点安装 server 和 agent yum install -y cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent # 在所有受管节点安装 agent 和 daemons yum install -y cloudera-manager-agent cloudera-manager-daemons装完之后先别急着启动 Server，元数据库还没初始化。CM Server 需要一个数据库来存配置和状态，用 MySQL 的话先建库建用户：
-- 在 MySQL 中执行 CREATE DATABASE scm DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; GRANT ALL ON scm.* TO 'scm'@'%' IDENTIFIED BY 'YourPassword'; FLUSH PRIVILEGES;然后用 CM 自带的脚本初始化：
# 初始化 SCM 元数据库 /opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm YourPassword这个脚本会建表、写配置。执行成功后会提示Your SCM database is configured correctly!。如果报连接失败，先检查 MySQL 的 bind-address 和用户权限，再检查 JDBC 驱动是否在/usr/share/java/mysql-connector-java.jar。CM 5.14.2 对驱动版本有要求，太新的驱动反而可能不认。
启动 Server：
systemctl start cloudera-scm-server # 跟踪日志，等待出现 "Started Jetty server" tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看到 Jetty 启动完成后，浏览器访问http://<管理节点IP>:7180，默认账号密码都是 admin。能进登录页，说明 Server 这一层通了。
4. 用 Parcel 分发 CDH 并调通 Agent 心跳
4.1 Parcel 的放置与校验
CM Server 起来只是管理平面就绪，真正跑 Hadoop 还需要 CDH 的 parcel。tar.gz 里的 parcel 文件（通常是.parcel和.parcel.sha两个文件）要放到 Server 的 parcel-repo 目录。
# 把 parcel 和校验文件复制到 parcel-repo cp /opt/cloudera-media/cdh/*.parcel /opt/cloudera/parcel-repo/ cp /opt/cloudera-media/cdh/*.parcel.sha /opt/cloudera/parcel-repo/ # 确认文件权限，CM 以 cloudera-scm 用户读取 chown -R cloudera-scm:cloudera-scm /opt/cloudera/parcel-repo/这里有个细节：.parcel.sha文件里的哈希值必须和 parcel 实际内容匹配，否则 CM 会认为文件损坏，一直卡在「正在下载」或「校验失败」。如果 sha 文件丢失，可以手动生成：sha1sum xxx.parcel | awk '{print $1}' > xxx.parcel.sha。但要注意 CM 期望的是 SHA1，不是 SHA256。
4.2 Agent 配置与心跳排查
每个受管节点上的 Agent 需要知道 Server 在哪。配置文件在/etc/cloudera-scm-agent/config.ini，关键项是server_host。
# /etc/cloudera-scm-agent/config.ini 关键片段 [General] server_host=<管理节点IP> server_port=7182改完重启 Agent：systemctl restart cloudera-scm-agent。然后在 CM Web 界面的「主机」页面看是否能自动发现新节点。如果节点没出现，按这个顺序查：Agent 进程是否在跑、7182 端口是否通、/var/log/cloudera-scm-agent/cloudera-scm-agent.log里有没有连接被拒的记录。
常见的一个坑是主机名解析。CM 对主机名很敏感，如果 Agent 上报的是短名而 Server 记录的是 FQDN，或者/etc/hosts里正反解不一致，节点会显示成「不良」状态。统一用 FQDN 并在所有节点的/etc/hosts里写全，能省掉大量玄学问题。
4.3 分配 Parcel 并启动集群服务
节点被识别后，在 CM 界面里分配 parcel、激活，然后走「添加服务」向导。向导会检查各节点的环境，包括 JDK、Python、目录权限、时钟同步。这一步的检查项最好一条条过，不要跳过。尤其是 NTP 时钟同步，CM 对时间偏差敏感，偏差大了监控数据会乱。
启动 HDFS、YARN 这些服务时，第一次启动慢是正常的，因为要格式化 NameNode、创建目录。如果某个角色起不来，先看该角色的日志，再看 Agent 日志，最后看 Server 日志，这个顺序能覆盖绝大多数问题。
5. 避坑指南：离线装 CM 最容易翻车的五个地方
5.1 坑一：元数据库连不上，报认证或驱动错误
现象是scm_prepare_database.sh执行失败，或者 Server 启动日志里刷Communications link failure。原因通常是三类：MySQL 没授权远程访问、JDBC 驱动版本不对、或者密码里有特殊字符没转义。解决方法是先用mysql -h <host> -u scm -p手动验证连通性，再确认/usr/share/java/mysql-connector-java.jar存在且版本在 5.1.x 区间，最后检查脚本参数里的密码是否需要加引号。
5.2 坑二：Agent 装上了但节点一直不出现
现象是 Web 界面主机列表为空。原因多半是 Agent 的server_host配错，或者 7182 端口被防火墙拦了。解决方法是telnet <server> 7182测连通性，检查 Agent 日志里的连接目标地址，确认/etc/hosts正反解一致。还有一个隐蔽原因是 Agent 的 UUID 冲突——克隆虚拟机时如果没清理/var/lib/cloudera-scm-agent/uuid，多台机器会用同一个 UUID，Server 只认一台。
5.3 坑三：Parcel 校验失败，一直卡在分发中
现象是 parcel 状态显示「正在下载」或「校验失败」。原因是.parcel.sha内容不对，或者文件权限导致 CM 读不到。解决方法是手动核对 sha1 值，确认 parcel-repo 目录属主是 cloudera-scm，并检查 Server 日志里具体的校验报错信息。有时候是文件传输过程中损坏，重新复制一遍就好。
5.4 坑四：服务启动时报目录权限或端口占用
现象是 HDFS 或 YARN 的某个角色起不来，日志里报Permission denied或Address already in use。原因是 CM 默认用各服务自己的系统用户跑进程，如果目录属主不对，或者上一个残留进程没清干净，就会冲突。解决方法是按日志里的路径检查属主，用ss -tlnp查端口占用，必要时手动清理残留进程再重启。
5.5 坑五：时钟不同步导致监控数据错乱
现象是 CM 界面里图表数据跳变、告警时间对不上。原因是节点间时间偏差超过阈值。解决方法是所有节点配同一个 NTP 源，用chronyc sources或ntpq -p确认同步状态。这个坑不致命但很烦，属于典型的「不影响跑但影响判断」的问题，早点配好省心。
6. 进阶技巧：把离线部署做成可重复的流程
走到这一步，单套集群能跑起来了。但如果你要交付多套环境，每次都手动敲命令迟早出错。我的习惯是把整个流程脚本化，分成三个阶段：准备阶段（解压、建源、配 repo）、安装阶段（装包、初始化数据库、起 Server）、纳管阶段（配 Agent、分发 parcel、启动服务）。每个阶段一个脚本，中间用配置文件传参，比如管理节点 IP、数据库密码、集群名称。
验证一套离线 CM 是否装得健康，我一般看四个指标：Server 日志里没有持续报错、所有 Agent 心跳正常、parcel 状态是「已激活」、以及随便挑一个服务（比如 HDFS）做一次重启能成功。这四个都过，基本可以交付。
还有一个实用技巧是保留一份「最小可用」的 parcel 集合。CDH 的 parcel 动辄几个 G，但实际业务可能只用 HDFS、YARN、Hive、Spark 这几个。把不需要的组件 parcel 剔掉，能显著缩短分发时间，也减少磁盘占用。CM 支持只分发已分配的 parcel，所以介质准备阶段就可以做裁剪。
最后说个血泪经验：离线环境的介质一定要做校验和备份。tar.gz 在多次拷贝、U 盘传递过程中损坏的概率不低，等到装到一半才发现包坏了，现场又没有第二份，那种感觉相当难受。我现在的习惯是拿到包先sha256sum记下来，复制到目标环境后再校验一次，确认一致再动手。希望帮到你。
本文还有配套的精品资源，点击获取
