Résolution de localhost (localhost)… ::1, 127.0.0.1
Connexion à localhost (localhost)|::1|:80… connecté.
requête HTTP transmise, en attente de la réponse… Erreur de lecture (Connexion ré-initialisée par le correspondant) dans les en-têtes.Nouvel essai.
Connexion à localhost (localhost)|::1|:80… connecté.
requête HTTP transmise, en attente de la réponse… Aucune donnée reçue.Nouvel essai
…
Je trouve dans ./log/app-stderr.log
from bin/rails:4:in <main>' /usr/local/bundle/gems/activerecord-4.2.5/lib/active_record/connection_adapters/postgresql_adapter.rb:651:in initialize’: could not connect to server: Connection refused (PG::ConnectionBad)
Is the server running on host « localhost » (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
et dans ./log/worker-stderr.log
could not connect to server: Connection refused
Is the server running on host « localhost » (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host « localhost » (127.0.0.1) and accepting
TCP/IP connections on port 5432?
d’ou peux provenir ce refus de connexion (c’est identique sur le compte root et utilisateur) ?
Je ne suis plus tout à fait sur le même sujet, mais dans sa continuité,
est-ce que je change de sujet?
Il ne faut pas mettre 127.0.0.1 mais les adresses ou les noms de tes containers respectifs pour postgre / redis / elasticsearch.
A savoir que les valeurs par défaut devraient fonctionner correctement sans modification :
docker-compose run --rm fabmanager bundle exec rake db:setup
docker-compose run --rm fabmanager bundle exec rake assets:precompile
docker-compose run --rm fabmanager bundle exec rake fablab:es_build_stats
docker-compose up -d
docker-compose ps
Les fichiers /log semblent bon, puis $ sudo wget localhost:3000
et cela dans les log
app-stderr.log
/usr/src/app/app/controllers/users/omniauth_callbacks_controller.rb:4:in <class:OmniauthCallbacksController>': undefined method strategy_name’ for #AuthProvider::SimpleAuthProvider:0x00000008c60e00> (NoMethodError) worker-stderr.log
undefined method `strategy_name’ for #AuthProvider::SimpleAuthProvider:0x00000009959d00> supervisord.log
WARN Included extra file « /etc/supervisor/conf.d/fablab.conf » during parsing
(aucune trace de ce fichier à cet endroit ?)
mon fichier index.html donne comme résultat
-ERR wrong number of arguments for ‹ get › command
-ERR unknown command ‹ User-Agent: ›
-ERR unknown command ‹ Accept: ›
-ERR unknown command ‹ Accept-Encoding: ›
-ERR unknown command ‹ Host: ›
-ERR unknown command ‹ Connection: ›
et j’ai repris la configuration initiale
désolé pour la loop !-)
ai-je un endroit ou chercher mes erreurs ?
Je me permets de rester sur le même topic, avec un problème d’accès au port 3000.
J’ai réinstaller un système ubuntu xenial avec installation de docker et docker-compose
pas de compte utilisateur dans le groupe docker
et repris une installation complète avec les fichiers de configuration :
./config/env # avec le paramétrage vu ensemble précédemment
./config/nginx/fabmanager.conf # sans ssl
./docker-compose.yml
j’obtiens avec
$ curl -i 127.0.0.1:3000
curl: (7) Failed to connect to 127.0.0.1 port 3000: Connexion refusée
et
$ curl -i 127.0.0.1
un résultat en html : We’re sorry, but something went wrong. If you are the application owner check the logs for more information.
pour informations :
$ docker-compose ps
fabmanager_elasticsearch_1 /docker-entrypoint.sh elas … Up 9200/tcp, 9300/tcp
fabmanager_fabmanager_1 /usr/bin/supervisord Up 3000/tcp
fabmanager_nginx_1 nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp
fabmanager_postgres_1 docker-entrypoint.sh postgres Up 5432/tcp
fabmanager_redis_1 docker-entrypoint.sh redis … Up 6379/tcp
Le résultat de ces commandes devrait se trouver dans app-stdout.log (ou app-stderr.log s’il y a eu des erreurs). Dans tous les cas, il y a 3 commandes à lancer, il ne faut pas oublier (en remplaçant les xxx) :
Sans relance up
$ docker-compose ps a comme réponse :
fabmanager_elasticsearch_1 /docker-entrypoint.sh elas … Up 9200/tcp, 9300/tcp
fabmanager_postgres_1 docker-entrypoint.sh postgres Up 5432/tcp
fabmanager_redis_1 docker-entrypoint.sh redis … Up 6379/tcp
Comme cela, ça devrait marcher. Par ailleurs, tu peux supprimer les variables ADMIN_EMAIL et ADMIN_PASSWORD de ton fichier env, elles ne servent à rien à cet endroit, et c’est mieux en terme de sécurité …
modification du fichier de conf env
et résultat de cette 3eme commande corrigée :
Creating network « fabmanager_default » with the default driver
Creating fabmanager_redis_1
Creating fabmanager_postgres_1
Creating fabmanager_elasticsearch_1
[ActiveJob] Enqueued ActionMailer::DeliveryJob (Job ID: ad7de28e-16a9-4c71-b5fe-5dec75e4cc22) to Sidekiq(mailers) with arguments: « NotificationsMailer », « send_mail_by », « deliver_now », gid://fablab/Notification/1
suivi de :
docker-compose run --rm fabmanager bundle exec rake assets:precompile
docker-compose run --rm fabmanager bundle exec rake fablab:es_build_stats
j’ai un résultat html $ wget localhost (ça chauffe !-))
et sur $ wget localhost:3000
Connexion à localhost (localhost)|::1|:3000… échec : Connexion refusée.
Connexion à localhost (localhost)|127.0.0.1|:3000… échec : Connexion refusée.
J’ai relancé les commandes avec le fichier env selon les conseils de Sylvain
mais je me retrouve avec les mêmes résultats sur $ wget localhost et $ wget localhost:3000
pour informations :
$ docker-compose ps
fabmanager_elasticsearch_1 /docker-entrypoint.sh elas … Up 9200/tcp, 9300/tcp
fabmanager_fabmanager_1 /usr/bin/supervisord Up 3000/tcp
fabmanager_nginx_1 nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp
fabmanager_postgres_1 docker-entrypoint.sh postgres Up 5432/tcp
fabmanager_redis_1 docker-entrypoint.sh redis … Up 6379/tcp
access.log
172.18.0.1 - - [15/Nov/2017:09:53:17 +0000] « GET / HTTP/1.1 » 200 5213 « - » « Wget/1.17.1 (linux-gnu) » « - »
ip de mon serveur : 172.16.1.35
app-stdout.log
Puma starting in single mode…
Environment: production
Listening on tcp://0.0.0.0:3000
Started GET « / » for 172.18.0.6 at 2017-11-15 09:53:17 +0000
Processing by ApplicationController#index as / Rendered application/index.html.erb (5.6ms)
Completed 200 OK in 7ms (Views: 4.8ms | ActiveRecord: 1.3ms | Elasticsearch: 0.0ms)
oui 2 commandes que je n’hésite pas à refaire
qui me laisse sur
$ wget localhost:3000
Résolution de localhost (localhost)… ::1, 127.0.0.1
Connexion à localhost (localhost)|::1|:3000… échec : Connexion refusée.
Connexion à localhost (localhost)|127.0.0.1|:3000… échec : Connexion refusée.
idem avec $ curl localhost:3000
curl: (7) Failed to connect to localhost port 3000: Connexion refusée
je m’interroge sur les 2 ip présent dans mes logs (voir ci-dessus) access.log et app-stout.log
qui évoque 172.18.0.1 et 172.18.0.6 alors que mon ip serveur est 172.16.1.35
je trouve dans var/log/kern.log
flfabmanager kernel: [91200.199666] IPv6: ADDRCONF(NETDEV_UP): vethd527091: link is not ready
flfabmanager kernel: [91200.199672] br-56ae0fe752bb: port 5(vethd527091) entered forwarding state
flfabmanager kernel: [91200.387871] eth0: renamed from vethebac62b
flfabmanager kernel: [91200.399834] IPv6: ADDRCONF(NETDEV_CHANGE): vethd527091: link becomes ready
flfabmanager kernel: [91213.487452] br-56ae0fe752bb: port 1(veth623a4c1) entered forwarding state
…
est-ce normal que des interfaces réseaux complémentaires soient créés ?
$ ifconfig
br-56ae0fe752bb Link encap:Ethernet HWaddr 02:42:3e:a9:a3:3f
inet adr:172.18.0.1 Bcast:0.0.0.0 Masque:255.255.0.0
adr inet6: fe80::42:3eff:fea9:a33f/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 docker0 Link encap:Ethernet HWaddr 02:42:92:3b:5c:6d
inet adr:172.17.0.1 Bcast:0.0.0.0 Masque:255.255.0.0 ens160 Link encap:Ethernet HWaddr 00:50:56:93:7a:0c
inet adr:172.16.1.35 Bcast:172.16.1.255 Masque:255.255.255.0 lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte veth623a4c1 Link encap:Ethernet HWaddr 02:d2:a7:6e:70:1e
adr inet6: fe80::d2:a7ff:fe6e:701e/64 Scope:Lien veth9623ce4 Link encap:Ethernet HWaddr 92:fd:ad:b6:70:74
adr inet6: fe80::90fd:adff:feb6:7074/64 Scope:Lien vetha57fd13 Link encap:Ethernet HWaddr de:1c:09:b6:fd:3b
adr inet6: fe80::dc1c:9ff:feb6:fd3b/64 Scope:Lien vethc6f0143 Link encap:Ethernet HWaddr 4a:ed:4e:9f:63:dc
adr inet6: fe80::48ed:4eff:fe9f:63dc/64 Scope:Lien vethd527091 Link encap:Ethernet HWaddr d6:b9:62:95:e9:f0
adr inet6: fe80::d4b9:62ff:fe95:e9f0/64 Scope:Lien
Je viens de me rendre compte que je t’ai dis une bêtise, pour mettre fab-manager sur le port 3000, il faut plutôt écrire :
Désolé
Et pour répondre à ta question, oui c’est normal que des interfaces réseau soient créées, c’est comme ça que tes containers communiquent entre eux (172.18.0.1 et 172.18.0.6 sont les IP de tes containers sur ces interfaces)