Le SDK complet pour le chat, les commentaires et les notifications
cord offre aux développeurs une solution puissante et flexible pour intégrer de manière transparente des fonctionnalités de collaboration en temps réel dans leurs applications. Avec des composants prédéfinis pour le chat, la présence et les notifications, ainsi que des primitives d'interface utilisateur entièrement personnalisables, cord permet une mise en œuvre rapide d'outils de collaboration sophistiqués dans l'application. Que vous construisiez une interface de messagerie simple ou un environnement multi-utilisateurs complexe, le SDK de cord offre la fiabilité et l'évolutivité nécessaires pour améliorer l'engagement des utilisateurs et rationaliser la communication au sein de votre produit.
cord a été initialement développé comme une solution commerciale pour fournir des fonctionnalités robustes de chat, de commentaires et de notification en temps réel pour les applications Web. En août 2024, alors que le service hébergé de cord s'est arrêté, l'équipe a décidé d'ouvrir l'intégralité de la base de code en open source. Reconnaissant la valeur de cord , plusieurs employés cord excord et passionnés d'open source au sein de leur clientèle, dont Preset, se sont réunis pour lancer ce projet open source. Beaucoup de ces contributeurs utilisent et dépendent de cord dans leurs propres produits et s'engagent à maintenir le projet en vie, à évaluer l'intérêt au sein de la communauté open source et, espérons-le, à voir ce projet étonnant développer une communauté florissante.
Pour obtenir une assistance supplémentaire et pour entrer en contact avec la communauté, veuillez vous référer aux ressources suivantes :
Utilisez ces instructions pour exécuter cord localement, en utilisant uniquement les ressources locales (DB, Redis, etc.).
Remarque : cord n'a été exécuté systématiquement que sur les distributions MacOS et Linux en utilisant apt
. Rien ne doit être spécifique à une plateforme, mais les instructions pour les autres plateformes sont laissées à titre d'exercice au lecteur.
Avant d'exécuter cord , vous devez installer un logiciel.
.nvmrc
et .node-version
qui spécifie la version de Node à utiliser.jq
(Mac : brew install jq
, Linux : apt install jq
)brew install libpq && brew link --force libpq
, Linux : apt install postgresql-client
)Pour nous connecter via TLS à notre machine locale, nous devons installer un certificat auto-signé.
Mac :
scripts/generate-localhost-certificates.sh
(qui utilisera Homebrew pour installer mkcert
)security.enterprise_roots.enabled
sur true
dans about:config
Linux :
mkcert
via apt install mkcert
scripts/generate-localhost-certificates.sh
Exécutez scripts/generate-dotenv.cjs --include-secrets=false
pour générer un fichier .env
contenant les options de configuration pour exécuter le serveur de développement.
Exécutez npm run local-dev
pour démarrer l'environnement de développement local.
Il existe deux étapes pour migrer vos données de la plateforme cord vers votre propre infrastructure auto-hébergée : la migration des données de la base de données et la migration des données S3 (telles que les pièces jointes des messages).
Dans les deux cas, vous avez besoin d’un jeton d’authentification de gestion de projet. Cela doit être fourni aux API suivantes dans un en-tête Authorization
.
Pour copier vos fichiers depuis S3, vous devez d'abord configurer un compartiment S3 comme décrit dans les étapes 1 et 2 de la documentation pour configurer un compartiment S3 personnalisé. Créez ensuite une stratégie qui autorise au moins les autorisations PutObject
et ListObjects
à arn:aws:iam::869934154475:role/radical-stack-prodServerLondonASGInstanceRole31491-P9EJBVI9CBCR
(notre utilisateur du serveur de production) sur le compartiment et sur chaque objet du compartiment. La politique devrait ressembler à ceci :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::869934154475:role/radical-stack-prodServerLondonASGInstanceRole31491-P9EJBVI9CBCR"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::YOUR-S3-BUCKET-ID",
"arn:aws:s3:::YOUR-S3-BUCKET-ID/*"
]
}
]
}
Une fois cela fait, contactez quelqu'un à cord , car nous devons également configurer une stratégie IAM dans notre compte pour approuver ce même accès.
Après avoir configuré les autorisations, appelez https://api.cord.com/v1/customer/copyfiles?region=YOUR-S3-REGION&bucket=YOUR-S3-BUCKET-ID
. Le gestionnaire est une copie incrémentielle qui prend un paramètre limit
de 1 à 1 000 (10 par défaut) et tente de copier autant de fichiers dans votre compartiment, vous devrez donc probablement l'exécuter plus d'une fois. Continuez à l'exécuter jusqu'à ce qu'il renvoie {"copied":0}
, auquel cas tous les fichiers sont copiés.
Vous pouvez effectuer cette étape à tout moment, et comme elle est incrémentielle, vous pouvez l'exécuter avant d'être prêt à passer à votre propre infrastructure, puis l'exécuter à nouveau au moment du basculement pour simplement copier tous les nouveaux fichiers qui ont été téléchargés. depuis.
Pour migrer les données de votre base de données, appelez https://api.cord.com/v1/customer/dbdump
. Cela produira un script SQL contenant toutes vos données, prêt à être exécuté sur une base de données vide via psql --variable=ON_ERROR_STOP=1
. Cela inclura toutes les données de tous vos projets. Soyez patient, la collecte de toutes les données peut prendre jusqu'à une minute ou deux.
Ces données ne sont évidemment valides qu'au moment de l'exécution de la commande. Vous souhaiterez donc probablement les utiliser pour tester votre processus de migration, puis les réexécuter juste avant de passer à votre propre infrastructure afin de capturer les informations les plus récentes. -date données disponibles.
Vous pouvez utiliser les fichiers de ce dépôt pour exécuter l'infrastructure de cord sous votre propre compte AWS. Voici approximativement la série d'étapes pour que cela soit opérationnel :
Vous avez besoin des informations suivantes :
1234567890
)eu-central-1
)cord .example.com
)Recherchez au moins les fichiers suivants et remplacez toutes les références aux trois éléments ci-dessus par vos valeurs. Il peut s'agir de constantes, d'ARN, etc. Utilisez la recherche et le remplacement. (Il y en a d'autres, mais cela devrait suffire à vous permettre d'être opérationnel.)
package.json
(les commandes npm db-ssh-tunnel
et db-ssh-tunnel-write
)ops/aws/config/zero/cssh
ops/aws/src/Config.ts
ops/dockerfiles/server.Dockerfile
ops/local-s3/create-buckets.sh
scripts/connect-docker-to-aws-ecr.sh
scripts/manual-deploy.sh
scripts/ci/build-on-commit.sh
scripts/lib/secrets.cjs
server/src/config/Env.ts
Dans us-east-1
, créez des certificats pour *.
, *.staging.
, et *.loadtest.
(par exemple, *.staging. cord .example.com
). Ceux-ci sont utilisés pour CloudFront, ils doivent donc se trouver dans us-east-1
quelle que soit la région dans laquelle vous travaillez.
Recherchez le VPC par défaut pour la région dans laquelle vous travaillez, ainsi que ses trois sous-réseaux par défaut. AWS les crée automatiquement pour vous dans les régions et doit être importé dans les configurations.
Créez une clé RSA SSH avec ssh-keygen -t rsa -b 4096 -C "[email protected]"
. Ensuite, dans AWS, accédez à la page Mes informations d'identification de sécurité et téléchargez-la dans la section « Informations d'identification AWS CodeCommit ». Ceci sera utilisé pour l’accès SSH au système. Également dans IAM, donnez à votre utilisateur la balise zeroAccount
: yes
avec tout autre utilisateur avec lequel vous souhaitez pouvoir accéder en SSH au système.
Mettez à jour toutes les constantes dans ops/aws/src/radical-stack/Config.ts
pour définir vos domaines, ajoutez des ARN pour les certificats et les VPC de l'étape précédente, etc.
Dans ops/aws
, effectuez npm install
et npm run deploy
. Cela prendra beaucoup de temps car cela fait apparaître de nombreux services (bases de données, instances EC2, etc.). En cas d'échec, CloudFormation n'est malheureusement pas en mesure d'annuler la création d'un certain nombre de ces éléments. Vous devrez donc les supprimer tous manuellement, sinon la prochaine tentative échouera car certains objets existent déjà. (J'espère que cela n'échouera pas.)
(Vos machines EC2 commenceront immédiatement à planter et à redémarrer continuellement car elles n'ont pas encore de version de serveur disponible. Ce n'est pas grave.)
L'hôte que nous utilisons comme bastion SSH s'appelle zero
. Ajoutez une strophe à ~/.ssh/config
(en la créant si nécessaire) qui se lit comme suit :
Host zero
HostName zero. cord .example.com
Port 28547
User YOUR_AWS_USERNAME
ForwardAgent yes
Ensuite, si cela fait au moins 15 minutes depuis que vous avez démarré zéro (il récupère et installe les clés publiques SSH pour les comptes d'utilisateurs toutes les 15 minutes), essayez de faire ssh zero
. Cela devrait vous déposer dans une console. Si tel est le cas, félicitations, vous êtes maintenant dans le réseau privé virtuel et tout devrait fonctionner.
Accédez à scripts/generate-dotenv.cjs
et modifiez les propriétés pour les ajuster selon vos besoins. À tout le moins, vous devez mettre à jour la région AWS et les noms d'hôtes basés sur cord .com. Également dans la fonction buildProdEnv
ajoutez INCLUDE_SDK_TESTBED: '1'
à la fin.
Exécutez ce qui suit depuis votre ordinateur local :
$ npm run db-ssh-tunnel-write
$ PGPASSWORD="$(aws secretsmanager get-secret-value --secret-id database-prod-1 | jq -r '.SecretString | fromjson | .password')" createdb -h localhost -p 25432 -U ChuckNorris radical_db
$ PGPASSWORD="$(aws secretsmanager get-secret-value --secret-id database-prod-1 | jq -r '.SecretString | fromjson | .password')" psql -h localhost -p 25432 -U ChuckNorris -d radical_db
radical_db=> CREATE EXTENSION "uuid-ossp";
radical_db=> COMMENT ON EXTENSION "uuid-ossp" IS 'generate universally unique identifiers (UUIDs)';
Sur zero
, faites cssh -l ubuntu build3
, qui vous connectera à la machine de build. Clonez le dépôt que vous utilisez (avec toutes les modifications ci-dessus), puis exécutez ./scripts/ci/build-on-commit.sh
. Cela devrait créer une version des serveurs et vous indiquer qu'il ne les déploiera pas automatiquement en raison des paramètres heimdall, mais vous donnera une commande à exécuter pour les pousser manuellement (cela commence par scripts/manual-deploy.sh
).
Exécutez la commande de déploiement manuel. La poussée échouera car les serveurs sont actuellement en mauvais état, mais ce n'est pas grave. Une fois terminé, les serveurs récupéreront le nouveau code lors de leur prochain cycle de redémarrage et devraient s'afficher correctement.
Modifiez la staging
en prod
dans la commande que vous avez exécutée et exécutez-la à nouveau. La même chose devrait se produire, mais les serveurs de production devraient fonctionner correctement.
Vous devriez maintenant disposer d’une version opérationnelle de toute l’infrastructure cord . Vous pouvez suivre les étapes de la section précédente de ce README pour migrer vos données DB et S3 vers le stockage de données.
À ce stade, vous pouvez ajouter des clés API pour tous les services que vous utilisez, tels que SendGrid et LaunchDarkly. Les clés se trouvent dans SecretsManager sous des éléments raisonnablement bien décrits, ou vous pouvez les rechercher dans scripts/generate-dotenv.cjs
.
Vous êtes maintenant prêt à partir. Chaque fois que vous souhaitez créer de nouvelles versions, vous pouvez vous connecter à la machine build3
et les exécuter vous-même, ou vous pouvez utiliser les exemples de github_workflows
pour exécuter des workflows GitHub afin d'exécuter des choses. (Vous devrez définir INCLUDE_GITHUB_RUNNER
sur true
dans ops/aws/src/radical-stack/ec2/build3.ts
pour exécuter GitHub Actions Runner.)