华为云 如何在不同地区之间迁移数据？

Kmesh 是内核原生Sidecarless服务网格数据平面。它借助 "eBPF "和 "可编程内核"，将流量治理下沉到操作系统内核，大大的降低了服务网格的资源开销和网络延迟。通过eBPF，流量数据可以直接在内核中获取，并且能够使用 "bpf map"将数据传递到用户空间。Kmesh使用这些数据构建监控指标和访问日志。▍如何获取原始数据在内核中，可以直接获取socket携带的流量信息。bpf_tcp_sock 中携带的数据如下：struct bpf_tcp_sock { __u32 snd_cwnd; /* Sending congestion window */ __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 snd_ssthresh; /* Slow start size threshold */ __u32 rcv_nxt; /* What we want to receive next */ __u32 snd_nxt; /* Next sequence we send */ __u32 snd_una; /* First byte we want an ack for */ __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 ecn_flags; /* ECN status bits. */ __u32 rate_delivered; /* saved rate sample: packets delivered */ __u32 rate_interval_us; /* saved rate sample: time elapsed */ __u32 packets_out; /* Packets which are "in flight" */ __u32 retrans_out; /* Retransmitted packets out */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn * total number of data segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut * total number of data segments sent. */ __u32 lost_out; /* Lost packets */ __u32 sacked_out; /* SACK'd packets */ __u64 bytes_received; /* RFC4898 tcpEStatsAppHCThruOctetsReceived * sum(delta(rcv_nxt)), or how many bytes * were acked. */ __u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked * sum(delta(snd_una)), or how many bytes * were acked. */ __u32 dsack_dups; /* RFC4898 tcpEStatsStackDSACKDups * total number of DSACK blocks received */ __u32 delivered; /* Total data packets delivered incl. rexmits */ __u32 delivered_ce; /* Like the above but only ECE marked packets */ __u32 icsk_retransmits; /* Number of unrecovered [RTO] timeouts */ };注意: 上述数据并没完全用于监控指标和访问日志功能。Kmesh将在后续的开发中逐步补充这些指标。现阶段使用的数据有：struct tcp_probe_info { __u32 type; struct bpf_sock_tuple tuple; __u32 sent_bytes; __u32 received_bytes; __u32 conn_success; __u32 direction; __u64 duration; // ns __u64 close_ns; __u32 state; /* tcp state */ __u32 protocol; __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 lost_out; /* Lost packets */ };除了这些socket携带的数据外，Kmesh通过socket_storage在建立链接时存储临时数据。当链接关闭时，从之前存储的临时数据中获取链接持续时间等数据。▍数据处理Kmesh在内核中获取了来自链接的数据后，会通过ringbuf将数据传递给用户态。Kmesh在用户态将ringbuf的数据解析之后，根据这些数据中携带的源服务和目标服务信息更新metricController中的缓存和构建metricLabels。构建的metricLabels有workload粒度的也有service粒度的。但workload粒度的监控指标最多是集群中pod数量的平方，因此Kmesh提供一个启动开关，使用户能够按需启用监控指标功能和访问日志功能。namespacedhost := "" for k, portList := range dstWorkload.Services { for _, port := range portList.Ports { if port.TargetPort == uint32(dstPort) { namespacedhost = k break } } if namespacedhost != "" { break } }建立工作负载粒度的度量和服务粒度的度量metricLabels后，更新缓存。每5秒钟，监控指标信息都会通过Prometheus API更新到Prometheus中。在处理指标时，会一起生成访问日志。每次链接关闭时，都会将生成的Accesslog打印到Kmesh的日志中。Kmesh监控指标功能和访问日志功能的整体架构图如下所示：指标细节现阶段Kmesh L4层监控的指标如下：工作负载粒度:NameDescribekmesh_tcp_workload_connections_opened_total源工作负载和目标工作负载之间总共建立了多少次链接kmesh_tcp_workload_connections_closed_total源工作负载和目标工作负载之间总共关闭了多少次链接kmesh_tcp_workload_received_bytes_total目标工作负载接收到了多少的数据kmesh_tcp_workload_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_workload_conntections_failed_total源工作负载和目标工作负载之间建立链接失败了多少次服务粒度:NameDescribekmesh_tcp_connections_opened_total源工作负载和目标服务之间总共建立了多少次链接kmesh_tcp_connections_closed_total源工作负载和目标服务之间总共关闭了多少次链接kmesh_tcp_received_bytes_total目标服务接收到了多少的数据kmesh_tcp_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_conntections_failed_total源工作负载和目标服务之间建立链接失败了多少次监控指标例子:kmesh_tcp_workload_received_bytes_total{connection_security_policy="mutual_tls",destination_app="httpbin",destination_canonical_revision="v1",destination_canonical_service="httpbin",destination_cluster="Kubernetes",destination_pod_address="10.244.0.11",destination_pod_name="httpbin-5c5944c58c-v9mlk",destination_pod_namespace="default",destination_principal="-",destination_version="v1",destination_workload="httpbin",destination_workload_namespace="default",reporter="destination",request_protocol="tcp",response_flags="-",source_app="sleep",source_canonical_revision="latest",source_canonical_service="sleep",source_cluster="Kubernetes",source_principal="-",source_version="latest",source_workload="sleep",source_workload_namespace="default"} 231也能够通过prometheus dashboard查看监控指标。具体步骤参考Kmesh可观测性文档。现阶段Kmesh访问日志展示的字段如下：NameDescribesrc.addr请求的源地址和端口src.workload源工作负载名称src.namespace源工作负载所在的namespacedst.addr请求的目标地址和端口dst.service目标服务的域名dst.workload目标工作负载的名称dst.namespace目标工作负载的命名空间direction流量流向，OUTBOUND表示从节点流出，INBOUND表示从流入节点sent_bytes本次链接发送的数据量received_bytes本次链接接收的数据量duration本次链接的持续时间Accesslog Result:accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system, dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms▍SummaryKmesh直接从套接字获取流量数据，并将其作为ringbuf传递到用户空间，以生成监控指标和访问日志。避免在用户空间拦截流量并以本地方式获取指标。定期批量更新用户空间中的指标，避免在大流量时增加网络延迟。随后，我们还将开发跟踪功能，以补充 Kmesh 的可观测能力。欢迎感兴趣的同学加入Kmesh开源社区!12月7日，Kmesh技术专家将在2024华为云开源开发者论坛上带来《服务网格的未来：Kmesh的设计思想与演进方向》技术分享及重磅发布！添加小助手k8s2222，报名领票参会！

如何选择正确的存储类型？

华为云如何实现容灾备份？

开放创新，释放云上数字生产力。12月7日，2024华为云开源开发者论坛将于上海举办。本届论坛面向生态合作伙伴、企业、个人和高校开发者，设置主论坛、云原生、开源共创、大前端四大论坛，帮助开发者使用开源链接鲲鹏、昇腾根生态和华为云生态，实现高效创新和价值裂变。2024华为云开源开发者论坛云原生专场汇聚 KubeEdge、Volcano、Karmada、Kmesh、openGemini、Sermant、OpenTiny、Kuasar 等技术大咖，邀您共探前沿技术，共领智能未来！完整议程已揭晓，欢迎报名参会 https://hdxu.cn/mitm

虚拟网络与子网的作用是什么？

作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，5G网络普及导致边缘设备产生的数据量快速增长。普通的边缘设备计算能力不足，因此传统方法会将边缘侧数据集中汇聚到云端数据中心进行处理，容易对响应实时性、网络稳定性以及数据安全性产生挑战。为满足用户在大规模设备场景中更高的可用性需求，KubeEdge Device-IoT在1.12版本推出设备管理框架（Device Management Interface，DMI）。DMI整合设备管理接口，将管理面和业务面数据解耦，优化边缘计算场景下的设备管理能力，打造基于云原生技术的设备数字孪生管理平台。在 1.15 版本中，我们根据边缘设备管理的用户需求迭代更新 v1beta1 版本的设备管理  API，并以此为基础完善 DMI 数据面功能，承载于南向的 Mapper 开发框架 Mapper-Framework 中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备管理面与数据面能力，能够自动生成 Mapper 工程，用户只需实现其中的设备驱动的功能即可使用 Mapper 管理边缘设备，简化用户设计开发 Mapper 的复杂度，提升开发效率。针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 本篇文章是系列文章的第一篇，主要介绍基于物模型的设备管理 API。    基于物模型的设备管理 API  为适应用户需求，在 v1.15.0 版本中，KubeEdge SIG Device-IoT 提出基于物模型的设备管理 API，将 Device Model 与 Device Instance从 v1alpha2 版本升级为 v1beta1 版本。新版本的设备管理 API 能够更全面的描述物理设备，新增了边缘设备数据处理的相关字段，能够适配 DMI 数据面能力增强功能。北向设备  API 结合南向的 DMI 接口，实现设备管理与设备数据处理，API 的主要更新包括：▍1. Device ModelDevice Model 用以描述一类边缘设备共同的设备属性。按照物模型的定义，Device Model 中新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段，如下图所示：// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. // Note: If you need to use the built-in stream data processing function, you need to define Name as saveFrame or saveVideo Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES,STREAM Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }上图展示了 Device Model 的核心 ModelProperty 字段，其中 Type 字段定义该属性的数据类型，AccessMode 定义该属性的访问方式，包括读写和只读两种。当访问方式设置为只读时，Mapper 会直接返回采集到的设备数据，反之当设置为读写后，Mapper 会对采集到的设备数据进行归一化等处理后再返回。Minimum 与 Maximum 则定义了设备属性的最大最小值，Unit 字段定义了设备属性的单位。下图展示了一个 Device Model 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: DeviceModel metadata: name: beta1-model spec: properties: - name: temp # define device property description: beta1-model type: INT # date type of device property accessMode: ReadWrite maximum: "100" # range of device property (optional) minimum: "1" unit: "Celsius" # unit of device property protocol: modbus # protocol for device, need to be same with device instance▍2. Device Instance一个 Device Instance 代表一个实际的设备对象。v1beta1 版本中，Device Instance 中内置的协议配置全部移除，包括 Modbus、OPC-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置设备协议，能够实现任何协议的设备接入。Modbus、OPC-UA、Bluetooth 等内置协议的 Mapper 仍会保留在 Mappers-go 仓库中，同时也会不断增加其他协议的内置 Mapper。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` }此外，为增强 DMI 数据面功能，本次更新在 Device Instance 的设备属性中增加了设备数据处理的相关配置，例如设备上报频率、数据推送频率、属性是否上报云端、设备数据推送方式，如下图所示。type DeviceProperty struct { ... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }ReportCycle 字段定义了 Mapper 向用户数据库、用户应用推送数据的频率；CollectCycle 字段定义了 Mapper 向云端上报数据的频率；ReportToCloud 字段定义了 Mapper 采集到的设备数据是否需要上报云端；PushMethod 字段定义了 Mapper 推送设备数据的方式。目前提供 HTTP、MQTT 以及 OpenTelemetry 等方式向用户应用推送数据，并内置集成 InfluxDB、MySQL、Redis、TDengine 数据库。用户能够通过配置文件控制Mapper 向用户应用、用户数据库中定时推送设备数据，也能够通过 API 主动拉取设备数据，实现设备数据处理方式的多样化，相比于将所有数据推送至云端再行处理的传统方法，能够有效减少云边通信阻塞的风险。下图展示了一个 Device Instance 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: temp collectCycle: 2000 # The frequency of reporting data to cloud, 2 seconds reportCycle: 2000 # The frequency of data push to user applications or databases, 2 seconds reportToCloud: true # Decide whether device data needs to be pushed to the cloud pushMethod: mqtt: # Define the MQTT config to push device data to user app address: tcp://127.0.0.1:1883 topic: temp qos: 0 retained: false visitors: # Define the configuration required by the mapper to access device properties (e.g. register address) protocolName: modbus configData: register: "HoldingRegister" offset: 2 limit: 1 protocol: # Device protocol. The relevant configuration of the modbus protocol is defined in the example. protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600基于 v1beta1版本的设备管理 API，我们以 Kubernetes CRD 的形式将 Device Model 与 Device Instance 引入 KubeEdge 集群。如需要更多详细的信息，可以参考设备管 API 的 proposal 文件[1] 以及相关 PR[2]。在本系列的下一篇文章中，我们会对 DMI 数据面能力的支持进行详细的介绍。▍相关链接[1]  docs/proposals/device-crd-v1beta1.md：cid:link_1[2]  相关PR：device crd v1beta1 and API definition：cid:link_2【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_3Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

基础设施即服务 (IaaS)： 如何设置自动扩展（Auto Scaling）？

如何配置负载均衡器？

什么是块存储与对象存储？

怎样管理虚拟机实例？

如何选择适合的 IaaS 提供商？

 aws 已创建 alb ingress 域名 无法访问，如何查看 ingress controller 情况 

KubeEdge 1.19.0版本现已正式发布。新版本在节点和设备方面引入了多个新特性，同时带来了全新版本的 Dashboard。 KubeEdge v1.19 新增特性：支持边缘节点上报 Event支持边缘节点 OTA 升级Mapper 支持设备数据写入Mapper 框架新增支持 OpenTelemetry全新版本 Dashboard  新特性概览  ▍支持边缘节点上报 EventKubernetes Event 作为集群中事件的报告，可以反馈节点、Pods 等集群资源的状态变化。在1.19版本中，EdgeCore 支持了边缘 Event 的上报，用户可以直接在云端通过kubectl get events 或者kubectl describe {resource_type} {resource_name} 获取边缘节点或者 pods 等状态。该特性在1.19版本中默认关闭，使用EdgeCore时执行--set modules.edged.reportEvent=true 或者如下修改 EdgeCore 配置参数并重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates:   requireAuthorization: true modules:   ...   edged:     reportEvent: true ...更多信息可参考：cid:link_3cid:link_4▍支持边缘节点 OTA 升级新版本在节点升级 NodeUpgradeJob 基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后，在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的 kubeedge/installation-pacakge 镜像是安全可靠的。在1.19版本中，我们可以通过 YAML 配置 NodeUpgradeJob 的 imageDigestGatter 来定义镜像摘要，value 用于直接定义摘要的值，registryAPI 用于通过 registry v2 接口获取镜像摘要，两者互斥，如果都没有配置则在升级时不进行镜像摘要的校验，样例：spec:   ...   imageDigestGatter:     value: ""     registryAPI:       host: ""       token: ""我们还可以通过 YAML 配置 NodeUpgradeJob 的 requireConfirmation 来定义是否要在边端进行确认操作，样例：spec:   ...   requireConfirmation: true当 requireConfirmation 设置为 true 时，在边端节点升级任务下发到边端后，任务状态会更新为 confirmation 状态等待边端发起确认命令后再继续进行升级。我们可以通过执行 keadm ctl 指令进行确认，以继续升级任务：keadm ctl confirm或者调用 Metaserver 接口进行确认，以继续升级任务：POST http(s)://localhost:<metaserver_port>/confirm更多信息可参考：cid:link_2cid:link_5cid:link_6▍Mapper 支持设备数据写入 Mapper 当前能够采集设备数据并上报，但在设备数据写入方面仍不完善。1.19版本在 Mapper-Framework 中增加了设备数据写入的能力，允许用户通过 Mapper 提供的 API 调用 device method，对 device property 完成数据写入。Device method API目前基于物模型的 v1beta1 版本的设备管理 API 包含 device property 的定义，在1.19版本中，新增 device method 的定义。Device method 指设备能够被外部调用的能力或方法，一个 device method 能够控制多个 device property 值。用户能在 device-instance 文件中定义 device method，通过 device method 完成 device property 的控制、写入。spec:   ...   methods:     - name: ""       description: ""       propertyNames:       - ""设备数据写入在1.19中改进 Mapper API 能力，新增 device method 调用接口。用户能够调用相关的接口获取某个设备包含的所有 device method，以及 device method 的调用命令，通过返回的调用命令发起设备写入请求。device method 的具体功能实现需要用户自行在 Mapper 的设备驱动层中完成。更多信息可参考：cid:link_7cid:link_8▍Mapper 框架新增支持 OpenTelemetry 当前 Mapper 向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式，但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架，能够封装设备数据并向多类应用或数据库推送数据，例如 GreptimeDB、 Prometheus 等，增强 Mapper 数据面推送设备数据的能力。spec:   ...   properties:     - name: ""       pushMethod:          otel：           endpointURL: ""更多信息可参考：cid:link_9▍全新版本 Dashboard之前发布的 KubeEdge Dashboard，新版本使用主流的 Next.js 框架以及 MUI 样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件，基于 KubeEdge 最新版本的后端 API，我们完善并增加了 Device 等相关功能页面，并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中，我们整理完善了 Kubernetes 以及 KubeEdge 后端接口的 Typescript 类型定义，并将依赖的后端接口更新至最新版本，确保其与最新的 KubeEdge 兼容。更多信息可参考：cid:link_10 版本升级注意事项 下个版本（v1.20），EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm 安装EdgeCore时设置 --set edged.rootDirectory=/var/lib/edged。从1.19版本开始，请在使用 keadm 安装 KubeEdge 时，使用--kubeedge-version 指定版本，--profile version 已废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.19版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_1【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

mv node-v12.16.1-linux-x64 /usr/local/Node.js