Skip to main content

Deploy the system using scripts

Notice:

The currently supported operating systems that have been tested and deployed using scripting include: Ubuntu 20.04/21.04/24.04, Kylin Server V10.

If you need to deploy Mapmost Studio in other operating systems, please consult customer service or use manual deployment.

1.1 Preparation​

1.1.1 Preparing the server​

Prepare the server according to the configuration recommendations and deployment architecture instructions, and provide a user with root permissions (root user, or an ordinary user who can be elevated to root permissions through the sudo command).

It is highly recommended to deploy a Mapmost Studio system using a clean server environment with no other software installed after installing the operating system!!!

To avoid various unexpected abnormal problems during deployment or use.

If there is no clean server environment, it is recommended to deploy the system manually!

1.1.2 Obtain the deployment package and deployment script​

Mapmost Studio deployment package and deployment script can be obtained by contact customer service.

The deployment script and deployment package are both in the form of tgz compressed packages, and the script is named system-deployment_<version>.tgz, such as system-deployment_latest.tgz.

Deployment packages are divided into minimum function package and plug-in package:

  • Minimum feature package

The naming format is mapmost-studio_<version>_<arch>_minimal_<time>.tgz, such as mapmost-studio_v9.2.0_amd64_minimal_20240813.tgz.

The minimum function package only includes the core functions of map service publishing and does not include model publishing functions such as images and 3D models. The minimal feature package can be deployed independently. An example of its structure is as follows:

mapmost-studio_v9.2.0_amd64_minimal_20240813/
├── data    # Stores data and configuration files for services and middleware
│   ├── mysql
│   ├── openresty
│   ├── postgresql
│   ├── redis
│   └── service    # Stores vector-map backend application configuration files
├── docker-packages    # Stores Docker service installation packages and configuration files
├── images    # Stores packaged image files for services and middleware
│   ├── middleware
│   │   ├── minio-RELEASE.2021-06-17T00-10-46Z.tar
│   │   └── ...
│   ├── service
│   │   ├── modeldeployment-manager
│   │   ├── vector-map
│   │   ├── cloud-minio-upload-2024-07-23T10-09-41.tar
│   │   └── studio-core-master-v9.2.0-rc5.tar
│   └── mapmost-studio-vector-map-24.tar
├── nfs-server-packages    # Stores NFS service installation packages
├── docker-compose.yaml.example    # docker compose configuration example
├── docker-compose.yaml.j2    # docker compose configuration template
├── CHANGELOG.md
└── SYSTEM_DEPLOYMENT.md
  • Plugin Pack

The naming format is mapmost-studio_<version>_<arch>_plugin_<time>.tgz, such as mapmost-studio_v9.2.0_amd64_plugin_20240809.tgz.

The plug-in package only contains the tool images required to publish model services and preview image data files. Plug-in packages cannot be deployed independently and must be deployed at the same time as the minimum feature package, or as a supplementary package after the minimum feature package has been deployed. An example of its structure is as follows:

mapmost-studio_v9.2.0_amd64_minimal_20240813/
├── data    # Stores data and configuration files for services and middleware
│   └── openresty
│       └── html
│           └── map.tgz
├── images    # Stores packaged image files for services and middleware
│   └── service
│       └── modeldeployment-manager
│           ├── dem-quantizedmesh-amd64.2024-06-26T14-18-31.tar
│           ├── imagetiler-amd64.2024-06-26T14-20-48.tar
│           └── ...
└── CHANGELOG.md

Notice:

When you only use the core map publishing function of the Mapmost Studio system, you can obtain only the minimum function package; if you want to use all the functions of the Mapmost Studio system, you need to obtain both the minimum function package and the plug-in package.

1.2 Upload deployment package and deployment script​

  1. Upload the deployment package and deployment script to the server, for example, to the /usr/local/src directory:
# Switch to the upload path
cd /usr/local/src
# Use the rz command or any other method to upload the deployment package
rz

Notice:

  1. When deploying on multiple nodes, just upload to any of the servers;
  2. When deploying only the core map release function of the platform, upload the minimum function package and deployment script; when deploying all platform functions, upload the minimum function package, plug-in package and deployment script;
  3. The upload path should avoid containing Chinese characters, spaces and other special characters. It is recommended to use the /usr/local/src directory;
  4. The deployment package and deployment script compressed package should be uploaded to the same directory.
  1. Unzip the deployment script compressed package:
# Switch to the deployment package and script directory
cd /usr/local/src
# Extract the deployment script archive
tar -zxvf system-deployment_latest.tgz

1.3 Modify script configuration information​

Switch to the script directory:

cd system-deployment

This script is based on Ansible and can realize the automated deployment of single/multi-node Maompost Studio system.

1.3.1 Configure server connection information​

Edit the ./hosts host asset inventory file in the root directory of the script:

vim ./hosts

This configuration file is used to define the SSH connection information of the host, that is, the target server information of the deployment system, including the server's IP address, user name, password, etc.

You only need to modify the content of the [Server] configuration block at the bottom of the configuration file. Refer to the configuration examples provided in the configuration file to add the target server connection information for deploying the Mapmost Studio system, such as:

...
[Server]
node-61 ansible_ssh_host=191.168.17.61 ansible_user=root ansible_ssh_pass=Ymg*tz9,Z!4,Sny

in:

  • node-61 is the name of the host node and cannot be repeated;
  • ansible_ssh_host specifies the host IP address used for SSH connections;
  • ansible_user specifies the username used for SSH connections;
  • ansible_ssh_pass Specifies the password used for SSH connections.

You can also use a private key to connect to the server, such as:

...
[Server]
test-21 ansible_ssh_host=191.168.17.21 ansible_user=root ansible_ssh_private_key_file=/etc/ansible/ssh-key/191.168.17.21-rsa

You need to first create the ssh-key directory in the script root directory and upload the private key file to the changed directory. Then modify the private key file name after the above ansible_ssh_private_key_file parameters (No need to adjust the path /etc/ansible/ssh-key/ configuration).

Notice:

  1. When deploying multiple nodes, you need to add the connection information of each server;
  2. The connection user specified by the ansible_user parameter must be the root user, or an ordinary user who can be elevated to root authority through the sudo command;
  3. The private key path specified by the ansible_ssh_private_key_file parameter is the mounting path in the container after the script is subsequently executed, not the actual path on the server. /etc/ansible/ssh-key/ in the parameter corresponds to ./ssh-key/ in the server script root directory. Therefore, when the location of the private key file on the server is ./ssh-key/rsa-key in the script root directory, the parameter path should be configured as /etc/ansible/ssh-key/rsa-key.

1.3.2 Modify system deployment information​

Edit the ./config.yaml deployment information configuration file in the script root directory:

vim ./config.yaml

This configuration file is used to define the configuration details of system deployment, such as defining the deployment nodes of each service, the user name and password of the database, etc.

Intranet deployment, and no special circumstances, you only need to modify the configuration of each service deployment node according to the actual situation. The example is as follows:

...
mapmost_studio: 
  ...
  docker: 
    ...
    ### Docker service deployment nodes; all nodes must be deployed
    node: ["191.168.17.61", "191.168.17.41", "191.168.17.21"]
  ...
  mysql: 
    ...
    ### MySQL service deployment node
    node: ["191.168.17.61"]
  ...      
  backend: 
    ...
    ### Backend service deployment nodes. For multi-compute-node deployment, the first item is the primary node and the remaining items are compute nodes
    node: ["191.168.17.41", "191.168.17.21"]

Other configuration items that need attention include:

  • System deployment directory and Docker service data directory
control_node: 
  docker: 
    ...
    ### Docker service data storage directory on the control node (the server node that runs the deployment script). Use a disk partition with sufficient space
    data_dir: "/data/docker"
   
mapmost_studio: 
  ## System deployment directory. Use a disk partition with sufficient space
  deploy_dir: "/data/project"
  ...
  docker: 
    ### Docker service data storage directory on other nodes. Use a disk partition with sufficient space
    data_dir: "/data/docker"
...

It is recommended to modify it to avoid the situation where the disk is fully used due to the gradual increase in published services in the subsequent use of the system.

  • System access mode configuration
...
mapmost_studio: 
  ...
  ## Whether to access the system through a public IP
  ## Only one of this parameter and public_access_https below can be set to true
  public_access: false
  ## Public access IP
  ## Used only when public_access above is set to true
  public_access_ip: "58.210.111.196"
  ## Whether to access the system through a public HTTPS domain
  ## Only one of this parameter and public_access above can be set to true
  public_access_https: false
  ## Public HTTPS access domain
  ## Used only when public_access_https above is set to true
  public_access_https_host: "studio.lalala.com"

The Mapmost Studio platform currently supports three access methods: intranet access, public network IP access, and public network https domain name access. You need to select the access method and adjust the above configuration according to the actual situation:

- No modification is required for intranet access;
- When accessing the public network IP, modify the `public_access` parameter to `true` and modify `public_access_ip` to the actual public network IP;
- When accessing the public network https domain name, modify `public_access_https` to `true` and modify `public_access_https_host` to the actual public network domain name.

Notice:

For public https domain name access, the deployment script does not currently support automatically adding SSL related configurations in OpenResty.

Therefore, after the script execution is completed, you need to manually upload the domain name certificate file to the OpenResty configuration directory /data/project/mapmost-studio/openresty/conf.d/, and add SSL related configurations in the OpenResty configuration file. The reference example is as follows:

server {
    listen 443 ssl;
    server_name studio.lalala.com;

    ssl_certificate conf.d/studio.lalala.com.pem;
    ssl_certificate_key conf.d/studio.lalala.com.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!3DES:!ADH:!RC4:!DH:!DHE;
    ssl_prefer_server_ciphers on;
    ...
}

Then use the docker restart mapmost-studio-openresty command to restart the OpenResty service to make the configuration take effect.

  • Configuration of each service port and default network segment of the container
...
mapmost_studio: 
  ...
  docker: 
    ...
    ### Default container network segment
    bip: "191.168.200.1/24"
    ...
  mysql: 
    ### MySQL service port
    port: 3306
...

When the server is not a clean server and other business applications are running on it, it is recommended to check whether there is any conflict with the default ports of each service in the configuration file before executing the deployment script. You should also check whether the container's default network segment conflicts with the server network segment.

Notice:

The configuration file has detailed description comments for each parameter item. It is recommended to read the description of each parameter before deployment.

1.4 Execute script​

You need to use the root user, or use an ordinary user who can be elevated to root privileges through the sudo command to execute the script.

  • Using the root user, execute the following command in the root directory of the script project to run the script:
./systemctl-deploy.sh -n 'mapmost-studio'
  • If you use an ordinary user, execute the following command in the root directory of the script project to run the script:
sudo ./systemctl-deploy.sh -n 'mapmost-studio'

Wait for the script to finish running. Examples of the results are as follows:

...
PLAY RECAP *******************************************************************************************************
test-61                    : ok=119  changed=48   unreachable=0    failed=0    skipped=29   rescued=0    ignored=7

In the above host execution result statistics, if failed is 0, it means the script is executed successfully.

Switch to the system directory:

cd /data/project/mapmost-studio

Among them, /data/project is the deployment directory specified by the mapmost_studio.deploy_dir parameter in the configuration file config-studio.yaml.

Check that the Mapmost Studio system container is running properly:

docker compose ps -a --format "table {{.Name}}\t{{.RunningFor}}\t{{.Status}}"

Examples of command results are as follows:

NAME                        CREATED          STATUS
cloud-minio-upload          28 minutes ago   Up 28 minutes
mapmost-studio-minio        34 minutes ago   Up 34 minutes
mapmost-studio-mysql        34 minutes ago   Up 34 minutes
mapmost-studio-openresty    33 minutes ago   Up 33 minutes
mapmost-studio-postgresql   32 minutes ago   Up 32 minutes
mapmost-studio-redis        34 minutes ago   Up 34 minutes
mapmost-studio-vector-map   28 minutes ago   Up 28 minutes
modeldeployment-manager     28 minutes ago   Up 28 minutes
studio-core-master          28 minutes ago   Up 28 minutes

The status of all containers is Up, which means they are running normally.