DICOM： Instructions for installing dcm4chee-arc-light by docker(docker版dcm4chee-arc-light的安装简述）

0）题记：

时间转瞬即逝，俗话说每四年一闰，近来近一闰的时间都在集中精力做一件事情，也是一段充满各种挑战的旅程，因此博客的打理频率也逐年降低，由每周一博、每月一博、每季一博，逐步堕落到了现在的每年一博。（汗、汗、汗-_-||）

翻开马克飞象，文档栈里的《DICOM世界观》第二章：[3]像素操作之算法博文已经堆放了快一年了，一直没有出栈，务必在2019年的尾巴写出来。可惜闭关这么久，猛的出山，怎奈手脚发麻，头晕眼花，看来上年纪了，或许唯一值得欣慰的就是发际线依然坚守得住。

PS：最近演艺界以及各界突发心脏病事件频发，作为医疗大健康工作者的我们还需要更加努力，回想起当年在学校时配合导师努力推动的全市/全国推广AED的活动，顿时觉得意义深远，依然需要坚持下去。

恰逢自己的阿里云DICOM服务宕机，之前安装的是老古董版本dcm4chee2.X(之前也有数篇介绍博文DICOM：dcm4chee开源框架编译相关问题总结、DICOM：dcm4chee奇葩逻辑浅析之UID修改、DICOM：Ubuntu14环境下安装dcm4chee+oviyam2.1、DICOM：开源DICOM服务框架DCM4CHE 构建以及DICOM：开源DICOM服务框架DCM4CHE 安装)，目前官方早已更新为dcm4chee-arc-light5.X，索性就升级一下版本。也因为憋得太久了，正好借此机会活动活动筋骨，废P不多说，详情如下。

1）安装：

第一次尝试新版本安装，做了两个简化处理，首先在本地利用虚拟机进行测试，其次选择容器化安装，减少对安装环境的配置。

1.1）背景说明：

• 本地安装环境物理机是Windows10专业版本
• 虚拟化环境使用的是VMWare Workstation15版本
• 虚拟机系统使用的是CentOS-7-x86_64-DVD-1708：
  虚拟主机IP地址：192.168.253.128，网络配置采用的是NAT模式。
  然后在虚拟机系统中安装了docker、docker-compose。

1.2）容器最小化安装

参照官方说明Run minimum set of archive services on a single hostEditNew Page完成dcm4chee-arc-light的安装，一步一步安装，竟然一次成功，异常顺利。

【后话】：本地VMWare虚拟机完成后，在阿里云、微软AZure公有云选择CentOS（版本大于6.0）系统，按照同样操作，竟然也没有遇到过任何错误，比理想中的顺畅，这个可能也就是docker容器化对环境依赖“地狱”问题的一种便利。

1.3）登录

在物理机中开启chrome浏览器，输入连接http://192.168.253.128:8080/dcm4chee-arc/ui2/#/study/study，出现dcm4chee-arc-ui2界面如下：

2）错误排查：

看来 “bug守恒定律” 依然没有失效，如1.3界面所示，虽然安装过程很顺利，但是后续调试过程依然出现了诸多问题。等调试完成后，蓦然回首依然会发现都是细枝末节的地方出现了问题。现记录详情如下：

2.1）问题①：查询失败

如下截图所示：

【问题说明】：
由上图可以看出，docker容器运行良好，能够顺利显示dcm4chee-arc-ui2主界面，

但是当发送请求到后台进行数据查询时，却提示错误。

进入调试模式查看

可以看到在物理机外部使用chrome浏览器输入192.168.253.128:8080访问虚拟机中的web服务时，可以顺利获取页面。而当通过页面【SUBMIT】按钮发送GET请求查询服务器数据列表时，发送请求的连接中的host_address=127.0.0.1。众所周知，这个IP地址是内部本地循环闭路验证的地址，在这种虚拟机嵌套docker容器的复杂环境下，其并不能顺利访问到服务端资源。

【解决方案-尝试①】：

仔细查看官方安装文档，在官方文档中docker-compose模式下牵涉到IP地址设置的地方有：

按照官方指导，在docker-compose.yml文件中的镜像slapd-dcm4chee新增环境变量

与此同时在docker-compose.env文件新增ARCHIVE_HOST设置

重启服务后，依然没有生效，服务端发送请求依然是127.0.0.1开始。

【解决方案-尝试②】：

在各大搜索引擎检索网络中的各类说明文档，诸如参考1：Centos Docker环境下安装Dcm4che归档服务、参考2:DCM4CHEE Archive light 5.10在CentOS6.8上的安装、参考3:Orthanc+OHIF DICOM Viewer最佳Dicom解析、在线浏览实践指南（解决方案）等等，查看具体差异，唯一有所不同且涉及到IP地址的只有这一条：

进入容器内部，修改配置文件dcm4chee-arc.xml，步骤如下：


最后exit退出容器，重启docker-compose依然没有解决问题。

【解决方案-尝试③】：

静下心来回忆一下，之前dcm4chee2.x版本时候，采用JBOSS部署，其中大多数的配置参数是可以通过管理员用户权限登录(例如DICOM：开源DICOM服务框架DCM4CHE 构建以及DICOM：开源DICOM服务框架DCM4CHE 安装)，然后在界面中进行配置的。那么dcm4chee-arc-light是否也可以呢。进入github官方的wiki，仔细阅读安装手册。其中在AE Title(s) of the Archive章节中有如下描述：

重新进入主页面：http://192.168.253.128:8080/dcm4chee-arc/ui2/#/study/study。

在第一页Devices中选择默认的配置项dcm4chee-arc单击进入配置详情页：

按照如下步骤操作
（切记：此UI交互比较奇葩，需要按照步骤点击，否则找不到对应的选项。下文其实很多问题都是来源于这个奇葩的交互设计，因此博文中尽量用截屏来说明问题）


然后按照上述流程，分别修改其他选项的IP由127.0.0.1变为192.168.253.128虚拟机本地IP地址。最终dcm4chee-arc设备配置项如下：

重新发起SUBMIT查询器请求，可以顺利返回结果。如下图所示：

【备注】：其中DICOM SCP服务的IP地址不需要修改，依然为127.0.0.1。

否则无法通过storescu终端完成文件发送。客户端发送的正确结果如下图所示：

2.2）问题②：自定义AETitle失败

同样是因为UI奇葩的交互逻辑设计，因此直接截屏上操作流程。

【解决方案】：

2.3）问题③： 自定义AETitle后dcmWebAppName与dcmAETitle不一致

在Chrome浏览器debug状态下，可以看到虽然dcmAETitle已经更新为DCMTHUNITY，但是dcmWebAppName依然为DCM4CHEE。

【解决方案】

参考的官方wiki指南Invoke Image Display:

具体的前端UI2设置的页面地址为：
http://192.168.253.128:8080/dcm4chee-arc/ui2/#/device/edit/dcm4chee-arc/dcmDevice.dcmWebApp%5B0%5D/properties.dcmDevice.properties.dcmWebApp

至此docker版本的dcm4chee-arc-light服务就已经安装并调试完成了，后续会继续更新相关新版本的使用和测试。敬请期待&I’m coming back.

作者：[email protected]
时间：2019-12-01