In an enterprise-level development environment, as the business scale expands and the number of projects increases, the requirements for the performance and reliability of ohpm-repo are getting higher and higher. Single-point deployment may not be able to meet the needs of high concurrency and high availability. At this time, multi-instance deployment becomes a more suitable choice. Today, we will delve into the multi-instance deployment solution of ohpm-repo in an enterprise-level environment and how to perform data migration.
Single-point Deployment vs Multi-instance Deployment
Local Single-machine Mode (Single-point Deployment)
Single-point deployment is the simplest deployment method of ohpm-repo, which is only deployed on one machine. This mode is like working in a small workshop where all tools and materials are placed in one place. It is suitable for small teams or projects in the initial development stage. Its advantages are simple deployment and convenient configuration. For scenarios with limited resources and low concurrency requirements, the cost is relatively low. However, single-point deployment has obvious limitations. Once this machine fails, the entire private repository service will be interrupted, affecting the development progress. Moreover, as the business volume increases, the performance bottleneck of single-point deployment will gradually emerge, and it cannot meet the needs of a large number of users accessing and operating simultaneously.
Server Cluster Mode (Multi-instance Deployment)
Multi-instance deployment, on the other hand, deploys ohpm-repo to multiple machines. These machines have the same configuration content and share the data storage space. This is like a large factory with multiple workshops working simultaneously. Each workshop can complete tasks independently but also share raw materials and information. Multi-instance deployment can effectively improve the system's concurrent processing ability and availability. When one instance fails, other instances can continue to provide services to ensure 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, improving overall performance. However, the configuration and management of multi-instance deployment are relatively complex, and multiple aspects such as data synchronization and load balancing need to be considered.
How to Migrate Existing Data to Multi-instance Deployment?
export_pkginfo to Export Package Data
Before performing data migration, we need to first export the package data in single-point deployment. ohpm-repo provides the export_pkginfo command to achieve this function. This command can export the list of packages already on the shelves in ohpm-repo or the OpenHarmony third-party library central repository to the pkgInfo_xxx.json file in the current directory.
On the machine with single-point deployment, open the terminal and execute the following command:
ohpm-repo export_pkginfo
If you want to export the package list from the OpenHarmony third-party library central repository, you also need to specify the --public-registry parameter:
ohpm-repo export_pkginfo --public-registry <registry address of the OpenHarmony third-party library central repository>
The exported pkgInfo_xxx.json file contains the key information of all the packages on the shelves, and this information will be used in the subsequent multi-instance deployment.
batch_publish for Batch Upload
In a multi-instance deployment environment, we need to re-upload the exported package data to the new instances. At this time, the batch_publish command comes in handy. This command can batch upload the packages in the provided zip file to ohpm-repo.
First, we need to package the package data exported by export_pkginfo into a zip file (if necessary, manually modify the pkgInfo_xxx.json file to specify the partial packages to be uploaded). Then, on one of the machines in the multi-instance deployment, execute the following command:
ohpm-repo batch_publish <zip_file>
If an organization of a package does not exist in ohpm-repo during the upload process, you can use the --force parameter to let the system select an administrator user as the organization leader to automatically create the organization:
ohpm-repo batch_publish <zip_file> --force
Through these two steps, we can migrate the package data in single-point deployment to the multi-instance deployment environment.
How to Configure MySQL Shared Storage?
How to Configure db: mysql and store: sftp for Data Sharing
In multi-instance deployment, in order to achieve data sharing, we usually choose to use MySQL to store metadata and combine it with sftp to store files.
-
Configure db as mysql: In the conf directory of the ohpm-repo unzipped directory, open the
config.yamlfile, find thedbconfiguration item, set its type tomysql, and configure the corresponding database connection information:
db:
type: mysql
config:
host: "Database host address"
port: 3366 # Modify according to the actual situation
username: "Database username"
password: "Database user password"
database: "repo"
For security reasons, it is recommended to use a database account with non-highest privileges for connection.
-
Configure store as sftp: In the same
config.yamlfile, find thestoreconfiguration item, set its type tosftp, and configure the relevant information of the sftp service:
store:
type: sftp
config:
location:
- name: test_one_sftp
host: "sftp service host address"
port: 22
read_username: "Username with read permission"
read_password: "Password of the user with read permission"
write_username: "Username with write permission"
write_password: "Password of the user with write permission"
path: /source22
server: http://<Specified address> # Modify according to the listen configuration and the actual network situation
When configuring sftp storage, pay attention to the configuration of the server address. When the host of listen is not 0.0.0.0, the server defaults to the complete format of listen; when the host of listen is 0.0.0.0, it needs to be configured according to the local network interface situation. It is recommended to manually modify it to the specified local ip/domain name. At the same time, if a reverse proxy is used, it is also necessary to configure use_reverse_proxy to true and correctly set the server to the domain name address of the reverse proxy server.
Through the above configuration, we have completed the setting of MySQL shared storage, enabling the multi-instance deployed ohpm-repo to share data and ensuring the consistency and reliability of the system.
In an enterprise-level environment, the multi-instance deployment and data migration of ohpm-repo are important means to improve system performance and availability. Through reasonable configuration and operation, the private repository can better serve large-scale development projects. I hope the above content is helpful to everyone. If you encounter any problems during the actual operation, you are welcome to communicate at any time.
Top comments (0)