docker提交运行容器 [英] docker commit running container

查看:224
本文介绍了docker提交运行容器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当提交运行容器的 docker commit 时,是否创建文件系统一致的快照?



我正在考虑这种备份容器的方法。你只需要 docker commit< container> < container>:< date> 并将其推送到本地注册表。



备份将是增量的,因为提交只会创建一个新的层。



大量的图层会大大影响容器的性能吗?有没有办法在以后的时间点删除中间层?



修改



通过一致我的意思是,每一个被设计为在功率损耗中生存的应用程序都应该能够从这个快照中恢复。基本上这意味着快照启动后文件不能更改。



同时我发现docker现在支持多种存储驱动程序(aufs,devicemapper,btrfs)。不幸的是,几乎没有关于它们与他们支持的选项之间的差异的文档。

解决方案

我想一致性是你定义的



在平坦化和叠加太多AUFS图层的缺点方面:
https://github.com/dotcloud/docker/issues/332



docker flatten 链接在那里。


When committing a running container with docker commit, is this creating a consistent snapshot of the filesystem?

I'm considering this approach for backing up containers. You would just have to docker commit <container> <container>:<date> and push it to a local registry.

The backup would be incremental, as the commit would just create a new layer.

Also would the big amount of layers hurt io performance of the container drastically? Is there a way to remove intermediate layers at a later point in time?

Edit

By consistent I mean that every application that is designed to survive a power-loss should be able to recover from this snapshots. Basically this means that no file must change after the snapshot is started.

Meanwhile I found out that docker supports multiple storage drivers (aufs, devicemapper, btrfs) now. Unfortunately there is hardly any documentation about the differences between them and the options they support.

解决方案

I guess consistency is what you define it to be.

In terms of flattening and the downsides of stacking too many AUFS layers see: https://github.com/dotcloud/docker/issues/332

docker flatten is linked there.

这篇关于docker提交运行容器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆