企业官网建设流程全解析

先泼一盆冷水：Jira 的安装本身不难，真正折磨人的是把环境、数据库、权限、备份这一套理顺。我见过太多人下载完安装包就开跑，结果装到一半发现磁盘不够、内存分配不合理、MySQL 版本不对，最后只能推倒重来。这篇东西就按我自己在实际部署里趟过的流程来写，尽量把能预埋的坑先给你填了。

这篇内容面向的是需要在本地或内网服务器上搭建 Jira 的运维、开发、测试人员。可能是要搭一个测试环境跑跑流程，也可能是团队协作需要一套问题追踪系统。不管你属于哪种情况，只要照着操作，两三小时内能拿下一个可用的实例。

1. 安装前想清楚三件事

很多人一上来就想找安装包，然后把 Jira 跑起来，这其实是顺序搞反了。真正合理的顺序是：先明确版本选择、规划好服务器配置、再考虑数据库选型。这三件事没想清楚，后面每一步都可能翻车。

1.1 版本选型：Server 版和 Data Center 版怎么选

Jira 官方现在提供三种形态：Cloud、Server、Data Center。Cloud 是托管服务，不做讨论；自托管部署主要在 Server 和 Data Center 之间纠结。

Server 版是传统意义上的单机部署，数据都存在你自己的服务器上，一次性买断 License（早期模式，后期也改成订阅了）。Data Center 则面向集群和高可用场景，支持多节点部署，代价是 License 价格翻几倍。对于绝大多数中小团队来说，Server 版的单机部署完全够用——你不需要多活，不需要滚动升级，一台配置好点的服务器搞定所有事。

参考建议：

• 团队规模在 500 人以内，选 Server 版就能平滑运行
• 对可用性有硬性要求（比如故障切换时间不能超过 10 分钟），才考虑 Data Center
• 明确后续要不要接很多第三方插件，插件授权在 Data Center 里往往还要另算钱

另外有个容易被忽略的事：Atlassian 在 2021 年就宣布了 Server 版停售和 EOL（End of Life）时间，Server 版新许可证在 2025 年后不再销售，但已有的授权可以继续用。如果你现在部署的是测试环境，用 Server 版仍然没问题；如果要做长期生产规划，至少心里要有数——后续可能需要迁移到 Data Center。

1.2 服务器配置：买多大内存、几核 CPU 才算够

Jira 是 Java 应用，跑在 JVM 上，内存和磁盘 IO 就是它的命脉。我自己部署时遇到的最典型问题是：按照官方最小值“2GB 内存”去配，结果系统一开起来就卡成幻灯片，索引构建时 CPU 直接打满。

先给出一套经过实测的配置参考（基于中小团队日常使用）：

注意，Jira 的“数据盘”不只是 MySQL 的数据目录，还有 Jira 的 HOME 目录（里面装索引、附件、导入文件）。附件大小往往比数据库还要夸张，团队传几个大文件测试包，几十 GB 就没了。所以数据盘按未来一年的附件增速去预估，不要卡着最低线算。

内存分配的技巧在后面配置 Java 参数时会详细说，现在先记住一个总原则：给系统留 1GB 左右内存，剩下全部给 Java 堆。4GB 物理内存的机器，别天真到把 3GB 都塞给 JVM。

1.3 数据库选型：MySQL 还是 PostgreSQL

Jira 官方同时支持 MySQL、PostgreSQL、Oracle、SQL Server 等，实际部署中大部分人也就用前两种。关于选型，我的建议是：

• 新部署、没有历史包袱，优先选 PostgreSQL。它对 SQL 标准的支持更规范，Jira 的兼容性测试覆盖得也更好，遇到诡异语法错误的概率小
• 如果团队里有专职 DBA 且对 MySQL 运维更熟练，选 MySQL 5.7 或 8.x 也能稳定运行

有一点必须特殊强调：Jira 对数据库版本有硬性要求，且对 MySQL 的版本兼容性要求极其苛刻。比如某个 Jira 版本明确不支持 MySQL 8.0.16 之前的一些版本，或者某些旧版本对 MySQL 8.0.x 中的 caching_sha2_password 认证插件不支持。这些都是真实的坑。最稳妥的办法是：先确定 Jira 版本，再去官方文档查对应的数据库支持矩阵，最后再建库。不要先装了 MySQL 最新版再回头看 Jira 支不支持。

我见过一个团队装了 MySQL 8.0.28，Jira 连不上，报错信息也不够直观，折腾了半天最后发现是 MySQL 认证插件不兼容，这就是顺序搞反了的代价。

1.4 网络与端口规划

Jira 的默认端口是 HTTP 8080，控制台端口是 8005（这个端口默认是用来接受 shutdown 指令的，生产环境最好改掉或加防火墙限制）。如果你在内网部署，8080 端口基本可以直接用；如果在云服务器上，记得在安全组放行 8080。

另外还需要考虑数据库端口：默认 MySQL 3306、PostgreSQL 5432。Jira 应用服务器和数据库服务器之间如果隔了防火墙，一定要保证双向放通。这里有一个常被忽略的点：Jira 服务器所在的主机阿里云/腾讯云安全组放行不算完，系统自带的 firewalld 或 iptables 也得放行。我遇到过一个客户，安全组全放开了，内部防火墙没有放行 3306，数据库连接超时，排查了很久才发现是这个原因。

2. 环境准备与依赖安装

到这一步才开始真正动手。Jira 是 Java 写的，但别急着装最新版 JDK——Jira 对 Java 版本有固定要求，装错了版本启动时直接失败，或者某些功能不可用。

2.1 操作系统基础配置

我习惯用 CentOS 7 系或者 Ubuntu 20.04 LTS / 22.04 LTS 来部署。如果你也用的是 CentOS 7，注意 CentOS 7 官方已经停止维护了，如果条件允许，建议切到 Alibaba Cloud Linux、Anolis OS 或者 Ubuntu LTS。操作系统层面要做的事情很简单：

• 更新系统软件包
• 关闭 SELinux（如果不想关闭，至少要设置为 permissive 模式，否则会有诡异的权限问题）
• 调整文件描述符上限（系统默认 1024 一般也够用，但建议调大）

2.2 Java 环境准备

先说 Java 版本选择。以 Jira 8.22 和 Jira 9.x 为例，8.22 支持 Java 8 和 Java 11；9.x 则要求 Java 11。安装完 Jira 后你可以通过java -version检查，也可以在 Jira 的排障信息里查看。

我推荐使用 OpenJDK 11（各发行版仓库里都有，直接装就行）。如果系统自带的是 Java 8，而你要装 Jira 9.x，那就必须先升级 Java。有些部署教程会建议用 Oracle JDK，但没必要，OpenJDK 完全满足要求，还免了授权顾虑。

以 Ubuntu 为例，安装 Java 11 的命令：

sudo apt update sudo apt install -y openjdk-11-jdk java -version

安装完之后要确认一下JAVA_HOME环境变量是否设置。在很多发行版里，命令能执行java -version不代表 JAVA_HOME 正确配置了。Jira 的启动脚本setenv.sh里最好显式指定 JAVA_HOME，避免后续系统默认 JDK 变化时把 Jira 搞挂。

2.3 数据库创建与账号权限

这是全局最容易出错的一步。以 PostgreSQL 为例，整个配置过程有明确的顺序：

1. 安装 PostgreSQL（这里以 Ubuntu 为例，CentOS 的仓库包名略有差异）：

sudo apt install -y postgresql postgresql-contrib sudo systemctl enable postgresql sudo systemctl start postgresql

2. 切换为 postgres 用户进入 psql：

sudo -u postgres psql

注意，PostgreSQL 9.x 中的认证机制叫做scram-sha-256，Jira 里配置数据库连接串时需要指定对应的认证方法，否则会报密码认证失败的错。

3. 创建专门给 Jira 用的数据库和账号：

CREATE DATABASE jiradb WITH ENCODING 'UTF8' LC_COLLATE 'C' LC_CTYPE 'C' TEMPLATE template0; CREATE USER jirauser WITH PASSWORD 'strong_password'; GRANT ALL PRIVILEGES ON DATABASE jiradb TO jirauser; GRANT USAGE, CREATE ON SCHEMA public TO jirauser;

这里最重要的坑：Jira 对数据库字符集和排序规则有硬性要求。数据库必须使用 UTF-8 编码。如果不指定ENCODING 'UTF8'，默认库模板可能是 SQL_ASCII 或其他乱七八糟的编码，后续 Jira 页面中文会直接变成乱码，而且这个乱码不是通过改个配置文件就能修复的，只能重建数据库。这就是为什么我在建库命令里加了TEMPLATE template0——因为默认的 template1 库的编码往往不符合要求，直接从 template0 建最省事。

LC_COLLATE 'C' LC_CTYPE 'C'是避免排序规则导致索引同步失败的关键。很多安装教程里没有这一步，如果按默认的en_US.UTF-8排序规则创建库，某些 Jira 版本会在构建索引时报 “could not find valid identifier” 之类的错误。

如果是 MySQL，建库语句如下：

CREATE DATABASE jiradb CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

注意 MySQL 5.7 里时区设置，可以用：

SET GLOBAL time_zone = '+08:00';

这个问题如果不处理，Jira 页面时间和数据库时间对不上，日志排查时逻辑容易混乱。

2.4 Jira 部署包下载

Atlassian 的官方下载链接可以直接拿到。不同版本的下载地址不同，最靠谱的方式是通过 Atlassian 的 Archive 页面或者直接改版本号拼 URL。以 Jira Software 8.22.11 为例，Linux 64 位的 tar.gz 包可以从官方 Archive 地址拉取。

提醒一句：国内网络环境下，从官方源下载 Jira 可能有点慢，建议挂代理或者用下载工具支持断点续传。文件大概 400MB 上下，断线重传功能比什么都重要。

3. 安装与初始化配置

软件包的安装其实就是解压和改配置。Jira 的目录结构分为两大部分：安装目录和 HOME 目录。安装目录放程序文件，HOME 目录放数据和配置。搞清楚这个分隔是理解 Jira 运维的第一步。

3.1 解压与目录规划

把下载好的 tar.gz 包放到规划目录下，我习惯放在/opt下：

cd /opt tar -zxvf atlassian-jira-software-8.22.11.tar.gz mv atlassian-jira-software-8.22.11-standalone jira

再创建 HOME 目录：

mkdir -p /var/jira_home

强烈建议把 HOME 目录放在独立的数据盘或分区上，不要放在根分区。因为附件和索引会一直增长，根分区满了系统直接挂掉。HOME 目录的位置会在首次启动向导里让你填，也可以提前在jira-application.properties里指定。

3.2 配置文件调整与内存参数计算

Jira 的 JVM 参数配置放在<安装目录>/bin/setenv.sh文件里。这个文件默认内容中 JVM_MINIMUM_MEMORY 和 JVM_MAXIMUM_MEMORY 分别是 256MB 和 512MB，这对于实际运行来说完全不够，一启动就会卡。

我建议的调整思路：先看物理内存总量，给操作系统和数据库留出余量，剩下的全给 JVM 堆。比如一台 8GB 内存的服务器，数据库也装在同一台机器上，那么 JVM 最大堆建议设置在 4GB 左右。如果数据库单独一台机器，8GB 内存可以给到 5GB~6GB。

编辑 setenv.sh，找到这行：

JIRA_MAXIMUM_MEMORY="4g" JIRA_MINIMUM_MEMORY="1g"

这两个值的意义：JIRA_MINIMUM_MEMORY是 JVM 启动时分配的初始堆大小，JIRA_MAXIMUM_MEMORY是最大堆内存上限。把初始值和最大值设成一致，可以避免 JVM 频繁扩容堆时产生卡顿，所以我一般会把两者设为相同值，至少也不要差太大。

还建议在 setenv.sh 里加上JVM_SUPPORT_RECOMMENDED_ARGS参数，增加 GC 日志输出和时区指定：

JVM_SUPPORT_RECOMMENDED_ARGS="-Duser.timezone=Asia/Shanghai -XX:+HeapDumpOnOutOfMemoryError"

这个参数有两个作用：一是把 JVM 的默认时区（默认是 UTC）改成东八区，避免日志里时间差 8 小时的问题；二是在发生内存溢出时自动 dump 堆内存快照，后面排查 OOM 原因时有据可查。

3.3 启动服务与首次页面配置

配置好之后就可以尝试启动了：

/opt/jira/bin/start-jira.sh

第一次启动会比较慢，因为 Jira 要创建数据表并初始化。可以通过日志观察进度：

tail -f /opt/jira/logs/atlassian-jira.log

看到类似 “Jira has been started” 之类的日志，就说明启动成功了。然后浏览器打开http://服务器IP:8080，会看到 Jira 的初始配置向导。

向导第一步要求设置数据库连接。如果你用的是 PostgreSQL，JDBC 连接串大概是这样的：

jdbc:postgresql://localhost:5432/jiradb

如果你用的是 MySQL，连接串是：

jdbc:mysql://localhost:3306/jiradb?useUnicode=true&characterEncoding=utf8&useSSL=false

填写时注意：连接串里面不要拼错 schema 名称和密码。如果发生连接错误，请重点确认数据库密码、端口、字符集。密码和端口写错的概率最高，别问我是怎么知道的。

向导下一步会要求设置应用属性（Application Title、Mode 等）。Mode 一般选择 “Private”（私有），这样不会把项目暴露给未登录用户。

接着会进入 License Key 输入页面。测试环境可以用 Atlassian 提供的免费试用 License，或者使用测试专用的开发 License。如果你正式购买了授权，把 License Key 粘贴进去就行。

3.4 基础配置：语言、许可证、应用设置

安装完成后，进入 Jira 管理后台（右上角齿轮图标 → System）。有几个基础配置建议在第一时间完成：

• 默认语言：在 System → General Configuration 里可以把默认语言设置为“中文（简体）”，也可以不设，让每个用户自己切
• 邮件通知：在 System → Mail 里配置 SMTP 服务。没有邮件通知的 Jira 等于失去了一半功能——你希望有人 @ 你时能收到邮件提醒，而不是隔一天才自己打开系统看
• 用户注册：内网环境建议关闭用户自助注册，由管理员统一创建

4. 上线后的必备配置与安全加固

服务能访问，就算安装成功了吗？在我看来还远远不够。不做安全加固、不做备份方案，这样的 Jira 就像在裸奔。这一节集中讲生产环境必须处理好的四件事。

4.1 服务化管理与开机自启

手工跑start-jira.sh启动不叫部署。服务器重启以后你要是忘了拉起来，那就是事故。建议注册成 systemd 服务。

创建一个服务文件/etc/systemd/system/jira.service：

[Unit] Description=Atlassian Jira Service After=network.target postgresql.service [Service] Type=forking User=jira Group=jira ExecStart=/opt/jira/bin/start-jira.sh ExecStop=/opt/jira/bin/stop-jira.sh Restart=on-failure LimitNOFILE=65536 [Install] WantedBy=multi-user.target

有几个细节需要说明：

• User=jira是让 Jira 以专用账号运行，不要用 root 跑。Linux 下有安全机制，root 启动 Java 进程可能遭遇各种环境变量问题，而专用账号还能限制权限
• LimitNOFILE=65536是因为 Atlassian 官方建议提高文件句柄上限。Jira 要打开很多文件（索引文件、日志文件、附件），默认的 1024 可能不够，导致文件操作失败
• Restart=on-failure是让服务在异常退出时自动拉起。注意Type=forking的选择要和启动脚本行为匹配——start-jira.sh 这个脚本启动完就立即返回，Jira 进程会在后台持续运行，所以不能使用默认的 simple 类型

创建完服务文件后，执行：

systemctl daemon-reload systemctl enable jira.service systemctl start jira.service

4.2 反向代理与 HTTPS 配置

Jira 默认是 HTTP 8080 直接暴露。如果只是内网访问，问题不大；一旦要通过公网访问，强烈建议在前面加一层 Nginx 做 TLS 终止和反代。这能解决两个实际问题：一是你不想让用户记一个带端口号的地址，二是公网上跑裸 HTTP 调用 API 会报安全警告，总是不太好看。

Nginx 配置参考：

server { listen 443 ssl; server_name jira.example.com; ssl_certificate /etc/nginx/ssl/jira.example.com.pem; ssl_certificate_key /etc/nginx/ssl/jira.example.com.key; client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

proxy_set_header Host $host是必须的，否则 Jira 会认为是访问了错误的域名或端口，重定向时可能把请求改写到 8080 端口，导致反代失效。

配置好反代后，还需要同步修改 Jira 自己的配置，把基础 URL 改掉。在 Jira 后台 → System → General Configuration 里找到 “Base URL”，改成你的域名地址，否则 Jira 生成的邮件链接、API 返回的 URL 全部都会是http://服务器IP:8080，转发到域名就没意义了。

4.3 备份方案：从文件备份到数据库备份

Jira 的备份不是只导出一份数据库就能万事大吉的，附件目录、索引目录都不可丢。完整的备份包含三块内容：

1. 数据库备份
2. Jira HOME 目录下的data（附件）和export（导出目录）
3. Jira 安装目录下的配置（如有自定义修改）

下面是一套我惯用的备份脚本思路：

#!/bin/bash DATE=$(date +%Y%m%d) BACKUP_DIR="/backup/jira" mkdir -p $BACKUP_DIR # 备份数据库 pg_dump -U jirauser -h 127.0.0.1 -F c -f $BACKUP_DIR/jiradb_$DATE.dump jiradb # 备份附件和配置 tar -czf $BACKUP_DIR/jira_home_$DATE.tar.gz /var/jira_home # 保留最近 7 天备份，删除更早的 find $BACKUP_DIR -type f -mtime +7 -exec rm {} \;

把这脚本放到 crontab 里，每天凌晨执行。注意-F c输出的自定义格式，将来用 pg_restore 恢复时非常灵活。Jira 自身的附件数据，就靠那一条 tar 命令完成。

很多团队部署完 Jira 以后不做备份，直到某个人把数据误删才追悔莫及。备份这件事别心存侥幸，磁盘便宜，数据无价。

4.4 插件与邮件通知配置

Jira 的生态优势在插件上非常明显，但装插件前要想清楚：很多市场插件会和 Jira 核心版本强绑定，版本升级后插件不匹配会导致整个系统无法启动。安装插件以前，先去 Atlassian Marketplace 确认该插件兼容你当前的 Jira 版本。

邮件通知配置也是一样，SMTP 服务器和账号密码准备好以后，在后台里填进去，发一个测试邮件确认通了再收工。这一步能做的事不大，但没做的话后面所有通过邮件触发的通知流全部失效，用户只会觉得 Jira “没反应”。

5. 常见问题与排查实录

从实际部署和后期运维来看，Jira 最消耗人力的部分往往是问题排查。这里把我遇到过的高频问题集中整理成一张速查表，方便你直接对号入座。

5.1 内存溢出与频繁卡顿

最典型的是 Jira 在运行几天后突然变得特别缓慢，查看日志发现频繁出现java.lang.OutOfMemoryError: Java heap space。这种问题通常是 JVM 堆参数设置不合理。如果是 4GB 内存的机器，却只给了 JVM 512MB 的堆，一旦索引构建或批量 JQL 查询时内存不够用，系统就卡成死机状。

处理方式：修改 setenv.sh 把内存调大，同时加上 GC 日志输出。注意调完内存后要重启服务。如果重启后还是频繁 OOM，就得考虑是不是磁盘太慢导致索引读写时间过长，或者某些插件本身就有内存泄漏的毛病。

5.2 数据库连接超时或认证失败

部署数据库和 Jira 分离时，这个连接问题出现的频率最高。排查思路按顺序走：

• 用telnet 数据库地址 3306测试端口是否通
• 检查 MySQL/PostgreSQL 是否允许远程连接（默认 MySQL 只绑定了 127.0.0.1，PostgreSQL 默认只监听 localhost）
• PostgreSQL 需要修改 3 个文件：postgresql.conf中的 listen_addresses 改为*；pg_hba.conf中添加客户端网段授权行

MySQL 调整监听地址的方式是修改my.cnf中的 bind-address 为 0.0.0.0。

5.3 启动失败与版本冲突

启动失败的现场一般在日志里都有直接记录。我最常遇到的是 Java 版本不兼容：明明系统装了 Java 11，Jira 还是起不来，因为 Jira 需要特定小版本。这时候直接用官网指定的 OpenJDK 版本重新安装，并且修改 setenv.sh 里的 JAVA_HOME 指向新路径。

另一个排查技巧：启动脚本start-jira.sh会通过jira.sh最终调用 Java，如果系统里有多个 Java 版本，务必在 setenv.sh 里显式写死：

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"

5.4 忘记管理员密码等日常运维问题

Jira 管理员的密码忘记了，可以进入数据库调整。操作思路是找到对应的用户表，将当前管理员密码置为已知值。注意要了解 Jira 对密码的存储方式，不同版本实现有差异，操作前先在测试环境验证，生产环境务必先备份数据库表。

还有一些看似小但实际很影响体验的问题：时区不对导致到期时间判断异常，项目里看到的时间永远比实际晚 8 小时，排查冲突问题时容易懵。解决办法就是按照前面说的，在 setenv.sh 里加-Duser.timezone=Asia/Shanghai，同时把数据库时区也调整到一致，前后端时间就能对上。

6. 部署过程中的几点心得

整理几点不容易在官方文档里看到、但实际部署非常受用的体会。

第一，Jira 对磁盘性能的敏感程度远超对 CPU 的要求。我用机械硬盘部署过一次测试环境，JQL 复杂查询的响应时间能到 20 多秒，换成 SSD 之后直接降到 1 秒以内。所以预算有限时，把钱花在 SSD 上比花在高配 CPU 上更值得。

第二，安装阶段的目录规划至关重要。一旦 Jira 已经开始使用，HOME 目录再想迁移就非常麻烦。最稳妥的方案是提前把 HOME 目录放在独立的数据盘并配置好挂载，而不是直接放在根分区里。

第三，安全加固别忽视。我见过没有做任何安全配置的 Jira，直接暴露在公网上，天天被恶意扫描、垃圾注册、蛮力登录整得焦头烂额。如果你确实要开启公网访问，请务必做好 HTTPS、限制登录失败次数、开启双因素认证（Atlassian 提供插件支持）。

第四，升级 Jira 时要养成看升级说明的习惯。跨大版本升级（比如 8.x → 9.x）时，插件兼容性、数据库版本支持列表、配置改动，每一项都可能变成升级的拦路虎。盲目上生产环境升级，中途报错的代价远大于升级前的准备时间。

最后分享一个提升日常运维效率的做法：搭建好 Jira 之后，第一时间用 API 发几个测试请求，确认 REST API 通。这样后续写脚本做自动化（比如批量导入任务、同步用户组、获取项目数据）时，你会发现自己已经提前把环境验证好了。

Jira 的安装和配置，核心就一句话：决策前置、配置合理、备份到位。把遇到的问题按这个思路去拆，大多数都能顺藤摸瓜找到答案。