WCF 服务容器化的一些问题

背景

目前项目当中存有 .NET Framework 和 .NET Core 两种类型的项目，但是都需要进行容器化将其分别部署在 Windows 集群和 Linux 集群当中。在 WCF 进行容器化的时候，遇到了以下几个问题：

某些服务使用到了 WSHttpBinding 保护服务安全，要在容器里面加载 SSL 证书。
WCF 服务的日志，如何重定向到标准输出流?

解决

问题一

关于第一个问题，最开始我觉得只需要将 WCF 服务打包出来，暴露一个 HTTP 端点。然后在这个 WCF 服务的前面再加一层 NGINX，具体的证书由 NGINX 进行管理。大概的流程就是 API Caller --> (HTTPS)F5 --> (HTTPS)NGINX --> (HTTP)WCF，按照这样的方式部署之后，对应的服务端点无法访问，具体的错误提示的是 Schema 不匹配。因为 WSHttpBinding 强制使用 HTTPS，如果我仅暴露一个 HTTP 端点，是无法绕过 WSHttpBinding 的限制的。

随后我又在网上找到了这篇文章，该文章的思路就是实现一个 CustomBinding，然后在里面忽略掉这块验证，经过我的测试无法满足需求。

上述方法行不通就只有创建一个自签 SSL 证书，并导入到 IIS 当中，随后在 NGINX 启用 SSL 转发，目前看来已经解决这个问题。下面是我的 Dockerfile 以及入口点的 PowerShell 脚本，脚本里面包含了证书生成与导入方法。

dockerfile:

FROM mcr.microsoft.com/dotnet/framework/sdk:4.8 AS build

WORKDIR /build

COPY . .

RUN cd ./src; nuget restore

WORKDIR /build/src/ProjectName

RUN msbuild Wcf.csproj /p:Configuration=Release -r:False

FROM mcr.microsoft.com/dotnet/framework/wcf:4.8-windowsservercore-ltsc2019 AS runtime

WORKDIR /WcfService

EXPOSE 443

COPY --from=build /build/wcf-entrypoint.ps1 .

COPY --from=build /build/src/ProjectName .

ENTRYPOINT ["powershell", ".\\wcf-entrypoint.ps1"]

entrypoint.ps1

$hostName = $env:HostName

$port = "443"

$password = "Your password."

$storeLocation = "Cert:\LocalMachine\My"

$certificate = New-SelfSignedCertificate -DnsName $hostName -CertStoreLocation $storeLocation

$thumbPrint = $certificate.Thumbprint

$certificatePath = ("cert:\localmachine\my\" + $certificate.Thumbprint)

$bindingInformation = "*:" + $port + ":" + $hostName

$securedString = ConvertTo-SecureString -String $password -Force -AsPlainText

Export-PfxCertificate -FilePath "C:\WcfService\temp.pfx" -Cert $certificatePath -Password $securedString

Import-PfxCertificate -FilePath "C:\WcfService\temp.pfx" -CertStoreLocation "Cert:\LocalMachine\Root" -Password $securedString

New-IISSite -Name "WcfService" -PhysicalPath C:\WcfService -BindingInformation $bindingInformation -CertificateThumbPrint $thumbPrint -CertStoreLocation $storeLocation -Protocol https

# Entry point for the application.

&C:\\ServiceMonitor.exe w3svc

问题二

由于 WCF 是托管在 IIS 里面的，我们的日志信息是无法输出到标准输出流的。所以我们就采取了一个曲线救国的方案，使用一个旁路程序，我们的日志输出到文件当中，由这个旁路程序监控文件变动，然后将变动的内容输出到标准输出流里面。

这个功能有点像 Logstash，你可能会说我们为什么不直接用 Logstash 收集这些日志呢？因为我们所有项目的日志，都是由基础架构团队统一处理。规范就是我们日志必须输出到标准输出流，并且日志是结构化日志，还需带上一些 ProjectId 之类的标记信息。然后由注入的 Sidecar 容器统一收集、处理、上报到 Garylog 平台。

回到正题，最开始我找到了微软实现的一个开源工具，它的本意就是为一些 Windows 容器解决日志收集问题的。

项目的地址是: https://github.com/microsoft/windows-container-tools。

使用这个工具，指定好路径与需要运行的程序，替换 Dockerfile 的入口点即可解决问题。微软那个工具的核心，就是使用了系统提供的文件监听 API，在 .NET 里面也有提供类似的 API，叫做 FileSystemWatcher，如果有兴趣的话，也可以参考 C++ 的源码和思路自己实现。

巴特西

WCF 服务容器化的一些问题

背景

解决

问题一

问题二

最新文章

热门文章