You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Open-IM-Server/config
hanson-wen b6ded44510
add aws upload, but not complete, leave some todos (#1858)
4 months ago
..
templates add aws upload, but not complete, leave some todos (#1858) 4 months ago
Readme.md feat: Add OpenIM server, environment support for Docker Compose, and Kubernetes deployment. (#1559) 7 months ago

Readme.md

OpenIM Configuration Guide

1. Directory Structure and File Descriptions

This document details the structure of the config directory, aiding users in understanding and managing configuration files.

1.1. Directory Structure

$ tree config
├── alertmanager.yml
├── config.yaml
├── email.tmpl
├── instance-down-rules.yml
├── notification.yaml
├── prometheus.yml
├── Readme.md
└── templates
    ├── alertmanager.yml.template
    ├── config.yaml.template
    ├── email.tmpl.template
    ├── env.template
    ├── instance-down-rules.yml.template
    ├── notification.yaml.template
    ├── open-im-ng-example.conf
    ├── prometheus-dashboard.yaml
    └── prometheus.yml.template

1.2. Directory Structure Explanation

  • Root Directory (config/): Contains actual configuration files and the templates subdirectory.
  • templates/ Subdirectory: Stores configuration templates for generating or updating configuration files in the root directory.

2. File Descriptions

2.1. Files in the Root Directory

  • alertmanager.yml: Configuration file for AlertManager, managing and setting up the alert system.
  • config.yaml: The main application configuration file, covering service settings.
  • email.tmpl: Template file for email notifications, defining email format and content.
  • instance-down-rules.yml: Instance downtime rules configuration file for the monitoring system.
  • notification.yaml: Configuration file for notification settings, defining different types of notifications.
  • prometheus.yml: Configuration file for the Prometheus monitoring system, setting monitoring metrics and rules.

2.2. Files in the templates/ Directory

  • alertmanager.yml.template: Template for AlertManager configuration.
  • config.yaml.template: Main configuration template for the application.
  • email.tmpl.template: Template for email notifications.
  • env.template: Template for environmental variable configurations, setting environment-related configurations.
  • instance-down-rules.yml.template: Template for instance downtime rules.
  • notification.yaml.template: Template for notification settings.
  • open-im-ng-example.conf: Example configuration file for the application.
  • prometheus-dashboard.yaml: Prometheus dashboard configuration file, specific to the OpenIM application.
  • prometheus.yml.template: Template for Prometheus configuration.

3. Configuration File Generation

Configuration files can be automatically generated using the make init command or the ./scripts/init-config.sh script. These scripts conveniently extract templates from the templates directory and generate or update actual configuration files in the root directory.

3.1. How to Use init-config.sh Script

$ ./scripts/init-config.sh --help
Usage: init-config.sh [options]
Options:
  -h, --help             Show this help message
  --force                Overwrite existing files without prompt
  --skip                 Skip generation if file exists
  --examples             Generate example files
  --clean-config         Clean all configuration files
  --clean-examples       Clean all example files

3.2. Examples of Operations

  • Generate all template configuration files:

    $ ./scripts/init-config.sh --examples
    
  • Force overwrite existing configuration files:

    $ ./scripts/init-config.sh --force
    

3.3. Points to Note

  • Template files should not be directly modified: Files in the template directory are templates included in source code management. Direct modification may lead to version conflicts or management issues.
  • Operations for Windows Users: Windows users can use the cp command to copy files from the template directory to the config/ directory and then modify the configuration items as needed.

4. Example Directory

Welcome to our project's examples directory! This directory contains a range of example files, showcasing various configurations and settings of our software. These examples are intended to provide you with templates that can serve as a starting point for your own configurations.

4.1. Overview

In this directory, you'll find examples suitable for a variety of use cases. Each file is a template with default values and configurations, demonstrating best practices and typical scenarios. Whether you're just getting started or looking to implement complex settings, these examples should help you get on the right track.

4.2. Structure

Here's a quick overview of the contents in this directory:

  • env-example.yaml: Demonstrates how to set up environmental variables.
  • openim-example.yaml: Example configuration file for the OpenIM application.
  • prometheus-example.yml: Example configuration for monitoring with Prometheus.
  • alertmanager-example.yml: Template for setting up Alertmanager configuration.

4.3. How to Use These Examples

To use these examples, simply copy the relevant files to your working directory and rename them as needed (for example, removing the -example suffix). Then, modify the files according to your needs.

4.4. Tips for Using Example Files:

  1. Read Comments: Each file contains comments explaining the various sections and settings. Make sure to read these comments for a better understanding of how to customize the file.
  2. Check Required Changes: Some examples might require mandatory changes before they can be used effectively (such as setting specific environmental variables).
  3. Version Compatibility: Ensure that the example files are compatible with the version of the software you are using.

5. Configuration Item Descriptions

6. Version Management and Upgrading

When managing and upgrading the config directory's versions, it is crucial to ensure that the configuration files in both the local config/ and config/templates/ directories are kept in sync. This process can ensure that your configuration files are consistent with the latest standard templates, while also maintaining custom settings.

6.1. Pulling the Latest Code

First, ensure that your local repository is in sync with the remote repository. This can be achieved by pulling the latest code:

$ git pull

6.2. Generating the Latest Example Configuration Files

Next, generate the latest example configuration files. This can be done by running the init-config.sh script, using the --examples option to generate example files, and the --skip option to avoid overwriting existing configuration files:

$ ./scripts/init-config.sh --examples --skip

6.3. Comparing Configuration File Differences

Once the latest example configuration files are generated, you need to compare the configuration files in the config/ and config/templates/ directories to find any potential differences. This step ensures that you can identify and integrate any important updates or changes. Tools like diff can be helpful in completing this step:

$ diff -ur config/ config/templates/

6.4. Updating Configuration Files

Based on the comparison results, manually update the configuration files in the config/ directory to reflect the latest configurations in config/templates/. During this process, ensure to retain any custom configuration settings.

6.5. Updating Binary Files and Restarting Services

After updating the configuration files, the next step is to update any related binary files. This typically involves downloading and installing the latest version of the application or service. Depending on the specific application or service, this might involve running specific update scripts or directly downloading the latest version from official sources.

Once the binary files are updated, the services need to be restarted to apply the new configurations. Make sure to conduct necessary checks before restarting to ensure the correctness of the configurations.

6.6. Best Practices for Version Management

  • Record Changes: When committing changes to a version control system, ensure to log detailed change logs.
  • Stay Synced: Regularly sync with the remote repository to ensure that your local configurations are in line with the latest developments.
  • Backup: Backup your current configurations before making any significant changes, so that you can revert to a previous state if necessary.

By following these steps and best practices, you can ensure effective management and smooth upgrading of your config directory.

7. How to Contribute

If you have an understanding of the logic behind OpenIM's configuration generation, then you will clearly know where to make modifications to contribute code.

7.1. OpenIM Configuration Item Descriptions

First, it is recommended to read the OpenIM Configuration Items Document. This will help you understand the roles of various configuration items and how they affect the operation of OpenIM.

7.2. Modifying Template Files

To contribute to OpenIM, focus on the ./deployments/templates directory. This contains various configuration template files, which are the basis for generating the final configuration files.

When making modifications, ensure that your changes align with OpenIM's configuration requirements and logic. This may involve adding new template files or modifying existing files to reflect new configuration options or structural changes.

7.3. Updating Configuration Center Scripts

In addition to modifying template files, pay attention to the ./scripts/install/environment.sh script. In this script, you may need to add or modify environment variables.

This script is responsible for defining environment variables that influence configuration generation. Therefore, any new configuration items or modifications to existing items need to be reflected here.

7.4. Configuration File Generation Process

The essence of the make init command is to use the environment variables defined in /scripts/install/environment.sh to render the template files in the ./deployments/templates directory, thereby generating the final configuration files.

When contributing code, ensure that your changes work smoothly in this process and do not cause errors during configuration file generation.

7.5. Contribution Guidelines

  • Code Review: Ensure your changes have passed code review. This typically means that the code should be clear, easy to understand, and adhere to the project's coding style and best practices.
  • Testing: Before submitting changes, conduct thorough tests to ensure new or modified configurations work as expected and do not negatively impact existing functionalities.
  • Documentation: If you have added a new configuration option or made significant changes to an existing one, update the relevant documentation to assist other users and developers in understanding and utilizing these changes.

7.6. Submission and Review

After completing your changes, submit your code to the OpenIM repository in the form of a Pull Request (PR). The PR will be reviewed by the project maintainers and you may be asked to make further modifications or provide additional information.