变更是运维的常用操作，而容器的变更和普通的变更不一样，从而会有不同的视角。
笑起来很容易，但是想笑很难。。。。Emmm，就是这样的。。。
容器变更
容器的运行都是通过一个镜像就能运行了，而镜像在使用的时候都是从registry中pull过来的，然后保存在本地之中，然后再利用这个image进行运行容器。
当程序出现bug之后，总是喜欢直接修改容器中的内容，然后继续运行，但是这样会造成一个问题，当容器重新调度到另外一个物理机的时候，从而会导致配置丢失，毕竟在调度的时候，又重新从镜像中心拉取了相关的配置，从而。。。在不知不觉中还原了配置。
在使用镜像中心的时候，默认是不能进行清空镜像中心的内容的，每次进行升级的时候，都是将镜像上传到镜像中心，从而镜像中心空间都是无限增大，需要手动清理空间。。。Emmm，手动清理？
还有一种方法就是直接移除整个镜像中心的目录，然后重新上传所有最新镜像的版本，但是这种是有风险的，毕竟如果这个时候出现物理机宕机，然后容器需要重新进行调度，那么这个时候，就会影响服务了，不过不存在单点的情况下，还是能够忍受的。。。需要衡量整体镜像中心的大小，预估时间然后上传
修改配置文件，开启删除功能。
测试删除功能：
curl -I -H "Accept: application/vnd.docker.distribution.manifest.v2+json" localhost:5000/v2/redis/manifests/latest获取sha
curl -i -X DELETE 192.168.1.198:5000/v2/redis/manifests/sha256:dfeb
当未修改配置文件的时候：
完整删除整个镜像存储：
出现如下报错时：
commit？
在有的时候，总是喜欢commit来进行修改容器的内容，从而不会丢失相关的配置，然而commit只是提交到本地，并不是提交到镜像中心。
当使用commit的时候，只是提交到本地的镜像仓库，而不是push到镜像中心，而且，当未指定repository和tag的时候，提交的都会变成none，当没有设置tag的时候，那么会将原来的镜像的tag变成none。。。so，该push的还是要push的，否则容器重新调度，配置还是会丢失。
也可以恢复本地的镜像：作为临时的测试，commit还是很好用的。
当需要从一个地方拿一个镜像过来玩玩的时候，save和load还是很好用的。
总结：当进行容器变更的时候，一定要修改镜像的版本，而不是随意修改本地仓库，本地是本地，镜像中心是中心。。。
一碗水端平，感觉是不可能的。。。公正？永远只是取舍的一种方式，这其中存在的强烈冲突。。。心如止水？
随着时间，慢慢慢慢变成了自己讨厌的人，是因为环境？还是因为必须有所取舍。。。说好的初心呢？初心喂了狗。。。
计较。。。哼。。。这是一个无解的题目，只能跳出这种思维的怪圈。。。做好一件事，其实也蛮难的。。。
