I am running through the Tyk Quickstart guide on my Mac (using Docker). Followed all directions up until the point when they have you create a new API key to test the HttpBin test endpoint. I fill out the “Add Key” form via the Tyk Dashboard, and hit Create, and then it loads forever, never completing. Anyone else ever see this?
EDIT: I am noticing that my tyk_dashboard instance in Kitematic is showing “Mongo connection failed:no reachable servers”. Perhaps this is the root issue. Not sure how to proceed but will do more digging.
I have since tried to update the mongo_url setting in the tyk_analytics.conf file from “mongo” to “127.0.0.1”, “localhost”, and my docker IP, and none of those seem to fix the error.
Hi Blake,
What version of docker are you running?
It’ll be a networking issue in the container set - Docker and Docker Compose change their minds from version to version about what naming conventions to use for network aliases.
You may just need to make sure the container aliases are correct in your version of docker (I.e. Check you can access the mongo container from the dashboard) and then amend the Tyk dashboard and pump files accordingly.
Also, might be worth checking that the mongo container has started properly.
M.
Thanks for the response!
$ docker --version
Docker version 1.10.3, build 20f81dd
How would I check that I can access the mongo container from the dashboard? I can use Kitematic to open a terminal within the dashboard, but then how to I check access to mongo from there?
Ok, to test the connectivity you would need to check the internal host name by pinging it.
So for the QuickStart, mongo is meant to just be on “mongo”
So you just
ping mongo
ping appears to be working from the gateway to mongo. however, the gateway log is filled with:
time=“2016-05-04T22:24:23Z” level=error msg=“Mongo connection failed:no reachable servers”
Hi Blake,
What’s the output of the MongoDB container? Has the process started ok?
Thanks,
Martin
Thanks Martin. Here is the container log contents:
2016-05-02T12:53:55.010+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=mongo
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] db version v3.2.4
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] git version: e*********************************************0
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] allocator: tcmalloc
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] modules: none
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] build environment:
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] distmod: debian71
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] distarch: x86_64
2016-05-02T12:53:55.011+0000 I CONTROL [initandlisten] target_arch: x86_64
2016-05-02T12:53:55.012+0000 I CONTROL [initandlisten] options: { storage: { mmapv1: { smallFiles: true } } }
2016-05-02T12:53:55.018+0000 I - [initandlisten] Detected data files in /data/db created by the ‘wiredTiger’ storage engine, so setting the active storage engine to ‘wiredTiger’.
2016-05-02T12:53:55.018+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2016-05-02T12:53:56.972+0000 W STORAGE [initandlisten] Detected configuration for non-active storage engine mmapv1 when current storage engine is wiredTiger
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten]
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is ‘always’.
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten] ** We suggest setting it to ‘never’
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten]
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is ‘always’.
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten] ** We suggest setting it to ‘never’
2016-05-02T12:53:56.972+0000 I CONTROL [initandlisten]
2016-05-02T12:53:56.984+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory ‘/data/db/diagnostic.data’
2016-05-02T12:53:56.985+0000 I NETWORK [initandlisten] waiting for connections on port 27017
2016-05-02T12:53:56.987+0000 I NETWORK [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2016-05-02T12:53:57.266+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.6:51078 #1 (1 connection now open)
2016-05-02T12:53:57.266+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.6:51079 #2 (2 connections now open)
2016-05-02T12:53:57.454+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.4:42050 #3 (3 connections now open)
2016-05-02T12:53:57.655+0000 I NETWORK [conn1] end connection 172.18.0.6:51078 (2 connections now open)
2016-05-02T12:53:57.655+0000 I NETWORK [conn2] end connection 172.18.0.6:51079 (2 connections now open)
2016-05-02T12:53:58.153+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.6:51087 #4 (2 connections now open)
2016-05-02T12:53:58.164+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.6:51088 #5 (3 connections now open)
2016-05-02T12:54:06.953+0000 I NETWORK [initandlisten] connection accepted from 172.18.0.4:42078 #6 (4 connections now open)
Ok, so it might be the config.
- You can ping mongo from inside the containers
- Mongo is running
- You managed to log into the dashboard - that requires a MongoDB connection
Can I suggest ensuring that the mongo URL is set back to being “mongo” (not localhost or anything) and instead stopping all the containers in kitematic and then doing another
docker compose up
To restart them again? This might fix the internal connectivity issues.