openimsdk / helm-charts Goto Github PK

View Code? Open in Web Editor NEW

13.0 13.0 9.0 2.15 MB

helm charts repository for openim

Home Page: https://openimsdk.github.io/helm-charts/

License: Apache License 2.0

Shell 0.23% Mustache 10.13% Smarty 89.22% Makefile 0.42%

charts helm helm-chart helm-charts k8s kubernetes kubernetes-deployment openim openimsdk

helm-charts's People

Contributors

Stargazers

Watchers

Forkers

anymous526 xuexihuang cubxxw laipi888 tangguo918 open-yuhaoz caesar168 fi-ecavc imstory

helm-charts's Issues

Can the project team provide a reverse proxy or load balancer based on Traefik?

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

Can the project team provide a reverse proxy or load balancer based on Traefik? This software has more performance and flexibility than nginx.

Solution Description

Traefik is an open-source Edge Router that makes publishing your services a fun and easy experience.

Benefits

traefik listens to your service registry/orchestrator API and instantly generates the routes so your microservices are connected to the outside world -- without further intervention from your part.

Potential Drawbacks

No response

Additional Information

No response

it is recommended that the project team can integrate the components appropriately,

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

When replicas are greater than 1, the following service pattern seems to be more appropriate, and it is recommended that the project team can integrate the components appropriately, and we are willing to cooperate with the testing:
openimserver-openim-0 11/11 running
openimserver-openim-1 11/11 running

Solution Description

and it is recommended that the project team can integrate the components appropriately。
openimserver-openim-0 11/11 running
openimserver-openim-1 11/11 running
openimserver-openim-2 11/11 running
openimserver-openim-3 11/11 running
openimserver-openim-4 11/11 running

Benefits

running component is clearer, and the O&M monitoring does not feel chaotic when there are multiple PODs

Potential Drawbacks

No response

Additional Information

No response

How do I deploy an SSL certificate for a related component in K8S? For example, minio.

What would you like to share?

How do I deploy an SSL certificate for a related component in K8S? For example, minio.

Additional information

No response

Enhancement Request: Transition to Subdomain-Based Access and Load Balancing for OpenIM Deployment with Sealos

Issue Description:

Currently, our system utilizes sealos for deploying OpenIM with a direct IP address method, as executed with the command sudo sealos run --env publicIP=192.168.10.10 labring/openim:errcode. However, in our business context, where OpenIM serves a secondary role, we propose a shift from using a public IP address to a subdomain-based approach. This change aims to enhance accessibility and streamline our service architecture.

Suggested Changes:

Subdomain Implementation: Replace the current public IP address configuration with subdomains such as api.xxxx.net.cn, ws.xxxx.net.cn, sysnotice.xxxx.net.cn, and minio.xxxx.net.cn. This approach will facilitate easier access and management.
Default Load Balancing Configuration: Integrate a default load balancing mechanism to manage traffic across these subdomains efficiently. This setup should ensure consistent performance and availability.
Dual Accessibility: Ensure that the endpoints are accessible both from the app side and server side for business system integration. This dual accessibility will leverage the already deployed load balancing within OpenIM.
Existing Database System Compatibility: Our current database system, managed by the Pigsty cluster, already utilizes a subdomain access method (e.g., sss.pigsty:5433) with Nginx for load balancing. Compatibility and seamless integration with this existing setup are crucial.
Consideration of Load Balancing Tools: We advise evaluating the integration of high-performance and popular tools like Traefik for load balancing, potentially replacing the less flexible Nginx in the Pigsty project. This consideration should be in line with OpenIM's requirements and our client's existing load balancing tools, which mainly include Nginx and Traefik.

Objective:

The goal is to create a more flexible, scalable, and efficient system architecture that supports our business needs and client integration requirements. By transitioning to a subdomain-based approach and optimizing load balancing, we aim to enhance the overall performance and user experience of our system.

How to collect Openim logs with Loki in K8S for system health analysis.

What would you like to share?

How to collect Openim logs with Loki in K8S for system health analysis.

Additional information

No response

Bug: failed to operate with openim-admin-front

What happened?

[Background]: I have successfully installed im-server and im-chat, and verified using the official Android app. It works perfectly. Based on my k8s cluster configuration, I did made some modifications, like using Aliyun LB instead of Nginx Ingress.

[Issue]: While exploring openim-admin-front, I encounter a CORS error:

It seems that the requests from the admin-front are not correctly requesting my cluster service(the request url looks like your official website. is this a default value?). I attempted to search through the source code but found nothing. Could you help me identify this problem?

What did you expect to happen?

How can we reproduce it (as minimally and precisely as possible)?

access {host}/openim-admin-front/login

Anything else we need to know?

No response

version

```console $ {name} version # paste output here ```

Cloud provider

aliyun

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Bug: <describe the error>The Kafka pods deployed via Helm are stuck in initialization and cannot start properly.

What happened?

Hello, my environment is kubernetes 1.23.6.
When the process of deploying openim runs the service kafka.
Helm install im-kafka infra/kafka- f infra/kafka-config.yaml-n openim.

Pod has been initializing, jammed, and can't run.

What did you expect to happen?

How can we reproduce it (as minimally and precisely as possible)?

Anything else we need to know?

No response

version

```console $ {name} version

paste output here

</details>


$ cenots  7
$ docker 20.10.0
$ kubernetes 1.23.6
$ network calico
$ CPU 4
$ Memory 8G
$ NFS storageClass 500G

### Cloud provider

<details>
</details>


### OS version

<details>
```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Centos 7

Install tools

Kubernetes

Bug: The openim-server-openim-msgtransfer-54c6d5d5-8pxvx and Openim-server-Openim-Pus-79C7768D89-7rdTM Pods restart indefinitely

configFolderPath: 
use config ../config/config.yaml
use config ../config/notification.yaml
PortFromConfig: prometheus_port
RootCmd.GetPortFromConfig: prometheus_port
2023-10-27 16:21:22.166 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.179909(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.167 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.739645(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.169 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.981042(ms)", "sql": "SELECT count(*) FROM information_schema.tables WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND table_type = 'BASE TABLE'"}
2023-10-27 16:21:22.169 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.175881(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.170 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.693231(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.170 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.239424(ms)", "sql": "SELECT * FROM `chat_logs` LIMIT 1"}
2023-10-27 16:21:22.171 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "1.190610(ms)", "sql": "SELECT column_name, column_default, is_nullable = 'YES', data_type, character_maximum_length, column_type, column_key, extra, column_comment, numeric_precision, numeric_scale , datetime_precision FROM information_schema.columns WHERE table_schema = 'openim' AND table_name = 'chat_logs' ORDER BY ORDINAL_POSITION"}
2023-10-27 16:21:22.172 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.181524(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.172 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.591284(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.173 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.890513(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'sendTime'"}
2023-10-27 16:21:22.174 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.164014(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.174 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.570112(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.175 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.816590(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'send_id'"}
2023-10-27 16:21:22.176 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.222836(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.176 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.624001(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.177 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.804750(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'recv_id'"}
2023-10-27 16:21:22.178 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.167356(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.178 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.598151(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.179 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.851954(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'session_type'"}
2023-10-27 16:21:22.180 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.181713(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.180 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.614439(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.182 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.838816(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'session_type_alone'"}
2023-10-27 16:21:22.182 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.204947(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.183 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.631816(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.184 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.803997(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'content_type'"}
2023-10-27 16:21:22.184 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.176506(ms)", "sql": "SELECT DATABASE()"}
2023-10-27 16:21:22.185 DEBUG [PID:1] msgTransfer [log/sql_logger.go:86] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.591860(ms)", "rows": 1, "sql": "SELECT SCHEMA_NAME from Information_schema.SCHEMATA where SCHEMA_NAME LIKE 'openim%' ORDER BY SCHEMA_NAME='openim' DESC,SCHEMA_NAME limit 1"}
2023-10-27 16:21:22.186 DEBUG [PID:1] msgTransfer [log/sql_logger.go:84] sql exec detail {"gorm": "/app/internal/msgtransfer/init.go:48", "elapsed time": "0.809862(ms)", "sql": "SELECT count(*) FROM information_schema.statistics WHERE table_schema = 'openim' AND table_name = 'chat_logs' AND index_name = 'content_type_alone'"}
mongo: mongodb://root:[email protected]:27017/openim?maxPoolSize=100&authSource=admin
start msg transfer prometheusPort: 0
2023-10-27 16:21:22.220 DEBUG [PID:1] msgTransfer [kafka/consumer_group.go:66] register consumer group {"groupID": "mongo"}
2023-10-27 16:21:22.220 DEBUG [PID:1] msgTransfer [kafka/consumer_group.go:66] register consumer group {"groupID": "redis"}
panic: kafka server: Offset's topic has not yet been created
goroutine 251 [running]:
github.com/openimsdk/open-im-server/v3/pkg/common/kafka.(*MConsumerGroup).RegisterHandleAndConsumer(0xc000596380, {0x1717de0, 0xc0005ca700})
 /app/pkg/common/kafka/consumer_group.go:71 +0x145
created by github.com/openimsdk/open-im-server/v3/internal/msgtransfer.(*MsgTransfer).Start
 /app/internal/msgtransfer/init.go:116 +0x197

Bug: Authentication Failure with SCRAM-SHA-1 Mechanism Leading to Service CrashLoopBackOff

What happened?

Several services within our OpenIM deployment are failing to start, entering a CrashLoopBackOff state. The logs indicate an authentication failure using the SCRAM-SHA-1 mechanism during the MongoDB connection handshake. This issue is affecting multiple components, including the openim-msgtransfer, openim-rpc-user, and others, leading to widespread service disruption.

Relevant Logs:

Error: ==> github.com/openimsdk/open-im-server/v3/pkg/common/db/unrelation.(*Mongo).createMongoIndex()@153: CreateIndex: connection() error occurred during connection handshake: auth error: sasl conversation error: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.

Service Status:

Several openimserver services are in a CrashLoopBackOff state, including openim-msgtransfer, openim-rpc-conversation, openim-rpc-friend, openim-rpc-group, and openim-rpc-msg.

Events:

Warning  BackOff  2m5s (x50214 over 7d14h)  kubelet  Back-off restarting failed container openim-rpc-user in pod openimserver-openim-rpc-user-7f8f7bd4c6-49smx_openim-lin(3bf29b26-a24f-4397-85be-de97fd2a646f)

What did you expect to happen?

Steps to Reproduce:

Deploy OpenIM version v3.3.0 in a Kubernetes environment.
Observe the pod statuses and logs for the aforementioned services.

Expected Behavior:
Services should start successfully without authentication errors during the MongoDB connection process.

Actual Behavior:
Services are crashing and entering a CrashLoopBackOff state due to authentication failures with SCRAM-SHA-1 during the MongoDB connection handshake.

Additional Information:

Configuration details, if relevant
Any recent changes made to the environment or configuration

Any insights or assistance in resolving this authentication issue would be greatly appreciated.

How can we reproduce it (as minimally and precisely as possible)?

Please ensure you replace placeholders like [Specify version] with actual version numbers from your environment and adjust any additional information to provide a clear and concise description of your issue.

Anything else we need to know?

Environment:

- OpenIM version: v3.3.0
- Kubernetes version: [Specify version]
- MongoDB version: [Specify version, if involved]
- Deployment environment: (e.g., cloud provider, on-prem)

version

```console $ {name} version # paste output here ```

Cloud provider

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Bug: OpenIM Chat Service internal run error

What happened?

internal server error.

What did you expect to happen?

run correct

How can we reproduce it (as minimally and precisely as possible)?

using old chart name

Anything else we need to know?

No response

version

```console $ {name} version # paste output here ```

Cloud provider

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Is the chart image library sure to exist? Open https://openim.github.io/helm-charts browser returns an error code.

What would you like to share?

Is the chart image library sure to exist? Open https://openim.github.io/helm-charts browser returns an error code.helm repo add openim https://openim.github.io/helm-charts
Error: looks like "https://openim.github.io/helm-charts" is not a valid chart repository or cannot be reached: Get "https://openim.github.io/helm-charts/index.yaml": read tcp 192.168.10.10:8492->185.199.108.153:443: read: connection reset by peer

Additional information

No response

The address is not right?helm repo add openim-infra https://xxxxx.xxx

Description

helm repo add openim-infra https://xxxxx.xxx
helm install im-mysql infra/mysql -f infra/mysql-config.yaml -n openim
helm install im-kafka infra/kafka -f infra/kafka-config.yaml -n openim
helm install im-minio infra/minio -f infra/minio-config.yaml -n openim
helm install im-mongodb infra/mongodb -f infra/mongodb-config.yaml -n openim
helm install im-redis infra/redis -f infra/redis-config.yaml -n openim

Screenshots

No response

Additional information

No response

recommended that the project team provide a stable image library

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

It is recommended that the project team provide a stable image library based on K8S to ensure that the images of the components used in OpenIM are continuous and available.

Solution Description

It is recommended that the project team provide a stable image library based on K8S to ensure that the images of the components used in OpenIM are continuous and available.

Benefits

It supports users to pull up with one click at any time to provide maximum deployment convenience.

Potential Drawbacks

No response

Additional Information

No response

Feature: add sending promethes alerts via email

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

Solution Description

prometheus-config.yaml file is configured with a feature to send alerts via email

Benefits

It's very convenient to configure the alert sending feature of Prometheus

Potential Drawbacks

No response

Additional Information

No response

Feature: Support for multiple msggateway services

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

Cannot support multiple msggateway services

Solution Description

Add the openim msggateway proxy service to act as a proxy for the msggateway service, and access the msggateway service through the consistency hash algorithm

Benefits

Transforming the msggateway service into a stateful service, supporting multiple msggateway services with low time complexity

Potential Drawbacks

No response

Additional Information

No response

Feature: add loki component

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

No response

Solution Description

add custome loki chart in repo

Benefits

Easy to view server log information

Potential Drawbacks

No response

Additional Information

No response

Proposal for Addressing OpenIM's Role in Relation to Business Systems: Master-Slave Positioning and Integration Strategy

Issue Description:

A key discussion topic that was overlooked in our last bi-weekly meeting concerns the master-slave positioning of OpenIM in relation to our business systems. This topic is crucial as it directly impacts our deployment strategy regarding reverse proxy and load balancing.

Discussion Points:

OpenIM as the Primary System: In scenarios where OpenIM acts as the primary system and the user's business system is secondary (similar to a chat application), OpenIM handles user registration and management. In these cases, OpenIM's service endpoints are directly exposed to the public, and load balancing and reverse proxy software are directly linked with Nginx.
OpenIM as a Secondary System: In other scenarios, clients have their own core business systems and integrate OpenIM as a functional module. Here, user registration and management are initially handled by the core system, followed by a secondary registration in OpenIM. In these instances, the client’s core business system is the one exposed directly to the public, making OpenIM an internal supporting system. This positioning requires a different interaction model between OpenIM and the core business system.

Suggestions for Improvement:

Unified Endpoint Strategy: For cases where OpenIM functions as a secondary system, it is recommended that OpenIM adopts a strategy similar to nginx-ingress in Kubernetes. This would involve providing a unified set of external service endpoints (API, WebSocket, backend management notifications, etc.), akin to how database clusters offer a unified access point.
Flexible Deployment and Integration: OpenIM should be engineered to be a versatile and efficient component, capable of both leading and supporting roles in different business scenarios. This flexibility will ensure that OpenIM can be effectively integrated regardless of its position as a primary or secondary system.
Load Balancing and Endpoint Exposure: Independently of its role, OpenIM should be developed and deployed as a cohesive system with robust load balancing capabilities. This includes properly exposing its endpoints for efficient and secure access.

Objective:

The goal is to transform OpenIM into a highly adaptive, efficient, and unified service, capable of effectively serving in both primary and secondary roles in various business scenarios. This will entail reevaluating and potentially revising its deployment and integration strategies to ensure optimal performance and compatibility with diverse business systems.

When accessing minio buckets, it is a good idea to provide the ability to skip SSL checks. Just add tls-insecure-skip-verify=true to the end of the https request

What would you like to share?

When accessing minio buckets, it is a good idea to provide the ability to skip SSL checks. Just add tls-insecure-skip-verify=true to the end of the https request

Additional information

No response

It is recommended that the project team try to set the parameters of the components under K8S as quasi-standard as the standard configuration of the production environment

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

It is recommended that the project team try to set the parameters of the components under K8S as quasi-standard as the standard configuration of the production environment. For example, according to the average daily online 100,000, the throughput is 10 million, and the storage is 2T per day. This prevents the openim from looking like a toy. This approach is used in other large software, such as CEPH, which provides medium to high availability rather than minimal availability.

Solution Description

For example, according to the average daily online 100,000, the throughput is 10 million, and the storage is 2T per day. This prevents the openim from looking like a toy. This approach is used in other large software, such as CEPH, which provides medium to high availability rather than minimal availability.

Benefits

It can help users to provide the best parameters to the greatest extent.

Potential Drawbacks

No response

Additional Information

No response

Docs: The readme.md can be easily read and deployed

Description

The document is concise, and I can easily deploy the service according to the document

Screenshots

No response

Additional information

No response

It is recommended that you install Prometheus and Grafana, loki and promtail automatically.

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

components are all standard and open automatically by default, so users who don't need them can be disabled, instead of having them manually execute installation commands. This is also a common practice in many open source software today.

Solution Description

Benefits

Minimize user operations.

Potential Drawbacks

No response

Additional Information

No response

how to use loki to collect logs in a k8s cluster?

Checklist

I've searched for similar issues and couldn't find anything matching
I've discussed this feature request in the OpenIMSDK Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

According to the instructions released in the official version, the 3.0 version or later regulates the logs, please consult an expert, how to use loki to collect logs in a k8s cluster? Does Openim provide an interface in K8S deployment?

Solution Description

Does Openim provide an interface in K8S deployment?

Benefits

It helps to analyze logs under the company's unified monitoring system

Potential Drawbacks

No response

Additional Information

No response

🔮[RFC #0009]: CI/CD Design for OpenIMSDK Helm Charts

[RFC #0000] CI/CD Design for OpenIMSDK Helm Charts

Summary

This RFC proposes a CI/CD pipeline design for the OpenIMSDK Helm charts to ensure their reliability and stability. The aim is to automate testing and deployment processes, reducing manual intervention and increasing efficiency.

Definitions

CI/CD: Continuous Integration and Continuous Deployment
Helm Chart: A package containing pre-configured Kubernetes resources
Kubernetes: An open-source system for automating deployment, scaling, and management of containerized applications

Motivation

To automate the testing and deployment of OpenIMSDK Helm charts.
To detect issues early in the development cycle.
To provide a stable and reliable deployment process for users.

What it is

A CI/CD pipeline for automating the testing, validation, and deployment of OpenIMSDK Helm charts. This will include linting, unit testing, integration testing, and automated release processes.

How it Works

Linting: Helm charts will be validated using helm lint, ensuring that they follow best practices and are free of syntax errors. This includes checking for any deprecated API usage.
Unit Testing: Utilize tools like helm unittest to test individual templates within the Helm charts. This will help in verifying the logic of templates and their outputs for different input values.
Integration Testing: Implement automated end-to-end tests that deploy the Helm charts in a Kubernetes cluster (can be a minikube or a kind cluster). This step will validate that all components of the Helm charts work together as expected. It will include testing of deployment, services, ingress, and any other Kubernetes resources defined by the Helm chart.
Security Scanning: Integrate a security scanning tool (like Trivy or Clair) to scan for vulnerabilities in the container images specified in the Helm charts. This step ensures that the images used are secure and up to date.
Dependency Update Checks: Regularly check for updates in Helm chart dependencies. Automate the process of updating these dependencies and triggering subsequent tests to ensure compatibility.
Automated Versioning and Chart Packaging: Implement a versioning strategy for the Helm charts. Use semantic versioning and automatically bump chart versions based on the type of changes (major, minor, or patch). Package the charts using helm package.
Publishing: On successful completion of all tests, automatically publish the Helm charts to a Helm repository. This could be a public repository like Helm Hub or a private one within the organization.
Notification and Reporting: Integrate notifications to alert the team in case of failed builds or tests. Also, generate reports of test results for review and audit purposes.
Documentation Update: Ensure that any changes in the Helm charts are automatically reflected in the documentation. This could be achieved by scripting documentation generation as part of the CI/CD process.

Migration

N/A – This RFC does not involve changes that require migration.

Drawbacks

Initial setup requires time and resources.
Complexity in maintaining the pipeline.

Alternatives

Continue manual testing and deployment: This is less efficient and more prone to errors.
Use third-party CI/CD tools: This could introduce dependencies and potential security issues.

Prior Art

Similar CI/CD processes are used in various open-source projects to ensure the quality and reliability of software releases.

Unresolved Questions

What specific tools and services will be used in the pipeline?
How will versioning be handled in the automated release process?

Spec. Changes (OPTIONAL)

N/A

History

Bug: install loki error

What happened?

install loki chart error, the promtail component install error,and install some not using components ,sush as filebeat logstash.

What did you expect to happen?

only install loki and promtail components

How can we reproduce it (as minimally and precisely as possible)?

using current vision

Anything else we need to know?

No response

version

```console $ {name} version # paste output here ```

Cloud provider

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Bug: unable to use fcm push

What happened?

I am trying to explore the Push feature of the OpenIM server(using android demo app). I noticed that the configuration options include FCM. However, the documentation on how to use FCM is somewhat unclear.
config:

The format for push.fcm.serviceAccount is "x.json," so I assume this should be a JSON file. Initially, I placed the JSON file in the root directory of the Helm charts. It DID NOT work.
I replaced the Helm image repository with my own packaged image and added some logs during startup. The logs indicate that the push service did not correctly read push.fcm.serviceAccount. Then I realized that helm did not specify serviceAccount during the Helm install. Certainly, there isn't that file inside the container either.
So, how should I fix it?

What did you expect to happen?

The FCM client initialized properly, and offline push notifications could be sent.

How can we reproduce it (as minimally and precisely as possible)?

in config-imserver.yaml, change push.enable to fcm

Anything else we need to know?

No response

version

```console $ {name} version # paste output here ```

Cloud provider

aliyun

OS version

```console # On Linux: $ cat /etc/os-release # paste output here $ uname -a # paste output here # On Windows: C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture # paste output here ```

Install tools

Docs: <description>The Kafka pods deployed via Helm are stuck in initialization and cannot start properly.

Description

Hello, my environment is kubernetes 1.23.6.
$ cenots 7
$ docker 20.10.0
$ kubernetes 1.23.6
$ network calico
$ CPU 4
$ Memory 8G
$ NFS storageClass 500G
When the process of deploying openim runs the service kafka.
$ Helm install im-kafka infra/kafka- f infra/kafka-config.yaml-n openim.

Pod has been initializing, jammed, and can't run.

Screenshots

Additional information

No response