Practical Case of HarmonyOS Next ohpm-repo: Building an Enterprise-level Private Repository

In an enterprise-level development environment, building a stable, efficient, and secure HarmonyOS Next ohpm-repo private repository is of great significance. It can not only centrally manage the third-party libraries on which projects depend but also improve development efficiency and ensure code security. Next, we will introduce in detail the guidelines for building an enterprise-level ohpm-repo private repository from aspects such as deployment architecture design, package management optimization, and access control. Design of the Enterprise-level ohpm-repo Deployment Architecture (Private Repository + Reverse Proxy + Multi-instance High Availability Architecture) Private Repository As the core component of the private repository, ohpm-repo is responsible for storing and managing third-party libraries. In an enterprise-level environment, we usually select an appropriate deployment method according to the business scale and concurrent requirements. If the business volume is small, a single-point deployment can be initially adopted as a transition. However, considering the long-term development and dealing with high-concurrency scenarios, multi-instance deployment is a better choice. In multi-instance deployment, each ohpm-repo instance is configured with the same content and shares the data storage space. In this way, when a certain instance fails, other instances can continue to provide services, ensuring the high availability of the repository. At the same time, multi-instance deployment can also use a load balancing mechanism to evenly distribute user requests to each instance, improving the overall performance. Reverse Proxy The reverse proxy plays an important role in the enterprise-level architecture. It is located in front of the ohpm-repo instance, hiding the real server address and enhancing the security of the system. At the same time, the reverse proxy can also filter, cache, and forward requests, optimizing the processing flow of user requests. When configuring the reverse proxy, we need to set use_reverse_proxy to true in the config.yaml file of ohpm-repo and configure store.config.server as the domain name address of the reverse proxy server. For example, when using Nginx as the reverse proxy server, it can be set like this in the Nginx configuration file: server { listen 80; server_name your_domain.com; location / { proxy_pass http://ohpm-repo-instances; # Point to the ohpm-repo instance cluster 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, not only is the security improved, but also its caching function can be utilized to accelerate the access to commonly used packages, enhancing the user experience. Multi-instance High Availability Architecture To implement the multi-instance high availability architecture, we also need to introduce a load balancer. The load balancer can dynamically distribute user requests according to the load situation of each ohpm-repo instance. Common load balancers include Nginx, HAProxy, etc. Taking Nginx as an example, the ohpm-repo instance cluster is defined by configuring the upstream module: upstream ohpm-repo-instances { server instance1_ip:port; server instance2_ip:port; # More instances can be added according to the actual situation } In this way, when a user request reaches the reverse proxy server, Nginx will forward the request to an appropriate ohpm-repo instance according to the load balancing algorithm (such as round-robin, weighted round-robin, etc.), ensuring the high availability and high performance of the system. How to Achieve Efficient Package Management? (How to Combine store: sftp for Distributed Storage) In an enterprise-level environment, efficient package management is the key to improving development efficiency. Combining store: sftp for distributed storage can make full use of the storage resources of remote servers to achieve efficient storage and management of packages. Configure store as sftp In the config.yaml file of ohpm-repo, configure store as the sftp storage method: store: type: sftp config: location: - name: sftp-server1 host: sftp_server_ip port: 22 read_username: read_user read_password: read_password write_username: write_user write_password: write_password path: /sftp/path server: http://your_domain.com # Modify according to the reverse proxy configuration Through the above configuration, ohpm-repo will store third-party libraries and their metadata on the specified sftp server. The location field can be configured with multiple sftp servers to achieve distributed storage, improving the reliability and scalability of sto

Mar 17, 2025 - 03:28

Practical Case of HarmonyOS Next ohpm-repo: Building an Enterprise-level Private Repository

In an enterprise-level development environment, building a stable, efficient, and secure HarmonyOS Next ohpm-repo private repository is of great significance. It can not only centrally manage the third-party libraries on which projects depend but also improve development efficiency and ensure code security. Next, we will introduce in detail the guidelines for building an enterprise-level ohpm-repo private repository from aspects such as deployment architecture design, package management optimization, and access control.

Design of the Enterprise-level ohpm-repo Deployment Architecture (Private Repository + Reverse Proxy + Multi-instance High Availability Architecture)

Private Repository

As the core component of the private repository, ohpm-repo is responsible for storing and managing third-party libraries. In an enterprise-level environment, we usually select an appropriate deployment method according to the business scale and concurrent requirements. If the business volume is small, a single-point deployment can be initially adopted as a transition. However, considering the long-term development and dealing with high-concurrency scenarios, multi-instance deployment is a better choice.

In multi-instance deployment, each ohpm-repo instance is configured with the same content and shares the data storage space. In this way, when a certain instance fails, other instances can continue to provide services, ensuring the high availability of the repository. At the same time, multi-instance deployment can also use a load balancing mechanism to evenly distribute user requests to each instance, improving the overall performance.

Reverse Proxy

The reverse proxy plays an important role in the enterprise-level architecture. It is located in front of the ohpm-repo instance, hiding the real server address and enhancing the security of the system. At the same time, the reverse proxy can also filter, cache, and forward requests, optimizing the processing flow of user requests.

When configuring the reverse proxy, we need to set use_reverse_proxy to true in the config.yaml file of ohpm-repo and configure store.config.server as the domain name address of the reverse proxy server. For example, when using Nginx as the reverse proxy server, it can be set like this in the Nginx configuration file:

server {
    listen       80;
    server_name  your_domain.com;

    location / {
        proxy_pass http://ohpm-repo-instances; # Point to the ohpm-repo instance cluster
        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, not only is the security improved, but also its caching function can be utilized to accelerate the access to commonly used packages, enhancing the user experience.

Multi-instance High Availability Architecture

To implement the multi-instance high availability architecture, we also need to introduce a load balancer. The load balancer can dynamically distribute user requests according to the load situation of each ohpm-repo instance. Common load balancers include Nginx, HAProxy, etc. Taking Nginx as an example, the ohpm-repo instance cluster is defined by configuring the upstream module:

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

In this way, when a user request reaches the reverse proxy server, Nginx will forward the request to an appropriate ohpm-repo instance according to the load balancing algorithm (such as round-robin, weighted round-robin, etc.), ensuring the high availability and high performance of the system.

How to Achieve Efficient Package Management? (How to Combine store: sftp for Distributed Storage)

In an enterprise-level environment, efficient package management is the key to improving development efficiency. Combining store: sftp for distributed storage can make full use of the storage resources of remote servers to achieve efficient storage and management of packages.

Configure store as sftp

In the config.yaml file of ohpm-repo, configure store as the sftp storage method:

store:
  type: sftp
  config:
    location:
      - name: sftp-server1
        host: sftp_server_ip
        port: 22
        read_username: read_user
        read_password: read_password
        write_username: write_user
        write_password: write_password
        path: /sftp/path
    server: http://your_domain.com # Modify according to the reverse proxy configuration

Through the above configuration, ohpm-repo will store third-party libraries and their metadata on the specified sftp server. The location field can be configured with multiple sftp servers to achieve distributed storage, improving the reliability and scalability of storage.

Advantages of Distributed Storage

Adopting sftp distributed storage has many advantages. Firstly, it can distribute the storage pressure across multiple servers, avoiding the performance bottleneck of single-point storage. Secondly, different development teams or projects can use different sftp storage paths according to their needs, achieving resource isolation and independent management. For example, the packages of the core business team can be stored on an sftp server with higher performance, while the packages of the testing team can be stored on a common server, rationally allocating resources.

In addition, in a multi-instance deployment environment, through sftp shared storage, each ohpm-repo instance can access the same package resources, ensuring the consistency and version unity of the packages and avoiding development problems caused by inconsistent package versions.

How to Implement Efficient Access Control? (Fine-grained Permission Management through access_token and groupmember)

access_token Mechanism

ohpm-repo adopts the access_token mechanism to verify user identities and control access permissions. 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.

In practical applications, we can improve security by setting the validity period of the access_token. For example, set the validity period to a relatively short time, such as 2 hours. In this way, even if the access_token is leaked, the attacker only has a limited time for illegal operations. At the same time, ohpm-repo can verify the validity of the access_token according to the user's operation type and permission level. For example, ordinary developers can only download packages, while administrators can perform advanced operations such as package uploading and deletion. The system will make judgments and authorizations according to the user permission information carried in the access_token.

Fine-grained Permission Management with groupmember

User group management through groupmember can achieve more fine-grained permission control. Administrators can create different user groups, such as the "Development Group", "Testing Group", "Management Group", etc., and add users to the corresponding groups. Each group can be granted different permissions. For example:

"Development Group": Can download and upload packages related to project development.
"Testing Group": Can only download packages related to testing and cannot perform upload operations.
"Management Group": Has all permissions, including user management, repository management, etc.

Although there is no direct place to configure groupmember in the config.yaml file, in the database of ohpm-repo, the groupmember table records the association relationship between users and groups. By managing the data in this table, administrators can flexibly control user permissions. For example, when a new employee joins the company, the administrator can add the employee to the corresponding user group, and the employee will automatically inherit the permissions of that group; when an employee's position changes, the administrator can adjust the user group the employee belongs to, achieving dynamic permission management.

Through the above deployment architecture design, package management optimization, and access control measures, we can build a fully functional, efficient, and secure enterprise-level ohpm-repo private repository. In the actual building process, appropriate adjustments and optimizations need to be made according to the specific needs and technical environment of the enterprise to ensure that the private repository can meet the long-term development needs of the enterprise.