应用服务自定义域需要在部署时进行验证，这反过来又需要 DNS CNAME 指向新的应用服务名称。然而，应用程序服务名称是动态创建的，因此我们不知道它在部署时将具有的名称。这个https://learn.microsoft.com/en-us/azure/app-service/manage-custom-dns-migrate-domain几乎解决了问题，但它还要求您在部署之前知道应用程序服务名称。
我尝试使用应用程序网关来代替应用程序服务并在重写规则中编辑 URL。这部分有效，但不幸的是，它有一个已记录的错误，如果有许多 Set-Cookie 需要重写，它会重写第一个并删除其余的。因此，我们无法重写应用程序网关上的标头（直到 MS 修复错误），而必须将公共 URL 一直发送到后端应用程序服务，这就是为什么我们需要在应用程序服务上定义的自定义域本身。
问题是：如果在创建应用服务之前我不知道应用服务的名称，如何在使用 Azure Devops 部署时在应用服务上创建自定义域？
视觉工作室 2019 16.8.5
我想使用阶段模板。有些阶段，我想根据条件而定。但是，当我在 YML 文件中尝试此操作时，它会生成错误。以下是 azure-pipelines.yml 文件中的两次尝试：
stages:
- template: 'build.yml'
- template: 'deploy.yml'
- template: 'test.yml'
- ${{ if eq('true', 'true') }}:
- template: 'optional.yml'
结果是：
Severity Code Description Project File Line Suppression State
Error Property ${{ if eq('true', 'true') }} is not allowed. azure-pipelines.yml 8
和这个：
stages:
- template: 'build.yml'
- template: 'deploy.yml'
- template: 'test.yml'
- template: 'optional.yml'
condition: eq('true', 'true')
结果是：
Severity Code Description Project File Line Suppression State
Error Property template is not allowed. …我有一个面向 .Net Core 3.0 的 Visual Studio Azure 应用服务项目。当我将它部署到 Azure 时，没有指定 Stack，Stack 最终会变成 .Net V4.7。
这篇文章提出了一个类似的问题：https : //social.msdn.microsoft.com/Forums/en-US/a4040bf9-2ba0-42c6-a242-87febf7a5e6d/select-net-core-22-as-technology-stack?forum =windowsazurewebsitespreview 答案是“.NET Core SDK 32 位二进制文件通常包含在 Windows 应用服务中。因此，无需明确选择 .NET Core 作为版本”。换句话说：因为是 Windows，所以不需要指定 .Net Core 目标。这意味着因为它是 Windows，所以它可以正常工作。
这篇文章也提出了一个类似的问题：Azure webapp: Stack settings答案是“在初始 Web 应用程序创建之后，不再需要确定应用程序是 .NET Core 应用程序，因为 .NET Core 位已经安装在底层工人”。这也意味着因为它是 Windows，所以它可以正常工作。
两者似乎都与此 Microsoft 参考相矛盾：https : //docs.microsoft.com/en-us/dotnet/standard/net-standard
据此，.Net Core 3.0 与任何版本的 .Net Framework 都不兼容。更正式地说，.Net Standard 2.1 被合并到 .Net Core 3.0 中，但没有 .Net 框架版本。然而，在 Azure 中，我的应用服务确实有效。
问题：它之所以有效，是因为虽然我在 Visual Studio 中指定了 .Net Core …
创建到应用服务的 HTTP 自定义域后，如何防止 Azure 应用服务从 HTTP 重定向到 HTTPS？
仅 HTTPS 已禁用 身份验证已按照如何删除 Azure SSL 绑定？
背景：应用程序服务前面有一个处理所有 HTTPS 流量的应用程序网关。应用服务重写标头和 Set-Cookie。根据https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers存在一个错误/限制：“如果响应有多个同名标头，则重写这些标头之一的值将导致丢弃响应中的其他标头。这种情况通常会发生在 Set-Cookie 标头中，因为响应中可以有多个 Set-Cookie 标头。” 我们受到这个限制的阻碍。这意味着我们无法使用此处描述的第一个解决方法： https: //learn.microsoft.com/en-us/azure/application-gateway/troubleshoot-app-service-redirection-app-service-url “解决方案：重写位置标题”。我们被迫使用第二种解决方案，它本质上是将流量传递到后端应用程序服务，如“替代解决方案：使用自定义域名”中所述。这些示例都使用 HTTP 作为后端。我们确实尝试过使用 HTTPS 作为后端，但这需要部署（我们使用 Azure Devops）将证书推送到应用程序服务以及应用程序网关，这对于一个简单的需求来说似乎需要付出很大的努力 - 特别是因为所有 Microsoft 示例都在后端使用 HTTP（如果有应用程序网关保护它）。
在应用程序网关能够正确处理多个 Set-Cookie 重写之前，这只是权宜之计。
我已经在AWS的Centos 7上安装了最新的s3fs，并且可以挂载我的S3存储桶并从中读取。我的要求是允许任何用户读取、写入、创建和删除文件和文件夹，包括其他人的文件和文件夹——基本上是一个免费的文件和文件夹。
\n在 fstab 中，我有这个：
\nmy-bucket /mnt/my-bucket fuse.s3fs _netdev,url=https://s3-eu-west-1.amazonaws.com,umask=0000,allow_other,rw,gid=0,uid=0 0 0\n当我尝试以 centos 用户身份创建名为 test 的新文件夹时，出现以下错误：\nmkdir: 无法创建目录 \xe2\x80\x98test\xe2\x80\x99: 不允许操作
\n我尝试将安装点 chmod/mnt为 777（默认为 755）。我也在文件# user_allow_other中取消了注释fuse.conf。两者都不起作用。
fstab 中满足要求的正确 umask、gid 和 uid（以及其他设置）是什么？
\n