Node.js 16 初体验

Node.js 16已经于4月20日发布,主要包括如下更新:

  • 升级V8引擎至9.0
  • 预构建的Apple silicon二进制文件以支持使用苹果芯片的Mac系统
  • 稳定部分API

详细更新日志可参考:https://nodejs.org/zh-cn/blog/release/v16.0.0/

Node.js发布时间表

可以在官网下载最新发布体验,或者使用版本管理工具(本文以跨平台的nvs为例)。

# 下载V16的Node.js
nvs add 16

# 在当前终端使用V16的Node.js(推荐)
nvs use 16
# 或者:设置全局默认的Node.js至V16
nvs link 16

查看node & npm版本

Node.js 16将会替代15并于接下来半年成为当前发布线(期间可能会有部分非紧要的代码更新),之后将于十月份进入长期支持(LTS)阶段并将该版本命名为Gallium。PS:V12会在2022年4月结束LTS阶段,V14为2023年4月,V10将于本月结束LTS阶段。

V8引擎的升级

每次V8引擎的升级都会带来性能的调整与提升以及支持最新的JavaScript语言特性,因此Node.js会常态化更新V8版本,Node.js 16使用V8 9.0(15使用的是V8 8.6)。

这次V8的升级带来了ECMAScript RegExp比对索引功能,能提供字符串的开始与结束索引。当正则表达式带有/d标签时,可以通过indices属性访问到索引数组。

RegExp match indice范例

更多V8更新请参考:https://v8.dev/

稳定Timers Promises API

Timers Promises API提供了可返回Promise对象的timer函数(无需再将timer通过util.promisify进行Promise化),该API于Node.js 15新增(本次发布将其从experimental状态更新为stable状态)。

import { setTimeout } from 'timers/promises';

async function run() {
  const res = await setTimeout(3000, 'fullFilledValue');
  console.log(`Get result=>${res} after 3s`);
}

run(); // 3s后输出:Get result=>fullFilledValue after 3s

其他特性

新的编译器与平台最低要求

Node.js针对不同的平台提供预构建的二进制文件,对于每个主要版本,在适当的情况下评估并提出最少的工具链。

Node.js v16.0.0是首个为apple芯片交付预构建二进制文件的版本,虽然将分别为Intel(darwin-x64)和ARM(darwin-arm64)架构提供压缩包,但macOS安装程序(.pkg)将作为“fat”(多架构)二进制文件提供。在基于Linux的平台上,构建Node.js 16的最低GCC级别将为GCC 8.3。详情请参考Node.js BUILDING.md文件

弃用

Node.js项目使用名为CITGM(Canary in the Goldmine)的工具,测试任何重大变化(包括弃用)对大量流行生态系统模块的影响,以在执行这些变化之前提供更多的参考。Node.js v16主要的弃用包括对多个核心模块内部执行process.binding()的运行时弃用,如process.binding(‘http_parser’)

云原生时代,拥抱微服务(三)—— 使用Kubernetes包管理器Helm

前文我们已经将Kubernetes集群搭建好,并且将应用容器化。然而作为开发者,在项目部署中依然觉得直接去管理各种Kubernetes对象是件非常费时且枯燥的事情(要直接去管理各种Kubernetes资源及相关联的标签与选择算符命名空间等)。

很多时候,当某处繁琐且重复时,便是优化开始的地方。 —— 皮皮叨叨

Helm是什么

Helm是对Kubernetes资源部署进一步的抽象,通俗地讲就是个Kubernetes包管理器,相当于Linux中的yum或apt。Helm通过直接部署将Kubernetes资源打包后的Charts,能够简化微服务应用的部署,并且能方便地更新与回滚应用。Helm Chart通过模板的方式部署应用程序。

Helm Chart具有如下目录结构:

YOUR-CHART-NAME/
 |
 |- .helmignore 
 | 
 |- Chart.yaml 
 | 
 |- values.yaml 
 | 
 |- charts/ 
 |
 |- templates/

其中:

  • .helmignore:声明所有在Chart打包时需忽略的文件,类似.gitignore功能。
  • Chart.yaml:存放该Chart的基本信息,如Chart名,版本号等
  • values.yaml:定义所有需要注入模板中的值,该文件中的值可被命令行参数覆盖。
  • templates:此文件夹存放该Chart所需要的Kubernetes资源清单(包括但不限于service、ingress、deployment等),其中的yaml文件使用golang 模板编写,value可以通过Values.yaml中定义的值注入。

小试牛刀(使用Helm安装WordPress)

  1. 安装Helm:

    sudo snap install helm --classic
    # 或
    microk8s.enable helm
  2. 新增环境变量(KUBECONFIG)

    安装完后直接运行helm ls

    运行 helm ls 命令

    会报“Kubernetes集群不可达”的错误。这是因为:helm v3版本不再需要Tiller,而是直接访问ApiServer来与k8s交互,通过环境变量KUBECONFIG来读取存有ApiServre的地址与token的配置文件地址,默认地址为~/.kube/config。而microk8s的相关配置文件路径为/var/snap/microk8s/current/credentials/client.config。解决方法:

    # 在.bashrc文件末尾追加新的KUBECONFIG
    echo export KUBECONFIG=/var/snap/microk8s/current/credentials/client.config >> ~/.bashrc
    # 执行.bashrc
    source .bashrc

    重新运行helm ls:

    运行helm ls命令

    可以看到helm已经能于Kubernetes集群正常交互。

  3. 安装WordPress

    # 添加远程helm chart仓库
    helm repo add bitnami https://charts.bitnami.com/bitnami
    
    # 安装WordPress
    helm install wordpress bitnami/wordpress \
    --namespace=wordpress \
    --set wordpressUsername=your-name,wordpressPassword=your-pwd,mariadb.mariadbRootPassword=db-root-pwd,ingress.enabled=true,ingress.hostname=your.domain.name

    参数含义及更多参数请参考:bitnami/wordpress

    通过运行helm ls -n wordpress可以看到wordpress已经部署(-n 代表namespace)。

    helm ls -n wordpress

    访问:http://your.domain.name

    wordpress网站首页效果

    能看到部署的WordPress已经成功运行,就这么简单,一两条命令的功夫就能拥有个人专属博客站点,Amazing!!!

    kubectl get

    通过kubectl get命令,可以看到Helm在底下帮我们创建好了WordPress站点所需的各种资源,Cool~

    那么Helm究竟使用了什么黑魔法呢?下面我们将通过为容器化后的应用创建Helm Chart来揭开其神秘面纱~

为应用程序定制Helm Chart

上面WordPress安装实质上是通过Helm安装远程仓库经过打包后的Chart实现的,在实际业务场景中我们也可以为应用程序定制Helm Chart。

  1. 创建Helm Chart

    helm create 

    helm create your-helm-chart-name

    可以看到我们已经成功创建了Helm Chart:

    新创建的Helm Chart目录结构

  2. 定制Helm Chart

    上面我们已经生成了一个通用的Chart,对于一些更为复杂的应用我们也可以在此基础上进行定制。基本操作流程就是根据需求修改或新增templates目录下各Kubernetes资源声明模板文件,在其中通过golang template语法注入values.yaml文件中定义的值,具有非常大的灵活性。

    举个栗子🌰,对于一般的API应用我们常常需要部署Job或者CronJob以执行特定任务,而且需要将kubernetes Secretskubernetes ConfigMaps注入到应用程序容器的环境变量中。

    除了工作负载Deployment的模板以外,我们还需要创建Job或者CronJob相关的模板(当然你也可以将三者放到一个模板中,再通过values.yaml中传入条件去生成对应的Kubernetes声明文件)。

    创建需要的工作负载模板

    我们发现上述多个工作负载模板中会有很多重复的内容(如容器的环境变量定义),对于这些可复用的模块我们可以将其在_helpers.tpl文件中新增声明:

    {{/* Add following code to templates/_helpers.tpl */}}
    {{/*
    Create container env to use
    */}}
    {{- define ".helm.container.env" -}}
    env:
     - name: MONGODB_HOST
       valueFrom:
         configMapKeyRef:
           name: your-api
           key: mongodb_host
     - name: MONGODB_DATABASE
       valueFrom:
         configMapKeyRef:
           name: your-api
           key: mongodb_database
     - name: MONGODB_USERNAME
       valueFrom:
         secretKeyRef:
           name: your-api
           key: mongodb_username
     - name: MONGODB_PASSWORD
       valueFrom:
         secretKeyRef:
           name: your-api
           key: mongodb_password
     - name: NODE_ENV
       value: {{ default "production" .Values.nodeEnv }}
    {{- end -}}

    templates/deployment.yaml模板文件:

    {{- if eq .Values.workload.kind "Deployment" }}
    apiVersion: apps/v1
    kind: Deployment
    metadata:
     name: {{ include ".helm.fullname" . }}
     labels:
       {{- include ".helm.labels" . | nindent 4 }}
    spec:
     replicas: {{ .Values.replicaCount }}
     strategy:
       type: {{ .Values.updateStrategy.type }}
       rollingUpdate:
         maxSurge: {{ .Values.updateStrategy.rollingUpdate.maxSurge }}
         maxUnavailable: {{ .Values.updateStrategy.rollingUpdate.maxUnavailable }}
     selector:
       matchLabels:
         {{- include ".helm.selectorLabels" . | nindent 6 }}
     template:
       metadata:
         labels:
           {{- include ".helm.selectorLabels" . | nindent 8 }}
       spec:
       {{- with .Values.imagePullSecrets }}
         imagePullSecrets:
           {{- toYaml . | nindent 8 }}
       {{- end }}
         serviceAccountName: {{ include ".helm.serviceAccountName" . }}
         securityContext:
           {{- toYaml .Values.podSecurityContext | nindent 8 }}
         containers:
           - name: {{ .Chart.Name }}
             securityContext:
               {{- toYaml .Values.securityContext | nindent 12 }}
             image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
             imagePullPolicy: {{ .Values.image.pullPolicy }}
             {{- include ".helm.container.env" . | nindent 10 }}
             {{- if .Values.workload.isGeneralDeployment }}
             ports:
               - name: http
                 containerPort: 3000
                 protocol: TCP
             livenessProbe:
               httpGet:
                 path: /api-health-check-endpoint
                 port: http
             readinessProbe:
               httpGet:
                 path: /api-health-check-endpoint
                 port: http
             {{- else }}
             command: {{ .Values.workload.command }}
             args: {{ .Values.workload.args }}
             {{- end }}
             resources:
               {{- toYaml .Values.resources | nindent 12 }}
         {{- with .Values.nodeSelector }}
         nodeSelector:
           {{- toYaml . | nindent 8 }}
         {{- end }}
       {{- with .Values.affinity }}
         affinity:
           {{- toYaml . | nindent 8 }}
       {{- end }}
       {{- with .Values.tolerations }}
         tolerations:
           {{- toYaml . | nindent 8 }}
       {{- end }}
    {{- end }}
    

    templates/cronJob.yaml文件

    {{- if eq .Values.workload.kind "CronJob" }}
    apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
     name: {{ include ".helm.fullname" . }}
     labels:
       {{- include ".helm.labels" . | nindent 4 }}
    spec:
     schedule: {{ .Values.workload.schedule }}
     jobTemplate:
       spec:
         template:
           metadata:
             labels:
               {{- include ".helm.selectorLabels" . | nindent 12 }}
           spec:
           {{- with .Values.imagePullSecrets }}
             imagePullSecrets:
               {{- toYaml . | nindent 12 }}
           {{- end }}
             serviceAccountName: {{ include ".helm.serviceAccountName" . }}
             securityContext:
               {{- toYaml .Values.podSecurityContext | nindent 12 }}
             containers:
               - name: {{ .Chart.Name }}
                 image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
                 imagePullPolicy: {{ .Values.image.pullPolicy }}
                 {{- include ".helm.container.env" . | nindent 14 }}
                 command: {{ .Values.workload.command }}
                 args: {{ range .Values.workload.args }}
                   - {{ . }}
                 {{ end }}
             restartPolicy: OnFailure
    {{- end }}
    

    templates/job.yaml文件

    {{- if eq .Values.workload.kind "Job" }}
    apiVersion: batch/v1
    kind: Job
    metadata:
     name: {{ include ".helm.fullname" . }}
     labels:
       {{- include ".helm.labels" . | nindent 4 }}
    spec:
     template:
       metadata:
         labels:
           {{- include ".helm.selectorLabels" . | nindent 8 }}
       spec:
       {{- with .Values.imagePullSecrets }}
         imagePullSecrets:
           {{- toYaml . | nindent 8 }}
       {{- end }}
         serviceAccountName: {{ include ".helm.serviceAccountName" . }}
         securityContext:
           {{- toYaml .Values.podSecurityContext | nindent 8 }}
         containers:
           - name: {{ .Chart.Name }}
             image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
             imagePullPolicy: {{ .Values.image.pullPolicy }}
             {{- include ".helm.container.env" . | nindent 10 }}
             command: {{ .Values.workload.command }}
             args: {{ range .Values.workload.args }}
               - {{ . }}
             {{ end }}
         restartPolicy: Never
    {{- end }}
    

    templates/service.yaml文件:

    {{- if and .Values.workload.isGeneralDeployment (eq .Values.workload.kind "Deployment") -}}
    apiVersion: v1
    kind: Service
    metadata:
     name: {{ include ".helm.fullname" . }}
     labels:
       {{- include ".helm.labels" . | nindent 4 }}
    spec:
     type: {{ .Values.service.type }}
     ports:
       - port: {{ .Values.service.port }}
         targetPort: http
         protocol: TCP
         name: http
     selector:
       {{- include ".helm.selectorLabels" . | nindent 4 }}
    {{- end -}}
    

    在使用支持外部负载均衡器的云提供商的服务时,设置 type 的值为 LoadBalancer, 将为 Service 提供负载均衡器。由于我们使用自建microk8s集群,LoadBalancer并没有效果,所以需要设置ingress以将Service暴露至公网。

    templates/ingress.yaml文件:

    {{- if .Values.ingress.enabled -}}
    {{- $fullName := include ".helm.fullname" . -}}
    {{- $svcPort := .Values.service.port -}}
    {{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
    apiVersion: networking.k8s.io/v1beta1
    {{- else -}}
    apiVersion: extensions/v1beta1
    {{- end }}
    kind: Ingress
    metadata:
     name: {{ $fullName }}
     labels:
       {{- include ".helm.labels" . | nindent 4 }}
     {{- with .Values.ingress.annotations }}
     annotations:
       {{- toYaml . | nindent 4 }}
     {{- end }}
    spec:
    {{- if .Values.ingress.tls }}
     tls:
     {{- range .Values.ingress.tls }}
       - hosts:
         {{- range .hosts }}
           - {{ . | quote }}
         {{- end }}
         secretName: {{ .secretName }}
     {{- end }}
    {{- end }}
     rules:
     {{- range .Values.ingress.hosts }}
       - host: {{ .host | quote }}
         http:
           paths:
           {{- range .paths }}
             - path: {{ . }}
               backend:
                 serviceName: {{ $fullName }}
                 servicePort: {{ $svcPort }}
           {{- end }}
     {{- end }}
    {{- end }}
    

    通过values.yaml定义默认值,实际部署时可传参替换。

    # Default values for .helm.
    # This is a YAML-formatted file.
    # Declare variables to be passed into your templates.
    replicaCount: 1
    
    updateStrategy:
     type: RollingUpdate
     rollingUpdate:
       maxSurge: 1
       maxUnavailable: 1
    
    nodeEnv: production
    
    image:
     repository: your.image.repository/path
     tag: latest
     pullPolicy: IfNotPresent
    
    imagePullSecrets: [{ name: your-image-registry }]
    nameOverride: "your-app-name"
    fullnameOverride: "your-app-name"
    
    workload:
     # Support Deployment,Job,CronJob
     kind: Deployment
     isGeneralDeployment: true
     command: ["yarn"]
     args: ["start"]
    
    serviceAccount:
     # Specifies whether a service account should be created
     create: false
     annotations: {}
    
    podSecurityContext: {}
    
    securityContext: {}
    
    service:
     type: ClusterIP
     port: 80
    
    ingress:
     enabled: true
     annotations:
       kubernetes.io/ingress.class: nginx
       kubernetes.io/tls-acme: "true"
     hosts:
       - host: your.domain.name
         paths:
           - '/'
     tls: []
    
    resources: {}
    
    nodeSelector: {}
    
    tolerations: []
    
    affinity: {}
    
  3. 启用Ingress控制器

    为了让 Ingress 资源工作,集群必须有一个正在运行的 Ingress 控制器Ingress控制器有很多种,我们将使用Kubernetes官方维护的nginx ingress控制器,在microk8s中启用ingress控制器非常简单:

    microk8s.enable ingress  # 将启用nginx ingress控制器
  4. 部署定制的Helm Chart

    helm upgrade -f values.yaml --install --namespace=default --set nodeEnv=staging,workload.kind=Job,workload.args={start-your-job,additional-args},replicaCount=2 your-app-name .

    其中:

    • -f : 默认value文件。
    • --namespace : 部署到某命名空间(对应命名空间需要在Kubernetes集群中存在)
    • --install : 若命名为your-app-name的helm应用不存在则安装,否则更新。
    • --set : 替换默认value的值。
    • your-app-name : helm应用名称(方便管理)
    • . : Helm Chart 所在根目录

    PS: 后续若有需要可以将定制的Helm Chart进行打包,并推送到指定远程仓库。

小结

Helm大大减少了向Kubernetes集群部署应用程序的复杂性,让我们能够快速的部署应用程序,同时也可通过远程的Chart仓库直接安装所需应用。编写定制的Chart也比较直接,需要对Kubernetes资源对象以及golang template有所了解。通过对Helm的应用,能更好地提高开发者的工作效率,以将更多精力聚焦在业务代码的开发上。

云原生时代,拥抱微服务(二)—— 容器化应用

前文我们已经搭建好k8s集群,接下来就可以对部分项目进行容器化改造了。

“万丈高楼平地起,敲好代码是关键。” —— 皮皮叨叨

创建镜像文件Dockerfile

以Node.js应用为例:

FROM node:12-alpine

# install tzdata so that we can set timezone which default is UTC
RUN apk add tzdata
ENV TZ Asia/Shanghai

# set our node environment, either development or production
# defaults to production, can override this to development on build and run
ARG NODE_ENV=production
ENV NODE_ENV $NODE_ENV

# default to port 3000 for node, and 9229 and 9230 (tests) for debug
ARG PORT=3000
ENV PORT $PORT
EXPOSE $PORT 9229 9230

# install dependencies first, in a different location for easier app bind mounting for local development
# due to default /opt permissions we have to create the dir with root and change perms
RUN mkdir /your-app && chown node:node /your-app
RUN mkdir /var/log/your-app && chown node:node /var/log/your-app
WORKDIR /your-app
# the official node image provides an unprivileged user as a security best practice
# but we have to manually enable it. We put it here so yarn installs dependencies as the same
# user who runs the app.
# https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md#non-root-user
USER node
COPY --chown=node:node . .
RUN yarn install --production=true
ENV PATH /your-app/node_modules/.bin:$PATH

CMD [ "yarn", "start" ]

PS: .dockerignore文件可通过gitignore.io生成。

应用配置信息及密钥管理

普通配置信息

ConfigMaps是一种Kubernetes资源,允许你为容器保存配置信息,这些配置后续可以通过挂载为容器的环境变量或者文件进行访问。

# your-config.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: your-api
data:
  mongodb_host: your.mongodb.host
  mongodb_database: your-database-name

通过在k8s集群中使用kubectl apply命令创建上述命名为your-apiConfigMap资源(如果该资源已经存在,则进行更新动作)。

kubectl apply -f path-to/your-config

密钥等敏感信息

不像ConfigMapsSecrets是一种用于存放敏感信息的Kubernetes资源,一般可用于存放各类凭证、ssh密钥,TLS密钥及证书,或者其他在应用中需要使用的敏感数据。Secrets同样可以挂载为容器的环境变量或者文件。

Secrets被保存为base64编码的字符串,我们需要在Secrets声明文件中将对应敏感信息(如数据库用户名与密码)转换为base64格式。可使用如下命令:

echo -n "db-user-name" | base64
# output: ZGItdXNlci1uYW1l

echo -n "db-pwd" | base64
# output: ZGItcHdk

注意,上述命令输出后的base64编码字符串就是我们需要保持到Kubernetes中的Secrets信息。

# your-secrets.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: your-api
data:
  mongodb_username: ZGItdXNlci1uYW1l
  mongodb_password: ZGItcHdk

使用kubectl apply命令创建对应Secrets资源:

kubectl apply -f path-to/your-secrets.yaml

【温馨提示】base64编码的字符串并不是被加密的,需要将上述Secrets声明文件保存到足够安全的地方,并且防止泄露!!!建议在Kubernetes集群中统一进行管理。

为应用程序创建Deployment工作负载

工作负载(Workloads)资源可以理解为在Kubernetes中的应用程序,主要包括:DeploymentStatefulSetDaemonSetJobCronJob等类型。

Deployment主要用于扩展与更新无状态容器Pod,适用于我们无状态的应用程序。Deployment会自动创建副本集(ReplicaSet)资源,以用于替换失败的Pods,弹性扩展或减少Pods

# your-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-api
  labels:
    app: your-api-label
spec:
  replicas: 3
  selector:
    matchLabels:
      app: your-api-label
  template:
    metadata:
      labels:
        app: your-api-label
    spec:
      containers:
        - name: your-api
          image: your-api-image:1.0.0
          env:
            - name: MONGODB_HOST
              valueFrom:
                configMapKeyRef:
                  name: your-api
                  key: mongodb_host
            - name: MONGODB_DATABASE
              valueFrom:
                configMapKeyRef:
                  name: your-api
                  key: mongodb_database
            - name: MONGODB_USER
              valueFrom:
                secretKeyRef:
                  name: your-api
                  key: mongodb_username
            - name: MONGODB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: your-api
                  key: mongodb_password

使用kubectl apply命令创建对应Deployment资源:

kubectl apply -f path-to/your-depoyment.yaml

使用Service公开Deployment工作负载

我们还需要通过创建Service资源以更好地访问不同Pod中的应用程序,并且能做到负载均衡。这主要是由于Pod是短暂的,一旦由于某种原因被销毁,其对应的IP地址也会被吊销,然后新生的Pod将获得一个不同的IP地址。

# your-service.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: your-api
spec:
  type: ClusterIP
  selector:
    app: your-api-label
  ports:
    - protocol: TCP
      port: 80
      targetPort: http

使用kubectl apply命令创建对应Service资源:

kubectl apply -f path-to/your-service.yaml

总结

我们首先通过创建Dockerfile以用于生成应用程序的容器镜像,然后通过使用ConfigMapsSecrets资源管理应用程序的配置及敏感信息,最后再运用DeploymentService资源部署及公开应用程序。

微服务高楼的基石貌似已经搭好了,胜利的曙光就在眼前。但是机智且追求效率的你一定发现了:一个应用程序这样做还好,可如果有多个应用程序也需要容器化,都分别去声明各种Kubernetes资源岂不是很繁琐?你这个ClusterIP类型的Service似乎还无法从外网访问?