Deployment and Best Practices of Enterprise-level ohpm-repo Private Repository in HarmonyOS Next

In the enterprise-level development scenario of HarmonyOS Next, an efficient, stable, and secure private repository for package management is of great significance. ohpm-repo provides us with a powerful tool to achieve this goal. The following will introduce in detail how to build an enterprise-level ohpm-repo private repository that supports multiple instances, so as to provide highly available and high-performance package management capabilities. Architecture Design of the Enterprise-level Private Repository Comparison between Single Instance and Multiple Instances (Local Mode vs Server Mode) Single Instance (Local Mode) Single instance deployment is like a small workshop, where ohpm-repo is deployed on one machine. The advantage of this mode is that the deployment is simple and the configuration is easy. It is suitable for small teams or the initial stage of project development, with low requirements for resources. However, its limitations are also obvious. Once this machine fails, the entire private repository service will be interrupted. Moreover, as the business volume grows, the performance bottleneck of the single instance will gradually emerge, failing to meet the needs of a large number of users accessing and operating simultaneously. Multiple Instances (Server Mode) Multiple instance deployment is like a large factory, deploying ohpm-repo to multiple machines. These machines have the same configuration content and share the data storage space. Multiple instance deployment can significantly improve the system's concurrent processing capability and availability. When one instance fails, other instances can continue to provide services, ensuring the normal operation of the private repository. At the same time, through reasonable load balancing configuration, user requests can be evenly distributed to each instance, enhancing the overall performance. However, the configuration and management of multiple instance deployment are relatively complex, and multiple aspects such as data synchronization and load balancing need to be considered. Using MySQL to Store Metadata and Improving Data Consistency In an enterprise-level environment, data consistency is of vital importance. Using MySQL to store the metadata of ohpm-repo is a good choice. In the config.yaml file of ohpm-repo, we can make the following configuration: db: type: mysql config: host: "Database host address" port: 3366 username: "Database username" password: "Database user password" database: "repo" By using MySQL to store metadata, multiple ohpm-repo instances can share the same database, ensuring data consistency. When one instance updates the metadata, other instances can obtain the latest data in a timely manner, avoiding problems caused by inconsistent data. Combining store: sftp to Achieve Distributed Storage and Improving File Access Speed To improve the file access speed, we can combine store: sftp to achieve distributed storage. Make the following configuration in the config.yaml file: store: type: sftp config: location: - name: test_one_sftp host: "sftp service host address" port: 22 read_username: "Username with read permission" read_password: "User password with read permission" write_username: "Username with write permission" write_password: "User password with write permission" path: /source22 server: http:// By configuring multiple sftp storage locations, we can store files分散ly on different servers to achieve distributed storage. This can improve the file access speed because users can obtain files from the server closest to them or with the lightest load. At the same time, distributed storage also improves data reliability. Even if one sftp server fails, other servers can still provide services. Highly Available Deployment Scheme for the Private Repository How to Configure config.yaml to Make Multiple Instances Share the Same Database In order to make multiple ohpm-repo instances share the same database, we need to set the db configuration item in the config.yaml file of each instance to the same MySQL database information, such as the MySQL configuration example mentioned earlier. In this way, all instances can connect to the same database, achieving the sharing and consistency of metadata. Enable Nginx for Reverse Proxy by Setting use_reverse_proxy: true In the config.yaml file, set use_reverse_proxy to true, which means enabling the reverse proxy. At the same time, the store.config.server needs to be configured as the domain name address of the reverse proxy server. For example: use_reverse_proxy: true store: config: server: http://nginx-proxy-server In the Nginx configuration file, we can make the following settings: server { listen 80; server_name your_domain.com; l

Mar 17, 2025 - 03:28

Deployment and Best Practices of Enterprise-level ohpm-repo Private Repository in HarmonyOS Next

In the enterprise-level development scenario of HarmonyOS Next, an efficient, stable, and secure private repository for package management is of great significance. ohpm-repo provides us with a powerful tool to achieve this goal. The following will introduce in detail how to build an enterprise-level ohpm-repo private repository that supports multiple instances, so as to provide highly available and high-performance package management capabilities.

Architecture Design of the Enterprise-level Private Repository

Comparison between Single Instance and Multiple Instances (Local Mode vs Server Mode)

Single Instance (Local Mode)

Single instance deployment is like a small workshop, where ohpm-repo is deployed on one machine. The advantage of this mode is that the deployment is simple and the configuration is easy. It is suitable for small teams or the initial stage of project development, with low requirements for resources. However, its limitations are also obvious. Once this machine fails, the entire private repository service will be interrupted. Moreover, as the business volume grows, the performance bottleneck of the single instance will gradually emerge, failing to meet the needs of a large number of users accessing and operating simultaneously.

Multiple Instances (Server Mode)

Multiple instance deployment is like a large factory, deploying ohpm-repo to multiple machines. These machines have the same configuration content and share the data storage space. Multiple instance deployment can significantly improve the system's concurrent processing capability and availability. When one instance fails, other instances can continue to provide services, ensuring the normal operation of the private repository. At the same time, through reasonable load balancing configuration, user requests can be evenly distributed to each instance, enhancing the overall performance. However, the configuration and management of multiple instance deployment are relatively complex, and multiple aspects such as data synchronization and load balancing need to be considered.

Using MySQL to Store Metadata and Improving Data Consistency

In an enterprise-level environment, data consistency is of vital importance. Using MySQL to store the metadata of ohpm-repo is a good choice. In the config.yaml file of ohpm-repo, we can make the following configuration:

db:
  type: mysql
  config:
    host: "Database host address"
    port: 3366 
    username: "Database username"
    password: "Database user password"
    database: "repo"

By using MySQL to store metadata, multiple ohpm-repo instances can share the same database, ensuring data consistency. When one instance updates the metadata, other instances can obtain the latest data in a timely manner, avoiding problems caused by inconsistent data.

Combining store: sftp to Achieve Distributed Storage and Improving File Access Speed

To improve the file access speed, we can combine store: sftp to achieve distributed storage. Make the following configuration in the config.yaml file:

store:
  type: sftp
  config:
    location:
      - name: test_one_sftp
        host: "sftp service host address"
        port: 22
        read_username: "Username with read permission"
        read_password: "User password with read permission"
        write_username: "Username with write permission"
        write_password: "User password with write permission"
        path: /source22
    server: http://

By configuring multiple sftp storage locations, we can store files分散ly on different servers to achieve distributed storage. This can improve the file access speed because users can obtain files from the server closest to them or with the lightest load. At the same time, distributed storage also improves data reliability. Even if one sftp server fails, other servers can still provide services.

Highly Available Deployment Scheme for the Private Repository

How to Configure config.yaml to Make Multiple Instances Share the Same Database

In order to make multiple ohpm-repo instances share the same database, we need to set the db configuration item in the config.yaml file of each instance to the same MySQL database information, such as the MySQL configuration example mentioned earlier. In this way, all instances can connect to the same database, achieving the sharing and consistency of metadata.

Enable Nginx for Reverse Proxy by Setting use_reverse_proxy: true

In the config.yaml file, set use_reverse_proxy to true, which means enabling the reverse proxy. At the same time, the store.config.server needs to be configured as the domain name address of the reverse proxy server. For example:

use_reverse_proxy: true
store:
  config:
    server: http://nginx-proxy-server

In the Nginx configuration file, we can make the following settings:

server {
    listen       80;
    server_name  your_domain.com;

    location / {
        proxy_pass http://ohpm-repo-instances; 
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Through the reverse proxy, we can hide the real address of the ohpm-repo instance and improve the security of the system. At the same time, the reverse proxy can also cache and optimize requests, enhancing the user's access experience.

How to Ensure Load Balancing between Different Instances? (Server Cluster + Data Synchronization Scheme)

In order to ensure load balancing between different instances, we can use a server cluster and a data synchronization scheme. Use a load balancer (such as Nginx or HAProxy) to evenly distribute user requests to each ohpm-repo instance. For example, configure the upstream module in Nginx:

upstream ohpm-repo-instances {
    server instance1_ip:port;
    server instance2_ip:port;
    # More instances can be added according to the actual situation
}

For data synchronization, since we use MySQL to store metadata, MySQL itself provides a replication function, which can achieve master-slave replication or multi-master replication. By configuring the replication function of MySQL, ensure the data consistency of each instance. At the same time, when using sftp to store files, file synchronization can also be carried out between sftp servers through data synchronization tools (such as rsync) to ensure file consistency.

Optimizing the Access Experience and Security

How to Control the Access Permissions of Packages? (Access Management Based on access_token)

ohpm-repo adopts an access management mechanism based on access_token to control the access permissions of packages. When a user logs in to the ohpm-repo private repository management address, the system will generate an access_token. In subsequent operations (such as package downloading, uploading, etc.), the user needs to carry this access_token. The server will verify the validity of the access_token and the user's permissions, and only users who pass the verification can perform corresponding operations. For example, ordinary users may only have the permission to download packages, while administrator users have higher permissions such as uploading and deleting packages.

Enable HTTPS to Protect the Security of Data Transmission

In the config.yaml file, configure listen as the https protocol, and configure https_key and https_cert:

listen: https://:8088
https_key:./ssl/server.key
https_cert:./ssl/server.crt

The following commands can be used to generate the certificate private key file and the certificate file:

openssl genrsa -out server.key 4096
openssl req -new -x509 -days 3650 -key server.key -out server.crt

After enabling HTTPS, all data transmitted between the client and the server will be encrypted, preventing the data from being stolen or tampered with during the transmission process and protecting the security of data transmission.

Log Analysis and Monitoring (run.log, access.log)

ohpm-repo will generate multiple log files, among which run.log and access.log are particularly important. run.log records the key information during the operation of ohpm-repo, such as the startup, stop, and exceptions of the service. By analyzing run.log, we can promptly discover potential problems of the system, such as the failure of a certain service to start or an abnormal database connection. access.log records the user's access information, such as the access time, access IP, and accessed interface. By analyzing access.log, we can understand the user's access behavior and discover abnormal access patterns, such as a certain IP address frequently requesting a certain interface, which may be under an attack. Log analysis tools (such as the ELK Stack) can be used to collect, analyze, and visually display these logs, so as to promptly discover and solve problems.

Through the above architecture design, highly available deployment scheme, and optimization measures for the access experience and security, we can build an enterprise-level ohpm-repo private repository that supports multiple instances, providing highly available and high-performance package management capabilities for HarmonyOS Next development. In the actual deployment process, appropriate adjustments and optimizations need to be made according to the specific needs and technical environment of the enterprise.