Java 使用FTP将Spring Boot app.jar部署到Azure不起作用

我正在尝试将本地构建的Spring启动应用程序部署到Azure应用程序服务。注意，我对使用Azure是新手

我使用Azure门户创建的应用程序服务具有以下特征：

• Stack

  ：

  JavaSE（JRE 8）

这将使尽可能地运行应用程序

我还添加了以下应用程序设置（环境变量）：

• JAVA\u选项

  ：

  -Dserver.port=80

• SPRING\u PROFILES\u ACTIVE

  ：

  prod

这应该设置正确的服务器端口，假设端口

80

是我应该使用的正确端口。我在其他帖子上读到了这篇文章。 第二个应用程序设置将确保使用应用程序内的

prod

配置文件

我使用FTP连接到应用程序服务，删除了

default.jar

，上传了我自己的

App.jar

，然后重新启动了应用程序服务

我收到通知，应用程序已重新启动，但似乎无法工作。 我无法访问应用程序，但也无法找到日志文件。 在Azure门户中尝试日志流只提供有关站点启动容器和docker相关日志的信息，而不是我的应用程序的日志

我不知道下一步该去哪里查找故障排除

注意，我正在使用FTP部署选项，因为我的应用程序是用Gradle构建的，Azure似乎只有一个Maven插件用于部署应用程序

更新

我使用FTP添加了一个web.config，其中包含：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
        </handlers>
        <httpPlatform processPath="%JAVA_HOME%\bin\java.exe"
            arguments="-Djava.net.preferIPv4Stack=true -Dserver.port=%HTTP_PLATFORM_PORT% -jar &quot;%HOME%\site\wwwroot\app.jar&quot;">
        </httpPlatform>
    </system.webServer>
</configuration>

---

请注意，同样的应用程序在Heroku上成功运行了几个月。

发生了一些事情。 添加上述web.config后，应用程序正在部署

Java运行时环境检测到一个致命错误

是由于使用内存和磁盘存储组合的Ehcache造成的

从应用程序中删除Ehcache后，应用程序仍然无法工作，根据日志，我发现应用程序在

230s

内没有启动。 在将应用程序设置

WEBSITES\u CONTAINER\u START\u TIME\u LIMIT

更新为

1800

后，它工作了

我不知道为什么这个应用要花这么长时间才能启动。从日志上看，在某些地区没有花费太多的时间；只是逐渐变慢了。

---

应用程序在本地启动于

8s

，在Heroku上启动于

20s

应用程序服务支持在Windows和Linux上运行java。Web.config工件仅在Windows上运行时有效，对于您的情况，因为您使用的是应用程序服务Linux，所以根本不会使用此工件

我们还有一些可以调整的设置，例如网站\u容器\u开始\u时间\u限制，但也有其他设置，如网站\u端口，用于配置容器将使用的端口。请查看常见问题解答：

另外，请查看应用程序服务的Java开发者指南：

谢谢

---

Joaqín

您添加了web.config文件吗？@geogechen否，在使用ftp复制一个jar时也需要这个文件吗？您现在知道web.config在这种情况下应该是什么样子吗？是否应该将其放置在与jar相同的位置？我已经添加了一个web.config，如上所述，但没有成功。首先，您应该确保您的jar文件可运行，然后您的日志显示存储了“hs_err_pid197.log”，也许您可以检查它。关于部署SpringBoot的详细步骤，您可以参考这个答案；这是一个标准的Spring Boot应用程序。我会发布一个我自己问题的答案；发生了各种各样的事情。嗨，华金，是的，我读过。但是，当您刚进入该平台时，很难找到jar不运行的原因。此外，该应用程序在本地运行时没有问题，并且立即在Heroku上运行，没有任何更改，这也给在Azure上运行它带来了一些启动问题。比如当使用Ehcache获取致命错误时；再一次在Heroku上，它立刻起作用了。无论如何，该应用程序现在正在运行，谢谢你的反馈。我现在完全惊讶于在Azure上为自定义域使用Let's Encrypt有多么困难。对于领先的PaaS提供商之一。。。在Netlify、Heroku等网站上，只需点击一个按钮即可启用此功能。Azure可以在这里做得更多，以争取在任何地方使用https实现更安全的web。

2019-01-25T12:53:31.730996889Z #
2019-01-25T12:53:31.731125589Z # A fatal error has been detected by the Java Runtime Environment:
2019-01-25T12:53:31.731207089Z #
2019-01-25T12:53:31.737259893Z #  SIGSEGV (0xb) at pc=0x000000000000b32e, pid=197, tid=0x00007fab3d393ae8
2019-01-25T12:53:31.740444095Z #
2019-01-25T12:53:31.740455395Z # JRE version: OpenJDK Runtime Environment (8.0_192-b01) (build 1.8.0_192-b01)
2019-01-25T12:53:31.740459895Z # Java VM: OpenJDK 64-Bit Server VM (25.192-b01 mixed mode linux-amd64 compressed oops)
2019-01-25T12:53:31.740463995Z # Problematic frame:
2019-01-25T12:53:31.740467795Z # C  0x000000000000b32e
2019-01-25T12:53:31.740471495Z #
2019-01-25T12:53:31.740475195Z # Core dump written. Default location: //core or core.197
2019-01-25T12:53:31.740479095Z #
2019-01-25T12:53:31.770424313Z # An error report file with more information is saved as:
2019-01-25T12:53:31.778837718Z # //hs_err_pid197.log
2019-01-25T12:53:31.827292848Z #
2019-01-25T12:53:31.827404948Z # If you would like to submit a bug report, please visit:
2019-01-25T12:53:31.827534548Z #   http://www.azulsystems.com/support/
2019-01-25T12:53:31.827635448Z #
2019-01-25T12:53:32.357760775Z /bin/init_container.sh: line 123:   197 Segmentation fault      (core dumped) java $JAVA_OPTS -jar "$JAR_PATH"
Docker logs from instance: RD0003FF30DE7C