docker 踩坑收集

docker 踩坑收集

 

尽可能地使用官方镜像

Docker镜像是建立Docker容器的基础，而Dockerfile是生成Docker镜像的关键文件。因此许多实践者在对自己欲运行软件不熟悉的情况下，就开始编写自己的Dockerfile，于是就陷入下面的折腾链：

编写/修改 Dockerfile -> 构建镜像 -> 运行容器 -> 出错 -> 寻找解决办法 -> 编写/修改 Dockerfile -> ....

而构建镜像往往需要下载安装一系列软件，这个过程可以用漫长两个字来形容。而在解决问题的过程中，又会让很多人望而却步，虽说人生在于折腾，但总这么折腾也不是什么好事。

许多软件都有现成的官方镜像，直接使用官方镜像的好处是：

• 一次pull，重复使用，直接避免了上面的折腾链。
• 版本切换方便：这几乎是件0成本的事，使用新版本能确保及时获得安全更新和最佳性能，通常只需要改变版本号就能使用特定版本的镜像。
• 通用性强：如果把镜像比作一个函数，那么只需要给出参数或者环境变量来创建容器，不用关心镜像本身，你的所有任务就是提供合适的参数。
• 免维护：官方镜像背后有专业团队帮你维护镜像。

细化服务

在Docker化lamp或者lnmp套件的时候，很多人喜欢把这四个东西全部放在一个镜像中，这是一个选择但一定不是个理想的选择。他们的出发点是，希望把软件打包成一个文件，分发给用户，让用户能够一键运行自己的应用，这有点像xammp等同类工具的思路。但在云时代，你向用户提供的应该是服务而不是软件包，这是几十年前的做法。拥抱持续集成、自动部署、快速迭代吧。既然选择了Docker，那么一定要对Docker的设计哲学有所认识。

Docker的出现是为了解决不同软件之间接口标准不一致的问题，而不是把软件打包。因此尽可能在一个容器中运行一种服务。

细化服务的优点是：

• 服务间的解耦，理论上各服务可以独立运行，这样就只需要专注某个服务开发，而很少关心其他服务的内部细节。
• 方便热更新，一个应用服务通常要依赖数据库服务，细化服务后，应用迭代只需要重启应用所在的那个容器，数据库始终不掉线，特别是多个应用依赖同一个数据库的情况，热更新某个应用变得很必要。
• 方便部署，经Docker标准化后，将各服务放置到一个集群中就变得相当容易。

使用docker-compose.yml来配置你的容器

不可否认的是，docker-compose的出现解决了太多实际应用中的痛点，容器间依赖，容器资源分配，容器启动顺序，启动/重启特定容器，都有对应的配置项和执行命令，这给许多CaaS提供商带来了很大的便利。

docker-compose实质是一系列python脚本，通过读取yml配置文件可以组织运行多个容器，而不用书写冗长的命令行。通常只需要docker-compose up即可。

volume你的数据

将经常变化的文件和数据volume到host或者数据卷，而不是统统构建到镜像中。特别是一些数据库的官方镜像也建议采用该方法，优点如下：

• 更加灵活地管理你的文件或数据，对于某些应用程序，如PHP脚本可以在host上替换（不建议的做法）并即时生效，而不需要重新构建镜像或者重启容器。
• 大大缩减镜像的体积（如果你构建自定义镜像的话）
• 确保你的重要数据不丢失，有人会手滑把容器删除，这样里面的所有数据都会丢失，把数据放到host上能加一道保险。

NOTE：以上仅代表个人观点，请谨慎考虑使用，如有错误，还请斧正。

。。。。。。 后续踩坑的情况持续收集当中。