WCF 服务容器化的一些问题

背景

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

  1. 某些服务使用到了 WSHttpBinding 保护服务安全,要在容器里面加载 SSL 证书。
  2. 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:LocalMachineMy"
$certificate = New-SelfSignedCertificate -DnsName $hostName -CertStoreLocation $storeLocation
$thumbPrint = $certificate.Thumbprint
$certificatePath = ("cert:localmachinemy" + $certificate.Thumbprint)
$bindingInformation = "*:" + $port + ":" + $hostName
$securedString = ConvertTo-SecureString -String $password -Force -AsPlainText
Export-PfxCertificate -FilePath "C:WcfServicetemp.pfx" -Cert $certificatePath -Password $securedString
Import-PfxCertificate -FilePath "C:WcfServicetemp.pfx" -CertStoreLocation "Cert:LocalMachineRoot" -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 服务容器化的一些问题

THE END
分享
二维码