Socket Unix Redis, Installation Ubuntu

J’essaie d’installer Discourse. J’ai configuré ma base de données, Redis et SMTP. Pour la base de données PostgreSQL, aucun problème avec le socket Unix, mais Redis semble poser problème.

Paramètres Redis :

sudo sed -i 's/^# unixsocket /unixsocket /' /etc/redis/redis.conf
sudo sed -i 's/^# unixsocketp.*/unixsocketperm 770/' /etc/redis/redis.conf
sudo sed -i 's/^# maxmemory <bytes>/maxmemory 1024mb/' /etc/redis/redis.conf
sudo sed -i 's/^# maxmemory-policy noeviction/maxmemory-policy allkeys-lru/' /etc/redis/redis.conf
sudo cat /etc/redis/redis.conf | grep "^maxmemory\|^unixsocket"

Configuration du socket Redis :
nano /var/www/discourse/config/discourse.conf
redis_host = "/var/run/redis/redis-server.sock"

Pendant l’installation de Discourse :

RAILS_ENV=production /root/.rbenv/versions/2.7.2/bin/bundle exec rake db:migrate

Échec du rapport d'erreur : Erreur de connexion à Redis sur localhost:///var/run/redis/redis-server.sock:6379 (SocketError) 2 Erreur de connexion à Redis sur localhost:///var/run/redis/redis-server.sock:6379 (SocketError
) échec de l'abonnement, reconnexion dans 1 seconde. Pile d'appels ["/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:362:in `rescue in establish_connection'", "/var/www/discourse/vendor/b
undle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:343:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:107:in `block in connect'", "/var/www/disc
ourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:308:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:106:in `connect'", "/var/www/disco
urse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:289:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:139:in `call_loop'", "/var/www
/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/subscribe.rb:44:in `subscription'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/subscribe.rb:14:in `subscribe'", "/var/
www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:3506:in `_subscription'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:2326:in `block in subscribe'", "/var/www
/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:69:in `block in synchronize'", "/root/.rbenv/versions/2.7.2/lib/ruby/2.7.0/monitor.rb:202:in `synchronize'", "/root/.rbenv/versions/2.7.2/lib/ru
by/2.7.0/monitor.rb:202:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:69:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/
redis.rb:2325:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.1/lib/message_bus/backends/redis.rb:287:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems
/message_bus-3.3.1/lib/message_bus.rb:754:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.1/lib/message_bus.rb:702:in `block in new_subscriber_thread'"]
rake aborted!
Redis::CannotConnectError: Erreur de connexion à Redis sur localhost:///var/run/redis/redis-server.sock:6379 (SocketError)
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:362:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:343:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:107:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:308:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:106:in `connect'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:381:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:233:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:320:in `logging'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:232:in `process'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis/client.rb:126:in `call'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:557:in `block in del'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:69:in `block in synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:69:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.1/lib/redis.rb:556:in `del'
/var/www/discourse/lib/discourse_redis.rb:81:in `block in del'
/var/www/discourse/lib/discourse_redis.rb:29:in `ignore_readonly'
/var/www/discourse/lib/discourse_redis.rb:79:in `del'
/var/www/discourse/lib/cache.rb:73:in `delete'

Si vous souhaitez installer Discourse pour la production, vous devez utiliser l’installation standard officielle de Discourse. Si vous souhaitez installer un environnement de développement, il existe des sujets pour chaque système d’exploitation.

1 « J'aime »

Merci pour votre réponse.

Pour clarifier, tout fonctionne parfaitement et je suis pleinement opérationnel, mais j’ai dû configurer l’hôte Redis sur “localhost” car la connexion via un socket Unix ne fonctionnait pas.

J’ai suivi ce guide : Install Discourse Forum on Ubuntu 18.04 Without Docker. Comme le guide est quelque peu daté, j’ai dû apporter quelques ajustements ici et là, mais je connais très bien Linux, j’ai donc pu le suivre sans problème.

Mon installation se trouve dans un conteneur LXC Proxmox exécutant Ubuntu 20.04.

Je ne trouve pas beaucoup de références en ligne concernant l’utilisation de Redis via un socket Unix. Je me demande si cela pourrait être une nouveauté pour Redis. J’ai trouvé un lien, mais il semble qu’ils utilisent Docker, ce qui n’est pas mon cas, donc cela ne s’applique pas directement : Discourse PR for redis.socketed.template.yml - Discourse System Administration - Unix Linux Community

1 « J'aime »

Dans ce cas, vous serez largement livré à vous-même, car seule l’installation standard officielle de Discourse est prise en charge ici.

Je pense qu’il sera plutôt difficile d’installer ou de maintenir une instance de production qui n’utilise pas Docker. Il y a plusieurs points délicats dans l’interaction entre nginx et Discourse qui seront compliqués à gérer sans le conteneur Docker fourni, mais tout est possible, je suppose.

Oui, heureusement, ils fournissent un exemple de configuration nginx

/var/www/discourse/config/nginx.sample.conf

D’après ce que je lis, même l’image Docker ne prend pas encore en charge Redis via un socket Unix.

Cela ne risque pas de changer. Si le modèle actuel ne prend pas en charge l’utilisation d’un socket, cela signifie que CDCK n’utilise pas de socket Redis dans leur hébergement ou dans leur installation Docker prise en charge.

Je ne suis pas sûr de quel problème vous essayez de résoudre en n’utilisant pas la configuration ./launcher et docker prise en charge, mais vous risquez de rencontrer un certain nombre d’autres problèmes.

Je ne sais pas si vous avez déjà utilisé Proxmox, mais à mon avis, c’est fantastique ! Je peux me connecter à l’interface web et créer une sauvegarde en un seul clic. Je peux ensuite apporter des modifications et, si quelque chose tourne mal, il me suffit de sélectionner la sauvegarde et de cliquer sur restaurer.

En plus de cela, vous obtenez des performances bien supérieures avec un conteneur LXC qu’avec une image Docker, il n’y a pas de comparaison possible.

Je ne dis pas que Docker est mauvais, car comme vous l’avez souligné, cela rend la configuration extrêmement simple.

Je parie que pour les usages que vous en avez faits, il a été excellent !

Je suis presque certain que des gens ont fait cette comparaison et qu’il y a 100 à 1000 fois plus d’images qui tournent sur Docker que sur LXC (que j’ai utilisé, il y a belle lurette).

Je ne dis pas que Proxmox est mauvais, mais si vous voulez que Discourse soit facile à installer et à maintenir, vous utiliserez Docker. Pour vous donner une idée, si vous demandiez de l’aide sur Marketplace avec un budget inférieur à 1 000 $, je ne répondrais pas.

Le but du fil était de demander l’état actuel du socket Unix de Redis. Pas de débattre pour savoir si LXC ou Docker est mieux adapté à Discourse. Je n’ai mentionné pourquoi je n’utilisais pas Docker que parce que vous sembliez peut-être curieux à ce sujet. Pour la personne moyenne, Docker gagnera à tous les coups, car c’est simple. C’est aussi la raison pour laquelle, pendant très longtemps, tant d’applications utilisaient MySQL plutôt que PostgreSQL. Mais j’adore absolument PostgreSQL.

Jusqu’à ce que je rencontre un problème dévastateur, je resterai certainement avec LXC, il fonctionne tout simplement très bien ! Je suis également tout à fait d’accord avec le fait que si vous pensez avoir besoin d’un support externe, vous devriez probablement vous en tenir aux paramètres par défaut recommandés. Moi-même, j’ai 20 services différents, chacun dans son propre conteneur LXC, tournant sur un seul nœud Proxmox, et ils fonctionnent tous parfaitement, et ce n’est qu’un seul nœud dans un cluster Proxmox. Sauvegardes automatisées, surveillance, migration entre les nœuds du cluster, ce sont toutes de superbes choses :slight_smile:

Ai-je mentionné que mon installation s’est déroulée sans accroc ? Jusqu’à présent, j’adore Discourse, à part devoir utiliser localhost pour Redis au lieu du socket Unix, je n’ai eu aucun problème. Je vais essayer de me souvenir de revenir ici dans quelques mois pour vous dire si c’est toujours le cas :wink:

2 « J'aime »

Ha ! NON ! Génial ! Content que tu aies résolu le problème ! Il semble que si tu es prêt à accepter localhost pour Redis, tu n’auras plus de soucis à te faire à l’avenir.

Je suppose que c’est usermod -aG redis discourse ou alternativement unixsocketperm 777 pour que unicorn ait les permissions d’accéder au socket. Assurez-vous également que le répertoire où le socket doit être créé existe et que l’utilisateur redis en est le propriétaire. Cependant, le package redis-server courant basé sur les services systemd sur Ubuntu assure cela.