问题描述
在构建一个常用库的Docker容器时，遇到了一个问题：他的应用程序依赖于这个库，他们在常用容器中构建应用程序，并将编译后的文件复制到一个“精简”应用程序容器中。然而，Docker构建的最大层级深度被超过了。用户希望了解如何解决这个问题以及常见的做法。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1：不在Docker中构建常用库
一种解决方法是不在Docker中构建常用库，而是在常用库的代码仓库中构建正确的版本，并在其依赖项的基础上构建应用程序，然后将构建的产物复制到一个镜像中。然而，这样做会导致CI代理程序反复构建相同版本的库。
方案2：对常用镜像进行版本控制
另一种解决方法是对常用镜像进行版本控制。可以找到一种方法将应用程序版本与常用镜像的标签相关联，并将标签作为--build-arg传递给docker build命令。这种解决方案比较复杂，但是可以实现常用镜像的版本控制。例如，可以使用构建摘要作为标签。然而，这样做会导致应用程序版本与常用镜像捆绑在一起的方式变得不太直观。
在用户的特殊情况下，可以通过在应用程序仓库中进行小的提交来保存常用镜像的标签，并在应用程序的构建中使用这个标签，直到常用镜像的下一次迭代。无论任何暂存环境滞后多少，都可以使用应用程序仓库分支中保存的标签。这也允许根据需要修补标签。
常见做法
在类似的情况下，常见的做法是使用Docker Squash等工具来减少构建层级的深度。Docker Squash可以将多个镜像层级合并为一个，从而减少构建层级的深度。这样可以减少构建时间和镜像大小。然而，需要注意的是，使用Docker Squash可能会导致一些副作用，例如丢失构建历史记录和不可逆的更改。
总结
在构建Docker容器时，如果遇到构建层级过深的问题，可以考虑不在Docker中构建常用库，而是在常用库的代码仓库中构建正确的版本，并在其依赖项的基础上构建应用程序。另一种解决方法是对常用镜像进行版本控制，并将标签作为--build-arg传递给docker build命令。此外，还可以使用工具如Docker Squash来减少构建层级的深度。然而，使用这些工具时需要注意可能带来的副作用。