Bonjour, j’utilise le M1 pour développer des automatisations et des outils afin de faire fonctionner Discourse. Le script discourse-setup a un problème pour reconnaître les processeurs basés sur ARM et échoue avec l’erreur suivante. Cela a entraîné le non-démarrage du conteneur. Dans mon cas, j’opte pour l’approche conteneur web + données, c’est donc le conteneur web qui ne démarre pas.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is \"*0\")
./discourse-setup --two-container
Le fichier de configuration containers/web_only.yml existe déjà !
. . . reconfiguré . . .
Sauvegarde du fichier existant sous le nom web_only.yml.2022-06-12-062509.bak
Arrêt du conteneur existant dans 5 secondes ou appuyez sur Control-C pour annuler.
AVERTISSEMENT : La prise en charge de aarch64 est actuellement expérimentale. Veuillez signaler tout problème sur https://meta.discourse.org/tag/arm
Appuyez sur n'importe quelle touche pour continuer
AVERTISSEMENT : Nous sommes sur le point de télécharger l'image de base de Discourse
Ce processus peut prendre entre quelques minutes et une heure, en fonction de votre vitesse de connexion Internet
Veuillez patienter
aarch64 : téléchargement de discourse/base
Digest : sha256:a2ce381fdc4fed59fe160fb01b79bce0d5266f59ad907a22f3399772c8711791
Statut : L'image est à jour pour discourse/base:aarch64
docker.io/discourse/base:aarch64
AVERTISSEMENT : Le fichier containers/web_only.yml est lisible par tous. Vous pouvez sécuriser ce fichier en exécutant : chmod o-rwx containers/web_only.yml
web_only n'a pas démarré !
./discourse-doctor peut aider à diagnostiquer le problème.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is \"*0\")
Nom d'hôte pour votre Discourse ? [discourse.example.com] :
Bonjour oui, j’utilise également Linux, pas MacOS. J’utilise une image RHEL9 complète, pas UBI, via UTM sur le M1. Le problème est donc bien lié à Linux. J’ai découvert quelques fils de discussion sur l’équipe de développement utilisant M1 après avoir publié cette PR et ce fil de discussion, mais sans approfondir, je soupçonne que cela est lié à l’équipe de développement utilisant une autre méthode pour le bootstrap ?
Est-ce que cela vaut la peine d’investir des efforts dans la production sur m1, alors qu’il n’y a pas de matériel m1 de qualité de production ? Cela ne semble pas être une bonne utilisation du temps.
Avez-vous regardé l’installation de développement ?
Je pense qu’il y a un malentendu ici. Je n’essaie pas de faire du développement sur Discourse lui-même. Je n’essaie pas non plus de faire fonctionner Discourse en production sur M1. Ce que j’essaie de faire, c’est :
Écrire du code d’automatisation pour gérer mon infrastructure
Cela inclut l’installation et la mise à niveau périodique de Discourse.
Le travail sera effectué sur mon ordinateur portable M1, en utilisant une image RHEL9 fonctionnant via UTM.
Cela implique d’avoir le code d’automatisation pour effectuer l’installation et le démarrage de Discourse dans la VM RHEL9.
Exécuter Discourse sur des serveurs basés sur Intel
Le code d’automatisation sera déployé sur un serveur basé sur RHEL pour les environnements UAT et de production.
Donc, sauf erreur de ma part, il n’y a pas de changements supplémentaires requis car je n’essaie pas de fonctionner sous MacOS. S’il y a des changements supplémentaires requis au-delà de ce qui est dans la PR, alors je suppose que je passerai à un serveur approprié pour le faire, mais est-ce le cas ? D’un autre côté, y a-t-il un problème avec la PR soumise qui pourrait bloquer sa fusion étant donné qu’elle est déjà terminée ?
Votre publication originale demande la prise en charge d’Apple M1 pour le package d’installation de production. Le problème est qu’il n’y a pas de matériel de production qui utilise les nouveaux processeurs Apple.
D’où ma question : est-il judicieux d’ajouter cette prise en charge, lorsqu’aucun scénario d’installation de production/M1 n’est possible ?
Ne serait-il pas plus judicieux de développer cela dans un environnement où votre matériel est plus représentatif du scénario d’installation final ?
Ce doit être un malentendu. J’ai dit « J’utilise le M1 pour développer l’automatisation et les outils afin de faire fonctionner Discourse » dans le message original. C’est pour développer l’automatisation, pas pour faire fonctionner Discourse.
Oui, ce serait bien de le faire fonctionner sur du matériel représentatif, mais c’est pour développer les outils nécessaires à l’installation et au démarrage de Discourse, et rien de plus. Parfois, je suis en déplacement et je veux pouvoir le faire uniquement avec mon ordinateur portable M1, sans être dépendant des machines situées dans un centre de données nécessitant une connexion VPN.
Je comprends ce que vous essayez de faire, tout ce que je dis, c’est que l’installation de production ne s’installe pas sur M1, parce que le M1 ne peut pas être utilisé en production.
Ce n’est pas tout à fait vrai, le Raspberry Pi par exemple utilise un SoC ARM, et discourse s’installe très bien, selon :
Alors, je suppose que je me suis trompé en disant que le problème venait du CPU basé sur ARM, car le problème ne concerne que le M1 ?
Quoi qu’il en soit, voici ce que j’ai fait…
Créer une nouvelle branche discourse-setup fonctionne bien avec la modification dans la PR, mais ensuite il lance le lanceur qui vérifie si j’ai le dernier code sur master. J’ai donc créé une nouvelle branche et y ai appliqué la modification. J’ai également ajouté une entrée dans /etc/hosts afin que lorsqu’il vérifie si je fonctionne sur le domaine sur lequel je dis fonctionner, le test soit réussi.
Exécuter à nouveau discourse-setup
Cette fois, cela a fonctionné, y compris le lanceur pour effectuer la compilation et le démarrage d’un conteneur.
Voici ce que je vois vers la fin de la sortie. J’ai essayé de naviguer vers http://127.0.0.1 et je ne vois qu’une page avec le nginx par défaut. Probablement que cela ne fonctionne vraiment pas après tout sur le M1 en raison d’autres problèmes. Je vais tester sur un système basé sur Intel. Bien que pour vérifier si le processus fonctionne et si nous avons quelque chose qui écoute sur le port 80 / 443, c’est bien, mais ce serait bien de pouvoir réellement servir une page.
I, [2022-06-14T15:29:42.810750 #1] INFO -- : Replacing (?-mix:#?ACCOUNT_EMAIL=.+) with ACCOUNT_EMAIL=$$ENV_LETSENCRYPT_ACCOUNT_EMAIL
in /shared/letsencrypt/account.conf
I, [2022-06-14T15:29:42.811886 #1] INFO -- : Replacing (?-mix:ssl_certificate_key.+) with ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME.key;
ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME_ecc.key;
in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812148 #1] INFO -- : Replacing (?-mix:add_header.+) with add_header Strict-Transport-Security 'max-age=63072000'; in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812430 #1] INFO -- : Replacing location @discourse { with location @discourse {
add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.813521 #1] INFO -- : > echo "Beginning of custom commands"
I, [2022-06-14T15:29:42.814803 #1] INFO -- : Beginning of custom commands
I, [2022-06-14T15:29:42.814856 #1] INFO -- : > echo "End of custom commands"
I, [2022-06-14T15:29:42.816137 #1] INFO -- : End of custom commands
I, [2022-06-14T15:29:42.818177 #1] INFO -- : Terminating async processes
I, [2022-06-14T15:29:42.819361 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 57
2022-06-14 15:29:42.819 UTC [57] LOG: received fast shutdown request
I, [2022-06-14T15:29:42.820068 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 118
118:signal-handler (1655220582) Received SIGTERM scheduling shutdown...
2022-06-14 15:29:42.829 UTC [57] LOG: aborting any active transactions
2022-06-14 15:29:42.832 UTC [57] LOG: background worker "logical replication launcher" (PID 66) exited with exit code 1
2022-06-14 15:29:42.835 UTC [61] LOG: shutting down
118:M 14 Jun 2022 15:29:42.866 # User requested shutdown...
118:M 14 Jun 2022 15:29:42.867 * Saving the final RDB snapshot before exiting.
118:M 14 Jun 2022 15:29:42.876 * DB saved on disk
118:M 14 Jun 2022 15:29:42.876 # Redis is now ready to exit, bye bye...
2022-06-14 15:29:42.958 UTC [57] LOG: database system is shut down
sha256:5f552461c03594fde4b917c0e995c5f63a777b44ee1638e0367c22a29fe1ec16
ef60feb320f8684423dcb5c3ca6062226d937cd72a642485052fa641f15cbc01
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e EMBER_CLI_PROD_ASSETS=1 -e DISCOURSE_HOSTNAME=dev.bogus.com -e DISCOURSE_DEVELOPER_EMAILS=support@bogus.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.gmail.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@bogus.com -e DISCOURSE_SMTP_PASSWORD=stupidpassword -e DISCOURSE_SMTP_DOMAIN=dev.bogus.com -e DISCOURSE_NOTIFICATION_EMAIL=noreply@dev.bogus.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h bogusdev-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f1:a1:42:8a:5f local_discourse/app /sbin/boot
0be6584a62912bae1d517882fde2a5bf61d1c39466448803be811fbd777c87a5
[root@bogusdev discourse]#
[root@bogusdev discourse]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0be6584a6291 local_discourse/app \"/sbin/boot\" 35 seconds ago Up 34 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
[root@bogusdev discourse]#
