我正在尝试使用容器内的回送设备来装载一些图像文件： > sudo losetup /dev/loop0 test.img losetup: /dev/loop0: failed to set up loop device: No such file or directory /dev/loop0确实不存在，并且 > sudo mknod /dev/loop0 b 7 0 mknod: '/dev/loop0': Operation not permitted 我怎样才能做这个工作？ 容器是否需要一些它可能没有的cgroup权限？
我试图添加一个文件到一个从官方的tomcat图像构build的Docker镜像。 该图像似乎没有root权限，因为我以用户tomcat身份login，如果我运行bash： docker run -it tomcat /bin/bash tomcat@06359f7cc4db:/usr/local/tomcat$ 如果我指示Dockerfile将文件复制到该容器，则该文件具有权限644 ，并且所有者为root 。 据我所知，这似乎是合理的，因为Dockerfile中的所有命令都以root身份运行。 但是，如果我尝试将该文件的所有权更改为tomcat:tomcat ，我得到一个Operation not permitted错误。 为什么我不能更改复制到该映像的文件的权限？ 它如何被复制： mkdir docker-addfilepermission cd docker-addfilepermission touch test.txt echo 'FROM tomcat COPY test.txt /usr/local/tomcat/webapps/ RUN chown tomcat:tomcat /usr/local/tomcat/webapps/test.txt' > Dockerfile docker build . docker build .的输出docker build . ： Sending build context to Docker daemon 3.072 kB Sending build […]
什么是LXC？ 为什么它是有用的？ LXC和普通虚拟化有什么区别？
假设我们有一台安装了lxc的服务器和一个用作img /var/lib/lxc/ubuntu_base的基础的lxc容器。 为了简单起见，让我们在复制基本图像后忘记configuration更改。 有些人build议使用子卷和快照来制作新的容器，但是可以很容易地做cp –reflink和类似的结果。 那么pipe理多个容器的方式是什么（或哪个更好）呢？ 快照 这种方式似乎是最好的，但像lxc-destroy这样的命令将无法工作，因为它将无法删除目录。 btrfs subvolume snapshot /var/lib/lxc/ubuntu_base /var/lib/lxc/container_1 CP与reflink 我不确定这个或快照之间是否有任何性能差异 cp –reflink=always /var/lib/lxc/ubuntu_base /var/lib/lxc/container_1 还有没有其他更好的方法来做到这一点，我不知道。 编辑： 我在reflink选项中看到的一件事是，如果别人正在运行，那么你不能删除基本容器，因为/proc和/dev是被挂载的，并且永远不会改变，se引用总是相同的。 但closures所有的复合容器似乎有帮助。
试图保持在红帽的优雅之中，并且仍然计划系统寿命，这是非常棘手的。 我一直是Linux容器（LXC）的支持者。 我最初的安装是基于从在线教程收集的信息，就像这个和这个一样 。 这以lxc-create ， lxc-start|stop和lxc-destroy命令为中心，并修改了现有的OpenVZ模板 。 这运作良好，并愉快地生产运行。 但是，我提出了一些额外的系统，并决定检查红帽目前关于EL6容器的文档。 我很惊讶地看到他们在这方面的官方立场。 在RHEL 6中是否提供了使用Linux容器所需的LXC工具？ ，Red Hat将LXC描述为技术预览，并build议使用libvirt来pipe理创build和pipe理容器 。 然而，Oracle在Unbreakable Linux中提倡完全不同的容器化技术 。 在libvirt方法中似乎有一些缺失的function，但我最初使用lxc- *命令的方法是一些手动过程…我不能完全知道什么是正确的，或者在EL6上pipe理容器的“接受”方法。 关于当今LXC和RHEL系统的传统观点是什么？ 你在你的组织中如何实施它们？ 一种方法与其他方法有什么优点？ 这些可以共存吗？
在将应用程序部署到服务器上时，应用程序与自身绑定的内容与从平台（操作系统和安装的包）提供的内容之间通常存在分离。 其中一点就是平台可以独立于应用程序进行更新。 例如，当需要紧急将安全更新应用于由平台提供的包而不重build整个应用程序时，这是非常有用的。 传统上，通过执行软件包pipe理器命令在操作系统上安装软件包的更新版本（例如，RHEL上的“yum update”），就可以应用安全更新。 但随着容器技术（如Docker）的出现，容器映像实际上将应用程序和平台捆绑在一起，保持容器系统最新的规范方法是什么？ 主机和容器都有自己的独立套件，需要在主机上更新和更新，不会更新容器内的任何包。 随着特别推出Docker容器的RHEL 7的发布，听听Redhat推荐的处理容器安全更新的方法是很有意思的。 关于几个选项的思考： 让包pipe理器更新主机上的包不会更新容器内的包。 必须重新生成所有容器映像才能应用更新似乎会中断应用程序和平台之间的分离（更新平台需要访问生成Docker映像的应用程序构build过程）。 在每个正在运行的容器中运行手动命令看起来很麻烦，并且在下一次从应用程序发行构件更新容器时，更改有被覆盖的风险。 所以这些方法都不令人满意。