Operations in the developer mode carry high risks. Incorrect operations may directly lead to irreversible problems in the project.
Proceed with the assistance of a technician! For details about how to contact technical support, see Technical Support Channel Introduction.
The developer mode provides a graphical user interface for high-risk operations, supporting functions such as project and container uninstallation, environment variable modification, port adjustment, and more.
It reduces reliance on error-prone manual processes, ensuring secure, efficient, and reliable operations.
1. Log in to FineOps as the admin, click a project, choose Maintenance > Component Management, and scroll to the bottom of the Component Management tab page.
2. Click the Enter Developer Mode button. A prompt appears: "Are you sure to enter the developer mode? Operations in the developer mode carry high risks. Incorrect operations may directly lead to irreversible problems in the project. Proceed with the assistance of a technician!"
3. Click Confirm to enter the developer mode.
Application Scenario
Typically, the access address of a FanRuan project is http://IP address:Port number/webroot/decision, where webroot is the default access path.
Scenario One: Enhancing Project Security
The default access path is easily guessed and vulnerable to attacks. You (the admin) can change it to a more complex and less predictable path to reduce the risk of being attacked.
For example, you can change the access address from http://IP address:Port number/webroot/decision to http://IP address:Port number/Project name/decision.
Scenario Two: Configuring a Short Domain for Access
To simplify long addresses for easier memorization and sharing, you (the admin) can empty the access path and, combined with SSL configuration, allow direct access via a domain name. For details, see Accessing Projects Through IP Addresses/Domain Names.
For example, you can change the access address from http://IP address:Port number/webroot/decision to https://Domain name.com.
Important Pre-operation Note
1. Target object: This function is available in FineOps-deployed FanRuan projects only. It is not supported for projects that are not deployed via FineOps.
2. System impact: Changing the access path will trigger an automatic restart of the project container. You are advised to perform this operation during off-peak business hours or outside working hours.
3. Access path change: After you modify the path, the project access address will be updated. Be sure to notify all relevant business users to ensure business continuity.
Procedure
1. Enter the developer mode.
Log in to FineOps as the admin, click an O&M project, and choose Maintenance > Component Management.
Scroll to the bottom of the Component Management tab page, and click Enter Developer Mode and Confirm to enter the developer mode.
2. Change the access path.
Click Modify Access Path.
Enter a new path using only letters and numbers. You can also leave it blank.
3. Confirm the modification to restart the container.
Click Confirm. A prompt will appear: "Are you sure to confirm the changes and restart the project?"
Click Confirm. FineOps will restart the project container automatically.
Wait patiently for the restart to complete. Then you can access the project using the new access path.
Scenario One: Project Migration
The project has been migrated to a new server or environment, and the project on the old server is no longer needed.
You (the admin) can uninstall the project from the old server to free up server resources and eliminate potential security risks.
Scenario Two: Test Project Cleanup
A test project was previously installed for pre-launch testing and is no longer required after testing is complete.
You (the admin) can uninstall the test project to clean up the system environment and avoid resource wastage.
1. Target object:
This function is available in FineOps-deployed FanRuan projects only. It is not supported for projects that are not deployed via FineOps.
2. Uninstallation instruction:
This operation will permanently and irreversibly delete the project and all associated resources (such as data, configuration, and the stored content) from the server.
Evaluate the impact carefully before uninstallation. FanRuan cannot perform any restoration operations.
3. Recommended action:
You are highly advised to create a snapshot backup of all involved servers before uninstallation. Consult the server O&M team for instructions on creating snapshot backups.
Restoring projects from snapshots recovers relevant data only, and the project availability is not guaranteed.
2. Uninstall the project.
Click Uninstall Project.
A prompt will appear: "This operation will permanently delete the project and all associated resources (such as data, configuration, and storage) on the server. All content cannot be restored after deletion! If you confirm hard deletion, enter the full name of the project here for secondary verification."
Enter the project name and click Confirm. FineOps will automatically uninstall all containers and related resources for the project sequentially.
3. Check the uninstallation progress.
You can view the uninstallation progress in the uninstallation box and wait for successful completion.
You can also exit the developer mode and check the uninstallation progress and results later on the Project Management page.
Host Setting allows you (the admin) to define custom resolution rules between hostnames and IP addresses.
This enables the mapping of specific hostnames (for example, example.com) to designated IP addresses (for example, 192.168.1.100).
After configuration, the system automatically passes these resolution rules to the docker run command (via the add-host parameter) that starts Docker containers. This ensures that the defined hostnames are correctly resolved within the Docker containers.
Scenario One: Network Isolation in Multi-NIC Environments
When a server is equipped with multiple network interface cards (NICs), you can configure Host Setting to resolve the service hostname to the IP address of a specific NIC.
After configuration, the service becomes accessible only through the designated network, thereby achieving network isolation and enhancing security control.
Scenario Two: Hostname Binding for Kerberos Authentication
In Kerberos authentication scenarios, binding hostnames to IP addresses is critical. Host Setting enables FineOps to resolve hostnames to correct IP addresses, thus ensuring clients can accurately locate the Kerberos service. This not only guarantees the uniqueness of host identities but also improves the reliability of the authentication process.
With Host Setting, you (the admin) can flexibly manage mapping relationships between hostnames and IP addresses, meeting diverse network and authentication requirements.
2. System impact:
You only need to configure Host Setting for components. After configuration, the system will automatically restart all containers of that component. To ensure business continuity, you are advised to perform this operation during off-peak business hours or outside of working hours.
3. Host naming rule
The hostname supports English letters (a-z, A-Z), numbers (0-9), dots (.), and hyphens (-) only, and cannot be empty.
4. Special case
For FineBI 6.1 projects, you must start Engine - Metadata Node and Engine - Calculation Node components in the specified order. If you need to configure Host Setting for the Engine - Metadata Node component, perform the following steps after completion.
a. Once the automatic restart completes, you must manually stop all Engine - Metadata Node and Engine - Calculation Node components in Component Management.
b. Then you need to start the Engine - Metadata Node component and ensure it runs in a healthy status (in the running status continuously for at least three minutes).
c. Finally, start all Engine - Calculation Node components.
2. Configure Host Setting.
Locate the component to be configured and click Host Setting.
Click Add Host and enter the hostname and the IP address. You can add multiple hosts.
Click Confirm. A prompt will appear: "Are you sure to confirm the changes and restart the container?"
Click Confirm. FineOps will restart all containers of this component automatically.
The configuration will take effect after the container restarts successfully.
The environment variables of a component refer to the low-risk parameters and their values in the docker run command that you use to deploy this project container via FineOps.
After modification, the system will automatically pass these parameters to the docker run command that starts the Docker container.
2. Container restart: Modifying the environment variable will trigger an automatic restart of the project container. To avoid impacting business operations, you are advised to perform this operation during off-peak business hours or outside working hours.
3. Rollback mechanism: If the container fails to restart automatically after an environment variable change, the system will revert the environment variable settings to the original settings and attempt to restart the container again. Therefore, you are advised to check and confirm that the change is successful after the operation is complete.
2. Customize the environment variable.
Locate the component to be configured and click Customize Environment Variable.
You can add parameters, modify parameter values, and delete parameters.
The following are high-risk parameters that cannot be modified using this function:
APP_PATH, APP_URLS, APP_WEBSOCKET_URLS, BI_CLUSTER_CONTAINER, BI_CONF_RPC_PORT_EXPOSE, BI_GRPC_PORT_EXPOSE, BI_SERVER_PORT_EXPOSE, CATALINA_OPTS, CLI_JAVA_OPTS, CONTEXT_PATH, CORE_EXTERNAL_PORT, DB_CACHE_EXTERNAL_PORT, ELASTIC_PASSWORD_FILE, ENV_MASTER_HOST, ENV_MASTER_PORT, ES_JAVA_OPTS, EXTERNAL_HTTP_PORT, FBP_BI_MASTER_HOST, FBP_BI_MASTER_PORT, FBP_BI_SERVER_MODE, FDL_WORKER_EXTERNAL_IP, FILE_SYNC_EXTERNAL_PORT, GENERAL_CACHE_EXTERNAL_PORT, GROUP_ID, GRPC_URLS, HOST_IP, JAVA_OPTS, JAVA_OPT_EXT, JVM_XMS, JVM_XMX, KAFKA_CFG_ADVERTISED_LISTENERS, KAFKA_CFG_LISTENERS, KAFKA_HEAP_OPTS, KAFKA_INTER_BROKER_PASSWORD, KAFKA_INTER_BROKER_USER, MASTER_EXTRA_VM_OPTIONS, MEMBER_EXTERNAL_PORT, MINIO_ACCESSKEY, MINIO_BROWSER_REDIRECT_URL, MINIO_ENDPOINT, MINIO_ROOT_PASSWORD, MINIO_ROOT_USER, MINIO_SECRETKEY, MINIO_URL, MONITOR_EXTRA_VM_OPTIONS, MYSQL_ROOT_PASSWORD, MYSQL_SERVICE_HOST, MYSQL_SERVICE_PASSWORD, MYSQL_SERVICE_PORT, MYSQL_SERVICE_USER, NACOS_IP, NACOS_NAMING_NAMESPACE, NACOS_PASSWORD, NACOS_PORT, NACOS_USER, NAMESPACE, NAMESRV_ADDR, NGINX_SUBNET, NGINX_URL, OPS_URL, POLARS_HOST, POLARS_NAME, POLARS_PORT, PROXY_APP_WEBSOCKET, SKYWALKING_OAP_URL, SPIDER_GRPC_PORT_EXPOSE, SPIDER_SERVER_PORT_EXPOSE, USER_ID, WORKER_EXTRA_VM_OPTIONS, bootstrap.memory_lock, gpload.external_addr, gploadPort, independence, jgroups.external_addr, nacos.namespace, nacos.password, nacos.serverAddr, nacos.username, and ops_sign_key
During project deployment via FineOps, a portion of the project directories will be mounted externally automatically. For details, see Preparing the FineBI Mounting Directory.
Uploading resources (if needed) to the help folder in the mounting directory is preferred.
If you need to mount directories that are not part of the default configuration externally, you can use this method to mount folders in /webroot.
2. Some paths do not support mounting.
You can mount folders in /usr/local/tomcat/webapps/webroot of the project's application components (including FineBI - Application Node, FineReport, and FineDataLink).
The following folders cannot be mounted as they have already been mounted or are restricted from being mounted for security reasons. When you input these paths, a prompt will appear: "This path does not support mounting."
backup
bi-data
help
logs
WEB-INF/assets
WEB-INF/classes
WEB-INF/config
WEB-INF/customlib
WEB-INF/dashboards
WEB-INF/dpworks
WEB-INF/local
WEB-INF/plugins
WEB-INF/reportlets
WEB-INF/reportlets_versions
WEB-INF/resources
WEB-INF/schedule
WEB-INF/treasures
WEB-INF
WEB-INF/lib
WEB-INF/skywalking-java-agent
WEB-INF/default-plugins
2. Add a mounting directory.
Locate the application component and click Add Mounting Directory.
Enter the folder path in /webroot that needs to be mounted, such as temp/attach.
The configuration will take effect after the container restarts successfully. In this example, FineOps will automatically mount the WEB-INF/temp/attach path of the project to /Project mounting directory/fanruanxxx/bi-web.
The mounting directory of the project/FineOps has specific disk space requirements. As the project continues to be used and the content grows over time, available disk space may become insufficient.
In such cases, you can change the root mounting directory of the project/FineOps to another directory with large available disk space by referring to this section.
1. Target project:
The system will automatically restart the container after configuration is complete. To ensure business continuity, you are advised to perform this operation during off-peak business hours or outside of working hours.
2. Target component:
For cluster projects with multiple main application/component servers, modifying the root mounting directory of a container applies the change to all components of that project on the server hosting the container, not just to that container, nor to all components in the entire project.
This section takes changing the project mounting path from /home/bi61/fanruanxxxx/ to /dev/fanruan/fanruanxxxx/ as an example.
1. Prepare a new mounting path.
Ensure that the new mounting path (which is /dev/fanruan in this example) actually exists.
Ensure that the server user used to deploy the project is the owner of the new mounting path and has read and write permission on it.
For details about directory preparation and permission configuration, see Preparing the FineBI Mounting Directory.
2. Copy and paste files in the mounting directory to the target location.
Copy the fanruanxxxx folder in /home/bi61 completely and paste it to /dev/fanruan.
Do not alter any content of this folder.
Be sure to complete this operation manually in advance. Otherwise, it may cause project startup failure after you switch the root mounting directory!
3. Enter the developer mode.
4. Modify the root mounting directory.
Locate the container to be adjusted and click the icon.
The original mounting directory of the project is /home/bi61/fanruanxxxx/, and the adjustable part is /home/bi61. Enter the new mounting path, which is /dev/fanruan.
5. Confirm the modification to restart the container.
Click Confirm. A prompt will appear: "Are you sure to confirm the changes and restart the container? After the change, all mounting directories of the current project on the node will change from the original directory "Original directory" to the new directory "New directory."
If you need to adjust the ports open to the public or the communication ports between components for a successfully deployed project, you can refer to this section.
If the project/FineOps uses a self-provided load balancer, manually check and adjust the forwarding policies.
1. Ensure port availability.
Ensure the prepared port is not in use. If it is already in use, use a free port.
For instructions on port occupancy inspection and firewall configuration, see Port Occupancy Inspection and Firewall Configuration.
2. Enter the developer mode.
3. Change the port.
Modify the host port as needed.
4. Confirm the modification to restart the container.
Click Confirm. FineOps will restart the project container automatically. The configuration will take effect after the container restarts successfully.
FineOps will automatically handle the following adjustments:
The forwarding policies of the project's internal gateway will be updated accordingly.
Cluster nodes will be automatically adapted to communication port changes
FineOps will automatically maintain the connection with the project.
FineOps will automatically restart containers to apply the new port configuration.
When the server of some nodes in the project is changed, requiring node cleanup, you (as the admin) can uninstall specified containers to release server resources.
This function is available for the individual uninstallation of all containers in the project except for OPS Agent.
This operation will permanently and irreversibly delete the container and all associated resources (such as data, configuration, and the stored content) from the server.
Restoring projects from snapshots recovers relevant data only, but the availability of the project and the corresponding container is not guaranteed.
2. Uninstall the container.
Locate the corresponding container and click the icon.
A prompt will appear: "After uninstallation, this container and the mounting directory will be cleaned up and the content cannot be restored! If you confirm uninstallation, enter the container name."
Enter the container name and click Confirm. FineOps will automatically uninstall the container and related resources sequentially.
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
10s後關閉
Submitted successfully
Network busy