Build problem troubleshooting

This article introduces the troubleshooting ideas encountered in the process of building components through Rainbond.

build process

Building the Rainbond source code is divided into the following steps:

1. Pull project source code

2. Start the Job task in the ‘rbd system’ namespace

3. Run the Job task, and the task image will be obtained from the private image repository.

4. Package project code, such as Vue project, and execute npm install, npm run build to package static files.

5. Through [Kaniko]（ https://github.com/GoogleContainerTools/kaniko ）Create a container image.

6. Push the image to a private image warehouse.

7. Successfully run.

common problem

Users’ use of Rainbond starts with deploying service components. We call this process build. The source of construction includes image, source code and application market. The most problematic of these methods is the construction method from mirror or source code.

The rbd-chaos component in Rainbond is specially used to build service components. Troubleshooting of this part often requires the use of commands to query its logs to obtain information.

kubectl logs -f -l name=rbd-chaos -n rbd-system

You can also view the logs through the console Platform Management -> Logs -> Cluster Logs -> Build Logs.

The build cannot be pulled to the mirror, prompting ImagePullBackOff

The containerd private mirror warehouse certificate is not configured

Usually use the kubectl describe command to view detailed error reports. If the error is x509: certificate signed by unknown authority, it is likely that the default image warehouse certificate of Rainbond is not trusted. If your environment is Containerd, you need to modify the containerd configuration file of each node and configure the goodrain.me private warehouse. Then restart containerd.

1. Modify the configuration file /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".registry.configs]
  [plugins."io.containerd.grpc.v1.cri".registry.configs."goodrain.me"]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."goodrain.me".tls]
       insecure_skip_verify = true

1. Modify the configuration file /etc/containerd/certs.d/goodrain.me/hosts.toml

[host."https://goodrain.me"]
  capabilities = ["pull", "resolve","push"]
  skip_verify = true

1. Restart the containerd of each node

The version of the private mirror warehouse is too low

If the x509: certificate signed by unknown authority error occurs in the stand-alone trial version (the default version of the stand-alone trial version is Containerd, and the certificate is also configured by default), then it is likely that the version of the private mirror warehouse is too low, and the registry needs to be upgraded to the latest version .

# Enter the rainbow-allinone container
$ docker exec -it rainbond-allinone bash
# Upgrade rbd-hub version
$ kubectl edit rbdcomponent rbd-hub -n rbd-system
spec:
  image: registry:2 # Get the latest version of the registry image from DockerHub

The builder image in the private warehouse is missing

If there is no build log for a long time after you click to start building, check the rbd-chaos log and find an error Back-off pulling image "goodrain.me/builder", it means that the builder image in the private warehouse is lost and the build task cannot be run. At this point, you only need to manually pull the image from the public network and push it to the private warehouse. In addition to the builder image, the component operation also requires a runner image, which can be processed here. The main operation steps are as follows:

1. Pull the builder and runner images to the local, and replace the image tag
2. Obtain the password of the private warehouse account and log in
3. Push the image to the private warehouse

• Containerd Runtime
• Docker Runtime

1. Pull image and change tag

nerdctl -n k8s.io image pull registry.cn-hangzhou.aliyuncs.com/goodrain/builder:v5.16.0-release
nerdctl -n k8s.io image pull registry.cn-hangzhou.aliyuncs.com/goodrain/runner:v5.16.0-release
nerdctl -n k8s.io image tag registry.cn-hangzhou.aliyuncs.com/goodrain/builder:v5.16.0-release goodrain.me/builder:latest
nerdctl -n k8s.io image tag registry.cn-hangzhou.aliyuncs.com/goodrain/runner:v5.16.0-release goodrain.me/runner:latest

1. Obtain the password of the private warehouse account and log in

# Obtain account and password
kubectl get rainbondcluster -nrbd-system -oyaml |grep imageHub -A3
# Login to private warehouse
nerdctl -n k8s.io login --username=admin goodrain.me

1. Push the image to a private repository

nerdctl -n k8s.io image push goodrain.me/builder:latest --insecure-registry
nerdctl -n k8s.io image push goodrain.me/runner:latest --insecure-registry

1. Pull image and change tag

docker pull registry.cn-hangzhou.aliyuncs.com/goodrain/builder:v5.16.0-release
docker pull registry.cn-hangzhou.aliyuncs.com/goodrain/runner:v5.16.0-release
docker tag registry.cn-hangzhou.aliyuncs.com/goodrain/builder:v5.16.0-release goodrain.me/builder:latest
docker tag registry.cn-hangzhou.aliyuncs.com/goodrain/runner:v5.16.0-release goodrain.me/runner:latest

1. Obtain the password of the private warehouse account and log in

# Obtain account and password
kubectl get rainbondcluster -nrbd-system -oyaml |grep imageHub -A3
# Login to private warehouse
docker login goodrain.me -uadmin

1. Push the image to a private repository

docker push goodrain.me/builder:latest
docker push goodrain.me/runner:latest

Component build source detection failed

Component build source detection failed. Possible causes of this problem include:

• The image address is filled incorrectly. For example, some images do not provide the arm64 version, so Rainbond installed in the arm64 environment cannot normally obtain the corresponding image.
• The mirror warehouse needs to fill in the user name and password to log in.
• If the above information is checked and correct, then query the rbd-chaos component log.

Which images cannot be run directly on Rainbond.

• Basic operating system images, such as CentOS Ubuntu alpine cannot run directly on Rainbond.
• Basic languages ​​& tools, such as golang compilation environment, docker compilation environment, maven compilation environment and other images cannot be run directly on Rainbond.

Node.js Frequently asked questions about front-end project construction

Many users build and deploy NodeJS front-end projects on Rainbond, such as Vue, React, etc. According to experience, the problems encountered here are also the most. The error message of building the NodeJS front-end project may come from the prompt on the page, or it may be prompted in the log on the right side of the build failure record.

source code is recognized as Node.js instead of NodeJSStatic

The Node.js language can be used not only to build front-end projects such as Vue, but also to build server-side projects. Both of these usages are supported in the Rainbond source build world, however building a front-end project as a server-side project won’t work properly. Pay attention to the build source page of the service component. The language column shows NodeJSStatic, which can prove that the NodeJS front-end project is being built. It’s important to note this: Rainbond recognizes a NodeJS front-end class project based on the existence of package.json and nodestatic.json files in the root of the source code. If it is found that the build has become the wrong type, after adding the specified file and submitting the code, click Recheck on the build source page, and build again.

No yarn.lock or package-lock.json file found in code directory, must generate and submit yarn.lock or package-lock.json file

Rainbond decides which build tool to use to build static files by identifying the yarn.lock or package-lock.json file in the source directory. So one (and only one) of the above files must exist. After submitting the corresponding file, rebuild it.

Two different lockfiles found: package-lock.json and yarn.lock

This message indicates that there are two lock files package-lock.json and yarn.json in the root directory of the current source code. Please delete the other lock file according to the package manager you want to use, and rebuild after submitting the code.

Outdated Yarn lockfile

This information indicates that the yarn.lock used for the current build conflicts with the version dependencies specified in package.json. According to the subsequent prompts in the build log, you can update yarn.lock locally and rebuild after submitting the code.

SyntaxError: Invalid or unexpected token

This message indicates that the npm version specified in the engines section in the current package.json conflicts with the node version selected in the build source. Delete all the contents of the engines section in package.json, resubmit and build.

The source code build cannot obtain the private mirror warehouse

For example, when using Dockerfile for source code construction, the FROM in the Dockerfile is the address of the private mirror warehouse, and you need to configure the private mirror warehouse address, account and password in Team View -> Management -> Mirror Warehouse Authorization Information.