AHdark Blog

Preface#

This article will describe the detailed operational steps and specific pros and cons analysis for deploying Cloudreve using different methods, along with personal testing results.

The decision to write this article came after receiving criticism for my comments on the Cloudreve Forum.

https://forum.cloudreve.org/d/1829/6

Although I still believe the tutorial in the forum article is not efficient, I have deeply reflected on myself. It is not entirely justifiable to criticize others' enthusiasm without making any constructive contributions. Therefore, I decided to write my own Cloudreve installation tutorial.

Updates#

2022.04.27#

• Changed the version deployed in the example
• Removed Unix Socket configuration as it is not very useful.

Preliminary Notes#

Method 1: Pure Cloudreve Environment#

• Pros: Relatively simple, requires less time, suitable for private cloud disk deployment
• Pros: Lightweight, friendly to extremely low-config servers
• Cons: Poor scalability, difficult log querying
• Cons: Completely unprotected, may crash easily
• Cons: Low database operability, not suitable for large data volumes
• Cons: A single server can only run one web program (i.e., the current Cloudreve)

Method 2: Script Nginx+MySQL+Redis + Cloudreve#

• Pros: Stable, suitable for production environments with hundreds of thousands of users
• Pros: Strong database load capacity
• Pros: Session loss is unlikely, good user experience
• Pros: Logs can be queried in real-time, high scalability
• Cons: Database memory overflow may cause total failure
• Cons: Relies on single server performance, difficult to achieve load balancing
• Cons: Longer deployment time

Method 3: Baota LNM+Cloudreve#

• Cons: Security is not guaranteed (I personally do not trust Baota at all)
• Pros: Easy maintenance
• Pros: Complete backup mechanism
• Pros: High scalability
• Pros: Suitable for beginners

Method 4: Docker Containerized Operation#

• Cons: Beginners often give up, containers are usually difficult for newcomers to understand
• Pros: Enterprise-level architecture, easy to operate
• Pros: Unlimited concurrency, can run on multiple servers
• Pros: Single node failure does not affect overall SLA, system recovers in seconds
• Pros: High security
• Pros: Using with k8s can automatically allocate load capacity for multiple applications

Server Pre-Operations#

The server used in this article is a VMware virtual machine deployed by AHdark in a local environment, running CentOS 8.5, and the Cloudreve program used is the open-source version from GitHub.

This tutorial is more suitable for domestic cloud servers, as it will include many steps to optimize the network environment for domestic servers.

Change Yum Source#

There are many existing yum mirror sources, and this article uses Alibaba Cloud's yum source as an example. Other yum sources can be changed by simply replacing the corresponding address.

If you are using a cloud server from a major domestic or foreign provider, please skip this step. I believe they will have it pre-configured in the system.

This section is sourced from the article: https://developer.aliyun.com/mirror/centos/

# Backup
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup

# Download new CentOS-Base.repo to /etc/yum.repos.d/

## CentOS 6
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-6.repo

## CentOS 7
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

## CentOS 8
curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-8.repo

# Generate cache
yum makecache

# Replace
sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo

Dependency Update#

Typically, the dependencies of pre-installed server images are quite outdated, so we need to update them.

yum -y update

The first dependency update usually takes a long time, please be patient.

Basic SSH Security#

The pre-installed SSH usually does not have a well-configured security setup, making it easy to be scanned and attacked. Therefore, we need to take some steps to protect our server.

Using password login is easily vulnerable to brute force attacks, so I recommend using key-based login.

“Setting up SSH Key Login on CentOS”

After that, we need to make some basic configurations.

# Backup
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Open SSH configuration file
vi /etc/ssh/sshd_config

Make the following configurations.

# Uncomment
LogLevel INFO

# Uncomment and modify content
MaxAuthTries 3
MaxSessions 5

# Add
Protocol 2

# Uncomment if using key login
PubkeyAuthentication yes

# Modify if only using key login
PasswordAuthentication no

# Uncomment and modify content
ClientAliveInterval 600
ClientAliveCountMax 3

Then restart the sshd service.

Before restarting the sshd service, please ensure you have an active SSH connection to prevent losing access to the server!

systemctl restart sshd

Then reconnect to check if it was successful; if not, restore from backup.

Method 1: Pure Cloudreve Environment#

Pros and Cons#

• Pros: Relatively simple, requires less time, suitable for private cloud disk deployment
• Pros: Lightweight, friendly to extremely low-config servers
• Cons: Poor scalability, difficult log querying
• Cons: Completely unprotected, may crash easily
• Cons: Low database operability, not suitable for large data volumes
• Cons: A single server can only run one web program (i.e., the current Cloudreve)

Typically, personal private clouds can be deployed using the following method.

Operations#

First, we need to obtain the Cloudreve source program files. You can download them from GitHub and upload them to the server or use wget to fetch them.

GitHub

cloudreve/Cloudreve

Download#

yum -y install wget
 && wget https://github.com/cloudreve/Cloudreve/releases/download/3.5.2/cloudreve_3.5.2_linux_amd64.tar.gz -O /cloudreve/cloudreve.tar.gz

Extract#

cd /cloudreve
tar -zxvf cloudreve.tar.gz
rm -f cloudreve.tar.gz

Initialize#

chmod +x cloudreve
chown root:root cloudreve
./cloudreve

Please remember the account password generated by Cloudreve on the first run!

After remembering it, press Ctrl+C to exit the program.

Configuration#

vi conf.ini

You can refer to the Cloudreve official documentation for all information regarding Cloudreve configuration files, or use the simplified configuration provided in this article.

[System]
Mode = master
Listen = :80
Debug = false
SessionSecret = 23333
HashIDSalt = something really hard to guess

[CORS]
AllowOrigins = *
AllowMethods = OPTIONS,GET,POST
AllowHeaders = *
AllowCredentials = false

The SessionSecret and HashIDSalt fields will be automatically generated and do not need to be changed.

If you want to enable SSL, please add the following content at the end of conf.ini.

[SSL]
Listen = :443
CertPath = /path/to/fullchain.pem
KeyPath = /path/to/private.key

Please make sure to modify CertPath and KeyPath to the location of your SSL certificate and private key. You can obtain an SSL certificate from freessl.cn, but I recommend purchasing a more formal and secure SSL certificate.

Firewall Configuration#

You can refer to this article for more information about CentOS Firewalld.

https://www.ahdark.blog/som/552.shtml

In this environment, you only need to enter the following commands.

# Open ports
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --zone=public --add-port=443/tcp --permanent

# Reload
firewall-cmd --reload

Process Daemon#

Since GIN is used, normal access to Cloudreve must ensure the program is running.

I personally recommend using Systemd for process management.

# Edit configuration file
vim /usr/lib/systemd/system/cloudreve.service

Edit the content as follows.

[Unit]
Description=Cloudreve
Documentation=https://docs.cloudreve.org
After=network.target
After=mysqld.service
Wants=network.target

[Service]
WorkingDirectory=/cloudreve
ExecStart=/cloudreve/cloudreve
Restart=on-abnormal
RestartSec=5s
KillMode=mixed

StandardOutput=null
StandardError=syslog

[Install]
WantedBy=multi-user.target

# Update configuration
systemctl daemon-reload

# Start service
systemctl start cloudreve

# Set to start on boot
systemctl enable cloudreve

Then you can start, restart, or stop the Cloudreve service using the following commands.

# Start service
systemctl start cloudreve

# Stop service
systemctl stop cloudreve

# Restart service
systemctl restart cloudreve

# Check status
systemctl status cloudreve

DNS Resolution (Optional)#

Go to your DNS provider and resolve the corresponding domain name to your IP to access the service normally.

Of course, you can also choose to use a pure IP, but I do not recommend it.

Using a CDN is definitely a better choice, but you need to further understand CDN configuration, and this method is not suitable for use with CDN.

Virtual machine deployment successful.

Method 2: Script Nginx+MySQL+Redis + Cloudreve#

This example uses the Oneinstack script, and I also encourage you to use LNMP and other scripts.

I recommend separating MySQL and Redis from the Cloudreve server for higher load capacity and stability.

Pros and Cons#

• Pros: Stable, can be used in production environments with over a hundred thousand users (tested feasible)
• Pros: Strong database load capacity
• Pros: Session loss is unlikely, good user experience
• Pros: Logs can be queried in real-time, high scalability
• Cons: Database memory overflow may cause total failure
• Cons: Relies on single server performance, difficult to achieve load balancing
• Cons: Longer deployment time

Operations#

Basic Web Environment Deployment#

Please refer to the Oneinstack installation method for installation.

The MySQL version needs to be 5.7 or higher, and it is recommended to compile and install (which takes longer), and please ensure to install Redis Server.

Create vhost#

Please visit https://oneinstack.com/install/ for detailed information.

This image is not a Cloudreve configuration image, it is taken from the Oneinstack official website.

Taken from https://oneinstack.com/install/

Please do not enable anti-leech or pseudo-static!

Remember to replace the SSL certificate with one that you have applied for and is compliant!

Download & Extract#

Enter the vhost directory, in this example it is /data/wwwroot/172.16.89.213.

cd /data/wwwroot/172.16.89.213

Download Cloudreve using wget (as above).

# Download
yum -y install wget && wget https://github.com/cloudreve/Cloudreve/releases/download/3.5.2/cloudreve_3.5.2_linux_amd64.tar.gz -O cloudreve.tar.gz

# Extract
tar -zxvf cloudreve.tar.gz && rm -f cloudreve.tar.gz

Configure MySQL#

When installing MySQL with Oneinstack, it will prompt you to enter the MySQL password, and now you need to log in using that password.

For example, my MySQL Root account password is 123456.

mysql -uroot -p123456

Then create a database and user, please replace the password accordingly.

CREATE DATABASE Cloudreve;
CREATE USER cloudreve@127.0.0.1 IDENTIFIED BY 'examplepassword';
GRANT ALL ON Cloudreve.* TO cloudreve@127.0.0.1;
exit;

Initialize#

chmod 777 cloudreve
chown root:root cloudreve
./cloudreve

At this point, the Cloudreve program will initialize and generate the initial account password, but you do not need to remember it.

Then edit conf.ini.

vi conf.ini

[System]
Mode = master
Listen = :5212
Debug = false
SessionSecret = 23333
HashIDSalt = something really hard to guess

[Database]
Type = mysql
Port = 3306
User = cloudreve
Password = examplepassword
Host = 127.0.0.1
Name = Cloudreve
TablePrefix = cr_
Charset = utf8

[CORS]
AllowOrigins = *
AllowMethods = OPTIONS,GET,POST
AllowHeaders = *
AllowCredentials = false

[Redis]
Server = 127.0.0.1:6379
Password =
DB = 0

Since Redis Server is included in the installation process and has no default password, you can use it directly. Just make sure not to expose Redis to the external network.

Run the program again to generate the data tables.

./cloudreve

At this point, please remember the administrator account password, but do not rush to log in.

Configure Process Daemon#

Since GIN is used, normal access to Cloudreve must ensure the program is running.

I personally recommend using Systemd for process management.

# Edit configuration file
vim /usr/lib/systemd/system/cloudreve.service

Edit the content as follows.

[Unit]
Description=Cloudreve
Documentation=https://docs.cloudreve.org
After=network.target
After=mysqld.service
Wants=network.target

[Service]
WorkingDirectory=/data/wwwroot/172.16.89.213
ExecStart=/data/wwwroot/172.16.89.213/cloudreve
Restart=on-abnormal
RestartSec=5s
KillMode=mixed

StandardOutput=null
StandardError=syslog

[Install]
WantedBy=multi-user.target

Then update the configuration.

# Update configuration
systemctl daemon-reload

# Start service
systemctl start cloudreve

# Set to start on boot
systemctl enable cloudreve

Then you can start, restart, or stop the Cloudreve service using the following commands.

# Start service
systemctl start cloudreve

# Stop service
systemctl stop cloudreve

# Restart service
systemctl restart cloudreve

# Check status
systemctl status cloudreve

Configure Nginx Reverse Proxy#

First, edit the corresponding Nginx vhost configuration file.

vi /usr/local/nginx/conf/vhost/127.0.0.1.conf

upstream cloudreve {
  server 127.0.0.1:5212;
}
server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  ssl_certificate /usr/local/nginx/conf/ssl/172.16.89.213.crt;
  ssl_certificate_key /usr/local/nginx/conf/ssl/172.16.89.213.key;
  ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
  ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-8-SHA256:EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
  ssl_prefer_server_ciphers on;
  ssl_session_timeout 10m;
  ssl_session_cache builtin:1000 shared:SSL:10m;
  ssl_buffer_size 1400;
  add_header Strict-Transport-Security max-age=15768000;
  ssl_stapling on;
  ssl_stapling_verify on;
  server_name 172.16.89.213;
  access_log /data/wwwlogs/172.16.89.213_nginx.log combined;

  location / {
    proxy_pass http://cloudreve;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
  }

  location ~ /(\.user\.ini\.ht\.git\.svn\.projectLICENSEREADME\.md) {
    deny all;
  }
  location /.well-known {
    allow all;
  }
}

In theory, it is possible to achieve load balancing for multiple Cloudreve backends by adding more servers in upstream {}, provided that the servers and corresponding ports are available and all Cloudreve instances share Redis and the database.

Then reload Nginx.

systemctl reload nginx

Then confirm that Cloudreve is running normally.

Cloudreve Status

Pro needs to correct the permissions of the .sock file.

chmod 777 /run/cloudreve.sock

Then access using the specified domain name to enter Cloudreve.

Access successful.

Method 3: Baota LNM+Cloudreve#

Pros and Cons#

• Cons: Security is difficult to guarantee (I personally do not trust Baota at all, especially after the database deletion incident)
• Pros: Easy maintenance
• Pros: Complete backup mechanism
• Pros: High scalability
• Pros: Suitable for beginners

Operations#

Environment Installation#

Install Baota, you can refer to https://www.bt.cn/bbs/thread-19376-1-1.html.

Go to the [Software Store] to install the following software.

• Nginx 1.18 or higher
• MySQL 5.7 or higher (at least 5.7, otherwise Cloudreve will not run!)
• Redis
• Supervisor manager

Create New Website#

Please be sure to select utf8mb4.

Do not use PHP.

Go to github.com/cloudreve/Cloudreve/releases to download the amd_64 installation package and upload it to the server directory.

Initialize#

Open the terminal in the Cloudreve directory.

chmod 777 cloudreve
chown root:root cloudreve
./cloudreve

At this point, the Cloudreve program will initialize and generate the initial account password, but you do not need to remember it.

Then edit conf.ini.

[System]
Mode = master
Listen = :5212
Debug = false
SessionSecret = 23333
HashIDSalt = something really hard to guess

[Database]
Type = mysql
Port = 3306
User = 172_16_35_223
Password = 6Lf56Kf5cjEKNZGj
Host = 127.0.0.1
Name = 172_16_35_223
TablePrefix = cr_
Charset = utf8mb4

[CORS]
AllowOrigins = *
AllowMethods = OPTIONS,GET,POST
AllowHeaders = *
AllowCredentials = false

[Redis]
Server = 127.0.0.1:6379
Password =
DB = 0

Since Redis Server is included in the installation process and has no default password, you can use it directly. Just make sure not to expose Redis to the external network.

Please remember to change the database information to the correct information.

Run the program again to generate the data tables.

./cloudreve

At this point, please remember the administrator account password, but do not rush to log in.

Supervisor#

Fill in as shown.

Having logs indicates normal operation.

Nginx Reverse Proxy#

Add reverse proxy configuration.

As shown, it is fine.

Method 4: Containerized Operation#

After the release of Cloudreve 3.5, Aaron updated the Docker deployment tutorial on the official documentation page and released the Cloudreve Image on Docker Hub, making deployment much simpler. Therefore, I improved this method on 2021.04.27.

Supplement on 2022.10.02: To facilitate container deployment, I submitted a Pull Request to Cloudreve for configuring applications through environment variables (cloudreve/Cloudreve#1475). After it is reviewed and merged into the main branch, I will write a detailed application method.

Pros and Cons#

• Cons: Containers are usually difficult for beginners to understand
• Cons: Docker has some performance overhead on servers
• Pros: Enterprise-level architecture, easy to operate
• Pros: Unlimited concurrency, can run on multiple servers
• Pros: Single node failure does not affect overall SLA, system recovers in seconds
• Pros: High security

Docker Operations#

Create Directory Structure#

Please ensure before running:

1. Manually create an empty conf.ini file or a conf.ini that complies with Cloudreve configuration file specifications, and replace <path_to_your_config> with that path.
2. Manually create an empty cloudreve.db file, and replace <path_to_your_db> with that path.
3. Manually create an uploads folder, and replace <path_to_your_uploads> with that path.
4. Manually create an avatar folder, and replace <path_to_your_avatar> with that path.

Or, directly use the following command to create:

mkdir -vp cloudreve/{uploads,avatar} \
    && touch cloudreve/conf.ini \
    && touch cloudreve/cloudreve.db

Run#

docker run -d \
    -p 5212:5212 \
    --mount type=bind,source=<path_to_your_config>,target=/cloudreve/conf.ini \
    --mount type=bind,source=<path_to_your_db>,target=/cloudreve/cloudreve.db \
    -v <path_to_your_uploads>:/cloudreve/uploads \
    -v <path_to_your_avatar>:/cloudreve/avatar \
    cloudreve/cloudreve:latest

Docker Compose Operations#

Create Directory Structure#

mkdir -vp /cloudreve/{uploads,avatar} \
&& touch /cloudreve/conf.ini \
&& touch /cloudreve/cloudreve.db \
&& mkdir -p /aria2/config \
&& mkdir -p /data/aria2 \
&& chmod -R 777 /data/aria2

Create docker-compose#

Please remember to modify the <your_aria_rpc_token> in the yml file.

vi docker-compose.yml

version: "3.8"
services:
  cloudreve:
    container_name: cloudreve
    image: cloudreve/cloudreve:latest
    restart: unless-stopped
    ports:
      - "5212:5212"
    volumes:
      - temp_data:/data
      - /cloudreve/uploads:/cloudreve/uploads
      - /cloudreve/conf.ini:/cloudreve/conf.ini
      - /cloudreve/cloudreve.db:/cloudreve/cloudreve.db
      - /cloudreve/avatar:/cloudreve/avatar
    depends_on:
      - aria2
  aria2:
    container_name: aria2
    image: p3terx/aria2-pro
    restart: unless-stopped
    environment:
      - RPC_SECRET=<your_aria_rpc_token>
      - RPC_PORT=6800
    volumes:
      - /aria2/config:/config
      - temp_data:/data
volumes:
  temp_data:
    driver: local
    driver_opts:
      type: none
      device: /data
      o: bind

Run#

docker-compose up -d