Zero. Preparation

So far I have docker, Mariadb, Nacos, gitea running on my Raspberry PI, but looking at the resource usage, the memory usage is 1.1g and the CPU load is almost negligible. I can still squeeze the surplus value out of it (I have capitalist potential too).

Get elasticSearch!! I must have been mad.

Given that more and more services will be available on the Raspberry PI in the future, some advance work is needed to avoid data loss as a result of a system failure like last time.

0. Perform periodic backup

The primary method to avoid data loss is backup regularly, there is need to backup the data mariadb data in the database and the version of the warehouse gitea service management, backup cycle can direct violence every day for a simple, reserved, better solution is to detect changes to the data again after the incremental backup, this scheme can reduce the read and write operations. And the backup package can be directly uploaded to the network, or at least need to add another U disk mount to the system for multi-point storage, otherwise, the FAILURE of the LAST U disk will still lead to data loss, about baidu web disk to upload files, you can use bypy tool, support PYTHon3.

pip3 install bypy  # installation bypy
bypy info  To perform web disk authentication, you need to access the link displayed on the command line
Copy the code

The script can be written after the backup target, backup scheme, and backup period are confirmed. I choose Python to write the script, which involves ~~ detecting file changes, ~~ compression and packaging, backing up database, connecting to web disks, and other operations. The whole code of more than 100 lines will not be put here, if you are interested in the step code cloud.

Because the docker service is invoked in the script, you need to execute the scheduled task as user root, and then run the crontab -e command to add the scheduled task to user root. The configuration file format varies by hour, day, month and week. You are advised to use the absolute path.

# m h  dom mon dow   command
0 1 * * 1,4 nohup /home/ubuntu/tools/python39/bin/python3 /mnt/workspace/backends/backuptask/backup.py &
Copy the code

The preceding configuration indicates that backup operations are performed in the background at 1:00 am on Monday and Thursday. For details, see tool.lu/crontab.

1. The USB flash drive is automatically mounted

Since the usb flash drive for the system was only 32G before, and the subsequent docker images, containers and backup functions all occupied a large amount of disk space, another 64G USB flash drive was purchased and mounted to raspberry PI. The main purpose was to reduce the reading and writing of the SYSTEM USB flash drive and store the static files in the new USB flash drive.

After the usb flash drive is inserted into the USB3.0 port of the raspberry PI, the only two USB3.0 ports of the raspberry PI are occupied. Run the ls -l /dev/sd* command to check the usb flash drive device, and then run the df -h command to check the device mounting status.

Two USB devices sda and SDB already exist in the /dev directory. Sda1 has been mounted to the system root directory as the partition of SDA. Therefore, the new USB disk is SDB. You are advised to run the mkfs.ext4 /dev/sdb1 command to format the USB flash drive to the ext4 format commonly used in Linux. After the formatting is complete, run the mount /dev/sdb1 / MNT command as user root to mount the USB flash drive to the/MNT directory. Then run LSBLK -f or df -th to view the file system type of the device.

The new USB flash drive has been manually mounted to the system/MNT directory, but will become invalid after the system restarts. To avoid manually mounting the USB flash drive each time, you need to modify the /etc/fstab file in the following format:

LABEL=writable          /               ext4    defaults        0       1
LABEL=system-boot       /boot/firmware  vfat    defaults        0       1
Copy the code

You can run the blkid or LSBLK -f command to view the LABEL and UUID information about the disk.

A new disk may not have LABEL information. You can directly specify disk devices in UUID mode by adding a line in the /etc/fstab file in the following format:

UUID=80f62414-080b-4214-a63c-c080ae35f5d6    /mnt            ext4    defaults        0       1
Copy the code

If you want to use the LABEL mode, specify a LABEL for the partition using e2label /dev/sdb1 labelname and add a line to the /etc/fstab file in the preceding format:

LABEL=labelname             /mnt            ext4    defaults        0       1
Copy the code

The LABEL names of devices cannot conflict.

2. Migrate the Docker path

The default data path of docker service is in /var/lib/docker directory. With each pull and image construction, the space occupied by the directory will become larger and larger. Currently, the disk space occupied by the operating environment of Docker image and container has reached more than four G, while the total size of USB disk I made in the system was only 32G. Therefore, you need to migrate the docker file to another mounted disk in advance, so that you can use the /dev/sdb1 mounted in the previous step.

After 19.xx, docker uses data-root instead of graph to specify the data store path. The parameter configuration is saved in /etc/dock/daemon. json file.

{
    "registry-mirrors": [
            "https://registry.docker-cn.com"."https://docker.mirrors.ustc.edu.cn"."http://hub-mirror.c.163.com"]."data-root": "/mnt/dockerlib"
}
Copy the code

The above configuration indicates that the data store path is set to the/MNT /dockerlib directory, and then you need to copy the previous docker data to this directory and restart the Docker service:

cp -rp /var/lib/docker /mnt/dockerlib  Copy the docker data file
systemctl daemon-reload  Reload the service configuration
systemctl restart docker  Restart the Docker service for the configuration to take effect
Copy the code

The original /var/lib/docker path can be deleted, and the system disk is slimmed instantly.

Reference links:

zhuanlan.zhihu.com/p/95533274

Blog.csdn.net/a772304419/…

Deploy ElasticSearch

Elasticsearch is a distributed, scalable, real-time search and data analysis engine based on Lucene. It provides a distributed multi – user – capable full – text search engine based on RESTful Web interface. Elasticsearch was developed in the Java language and released as open source under the Apache license. The latest version is 7.16.2, which supports Docker deployment and provides runnable images under arm64 architecture. The deployment mode can be as follows:

Docker pull ElasticSearch :7.16.2 docker run -d --name elasticsearch --restart always -p 9200:9200 -p 9300:9300 \ -e"discovery.type=single-node" -e ES_JAVA_OPTS="-Xms256m -Xmx512m"\ elasticsearch: 7.16.2The runtime uses Xms and Xmx to limit the minimum and maximum memory allocated to the heap
Copy the code

Memory usage increased from 1.1g to 1.9G after container startup.

Take the plunge and deploy a Skywalking bike to a motorcycle

Deploy Skywalking

Apache SkyWalking is an APM (Application Performance Monitoring) tool for distributed systems, specifically designed for microservices, cloud native, and container based architectures (Docker, Kubernetes, Mesos). I tried to compile Skywalking myself by referring to the official source code compilation document, but failed all the time. The main error message is as follows:

[INFO] --- exec-maven-plugin:1.6.0:exec (default) @ receiver-proto ---
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 1: cannot open ▒▒: No such file
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 1:ELF: not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 2: ۝▒▒▒D▒: not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 1: ▒!▒: not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 1: : not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 1: Bi3$: not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 2: cannot open @: No such file
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 2: B1▒t▒▒*▒-▒%▒▒: not found
/root/downloads/skywalking/oap-server/server-receiver-plugin/receiver-proto/target/bin/flatc: 2: Syntax error: word unexpected (expecting ")")
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 2 (Exit value: 2)
    at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
    at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)
    at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:313)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.xterm-256colormaven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.apache.maven.wrapper.BootstrapMainStarter.start (BootstrapMainStarter.java:39)
    at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
    at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:61)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for apm 8.9.1:
[INFO]
[INFO] apm ................................................ SUCCESS [  9.083 s]
.
.
.
[INFO] skywalking-management-receiver-plugin .............. SUCCESS [  2.228 s]
[INFO] skywalking-jvm-receiver-plugin ..................... SUCCESS [  2.454 s]
[INFO] receiver-proto ..................................... FAILURE [  7.713 s]
[INFO] envoy-metrics-receiver-plugin ...................... SKIPPED
.
.
.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  06:14 min
[INFO] Finished at: 2021-12-30T06:27:10Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:exec (default) on project receiver-proto: Command execution failed.: Process exited with an error: 2 (Exit value: 2) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :receiver-proto
Copy the code

Protobuf and grPC-java are still invalid after installing protobuf and grPC-java. The official Docker image has been supported by arm64 since version 8.9.0. This is “wait for the party to win”, so to deploy Skywalking, just pull the official image and launch:

Docker pull apache/skywalking - oap - server: 8.9.1# Backend service mirroringDocker pull apache/skywalking - UI: 8.9.1# Front-end interface mirroringdocker run --name skywalking --restart always -d -e TZ=Asia/Shanghai \ -e SW_STORAGE=elasticsearch -e SW_STORAGE_ES_CLUSTER_NODES=192.168.3.14:9200 \ -p 12800:12800 \ p 11800:11800 \ Apache/Skywalking - OAP-server :8.9.1Run the backend service image as elasticSearchDocker run - name skywalking - webui - restart always \ - e - d SW_OAP_ADDRESS TZ = = http://192.168.3.14:12800 - e Asia/Shanghai Apache/skywalking - 8088-8080 \ -p UI: 8.9.1Run the front-end image
Copy the code

After the container started, the memory footprint reached 3.1g and the CPU load was still low.

The skywalking service back-end listens to port 12800, and the front-end listens to port 8080 mapped to 8088. Therefore, you can visit http://192.168.3.14:8088 to open the Skywalking page.

3. System resource limitation

The memory usage of the container is 3.16GB when the container is first started. The memory usage of the container is 3.3GB when the container is first started. The memory usage of the container is 3.16GB when the container is first started. Your kernel does not support memory limit capabilities or the cgroup is not mounted. Limitation discarded.

Reason is raspberry pie default does not support the current system cgroup memory limits, need to manually open, open way is to edit the/boot/firmware/cmdline. TXT file, Add cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 swapAccount =1 at the end of the file and restart the system. Cgroup_enable =cpuset Cgroup_enable =memory Cgroup_memory =1 is used to enable the memory limit and swapAccount =1 is used to enable the swap space limit.

Net. ifnames=0 dwC_OTg. Lpm_enable =0 console=serial0,115200 console=tty1 root=LABEL=writable rootfSType =ext4 elevator=deadline rootwait fixrtc cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 swapaccount=1Copy the code

After the system restarts, wait for a moment to verify the service status. After confirming that all services are normal, use the Docker stats command to check the resources occupied by the container.

They have 3.7GB of ram, they have used 2.8GB, the capitalists are so kind that they can add another 200M, let’s buy raspberry PI 3B… To avoid further memory growth, limit the container resources as follows.

Stop and delete nacos, ElasticSearch, Skywalking and other containers, and run the Docker run command again.

docker run -d --name work_nacos --restart=always -p 2288:8848 \
    -e "DB_HOST = 192.168.3.14" -e "DB_PORT=3306" -e "DB_NAME=nacosdata" \
    -e "DB_USER=nacos" -e "DB_PASSWORD=***********"\ --memory=750M nacOS :2.0.3 docker run -d --name work_es --restart always -p 9200:9200 -p 9300:9300 \ -e"discovery.type=single-node" -e ES_JAVA_OPTS="-Xms256m -Xmx512m"\ --memory=700M elasticSearch :7.16.2 docker run --name work_skw --restart always -d -e TZ=Asia/Shanghai \ -e SW_STORAGE= elasticSearch -e SW_STORAGE_ES_CLUSTER_NODES=192.168.3.14:9200 \ -e JAVA_OPTS="-Xms256m -Xmx512m"-p 12800:12800 -p 11800:11800 \ --memory=680M Apache/Skywalking -oap-server:8.9.1# Skywalking's memory footprint plummeted after the JAVA_OPTS parameter was addedDocker run - name work_skwui - restart always \ - e - d SW_OAP_ADDRESS TZ = = http://192.168.3.14:12800 - e Asia/Shanghai \ - the memory = 320 m - p 8088:8080 apache/skywalking - UI: 8.9.1Copy the code

The JAVA_OPTS variable is added when the skywalking container is started by the above command, which limits the memory usage from the Java project and greatly reduces the memory usage. Use the Docker STATS command to check the container running status.

Reference links:

Container resource limits Support_memory_limmit