记一次Jira和Confluence的云端迁徙

将本地单容器化Jira和Confluence应用依次迁徙至Atlassian Cloud

步骤：

前期准备

• SAML Integration, 在Atlassian Cloud上添加证书
• 复现Confluence生产环境：
  • 复制生产环境DB VM
  • 拷贝生产环境DB Snapshot至复制环境

中期演习和实操：

• JIRA项目数据由UI直接导出，附件从服务器中拷贝，打包上传。
• Confluence因为版本问题需要先容器化升级，之后导出数据：
  • 在准备好的复制环境中Rsync同步NFS
  • 启动旧容器
  • 更新Config file
  • 启动新容器
  • 导出Space数据

后期的一些集成和收尾：

• GitHub Integration via Smart Commits
• Scriptrunner用于和Jenkins的集成
• 在JIRA XML里更新Comments/Descriptions里旧的linkage
• JIRA Macro Repair

中途遇到的一些问题：

• 之前预演时因为操作不慎，rsync覆盖confluence的config file后指向了生产数据库。发现时生产数据库已被写入不同版本号，并导致此后的备份被污染（生产环境居然只有Daily Backup），所幸最后能通过进入数据库表操作删除错误版本号解决，旧版本instance得以顺利启动。

还有一些问题在此之前的多次预演时并没有暴露，而正式迁徙时则花样频发，“惊喜”不断：

• 为新版本容器准备的新config file权限不一致，导致新容器启动后报错，升级失败。最后不得已回滚旧容器然后重新操作。
• 新容器启动时多次因为文件读取权限问题导致报错，解决方法是索性chmod -R 777.
• 上传Space Data后的处理与解压相当龟速

最惊险的问题是：

• 数据迁徙完成，给用户发放回权限后，发现用户只能访问Confluence而不能登陆JIRA，最后Atlassian内部escalate并于周日凌晨5点予以修复。细节如下：" We found that the syncing is failing with Jira and User management where it detected duplicated user_name

Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint \"cwd_user_unique_lower_user_name\"
  Detail: Key (lower_user_name)=(harsh) already exists

The problem here is that the user that is being detected as duplicate is actually in the Jira internal directory (and not IDP directory) - it should be perfectly acceptable for a duplicate lower_user_name if one entry is in the internal directory (usually has an ID of 1), and the other is in IDP (usually has an ID of 10000)."

• 同事变更旧生产环境Project权限为"ReadOnly"时偷懒，所有项目用一个scheme并让所有用户进入同一个Group，导致不该拥有view权限的用户可以看到所有项目，最后手动修正。

那个周末挺忙的。