能够在Local Docker容器中部署Liberty docker镜像,并且可以访问Liberty服务器。
我将自由图像推送到我系统中安装的Minishift,但是当我要创建docker容器时,我面临如下错误:
以前有人试过这个,请分享你的观点:
记录跟踪:
unable to write 'random state'
mkdir: cannot create directory '/config/configDropins': Permission denied
/opt/ibm/docker/docker-server: line 32:
/config/configDropins/defaults/keystore.xml: No such file or directory
JVMSHRC155E Error copying username into cache name
JVMSHRC686I Failed to startup shared class cache. Continue without
using it as -Xshareclasses:nonfatal is specified
CWWKE0005E: The runtime environment could not be launched.
CWWKE0044E: There is no write permission for server directory
/opt/ibm/wlp/output/defaultServer
答案 0 :(得分:2)
默认情况下,OpenShift会将图像作为项目唯一的指定用户ID运行。已编写了许多可用图像,因此它们只能以root
运行,即使它们不需要以root
运行。
如果您尝试运行此类图像,因为目录/文件已设置为只有root
用户可写,因此将图像作为非root
用户ID运行会导致它失败。
最佳做法是编写图像,以便可以作为任意用户ID运行。不幸的是,很少有人这样做,结果是他们的图像无法在更安全的多租户环境中用于在容器中部署应用程序。
OpenShift文档提供了有关如何实现图像的指南,以便可以在更安全的环境中运行。请参阅:
中的“支持任意用户ID”部分如果图像是由第三方构建的,并且他们没有兴趣对其图像进行更改,那么在安全的多租户环境中工作,则有几个选项。
第一个是创建派生图像,在构建它的步骤中,返回并修复目录和文件的权限,以便可以使用。请注意,在执行此操作时,您必须小心更改权限,因为更改派生图像中文件的权限会导致创建文件的完整副本。如果文件很大,这将开始摧毁你的图像大小。
第二种情况是,如果您是OpenShift群集的管理员,则可以放松群集中用于运行映像的服务帐户的安全性,以便允许它以root
的形式运行容器。如果可能,您应该避免这样做,特别是对于您不信任的第三方图像。有关如何执行此操作的详细信息,请参阅:
如果需要修复权限的总大小很小,那么可能能够与某些图像一起使用的最终方法是使用init容器来复制需要对{{的写访问权限的目录。 1}}音量。然后在主容器挂载中复制目录顶部的emptyDir
卷。这样可以避免需要修改图像或启用emptyDir
。如果必须复制应用程序二进制文件,anyuid
卷中可用的空间量可能还不够。这可能只适用于应用程序想要更新配置文件或创建锁定文件的地方。如果将相同的目录用于大量临时文件系统数据(如缓存数据库或日志),则无法使用此方法。