摘要： 本文以构建Haskell应用程序为例，演示了两种不同的方法来实现多阶段构建。
写在前面
在这篇文章中,Deni Bertovic将向我们展示如何使用Docker来快速构建Haskell应用程序并生成Docker镜像。
备注: Haskell 是一种标准化的，通用的纯函数编程语言，有非限定性语义和强静态类型。作为一门函数编程语言，主要控制结构是函数。Haskell具有“证明即程序、命题为类型”的特征。（摘自维基百科）
接下来，我们将从两个案例入手，通过对比分析来帮助您理解。第一个案例，使用相同的Linux发行版（ubuntu:16.04）进行开发。第二个案例，使用不同的操作系统和发行版来进行开发。
关于Docker多阶段构建功能和“Stack Images Container”指令，会在该文章的最后有更多介绍。
案例一：在相同的操作系统或发行版上构建和部署
如果我们在相同的Linux发行版上构建Haskell应用程序（在本例中是一个Docker镜像），那么构建它的过程就会十分精简。
在这种情况下，我们就能够在本地构建我们的Haskell应用程序了。使用Stack，然后将编译后的二进制文件嵌入到Docker镜像中。
让我们看一下将要使用的Makefile，特别是构建目标：
构建二进制文件和docker 镜像
build:
@stack build
@BINARY_PATH=${BINARY_PATH_RELATIVE} docker-compose build
正如我们所看到的，我们先在本地使用Stack来构建二进制文件，然后通过调用docker-compose和提供的Dockerfile构建出最终的docker镜像。
docker-compose文件如下所示：
version:'2'services: myapp: build: context: . args: - BINARY_PATH image: fpco/myapp command:/opt/myapp/myapp
正如我们从docker-compose文件中看到的，我们在Docker构建时将一个“构建参数”传递进去。具体而言，我们传递的就是位于.stack-work/path/to/myapp中的二进制文件的相对位置。接下来，让我们观察一下Dockerfile，看看如何使用这个构建参数。
FROM ubuntu:16.04RUN mkdir -p /opt/myapp/ARG BINARY_PATHWORKDIR /opt/myappRUN apt-get update && apt-get install -y \ ca-certificates \ libgmp-devCOPY"$BINARY_PATH"/opt/myappCOPYstatic/opt/myapp/staticCOPY config /opt/myapp/configCMD ["/opt/myapp/myapp"]
在Dockerfile中，我们只需要简单的将.stack-work/path/to/myapp复制到Dockerfile中的预定位置即可。
案例二：在不同的操作系统或发行版中构建
如果在一个与我们部署的操作系统或发行版不同的机器上进行开发，那么事情就会变得复杂一些，因为我们要将动态链接库嵌入到Docker镜像中。具体来说，我们现在必须在Docker容器中编译二进制文件，而不是在本地主机上编译它。
以前，可以通过下面两种方式来完成：
将所有构建时相关的文件打包到最终的Docker镜像中
将整个构建过程分解为Dockerfile.build（包含所有构建时相关的文件）和Dockerfile（包含运行时相关的文件和最终的二进制文件）两部分。这是一个相当繁琐的过程，需要一个shell脚本来辅助。首先构建第一个Docker镜像，然后利用这个docker镜像启动一个容器，获取已编译的二进制文件，之后再启动第二个容器，将这个已编译二进制文件嵌入其中，最后将其生成为新的docker镜像。您可以在Docker文档中了解到更多相关信息。
现在，Docker已经采用了一个名为多阶段构建的功能，它使整个构建过程变得简单化、自动化。它所带来的好处就是，我们不再使用构建工具和构建需求来扩大生产镜像，从而保证我们原本的镜像大小。
Docker多阶段构建
在这种情况下，我们的Dockerfile看起来像以下这样：
FROM fpco/stack-build:lts-9.9asbuildRUN mkdir /opt/buildCOPY . /opt/buildRUN cd /opt/build && stack build --system-ghcFROM ubuntu:16.04RUN mkdir -p /opt/myappARG BINARY_PATHWORKDIR /opt/myappRUN apt-get update && apt-get install -y \ ca-certificates \ libgmp-dev# NOTICE THIS LINECOPY --from=build /opt/build/.stack-work/install/x86_64-linux/lts-9.9/8.0.2/bin .COPYstatic/opt/myapp/staticCOPY config /opt/myapp/configCMD ["/opt/myapp/myapp"]
在Dockerfile中，我们首先使用fpco / stack-build：lts-9.9镜像来构建我们的应用程序。在我们构建完镜像之后，我们有另一个FROM 块使用相同的fpco/stack-build基础镜像，在这里我们复制了前一个版本的二进制文件。这使我们只能交付最终的二进制文件，而不需要任何相关的构建文件。
使用“Stack Images Container”
Stack通过一种将应用程序的可执行文件放入其中的方式来构建Docker镜像。虽然在Docker引入多阶段构建之前，这种支持是可用的，但与上述方法相比，它缺乏灵活性。然而，它需要对docker的熟悉程度要低得多，因此对于大多数人来说，应该更容易上手。
首先让我们看看要将stack.yaml复制到stack-native.yaml所需的更改：
docker:Docker Carrying Haskell.jpg enable:trueimage: container: base:"fpco/myapp-base"name:"fpco/myapp"add:static/:/opt/app/staticconfig/:/opt/app/config
正如我们所看到的，我们正在让Stack使用docker构建我们的可执行文件（如果您正在构建像OSX或Windows这样的非Linux平台，则需要该文件），然后指定一些我们想要Stack为我们构建容器的元数据。
我们需要将生成镜像的名称和本地目录添加到镜像中。Stack将自动为我们添加可执行文件。
让我们看一下我们的Dockerfile.base，我们将用它来构建我们的基础镜像。
FROM ubuntu:16:04RUN mkdir -p /opt/appWORKDIR /opt/appRUN apt-get update && apt-get install -y \ ca-certificates \ libgmp-dev
正如我们所看到的，除了少了复制生成的二进制文件的部分，它与我们之前的Dockerfile没有什么不同，因为Stack将会为我们完成这一点。
我们可以使用make build-base来构建镜像。然后建立新的镜像来运行make build-stack-native。
上面的目标是这样的：
构建用于stack image container的基础镜像
build-base:
@docker build -t fpco/myapp-base -f Dockerfile.base .
使用stack-native.yaml构建应用程序
build-stack-native: build-base
@stack --stack-yaml stack-native.yaml build
@stack --stack-yaml stack-native.yaml image container
现在来测试我们构建的镜像吧，让我们运行make run-stack-native试试看吧，如下所示：
**运行由stack image container构建的容器
run-stack-native: @docker run -p3000:3000-it -w /opt/app \ ${IMAGE_NAME} myapp
可以在Stack文档中阅读关于stack image container的更多信息。
总结
这篇文章演示了如何使用Docker多阶段构建来构建Haskell应用程序并生成Docker镜像，同时保持了镜像原有的大小。此外，还展示了一种使用“Stack Images Container”的替代方法，同样它也可以生成类似的docker镜像，但与前者相比，它缺乏了一些灵活性。
根据您的项目需要，选择适合您的方法吧！
注：上面的示例代码可以在Github上找到，并且包含关于进程管理和权限处理的一些内容，为简洁起见，这些内容在本文中被省略了。
如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@service.aliyun.com 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容
网友评论