【Azure 应用服务】本地Node.js部署上云(Azure App Service for Linux)遇到的三个问题解决之道

简介: 【Azure 应用服务】本地Node.js部署上云(Azure App Service for Linux)遇到的三个问题解决之道

问题描述

当本地Node.js(Linux + Node.js + npm + yarn)部署上云,选择 Azure App Service for Linux 环境。但是在部署时,遇见了以下三个问题:

问题一:使用VS Code进行部署,部署速度非常的慢,且长时间无法部署成功

问题二:本地项目文件部署到App Service的WWWROOT目录下,但是项目中的node_modules为空,即App Service没有完成自动化部署

问题三:部署成功后,项目无法访问,端口3000没有被App Service监听

 

问题解答

问题一:使用VS Code进行部署,部署速度非常的慢,且长时间无法部署成功

因为Node.js 应用必须与所有必需的 NPM 依赖项一起部署。但如果项目根目录文件中包含了 yarn.lock 或者是在 package.json 中指定了 yarn 作为Package Manager,则会使用 yarn 来代替 npm。 且默认会使用最新版的 yarn。这会导致在部署时出现未知问题。如卡顿导致长时间无响应。

解决办法为,删除 yarn.lock 文件。

引用文档:https://github.com/microsoft/Oryx/blob/main/doc/runtimes/nodejs.md#package-manager

Package manager

The version of npm used to install dependencies and run npm scripts is the one bundled with the specified Node.js version as listed here.

If a yarn.lock file is found in your repo root or if you specify "yarn" in the engines field of package.json, the latest or specified version of yarn will be used instead of npm.

Note that installing packages globally is unsupported, whether requested directly by your app or by some pre/post install script of an included package. For example, this will not work in your package.json:

"scripts" : {

   "preinstall" : "npm install -g somepackage"

 }

 

问题二:本地项目文件部署到App Service的WWWROOT目录下,但是项目中的node_modules为空,即App Service没有完成自动化部署

因为项目文件已经部署到 wwwroot目录下,但是 node_modules 为空,表示部署时没有完成 npm install 自动编译的命令。所以经过查看关于App Service对部署是否自动build的资料发现,当对App Service进行部署的时候,App Service Kudu会自动执行编译命令。其主要是通过 SCM_DO_BUILD_DURING_DEPLOYMENT 参数进行控制。

SCM_DO_BUILD_DURING_DEPLOYMENT 设置为 true 时,Kudu会自动编译项目文件,如运行 npm install 或 dotnet build / dotnet pulish

SCM_DO_BUILD_DURING_DEPLOYMENT 设置为false时,则不会。当使用ZIP 包部署时,就不会触发自动编译。因为Kudu认为ZIP中的文件已经是可执行文件,不在需要编译。

Reference : https://github.com/projectkudu/kudu/wiki/Configurable-settings#enabledisable-build-actions

 

解决办法为,在App Service的Configuration中添加 SCM_DO_BUILD_DURING_DEPLOYMENT 参数,并配置值为 true。或者是在项目跟目录中添加 .deployment 文件。并在其中加入

[config]

SCM_DO_BUILD_DURING_DEPLOYMENT=true

如图:

 

问题三:部署成功后,项目无法访问,端口3000没有被App Service监听

Node.js 应用需要侦听正确的端口才能接收传入的请求

当部署完成,但无法通过浏览器访问App Service 。这时候,就可以直接登录Kudu 查看 docker 日志。在日志中看见 app service默认监听的端口为8080。

而 Node.js 项目中,使用的确是3000,所以需要通过配置App Service的 Application Setting来解决这个问题。

解决办法为:通过App Service门户,添加 PORT 或者 WEBSITES_PORT 应用配置参数值为3000.

 

Reference:

https://docs.azure.cn/zh-cn/app-service/configure-custom-container?pivots=container-linux#configure-port-number

https://docs.azure.cn/zh-cn/app-service/configure-language-nodejs?pivots=platform-linux#get-port-number

相关文章
|
7月前
|
Java 应用服务中间件 API
【App Service】部署War包到Azure云上遇404错误
Java应用部署至Azure App Service for Windows后报404,本地运行正常。经排查,日志提示类文件版本不兼容:应用由Java 17(class file version 61.0)编译,但环境仅支持到Java 11(55.0)。错误根源为Java版本不匹配。调整App Service的Java版本至17后问题解决,成功访问接口。
754 3
|
7月前
|
存储 Linux 网络安全
【Azure App Service】Root CA on App Service
Azure App Service for Windows应用连接外部SSL服务时,需确保其证书由受信任的根CA颁发。多租户环境下无法修改根证书,但ASE(单租户)可加载自定义CA证书。若遇证书信任问题,可更换为公共CA证书或将应用部署于ASE并导入私有CA证书。通过Kudu的PowerShell(Windows)或SSH(Linux)可查看当前受信任的根证书列表。
166 13
|
8月前
|
API 网络架构 容器
【Azure Container App】查看当前 Container App Environment 中的 CPU 使用情况的API
在扩展 Azure Container Apps 副本时,因 Container App Environment 的 CPU 核心数已达上限(500 cores),导致扩展失败。本文介绍如何使用 `az rest` 命令调用 Azure China Cloud 管理 API,查询当前环境的 CPU 使用情况,并提供具体操作步骤及示例。
308 17
|
8月前
|
网络协议 Java Linux
【App Service】在Azure环境中如何查看App Service实例当前的网络连接情况呢?
在 Azure App Service(Windows 和 Linux)中部署应用时,分析网络连接状态是排查异常、验证端口监听及确认后端连接的关键。本文介绍如何在 Linux 环境中使用 `netstat` 命令查看特定端口(如 443、3306、6380)的连接情况,并解析输出结果。同时说明在 Windows App Service 中 `netstat` 被禁用的情况下,如何通过门户抓包等替代方法进行网络诊断。内容涵盖命令示例、操作步骤及附录说明,帮助开发者快速掌握云环境中的网络分析技巧。
217 11
|
8月前
|
数据安全/隐私保护
【Azure Function App】PowerShell Function 执行 Get-AzAccessToken 的返回值类型问题:System.String 与 System.Security.SecureString
将PowerShell Function部署到Azure Function App后,Get-AzAccessToken返回值类型在不同环境中有差异。正常为SecureString类型,但部分情况下为System.String类型,导致后续处理出错。解决方法是在profile.ps1中设置环境变量$env:AZUREPS_OUTPUT_PLAINTEXT_AZACCESSTOKEN=false,以禁用明文输出。
223 1
|
8月前
|
Linux 应用服务中间件 Shell
二、Linux文本处理与文件操作核心命令
熟悉了Linux的基本“行走”后,就该拿起真正的“工具”干活了。用grep这个“放大镜”在文件里搜索内容,用find这个“探测器”在系统中寻找文件,再用tar把东西打包带走。最关键的是要学会使用管道符|,它像一条流水线,能把这些命令串联起来,让简单工具组合出强大的功能,比如 ps -ef | grep 'nginx' 就能快速找出nginx进程。
962 1
二、Linux文本处理与文件操作核心命令
|
8月前
|
Linux
linux命令—stat
`stat` 是 Linux 系统中用于查看文件或文件系统详细状态信息的命令。相比 `ls -l`,它提供更全面的信息,包括文件大小、权限、所有者、时间戳(最后访问、修改、状态变更时间)、inode 号、设备信息等。其常用选项包括 `-f` 查看文件系统状态、`-t` 以简洁格式输出、`-L` 跟踪符号链接,以及 `-c` 或 `--format` 自定义输出格式。通过这些选项,用户可以灵活获取所需信息,适用于系统调试、权限检查、磁盘管理等场景。
548 137
|
8月前
|
安全 Ubuntu Unix
一、初识 Linux 与基本命令
玩转Linux命令行,就像探索一座新城市。首先要熟悉它的“地图”,也就是/根目录下/etc(放配置)、/home(住家)这些核心区域。然后掌握几个“生存口令”:用ls看周围,cd去别处,mkdir建新房,cp/mv搬东西,再用cat或tail看文件内容。最后,别忘了随时按Tab键,它能帮你自动补全命令和路径,是提高效率的第一神器。
1460 58
|
7月前
|
存储 安全 Linux
Linux卡在emergency mode怎么办?xfs_repair 命令轻松解决
Linux虚拟机遇紧急模式?别慌!多因磁盘挂载失败。本文教你通过日志定位问题,用`xfs_repair`等工具修复文件系统,三步快速恢复。掌握查日志、修磁盘、验重启,轻松应对紧急模式,保障系统稳定运行。
1330 2
|
8月前
|
Unix Linux 程序员
Linux文本搜索工具grep命令使用指南
以上就是对Linux环境下强大工具 `grep` 的基础到进阶功能介绍。它不仅能够执行简单文字查询任务还能够处理复杂文字处理任务,并且支持强大而灵活地正则表达规范来增加查询精度与效率。无论您是程序员、数据分析师还是系统管理员,在日常工作中熟练运用该命令都将极大提升您处理和分析数据效率。
715 16