Upgrade tyk2.0 from older version, Also want to setup in docker

Martin,

Thanks. I have already change that and it’s appears functional. Another question regarding key creation.
With the upgrade to v2.0 from what I understand the key generation was removed from the dashboard for free licences is that correct?

Nope, Free license are fully functional. If key generation isn;t working it’s because your gateway is misconfigured :slight_smile:

But I’m using the tyk config file based on this Tyk.conf

The config is also the same that I post previously [quote=“Carlos_Carvalho, post:18, topic:763”]
For example the tyk gateway config file:

{
“listen_port”: 8080,
“node_secret”: “352d20ee67be67f6340b4c0605b044b7”,
“template_path”: “/opt/tyk-gateway/templates”,
“tyk_js_path”: “/opt/tyk-gateway/js/tyk.js”,
“middleware_path”: “/opt/tyk-gateway/middleware”,
“use_db_app_configs”: true,
“db_app_conf_options”: {
“connection_string”: “http://172.18.0.21:3000”,
“node_is_segmented”: false,
“tags”:
},
“app_path”: “/opt/tyk-gateway/apps/”,
“storage”: {
“type”: “redis”,
“host”: “172.18.0.16”,
“port”: 6379,
“username”: “”,
“password”: “”,
“database”: 0,
“optimisation_max_idle”: 100
},
“enable_analytics”: true,
“analytics_config”: {
“type”: “mongo”,
“csv_dir”: “/tmp”,
“mongo_url”: “”,
“mongo_db_name”: “”,
“mongo_collection”: “”,
“purge_delay”: -1,
“ignored_ips”:
},
“health_check”: {
“enable_health_checks”: true,
“health_check_value_timeouts”: 60
},
“optimisations_use_async_session_write”: true,
“enable_non_transactional_rate_limiter”: true,
“enable_sentinel_rate_limiter”: false,
“allow_master_keys”: false,
“policies”: {
“policy_source”: “service”,
“policy_connection_string”: “http://172.18.0.21:3000”,
“policy_record_name”: “tyk_policies”
},
“hash_keys”: true,
“close_connections”: true
}
[/quote]

What I’m missing?

I need your tyk analytics conf, not the gateway, the dashboard will call the gateway to create keys, so it needs to be able to resolve the instance.

I followed same thought process with the dashboard config but ok here you go :blush:

{
    "listen_port": 3000,
    "tyk_api_config": {
        "Host": "http://172.18.0.18",
        "Port": "8080",
        "Secret": "352d20ee67be67f6340b4c0605b044b7"
    },
    "mongo_url": "mongodb://mongo:27017/tyk_analytics",
    "page_size": 10,
    "admin_secret": "12345",
    "shared_node_secret": "352d20ee67be67f6340b4c0605b044b7",
    "redis_port": 6379,
    "redis_host": "172.18.0.16",
    "redis_password": "",
    "enable_cluster": false,
    "force_api_defaults": false,
    "notify_on_change": true,
    "license_key": "LICENSE_GOES_HERE",
    "redis_database": 0,
    "redis_hosts": null,
    "hash_keys": true,
    "email_backend": {
        "enable_email_notifications": false,
        "code": "",
        "settings": null,
        "default_from_email": "",
        "default_from_name": ""
    },
    "hide_listen_path": false,
    "sentry_code": "",
    "sentry_js_code": "",
    "use_sentry": false,
    "enable_master_keys": false,
    "enable_duplicate_slugs": true,
    "show_org_id": true,
    "host_config": {
        "enable_host_names": false,
        "disable_org_slug_prefix": true,
        "hostname": "",
        "override_hostname": "",
        "portal_domains": {},
        "portal_root_path": "/portal"
    },
    "http_server_options": {
        "use_ssl": false,
        "certificates": [
            {
                "domain_name": "",
                "cert_file": "",
                "key_file": ""
            }
        ],
        "min_version": 0
    },
    "ui": {
        "login_page": {},
        "nav": {},
        "uptime": {},
        "portal_section": null,
        "designer": {},
        "dont_show_admin_sockets": false,
        "dont_allow_license_management": false,
        "dont_allow_license_management_view": false
    },
    "home_dir": "/opt/tyk-dashboard",
    "identity_broker": {
        "enabled": false,
        "host": {
            "connection_string": "",
            "secret": ""
        }
    },
    "tagging_options": {
        "tag_all_apis_by_org": false
    }
}

Ok, so you’re tyk.conf doesn’t declare a secret to use for API calls, only one for the node heartbeat. You need to add a "secret": "352d20ee67be67f6340b4c0605b044b7" to your tyk.conf, since you’ve declared it in your dashboard configuration.

So basically, the dashboard was making a request to the gateway, with it’s API secret, but the gateway wasn’t configured with one and so defaulted to an empty string.

Hello Martin,

I have already defined the node secret in my local gateway . But still have problems when trying to generate keys for the organization. I can in dashboard to create them but I cannot create when using my api. I have the same problem a while back and I talked to you and at the time You told me to create a little timer to wait for API reload. In the previous version it was working but know it gives a null pointer exception on tyk gateway.

The previous thread link Create Organisations, Users, Api Definitions, Key - #7 by Carlos_Carvalho

The stack trace is as follows.

time=“Jun 2 09:17:50” level=info msg=“Reloading endpoints”
time=“Jun 2 09:17:50” level=info msg=“Initiating reload”
time=“Jun 2 09:17:58” level=info msg=“Reloading endpoints”
time=“Jun 2 09:17:58” level=info msg=“Reloading endpoints”
time=“Jun 2 09:18:00” level=info msg=“Detected 4 APIs”
time=“Jun 2 09:18:00” level=info msg=“–> Loading API: Admin”
time=“Jun 2 09:18:00” level=info msg=“----> Tracking: (no host)”
time=“Jun 2 09:18:00” level=info msg=“----> Checking security policy: Open”
time=“Jun 2 09:18:00” level=info msg=“–> Loading API: Services”
time=“Jun 2 09:18:00” level=info msg=“----> Tracking: (no host)”
time=“Jun 2 09:18:00” level=info msg=“----> Checking security policy: Token”
time=“Jun 2 09:18:00” level=info msg=“–> Loading API: Order Service”
time=“Jun 2 09:18:00” level=error msg=“Duplicate listen path found, skipping. API ID: 78d4811b0b1448a16aa0736a65dff00f”
time=“Jun 2 09:18:00” level=warning msg=“----> Skipped!”
time=“Jun 2 09:18:00” level=info msg=“–> Loading API: Order Service”
time=“Jun 2 09:18:00” level=error msg=“Duplicate listen path found, skipping. API ID: 609c625e6b5947b6748e94da28a6d3e6”
time=“Jun 2 09:18:00” level=warning msg=“----> Skipped!”
time=“Jun 2 09:18:00” level=info msg=“Loading uptime tests…”
time=“Jun 2 09:18:00” level=info msg=“API reload complete”
time=“Jun 2 09:18:28” level=info msg=“Reset quota for key.” inbound-key=574ff9c6dc7161002400000a3de868c888f047386dae1e273e327fe8 key=quota-700f3253
2016/06/02 09:18:28 http: panic serving 172.18.0.21:39597: runtime error: invalid memory address or nil pointer dereference
goroutine 140 [running]:
net/http.(*conn).serve.func1(0xc8203a4a00)
/usr/local/go/src/net/http/server.go:1389 +0xc1
panic(0xc90e00, 0xc820012080)
/usr/local/go/src/runtime/panic.go:426 +0x4e9
main.createKeyHandler(0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/home/tyk/go/src/github.com/lonelycode/tyk/api.go:1315 +0x141b
main.CheckIsAPIOwner.func1(0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/home/tyk/go/src/github.com/lonelycode/tyk/middleware_api_security_handler.go:24 +0xe1
net/http.HandlerFunc.ServeHTTP(0xc820133d10, 0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/usr/local/go/src/net/http/server.go:1618 +0x3a
github.com/gorilla/mux.(*Router).ServeHTTP(0xc82049c230, 0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/home/tyk/go/src/github.com/gorilla/mux/mux.go:98 +0x29e
net/http.(*ServeMux).ServeHTTP(0xc82025cdb0, 0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/usr/local/go/src/net/http/server.go:1910 +0x17d
net/http.serverHandler.ServeHTTP(0xc820444e80, 0x7f4d5be5c0f8, 0xc8202a2000, 0xc8200749a0)
/usr/local/go/src/net/http/server.go:2081 +0x19e
net/http.(*conn).serve(0xc8203a4a00)
/usr/local/go/src/net/http/server.go:1472 +0xf2e
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2137 +0x44e
root@gateway:/opt/tyk-gateway#

Thanks

Carlos Carvalho

It looks like one of your services is not being loaded (order service) - it’s right there in the logs - it has a duplicate listen path as another API

If you are creating a key for this API it will fail because t isn’t loaded.

But Martin the listen path is validated ignoring organization? I mean, if the organization is different the validation of the listen path makes sense?

No, a gateway can only listen on one path per API - Tyk Gateway itself has almost no comprehension of what an ORG is, that’s purely a Dashboard concept.

If you are going multi-tenant, then I suggest you manage the listen paths more aggressively and have them auto-assigned, there’s a setting for this, but then they become IDs and you will need to manage rewrites yourself.

Hum… ok. Different approach then…Let’s suppose that I define in the listen path or name and set the API definition accordingly.

I have noticed that on github a issue is open relating this question:

Do you foresee problems on my end if instead I put another param instead of {id} (let’s say {org}) and not strip the listen path from inbound request? Will it work? Or is more complex?

if Tyk detects two listen paths that are a string match, it will skip the latter, so a wildcard might not help here.

What are you trying to achieve? No matter what yu do you will need to differentiate an inbound request by org somehow, that’s either busy path or by domain…

I’m trying to have the same API in a multi tenant setup. I have a nginx that will balance the incoming requests for this API and redirect to tyk gateway upstream…I need to redirect to the correspondent “tenant API”

Example:

 ORG 1 Path 1
 /api/tenant1

 API Definition 1
 /api/{tenant1}


 ORG 2 Path 2
 /api/tenant2


API D1finition 2
 /api/{tenant2}

So the listen paths are different at the NGinX level? not sure I’m following here…

Two points:

First Point → Configuration and routing
Nginx will route traffic to tyk. At the moment it’s defined like so:

location /api {
	proxy_set_header Host $http_host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Scheme $scheme;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

	proxy_pass_header Server;
	proxy_pass_header Authorization;
	proxy_pass_header x-api-version;

	proxy_pass http://api-gateway;
}

What I would like in the future it’s to rewrite the proxy_pass to pass parms to the gateway upstream

Second Point → Creating API Definitions and Keys
The upstream will be the tyk gateway and I need the listen path to be dynamic so that is different and not give the error of the duplicate API Definition. If this is not possible I only see the domain approach and didn’t understand you when you said[quote=“Martin, post:34, topic:763”]
somehow, that’s either busy path or by domain…
[/quote]

Thanks Martin

Ok, so the rule is simple - same string in listen path means a skip.

So define the same API with different listen paths and have two NGinX rewrites, one for org 1 and one for org 2.

We do this with lots of multi tenant installs, because you can tightly control listen paths that way and ensure no dupes but still have dupes on the domain side.

Hum…OK . We will not be doing multiple installs on different clients. When I refer multi tenant is that our platform will have multi tenant application logic. The tenants will be incorporated in the platform. We will be leveraging the organization concept for our benefit.

The rule stil holds: one listen path per API, Tyk Gateway has no tenancy concept, you need to manage that via domains or listen paths or a combo of the two.

Multi tenancy comes from the dashboard, and it baseline assumes that you will be running tenants in different domains or listen paths.

So, you either need to give each shared listen path a different domain or you need to use unique listen paths.

To clarify this bit, I don’t mean multiple installs, I mean a single gateway and dashboard but tenants must bind their API listen paths to custom domains so that there is no overlap.

OR

You disable the listen path entry system in the UI, and set Tyk Dashboard up to force defaults, in which case listen paths are actually API IDs and then you can control which virtual tenant API to target from NGINX using a rewrite. This guarantees unique paths and allows you to control how to target those via your rewrites, it also means your tenants can’t break things by editing or adding APIs.

We actually have a service called the host manager that manages NGinX and the relebvant configurations for you.

Here’s all the relevant docs for working in tandem with NGinX:

https://tyk.io/docs/tyk-api-gateway-v1-9/configuration/working-with-nginx/

https://tyk.io/docs/tyk-api-gateway-v1-9/configuration/tyk-domains-and-url-handling/

https://tyk.io/docs/tyk-api-gateway-v1-9/host-manager/