Configuration HA de Discourse dans un environnement réseau isolé

[Veeru_Badavath]

Merci d’avance.
Je prévois de configurer Discourse avec une haute disponibilité dans un environnement de production. Ci-dessous mon plan de conception et quelques conditions environnementales.

1. Configuration avec 3 serveurs d’applications et 2 serveurs de base de données Postgres. Toujours un serveur PG en mode écriture et un autre en mode lecture seule.

2. Ces 3 serveurs d’applications pointeront vers le même serveur de base de données.

3. Chaque instance de base de données devrait servir respectivement des opérations de lecture et d’écriture uniquement.

4. Les serveurs de production n’ont pas de connectivité Internet mais je peux télécharger des images dockerHub.

5. Nous avons notre propre serveur GitLab.

6. Est-il possible d’amorcer une image Docker et cette image sur plusieurs serveurs ?

Quelqu’un peut-il m’aider à réaliser cette configuration ? Si des liens ou des suggestions, envoyez-moi un message privé.

[Falco]

@Veeru_Badavath

Est-il possible de démarrer une image docker et cette image sur plusieurs serveurs ?

Après avoir exécuté ./launcher bootstrap app quelque part, vous devrez enregistrer cette image de conteneur résultante (généralement en la poussant vers un registre), puis la télécharger et l’exécuter sur vos trois serveurs d’application.

@Veeru_Badavath

Configuration avec 3 serveurs d’application et 2 serveurs de base de données Postgres.

Vous aurez également besoin d’un serveur Redis central (et potentiellement de répliques pour celui-ci). Il vous manque également un équilibreur de charge pour diriger les requêtes vers ces différents serveurs d’application.

[Veeru_Badavath]

Merci pour votre réponse @Falco

Nous utilisons HAProxy comme équilibreur de charge et Nexus pour stocker les artefacts.

[Veeru_Badavath]

Salut @Falco
Dans mon environnement de production, je n’ai pas accès à Internet. Ce que je prévois, c’est d’effectuer le bootstrap sur une machine accessible par Internet, puis d’apporter cette image de bootstrap aux serveurs de production. Pendant ce processus sur la VM de production, le conteneur ne démarre pas car le serveur Unicorn recherche un identifiant de processus parent, ce qui l’empêche de s’exécuter.

Pouvez-vous m’aider ici ? Dois-je copier le répertoire /var/discourse après le bootstrap sur le serveur de production ?

[Falco]

@Veeru_Badavath

En faisant cela

Qu’est-ce que « cela » ? Le bootstrap ou l’exécution de l’image de conteneur précédemment bootstrapée ?

[Veeru_Badavath]

Lorsque j’exécute l’image de conteneur précédemment amorcée

[Falco]

Comment avez-vous enregistré et exporté l’image vers le serveur de production ?

Comment, exactement, essayez-vous d’exécuter cette image enregistrée en production ?

[Veeru_Badavath]

image précédemment amorcée poussant vers le référentiel Nexus et depuis le référentiel Nexus tirant sur le serveur de production.

commande docker run générée à partir de ./launcher start-cmd app et exécution de la même commande sur le serveur de production.

[Falco]

Pouvez-vous partager le journal d’erreurs lors de son démarrage en production ?

[Veeru_Badavath]

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
chgrp: invalid group: ‘syslog’
ok: run: redis: (pid 51) 0s
ok: run: postgres: (pid 56) 0s
supervisor pid: 53 unicorn pid: 75
config/unicorn_launcher: line 71: kill: (75) - No such process
config/unicorn_launcher: line 15: kill: (75) - No such process
(53) exiting
ok: run: redis: (pid 51) 7s
ok: run: postgres: (pid 101) 0s
supervisor pid: 96 unicorn pid: 103
config/unicorn_launcher: line 71: kill: (103) - No such process
config/unicorn_launcher: line 15: kill: (103) - No such process
(96) exiting
ok: run: redis: (pid 51) 14s
ok: run: postgres: (pid 127) 0s
supervisor pid: 120 unicorn pid: 129
config/unicorn_launcher: line 71: kill: (129) - No such process
config/unicorn_launcher: line 15: kill: (129) - No such process
(120) exiting
ok: run: redis: (pid 51) 22s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 51) 30s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 51) 37s
ok: run: postgres: (pid 174) 0s
supervisor pid: 165 unicorn pid: 176
config/unicorn_launcher: line 71: kill: (176) - No such process
config/unicorn_launcher: line 15: kill: (176) - No such process
(165) exiting
ok: run: redis: (pid 51) 48s
ok: run: postgres: (pid 196) 1s
supervisor pid: 191 unicorn pid: 198
config/unicorn_launcher: line 71: kill: (198) - No such process
config/unicorn_launcher: line 15: kill: (198) - No such process
(191) exiting
ok: run: redis: (pid 51) 54s
timeout: down: postgres: 1s, normally up, want up

[Falco]

Utilisez-vous PostgreSQL, Redis et Object Storage externes ? C’est ce qui est attendu en cas de haute disponibilité (HA), et vos serveurs de production ainsi que vos serveurs de build doivent avoir accès à ces services externes.

[Veeru_Badavath]

Juste pour tester le scénario, bootstrap s’exécute sur un serveur et exécute une image de conteneur bootstrapée sur un autre serveur avec une configuration autonome.

[Falco]

C’est une façon sûre qui ne fonctionnera pas.

[Veeru_Badavath]

Y a-t-il une raison de mentionner le stockage d’objets, ne pouvons-nous pas utiliser le stockage interne du serveur ?

[Veeru_Badavath]

Dans la configuration HA, devons-nous copier le répertoire discourse bootstrap effectué sur tous les serveurs d’applications ?

[Falco]

@Veeru_Badavath

Une raison de mentionner le stockage d’objets, ne pouvons-nous pas utiliser le stockage interne du serveur ?

Comment allez-vous gérer plusieurs serveurs d’applications et les téléchargements d’utilisateurs ? Un lecteur réseau partagé entre tous les serveurs ? Cela pourrait fonctionner, mais notre solution officielle pour cela est le stockage d’objets utilisant l’API S3.

@Veeru_Badavath

Dans une configuration HA, devons-nous copier le répertoire discourse bootstrap effectué sur tous les serveurs d’applications ?

Pas besoin de cela, tant que vous

@Falco

Utilisez-vous un PostgreSQL, Redis et un stockage d’objets externes ?

[Veeru_Badavath]

@Falco

Utilisez-vous un PostgreSQL, un Redis et un stockage d’objets externes ?

Oui, j’utilise un serveur Postgres externe et un cluster Redis

@Falco

Utilisez-vous un PostgreSQL, un Redis et un stockage d’objets externes ?

3 serveurs d’applications sont utilisés pour le cluster Redis avec l’application.

@Falco

Comment allez-vous gérer plusieurs serveurs d’applications et les téléchargements d’utilisateurs ? Un lecteur réseau partagé entre tous les serveurs ? Cela peut fonctionner, mais notre solution officielle pour cela est le stockage d’objets utilisant l’API S3.

J’ai donc besoin d’utiliser un répertoire/stockage partagé pour le répertoire de build de Discourse. Merci @Falco, c’est maintenant clair pour moi.

[Veeru_Badavath]

Désolé de vous déranger @Falco, j’ai une dernière question.

Lors de l’exécution de l’étape de reconstruction, cela aura-t-il un impact sur les données existantes dans la base de données Postgres ? Si oui, comment le gérer ?

[Falco]

@Veeru_Badavath

Lors de l’exécution de l’étape de reconstruction, cela aura-t-il un impact sur les données existantes dans la base de données Postgres ? Si oui, comment le gérer ?

Oui, il y aura des migrations exécutées lors d’une reconstruction, qui modifieront à la fois les données et la structure.

Dans un environnement HA, vous devrez suivre les instructions que nous avons ici : Introducing Post Deployment Migration

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.