WebSphere 8.5静默安装与补丁升级实战

简介：针对 WAS 8.5 的静默安装与补丁升级，这份 docx 文档梳理了完整的实操流程，适合需要批量部署 WebSphere Application Server 的系统运维与实施人员。内容包括安装包准备、目录结构规划、Installation Manager 静默安装、通过 repository.config 指定仓库并执行安装命令，以及管理概要/应用概要创建、Web 控制台启动、节点与 Server 启停等关键环节；补丁静默安装与静默卸载也在其中一并说明。资源为单个 Word 文档，压缩包大小 144KB，打开即可按步骤对照操作，无需额外脚本或附件。目前已有 1639 人在 CSDN 学习下载，对于希望减少交互式安装出错概率、提升部署效率的读者，这份步骤清单能直接作为现场操作参考。

1. WebSphere 8.5 静默安装：批量交付中间件的基础操作

当你要在一批刚交付的 Linux 服务器上装 WebSphere Application Server 8.5，或者需要在自动化流水线里每天重建一套测试环境时，图形安装向导就是最大的阻塞点。WAS 8.5 静默安装的思路很简单：把安装向导里所有的交互回答写进一个 XML 响应文件，再用 -silent 参数读取它一次性执行。但实际落地时你会遇到响应文件参数写错了、offering ID 不匹配、补丁升级后版本号没变化之类的麻烦。这里从响应文件的最小骨架讲起，覆盖静默安装和升级补丁的完整命令，适合需要批量部署 WAS 8.5 的运维和平台工程师。

2. 静默安装前必须理清的目录结构与安装介质

2.1 WAS 8.5 传统版与 Liberty 的部署选型

WAS 8.5 同时包含两类运行时：传统版（WebSphere Traditional）和 Liberty。传统版适合承载需要完整 EJB 容器和集群能力的重量级应用，使用 IBM Installation Manager 管理组件，安装介质根目录下放着 install、uninstall 脚本，响应文件是 XML 格式。Liberty 则是更轻量的动态运行时，也由 IM 安装，但补丁与配置方式完全不同。

在量产环境里谈静默安装，我一般默认选传统版，因为它对 JDK 版本和系统库的依赖更规整，升级补丁也有成熟的 offering ID 语义。Liberty 的配置更倾向用 server.xml 做随需裁剪，补丁形式也以二进制覆盖包为主，和传统版的 imcl 升级流程不适合混用。先想清楚你要交付的是哪种运行时，再往下看，否则后面命令跑出来的结果会和预期差很远。

另外，静默安装并非 WAS 特有。很多人熟悉的搜狗输入法，它的静默安装参数经常被用来在装机脚本里预置配置；WAS 8.5 的响应文件就是更大号的这类参数集合，只不过它把安装、替换文件、更新产品代码这些动作统一交给了 IM 调度。理解这一点，你就能明白为什么补丁升级也用同一个 imcl 命令。

2.2 安装介质、目录规划与权限检查

动手前先把安装介质整理到独立目录。WAS 8.5 安装光盘解压后，根目录必须有 install 可执行文件和 repository.config 文件，这两个是 IM 识别仓库的依据。建议把介质放在只读挂载点上，避免安装过程被误改；另外把响应文件、日志、补丁包统一放在数据目录，例如 /data/was，方便回滚和追溯。

下面的目录划分我基本照搬生产环境里的常见布局：

WAS 8.5 在 Linux 上不要直接用 root 安装。虽然 root 能跑通图形界面，但用非 root 用户安装后生成的 profile 文件属主更干净，也不会在后续创建节点时出现权限污染。先建一个专用用户并准备好目录：

useradd -m -s /bin/bash wasadmin mkdir -p /opt/IBM /data/was /was8.5_media chown -R wasadmin:wasadmin /opt/IBM /data/was /was8.5_media su - wasadmin -c "df -h /opt/IBM"

这里 useradd 创建 wasadmin 作为 WAS 的唯一属主；chown 把安装目录和数据目录都授权给它。最后一条 df 是顺手确认磁盘可用空间，WAS 8.5 传统版安装后占用至少在 1.5GB 左右。/tmp 也要留有约 1GB 空间，Installer 解压临时文件时会用到。

2.3 响应文件骨架与静默安装参数的最小集

静默安装响应文件并不需要把每个参数都写全，IM 会为没有给出的参数自动填默认值。先给一个能跑通安装的骨架文件，后面再讨论每项该留意什么。下面这个例子安装的是 Network Deployment（ND）版：

<?xml version="1.0" encoding="UTF-8"?> <agent-input acceptLicense="true"> <profile id="WebSphere Traditional" installLocation="/opt/IBM/WebSphere/AppServer"> <data key="eclipse.location" value="/opt/IBM/WebSphere/AppServer"/> </profile> <install modifyAll="false"> <offering id="com.ibm.websphere.ND.v85" profile="WebSphere Traditional"> <properties> <property name="user.install.was" value="/opt/IBM/WebSphere/AppServer"/> <property name="user.install.profiles" value="/opt/IBM/WebSphere/AppServer/profiles"/> <property name="user.install.java" value="/opt/IBM/WebSphere/AppServer/java"/> </properties> </offering> </install> <server> <repository location="/was8.5_media"/> </server> <preference name="com.ibm.cic.common.core.preferences.eclipseCache" value="/opt/IBM/IMShared"/> </agent-input>

这个文件里最核心的静默安装参数有三个。acceptLicense 必须为 true，否则安装会在第一个交互点停下来；profile 的 installLocation 与 property 中的 user.install.was 要指向同一个 WAS 主目录；offering id 决定装的是哪个产品，ND 是 com.ibm.websphere.ND.v85，单机 Base 版是 com.ibm.websphere.BASE.v85。repository location 指向你解压出的介质根目录，IM 会扫描该目录下的 repository.config 来识别可用产品。

3. 用响应文件跑通 WAS 8.5 静默安装

3.1 响应文件里的静默安装参数对照与填法

骨架已经能跑，但真实环境里你会想要修改端口、选择安装哪些功能部件。WAS 8.5 的响应文件对这些有对应属性，只是属性名不像图形界面那么直观。下面列出生产里最常用到的几项：

注意 user.appserver.user 参数只在创建 profile 阶段有意义，单纯的 install 不受它影响。很多初看文档的人把它当作安装用户，实际上安装用户取决于你执行 imcl 命令时的系统用户，响应文件里的 user 属性更多是用来约束生成的 server 进程归属。别在批量部署时把这两个概念混在一起。

3.2 执行 install 与 imcl 静默安装命令

介质目录里自带的 install 命令是最稳妥的入口，因为它在脚本里已经准备好了 IM 路径和 JVM 参数。执行方式如下：

cd /was8.5_media ./install -options /data/was/was85_response.xml -silent -log /tmp/was85_install.log

install 命令会读取 -options 指向的 XML，-silent 让它不做任何交互，-log 把安装过程写到指定文件。命令执行完毕后看退出码，0 表示成功，非 0 需要立即检查日志。有一点要注意：install 脚本默认使用当前目录下的 IM 配置，如果你已经手工升级过 IM，最好改用下面的 imcl 方式。

更可控的静默安装是直接调用 IM 的 imcl 工具：

/opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.ND.v85 \ -repositories /was8.5_media \ -installationDirectory /opt/IBM/WebSphere/AppServer \ -acceptLicense -showProgress

imcl install 后跟 offering id，-repositories 指定仓库，-installationDirectory 指定安装目录。首次安装时这个目录可以不存在，也可以为空。-showProgress 会在终端输出进度百分比，适合在人工确认机器上执行；在完全无人值守的脚本里，去掉 -showProgress 反而更干净，所有输出交给 -log 或系统日志。

3.3 安装日志、退出码与失败重试

安装失败时第一反应是去看日志，而不是重跑命令。IM 的日志集中在两个位置：WAS 安装目录下的 logs/install，以及 /var/ibm/InstallationManager/logs。后者文件名带时间戳，例如 2019_12_30_15.00.00_install.log，记录的是 IM 自身解析仓库、计算依赖的过程。用下面几条命令可以快速定位问题：

echo $? tail -n 200 /var/ibm/InstallationManager/logs/*.log find /opt/IBM/WebSphere/AppServer/logs -name "*.log" -mmin -10

退出码是 0 时也建议扫一眼日志里的 WARNING。常见失败原因有三个：一是 repository 路径写错，到仓库目录下 ls repository.config 就能确认；二是 /tmp 空间不足，IM 在解压时会静默失败；三是响应文件里 offering id 和仓库里的产品不匹配，这种情况 imcl 会在日志里直接列出可用的 offering id。对照日志修正参数后，imcl install 可以重复执行，IM 会跳过已经完成的组件，但不会自动清理失败残留，所以重试前把安装目录下新增的内容备份出来更稳妥。

4. 升级补丁：补丁介质、升级命令与回滚方案

4.1 WAS 8.5 补丁类型与仓库结构

WAS 8.5 的补丁升级不是简单覆盖文件，而是通过 IM 重新计算产品元数据并替换受影响的二进制。补丁包从 Fix Central 下载后，解压出来的目录同样包含 repository.config，所以可以把它看成另一个仓库。补丁和基础介质的关系是叠加式的，升级时 repositories 参数里可以同时给多个仓库。

常见的补丁类型有三类，处理方式略有不同：

从 8.5.0 升级到 8.5.5.x 时，不要直接只拿最新补丁包当仓库。IM 在计算依赖时会去找基础版本和中间补丁，缺一个就报 repository 不完整。最省心的做法是把从 8.5.0 到目标版本的补丁包全部解压到同一个仓库目录，让 IM 自己挑。iFix 通常只针对某个 APAR，升级完 Fix Pack 后再单独指向 iFix 仓库。

4.2 用 imcl install 升级的完整命令

补丁升级前先把应用服务器停止，避免文件被 JVM 占用。如果有多个 server 或节点，用 stopManager 停止 deployment manager，再逐台停节点。下面是在单台机器上从 8.5.0 升到 8.5.5.10 的完整命令序列：

/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 -user wasadmin -password changeit /opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.ND.v85 \ -repositories /was_fixpack/8.5.5.10,/was8.5_media \ -installationDirectory /opt/IBM/WebSphere/AppServer \ -acceptLicense -showProgress

stopServer.sh 的账号密码是 profile 配置的管理员凭据，若当时用的是默认设置，改成部署时的实际账号即可。imcl install 后面的 offering id 仍写产品 id，不需要带版本号，IM 会扫描 repositories 里的所有包并自动选择更高的版本。多个仓库用英文逗号分隔，基础介质放最后，只是习惯，顺序不影响结果。

升级完成后立刻验证一下版本信息：

/opt/IBM/WebSphere/AppServer/bin/versionInfo.sh /opt/IBM/InstallationManager/eclipse/tools/imcl listInstalledPackages

versionInfo.sh 输出里能看到产品版本和 Build Level，listInstalledPackages 则列出 IM 记录的每个产品的精确版本标识。这两者要同时看，因为二进制文件版本有时会被旧启动脚本缓存干扰，IM 记录版本才是最终依据。

4.3 验证补丁生效与回滚

版本号正确只代表补丁装上了，不代表应用能跑。还需要验证 WAS 服务能正常启动和节点与 dmgr 同步。我的习惯是启动 server 后看日志里的版本标记和端口监听状态。

回滚补丁在 IM 体系里同样一条命令搞定：

/opt/IBM/InstallationManager/eclipse/tools/imcl rollback com.ibm.websphere.ND.v85 \ -installationDirectory /opt/IBM/WebSphere/AppServer \ -acceptLicense -showProgress

imcl rollback 会回滚到上一个已安装版本，前提是 IM 元数据里还保留着旧版本的安装记录。如果你手工删过 /opt/IBM/IMShared 或 IM 的 repository 缓存，rollback 会找不到对象，这时只能靠备份重建。所以在打补丁前做一次 WAS 主目录和 IM 缓存的全量备份仍然是最可靠的兜底，不要依赖 rollback 能解决所有问题。

5. 安装后验证与静默化运维技巧

5.1 用 profile 创建和端口探测确认安装结果

安装完成后先别急着跑业务，用 manageprofiles 命令创建一份 profile，再确认配置仓库和数据源能正常加载。创建 profile 前先检查安装结果：

/opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh -listProfiles /opt/IBM/WebSphere/AppServer/bin/manageprofiles.sh -create -profileName AppSrv01 -templateName default /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1 tail -f /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/SystemOut.log

manageprofiles -listProfiles 只在已创建 profile 的情况下有输出，用来确认 IM 安装阶段是否注册成功。没有 profile 时用 -create 创建默认 profile，-templateName default 会生成单应用服务器结构。startServer.sh 启动后观察 SystemOut.log 里的 "SERVER server1 STARTED" 行，这是比端口探测更可靠的信号，因为端口可能被其他进程占用导致假成功。日志里同时会打出版本号与安装目录，顺手记下来用于后续排障。

5.2 把安装和补丁封装成带参数的运维脚本

静默安装的价值在于可重复，所以我会把安装、打补丁、版本验证三个动作封装成一个带 action 参数的脚本。脚本不复杂，但能避免手工执行时漏掉 stopServer、忘加 -acceptLicense 这类问题。核心思路是接受 install、update、version、rollback 四个动作，分别对应 imcl 的常见调用方式：

was_ctl() { IMCL=/opt/IBM/InstallationManager/eclipse/tools/imcl case $1 in install) "$IMCL" install com.ibm.websphere.ND.v85 -repositories "$REPO" -installationDirectory "$WAS_HOME" -acceptLicense ;; update) "$IMCL" install com.ibm.websphere.ND.v85 -repositories "$FIX_REPO" -installationDirectory "$WAS_HOME" -acceptLicense ;; version) "$IMCL" listInstalledPackages ;; rollback) "$IMCL" rollback com.ibm.websphere.ND.v85 -installationDirectory "$WAS_HOME" -acceptLicense ;; esac }

这个脚本把最容易出错的 repositories 路径和 WAS 目录收敛成 REPO、FIX_REPO、WAS_HOME 三个变量，执行时只需要调用was_ctl install或was_ctl update。回滚时使用 imcl rollback 前，我会先执行 listInstalledPackages 记录当前版本，确认回滚目标版本确实存在于 IM 缓存中。很多时候补丁失效不是回滚命令没跑对，而是缓存目录被清理工具删掉。这个脚本改一下 installLocation 和 repositories 就能复用到新环境，后续维护成本很低。

本文还有配套的精品资源，点击获取