人们如何处理Docker容器的持久存储?
我目前正在使用这种方法:构建映像，例如PostgreSQL，然后启动容器
docker run --volumes-from c0dbc34fd631 -d app_name/postgres
恕我直言，这有缺点，我不能(意外地)删除容器“c0dbc34fd631”。
另一个想法是将主机卷“-v”挂载到容器中，然而，容器中的用户id不一定与来自主机的用户id匹配，然后权限可能会被打乱。
注意:除了——volumes-from 'cryptic_id'，你还可以使用——volumes-from my-data-container，其中my-data-container是你分配给仅数据容器的名称，例如docker run——name my-data-container…(见公认答案)
当前回答
使用Kubernetes的Persistent Volume Claim (PVC)，这是一个Docker容器管理和调度工具:
持久的卷
为此目的使用Kubernetes的优点是:
您可以使用任何存储，如NFS或其他存储，即使节点宕机，存储也不需要。 此外，这些卷中的数据可以配置为即使在容器本身被销毁后也可以保留，以便在必要时由另一个容器回收。
其他回答
虽然这仍然是Docker需要做一些工作的一部分，但你应该将卷与volume指令放在Dockerfile中，这样你就不需要从另一个容器复制卷了。
这将降低容器的相互依赖性，并且不必担心删除一个容器会影响另一个容器。
这取决于你的场景(这并不适合生产环境)，但这里有一种方法:
创建MySQL Docker容器
它的要点是使用主机上的目录进行数据持久性。
从Docker Compose 1.6开始，现在在Docker Compose中改进了对数据卷的支持。下面的合成文件将创建一个数据映像，该映像将在父容器重新启动(甚至删除)之间持续存在:
下面是博客公告:Compose 1.6:用于定义网络和卷的新Compose文件
这是一个合成文件的例子:
version: "2"
services:
db:
restart: on-failure:10
image: postgres:9.4
volumes:
- "db-data:/var/lib/postgresql/data"
web:
restart: on-failure:10
build: .
command: gunicorn mypythonapp.wsgi:application -b :8000 --reload
volumes:
- .:/code
ports:
- "8000:8000"
links:
- db
volumes:
db-data:
据我所知:这将创建一个数据卷容器(db_data)，它将在重新启动之间持续存在。
如果你运行:docker volume ls，你会看到你的卷被列出:
local mypthonapp_db-data
...
您可以获得关于数据量的更多详细信息:
docker volume inspect mypthonapp_db-data
[
{
"Name": "mypthonapp_db-data",
"Driver": "local",
"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/mypthonapp_db-data/_data"
}
]
一些测试:
# Start the containers
docker-compose up -d
# .. input some data into the database
docker-compose run --rm web python manage.py migrate
docker-compose run --rm web python manage.py createsuperuser
...
# Stop and remove the containers:
docker-compose stop
docker-compose rm -f
# Start it back up again
docker-compose up -d
# Verify the data is still there
...
(it is)
# Stop and remove with the -v (volumes) tag:
docker-compose stop
docker=compose rm -f -v
# Up again ..
docker-compose up -d
# Check the data is still there:
...
(it is).
注:
您还可以在卷块中指定各种驱动程序。例如，你可以为db_data指定Flocker驱动程序: 卷: db-data: 司机:群 随着Docker Swarm和Docker Compose之间的集成越来越完善(并且可能开始将Flocker集成到Docker生态系统中(我听说Docker已经收购了Flocker)，我认为这种方法应该会变得越来越强大。
声明:这种方法很有前途，我在开发环境中成功地使用了它。我对在生产中使用它感到不安!
根据您的需要，管理持久数据有几个级别:
Store it on your host Use the flag -v host-path:container-path to persist container directory data to a host directory. Backups/restores happen by running a backup/restore container (such as tutumcloud/dockup) mounted to the same directory. Create a data container and mount its volumes to your application container Create a container that exports a data volume, use --volumes-from to mount that data into your application container. Backup/restore the same as the above solution. Use a Docker volume plugin that backs an external/third-party service Docker volume plugins allow your datasource to come from anywhere - NFS, AWS (S3, EFS, and EBS) Depending on the plugin/service, you can attach single or multiple containers to a single volume. Depending on the service, backups/restores may be automated for you. While this can be cumbersome to do manually, some orchestration solutions - such as Rancher - have it baked in and simple to use. Convoy is the easiest solution for doing this manually.
@tommasop的回答很好，并解释了使用仅数据容器的一些机制。但是，有些人最初认为数据容器很愚蠢，因为可以将一个卷绑定到主机上(正如其他几个答案所建议的那样)，但现在意识到实际上只有数据的容器非常整洁，我可以推荐我自己的博客文章:为什么Docker数据容器(卷!)很好
请参见:我对“管理Docker共享卷权限的(最佳)方法是什么?”的回答，以获得如何使用数据容器来避免权限和与主机的uid/gid映射等问题的示例。
To address one of the OP's original concerns: that the data container must not be deleted. Even if the data container is deleted, the data itself will not be lost as long as any container has a reference to that volume i.e. any container that mounted the volume via --volumes-from. So unless all the related containers are stopped and deleted (one could consider this the equivalent of an accidental rm -fr /) the data is safe. You can always recreate the data container by doing --volumes-from any container that has a reference to that volume.
和往常一样，做备份!
更新:Docker现在有了可以独立于容器管理的卷，这进一步简化了管理。
