New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using SSL at Docker #181

Closed
senj opened this Issue Jan 28, 2016 · 31 comments

Comments

Projects
None yet
5 participants
@senj

senj commented Jan 28, 2016

Hi,

if I'm using SSL in Docker, do I have to change something at the ambassador? change the host to https://ambassador or sth.?

SSL in config for tyk but not for tyk_analytics:

  • portal works on https
  • test API "could not get any response"
  • API dashboard works http

SSL in config for tyk_analytics but not for tyk:

  • portal http and just a white page
  • test API works on http
  • API dashboard works https

SSL in config for both:

  • portal https and just a white page
  • test API could not get any response
  • API dashbaord works https

I trust the certificates on my client but not in my container.. ?

Greetings..

@lonelycode

This comment has been minimized.

Show comment
Hide comment
@lonelycode

lonelycode Jan 28, 2016

Member

I would suggest to not run the docker components together but split them out and use publicly addressable network IP's / hostnames to target them instead of plumbing the containers together through the ambassador proxy. They aren't really meant to be run together like they are in the quick start, that's a kludge to make it nice and easy to get started with.

Here's an idea, but I'm not sure exactly if it will work:

  1. Put SSL certs for portal domain and for gateway in the tyk.conf since (in the quickstart), it is proxying the traffic to that component
  2. For the dashboard, you just need the cert for the dashboard, and you'll need to explicitly set the port

If you are proxying the dash via the gateway too, then you could add the cert to the tyk.conf only as it will handle the offloading.

Member

lonelycode commented Jan 28, 2016

I would suggest to not run the docker components together but split them out and use publicly addressable network IP's / hostnames to target them instead of plumbing the containers together through the ambassador proxy. They aren't really meant to be run together like they are in the quick start, that's a kludge to make it nice and easy to get started with.

Here's an idea, but I'm not sure exactly if it will work:

  1. Put SSL certs for portal domain and for gateway in the tyk.conf since (in the quickstart), it is proxying the traffic to that component
  2. For the dashboard, you just need the cert for the dashboard, and you'll need to explicitly set the port

If you are proxying the dash via the gateway too, then you could add the cert to the tyk.conf only as it will handle the offloading.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Jan 29, 2016

Contributor

For me I got this working by just configuring SSL in the gateway (with a wildcard cert for subdomains covering both the portal and dashboard), then proxying the dashboard through the gateway, as @lonelycode mentions in his last comment.

Contributor

josephearl commented Jan 29, 2016

For me I got this working by just configuring SSL in the gateway (with a wildcard cert for subdomains covering both the portal and dashboard), then proxying the dashboard through the gateway, as @lonelycode mentions in his last comment.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Jan 31, 2016

Contributor

@lonelycode Is there any way to redirect from http to https using the http_server_options ?

Contributor

josephearl commented Jan 31, 2016

@lonelycode Is there any way to redirect from http to https using the http_server_options ?

@lonelycode

This comment has been minimized.

Show comment
Hide comment
@lonelycode

lonelycode Jan 31, 2016

Member

Nope, not yet. You can do it with third party DNS like Cloudflare or whacking a web server in front of Tyk.

Member

lonelycode commented Jan 31, 2016

Nope, not yet. You can do it with third party DNS like Cloudflare or whacking a web server in front of Tyk.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 1, 2016

Contributor

Actually I'm seeing an issue. Everything works except for requesting API keys (though creating them manually in the dashboard works).

screen shot 2016-02-01 at 15 33 55

When I request a new key through the portal I see the following:

tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=warning msg="Failed to retrieve object: not found" 
tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=error msg="No menus found" 
tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=error msg="Trying to create token from cvatalogue with no auth types! No supported auth types!" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=warning msg="Failed to retrieve object: not found" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="No menus found" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Trying to create token from cvatalogue with no auth types! No supported auth types!" 
tyk-gateway_1   | 2016/02/01 15:51:21 http: TLS handshake error from 172.17.0.4:59002: tls: oversized record received with length 21536
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=warning msg="Failed create:Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Key creation failed! Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Generation error: Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 

It seems to think the catalogue at first has no supported auth types, but the API is set to auth token. Then it goes ahead and still displays the request button but when I click that there is a lot of bad SSL responses.

Actually it looks the the dashboard is hitting the HTTP endpoint, and getting back an HTTPS response. Will try changing the tyk_api_config Host to to "https://ambassador_1" at port 8080

Contributor

josephearl commented Feb 1, 2016

Actually I'm seeing an issue. Everything works except for requesting API keys (though creating them manually in the dashboard works).

screen shot 2016-02-01 at 15 33 55

When I request a new key through the portal I see the following:

tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=warning msg="Failed to retrieve object: not found" 
tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=error msg="No menus found" 
tyk-dashboard_1 | time="2016-02-01T15:51:16Z" level=error msg="Trying to create token from cvatalogue with no auth types! No supported auth types!" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=warning msg="Failed to retrieve object: not found" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="No menus found" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Trying to create token from cvatalogue with no auth types! No supported auth types!" 
tyk-gateway_1   | 2016/02/01 15:51:21 http: TLS handshake error from 172.17.0.4:59002: tls: oversized record received with length 21536
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=warning msg="Failed create:Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Key creation failed! Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 
tyk-dashboard_1 | time="2016-02-01T15:51:21Z" level=error msg="Generation error: Failed to create key: Post http://ambassador_1:8080/tyk/keys/create: malformed HTTP response \"\\x15\\x03\\x01\\x00\\x02\\x02\\x16\"" 

It seems to think the catalogue at first has no supported auth types, but the API is set to auth token. Then it goes ahead and still displays the request button but when I click that there is a lot of bad SSL responses.

Actually it looks the the dashboard is hitting the HTTP endpoint, and getting back an HTTPS response. Will try changing the tyk_api_config Host to to "https://ambassador_1" at port 8080

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 1, 2016

I'm seeing the same issue when trying to request a key.

senj commented Feb 1, 2016

I'm seeing the same issue when trying to request a key.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 1, 2016

Contributor

I tried setting the Host to https://ambassador_1 but of course my SSL certificate is not valid for that URL.
I will try generate an SSL cert to be used only for the ambassador URL, and use my cert for the dashboard and portal URLs.

Contributor

josephearl commented Feb 1, 2016

I tried setting the Host to https://ambassador_1 but of course my SSL certificate is not valid for that URL.
I will try generate an SSL cert to be used only for the ambassador URL, and use my cert for the dashboard and portal URLs.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 1, 2016

Contributor

OK I got it working. I am serving all components from subdomains (e.g. dashboard.mydomain.com, portal.mydomain.com) using a wildcard SSL.

So I need to use the Ambassador with HTTPS, but in order to do that I need the Ambassador to be at a URL which has my domain in.

So I created a new DNS entry valid with that SSL certificate pointing to the machine running Docker (e.g. name it ambassador.mydomain.com) The reason for adding a new DNS entry is my Dashboard and Portal are bound to the others.

Then in my tyk_api_config I changed the host and port to be

"Host": "https://ambassador.mydomain.com",
"Port": "80"

I changed port 8080 to 80 so I did not have to expose port 8080 on the machine.

Requesting API keys then works fine.

The downside of this is not all traffic travels within the Docker network, but since it is protected with HTTPS it should be fine.

Contributor

josephearl commented Feb 1, 2016

OK I got it working. I am serving all components from subdomains (e.g. dashboard.mydomain.com, portal.mydomain.com) using a wildcard SSL.

So I need to use the Ambassador with HTTPS, but in order to do that I need the Ambassador to be at a URL which has my domain in.

So I created a new DNS entry valid with that SSL certificate pointing to the machine running Docker (e.g. name it ambassador.mydomain.com) The reason for adding a new DNS entry is my Dashboard and Portal are bound to the others.

Then in my tyk_api_config I changed the host and port to be

"Host": "https://ambassador.mydomain.com",
"Port": "80"

I changed port 8080 to 80 so I did not have to expose port 8080 on the machine.

Requesting API keys then works fine.

The downside of this is not all traffic travels within the Docker network, but since it is protected with HTTPS it should be fine.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 1, 2016

Contributor

I think it should be possible with just https://ambassador_1, if you change your SSL config to:

"http_server_options": {
    "use_ssl": true,
    "server_name": "*.mydomain.com",
    "min_version": 2,
    "certificates": [
      {
        "domain_name": "*.mydomain.com",
        "cert_file": "/opt/tyk-gateway/ssl/mydomain.crt",
        "key_file": "/opt/tyk-gateway/ssl/mydomain.key"
      },
      {
        "domain_name": "*",
        "cert_file": "/opt/tyk-gateway/ssl/selfsigned.crt",
        "key_file": "/opt/tyk-gateway/ssl/selfsigned.key"
      }
    ]
  }

So a different SSL cert is used for the ambassador_1. Will give it a try later on.

Contributor

josephearl commented Feb 1, 2016

I think it should be possible with just https://ambassador_1, if you change your SSL config to:

"http_server_options": {
    "use_ssl": true,
    "server_name": "*.mydomain.com",
    "min_version": 2,
    "certificates": [
      {
        "domain_name": "*.mydomain.com",
        "cert_file": "/opt/tyk-gateway/ssl/mydomain.crt",
        "key_file": "/opt/tyk-gateway/ssl/mydomain.key"
      },
      {
        "domain_name": "*",
        "cert_file": "/opt/tyk-gateway/ssl/selfsigned.crt",
        "key_file": "/opt/tyk-gateway/ssl/selfsigned.key"
      }
    ]
  }

So a different SSL cert is used for the ambassador_1. Will give it a try later on.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 1, 2016

Contributor

OK I got this working without having to leave the Docker network.

  1. Generate a self signed cert for the CN ambassador_1

  2. In your tyk-gateway.conf file add both your own cert and the self signed cert for ambassador_1

"http_server_options": {
    "use_ssl": true,
    "server_name": "*.mydomain.com",
    "min_version": 2,
    "certificates": [
      {
        "domain_name": "*.mydomain.com",
        "cert_file": "/opt/tyk-gateway/ssl/mydomain.crt",
        "key_file": "/opt/tyk-gateway/ssl/mydomain.key"
      },
      {
        "domain_name": "ambassador_1",
        "cert_file": "/opt/tyk-gateway/ssl/ambassador_1.crt",
        "key_file": "/opt/tyk-gateway/ssl/ambassador_1.key"
      }
    ]
  }
  1. You will need to create a Dockerfile which extends tyk-dashboard and install the ambassador_1.crt as a trusted cert, you can do that with
ADD ambassador_1.crt /usr/local/share/ca-certificates/ambassador_1.crt

RUN update-ca-certificates
  1. In your tyk-dashboard.conf set your api_config to include https
  "tyk_api_config": {
    "Host": "https://ambassador_1",
    "Port": "8080",
    "Secret": "352d20ee67be67f6340b4c0605b044b7"
  },
  1. Change your Docker compose to use your custom version of tyk-dashboard with the SSL cert installed
Contributor

josephearl commented Feb 1, 2016

OK I got this working without having to leave the Docker network.

  1. Generate a self signed cert for the CN ambassador_1

  2. In your tyk-gateway.conf file add both your own cert and the self signed cert for ambassador_1

"http_server_options": {
    "use_ssl": true,
    "server_name": "*.mydomain.com",
    "min_version": 2,
    "certificates": [
      {
        "domain_name": "*.mydomain.com",
        "cert_file": "/opt/tyk-gateway/ssl/mydomain.crt",
        "key_file": "/opt/tyk-gateway/ssl/mydomain.key"
      },
      {
        "domain_name": "ambassador_1",
        "cert_file": "/opt/tyk-gateway/ssl/ambassador_1.crt",
        "key_file": "/opt/tyk-gateway/ssl/ambassador_1.key"
      }
    ]
  }
  1. You will need to create a Dockerfile which extends tyk-dashboard and install the ambassador_1.crt as a trusted cert, you can do that with
ADD ambassador_1.crt /usr/local/share/ca-certificates/ambassador_1.crt

RUN update-ca-certificates
  1. In your tyk-dashboard.conf set your api_config to include https
  "tyk_api_config": {
    "Host": "https://ambassador_1",
    "Port": "8080",
    "Secret": "352d20ee67be67f6340b4c0605b044b7"
  },
  1. Change your Docker compose to use your custom version of tyk-dashboard with the SSL cert installed
@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 1, 2016

Great work, will try this tomorrow, thanks for sharing.

senj commented Feb 1, 2016

Great work, will try this tomorrow, thanks for sharing.

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 1, 2016

Maybe I'm late to the discussion but I took a shortcut and configured a reverse proxy in front of the Dashboard/Gateway. The admin looks like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/domain-bundle.crt;
    ssl_certificate_key /etc/ssl/private/domain-private.key;

    server_domain dashboard-server;

    location / {
        proxy_pass http://tyk_dashboard:3000;
    }
}

and this is the config for the gateway:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/domain-bundle.crt;
    ssl_certificate_key /etc/ssl/private/domain-private.key;

    server_name gateway-server;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

the reverse proxy is also running on a container. I'm using this setup for our staging environment and it seems to do the job ;)

yoanisgil commented Feb 1, 2016

Maybe I'm late to the discussion but I took a shortcut and configured a reverse proxy in front of the Dashboard/Gateway. The admin looks like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/domain-bundle.crt;
    ssl_certificate_key /etc/ssl/private/domain-private.key;

    server_domain dashboard-server;

    location / {
        proxy_pass http://tyk_dashboard:3000;
    }
}

and this is the config for the gateway:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/domain-bundle.crt;
    ssl_certificate_key /etc/ssl/private/domain-private.key;

    server_name gateway-server;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

the reverse proxy is also running on a container. I'm using this setup for our staging environment and it seems to do the job ;)

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 2, 2016

As we also want an http cache in front of the gateway this seems to be a viable solution.

Can you please explain

 server_domain dashboard-server;

what is dashboard-server / gateway-server?

Is domain-bundle a wildcard certificate / on which CN / are they in the trusted store?

Does this

proxy_set_header Host $host; 

influences the routing at the gateway? i want to use path based routing.

Thanks ..

senj commented Feb 2, 2016

As we also want an http cache in front of the gateway this seems to be a viable solution.

Can you please explain

 server_domain dashboard-server;

what is dashboard-server / gateway-server?

Is domain-bundle a wildcard certificate / on which CN / are they in the trusted store?

Does this

proxy_set_header Host $host; 

influences the routing at the gateway? i want to use path based routing.

Thanks ..

@JnMik

This comment has been minimized.

Show comment
Hide comment
@JnMik

JnMik Feb 2, 2016

@senj

proxy_set_header Host $host; tell the reverse-proxy to forward the client "Header: host" to the backend server

gateway-server and dashboard-server are only hostnames that Yoanis use on his machine, they are proxied to tyk_dashboard:3000 and gateway:8000 respectively.

JnMik commented Feb 2, 2016

@senj

proxy_set_header Host $host; tell the reverse-proxy to forward the client "Header: host" to the backend server

gateway-server and dashboard-server are only hostnames that Yoanis use on his machine, they are proxied to tyk_dashboard:3000 and gateway:8000 respectively.

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 2, 2016

roger that. it's nice to have some more info on this topic now.

senj commented Feb 2, 2016

roger that. it's nice to have some more info on this topic now.

@senj senj closed this Feb 2, 2016

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 2, 2016

@senj

Yes, these are wildcard certificates. So for instance if you own mydomain.com for which you also have wildcard certificates, the configuration will look like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_domain admin.mydomain.com;

    location / {
        proxy_pass http://tyk_dashboard:3000;
    }
}

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_name gateway.mydomain.com;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

You're not forced to use wildcard certificates, as they also cost a little more money, as long as they are valid for the domains declared Nginx's directive server_name. As for proxy_pass and proxy_header notice they are only preset for the gateway configuration, which is the one responsible for forwarding API calls. The reason I went for this is because I'm using the domain listen option when defining my API(s). I guess you can just remove those instructions if you're just using the listen paths option.

Anyhow this is just my 2 cents on the subject.I find it a bit more easier to deal with and as you said you gain a lot by having Nginx taking care of performing SSL termination, cache, logging and all the cool stuff it comes with ;).

yoanisgil commented Feb 2, 2016

@senj

Yes, these are wildcard certificates. So for instance if you own mydomain.com for which you also have wildcard certificates, the configuration will look like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_domain admin.mydomain.com;

    location / {
        proxy_pass http://tyk_dashboard:3000;
    }
}

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_name gateway.mydomain.com;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

You're not forced to use wildcard certificates, as they also cost a little more money, as long as they are valid for the domains declared Nginx's directive server_name. As for proxy_pass and proxy_header notice they are only preset for the gateway configuration, which is the one responsible for forwarding API calls. The reason I went for this is because I'm using the domain listen option when defining my API(s). I guess you can just remove those instructions if you're just using the listen paths option.

Anyhow this is just my 2 cents on the subject.I find it a bit more easier to deal with and as you said you gain a lot by having Nginx taking care of performing SSL termination, cache, logging and all the cool stuff it comes with ;).

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 5, 2016

Thanks for you configs, I got it working now! Just adding the portal configs

 server_name portal.mydomain.net;

    location /portal-assets/ {
        proxy_pass http://mydomain:3000/portal-assets/;
        proxy_pass_request_headers      on;
    }

    location / {
        proxy_pass http://mydomain:8080/portal/;
        proxy_pass_request_headers      on;
        # proxy_set_header Host            $host;
        # proxy_set_header X-Forwarded-For $remote_addr;
    }

senj commented Feb 5, 2016

Thanks for you configs, I got it working now! Just adding the portal configs

 server_name portal.mydomain.net;

    location /portal-assets/ {
        proxy_pass http://mydomain:3000/portal-assets/;
        proxy_pass_request_headers      on;
    }

    location / {
        proxy_pass http://mydomain:8080/portal/;
        proxy_pass_request_headers      on;
        # proxy_set_header Host            $host;
        # proxy_set_header X-Forwarded-For $remote_addr;
    }
@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 5, 2016

@senj

If you configure your gateway like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_name gateway.mydomain.com;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

then you should be able to see at https://gateway.mydomain.com/portal/ (do not forget the trailing slash ;)).

@lonelycode is this setup something you would recommend for production? One of the reasons I like this is because I'd love to have Tyk deploying in production using Docker. With the addition of multi host networking and the aid of Compose I believe it should be quite easy to get Tyk up and running in production. What do you think?

yoanisgil commented Feb 5, 2016

@senj

If you configure your gateway like this:

server {
    listen   443;

    ssl    on;
    ssl_certificate /etc/ssl/certs/mydomain.com-bundle.crt;
    ssl_certificate_key /etc/ssl/private/mydomain.com-private.key;

    server_name gateway.mydomain.com;

    location / {
        proxy_pass http://gateway:8080;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

then you should be able to see at https://gateway.mydomain.com/portal/ (do not forget the trailing slash ;)).

@lonelycode is this setup something you would recommend for production? One of the reasons I like this is because I'd love to have Tyk deploying in production using Docker. With the addition of multi host networking and the aid of Compose I believe it should be quite easy to get Tyk up and running in production. What do you think?

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 5, 2016

So you mean I don't have to proxy to /portal, /portal-assets etc, because the tyk gateway will handle this for me

senj commented Feb 5, 2016

So you mean I don't have to proxy to /portal, /portal-assets etc, because the tyk gateway will handle this for me

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 5, 2016

Yes. But make sure you followed the instructions here:

https://tyk.io/v1.9/setup/docker/

especially the part where you replace localhost by ambassador_1;)

yoanisgil commented Feb 5, 2016

Yes. But make sure you followed the instructions here:

https://tyk.io/v1.9/setup/docker/

especially the part where you replace localhost by ambassador_1;)

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 9, 2016

If I try this I always get an empty page (200 OK) and the logs say
http: proxy error: dial tcp 172.17.0.10:3001: getsockopt: connection refused
but only for /portal/, my other APIs are working.

If I connect to
http://ambassador_1:3001/56b9f656bc9bfb0001000001/portal/
and replace ambassador_1 with my host, it also works.

Maybe my "command" in my docker-compose is wrong? but all the -name parameters match my containers.

senj commented Feb 9, 2016

If I try this I always get an empty page (200 OK) and the logs say
http: proxy error: dial tcp 172.17.0.10:3001: getsockopt: connection refused
but only for /portal/, my other APIs are working.

If I connect to
http://ambassador_1:3001/56b9f656bc9bfb0001000001/portal/
and replace ambassador_1 with my host, it also works.

Maybe my "command" in my docker-compose is wrong? but all the -name parameters match my containers.

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 9, 2016

Weird .. @lonelycode any ideas? I followed the docker setup and everything worked as expected. Did you try starting over from scratch?

yoanisgil commented Feb 9, 2016

Weird .. @lonelycode any ideas? I followed the docker setup and everything worked as expected. Did you try starting over from scratch?

@lonelycode

This comment has been minimized.

Show comment
Hide comment
@lonelycode

lonelycode Feb 9, 2016

Member

Sorry guys, no idea... internal docker compose wiring is plain weird. I'm a big fan of traditional networking :-)

Member

lonelycode commented Feb 9, 2016

Sorry guys, no idea... internal docker compose wiring is plain weird. I'm a big fan of traditional networking :-)

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 9, 2016

@senj it looks to me like one of the containers is not running. What does your config looks like? On which container do you see the error?

yoanisgil commented Feb 9, 2016

@senj it looks to me like one of the containers is not running. What does your config looks like? On which container do you see the error?

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 9, 2016

After reading a lot of docker documentation, especially about networking, I think it's the best to remove the ambassador pattern completly and use user defined networks.
As I understood, this will remove the static (or legacy as the docs call it) linking completly and I can assign each container it's own IP address as lonelycode proposed (although it is a local one).
Because I also want to have multiple gateways in my dev environment (one for each developer) it is cleaner to separate each gateway in it's own network.
It seems there were a lot of network related changes on 1.9 / 1.10 so there is no need for ambassador anymore. I hope I can figure this out tomorrow.

senj commented Feb 9, 2016

After reading a lot of docker documentation, especially about networking, I think it's the best to remove the ambassador pattern completly and use user defined networks.
As I understood, this will remove the static (or legacy as the docs call it) linking completly and I can assign each container it's own IP address as lonelycode proposed (although it is a local one).
Because I also want to have multiple gateways in my dev environment (one for each developer) it is cleaner to separate each gateway in it's own network.
It seems there were a lot of network related changes on 1.9 / 1.10 so there is no need for ambassador anymore. I hope I can figure this out tomorrow.

@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Feb 9, 2016

Contributor

Yes - I did this locally with the 1.10 RC2 and it worked fine, was waiting for it to go gold before submitting a PR. Will submit one tomorrow.

Contributor

josephearl commented Feb 9, 2016

Yes - I did this locally with the 1.10 RC2 and it worked fine, was waiting for it to go gold before submitting a PR. Will submit one tomorrow.

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 9, 2016

@josephearl the only problem I see with that is that users will be forced to use Docker >= 1.10 (which is quite recent BTW). Anyhow that might not be a concern on a development environment, but yet seems a bit restrictive. I still don't see what went wrong with @senj 's setup though it will be nice if we could reproduce his use case.

yoanisgil commented Feb 9, 2016

@josephearl the only problem I see with that is that users will be forced to use Docker >= 1.10 (which is quite recent BTW). Anyhow that might not be a concern on a development environment, but yet seems a bit restrictive. I still don't see what went wrong with @senj 's setup though it will be nice if we could reproduce his use case.

@lonelycode

This comment has been minimized.

Show comment
Hide comment
@lonelycode

lonelycode Feb 9, 2016

Member

Yeah we had to put old compose configs in to handle naming conventions for previous versions before - not ideal.

... I think keeping things fresh is a good idea, but maybe try and make it reactive to the docker version somehow.

We could split the repo into multiple directories named after the supported docker versions, with a different compose config for each docker version.

The official docs then support latest, and then the read me in each folder can be up to date for legacy?

Just an idea...

Member

lonelycode commented Feb 9, 2016

Yeah we had to put old compose configs in to handle naming conventions for previous versions before - not ideal.

... I think keeping things fresh is a good idea, but maybe try and make it reactive to the docker version somehow.

We could split the repo into multiple directories named after the supported docker versions, with a different compose config for each docker version.

The official docs then support latest, and then the read me in each folder can be up to date for legacy?

Just an idea...

@yoanisgil

This comment has been minimized.

Show comment
Hide comment
@yoanisgil

yoanisgil Feb 9, 2016

I think that might work. However it stills bug me why 1.9 won't work for @senj ...

yoanisgil commented Feb 9, 2016

I think that might work. However it stills bug me why 1.9 won't work for @senj ...

@senj

This comment has been minimized.

Show comment
Hide comment
@senj

senj Feb 12, 2016

@josephearl any update on this?
I'm on 1.10 now and all the components are running, but I don't know what I should enter for

  • tyk_api_config => host. I tried it with my gateway alias, but if I try to create a key he can't find the value I enter there.
  • and in the API definition's target URLs at tyk dashboard.

I use the new -link feature so I can connect the components via alias (this works for redis_host) and put everything in my custom bridge-based network. E.g.:

  dashboard:
    image: tykio/tyk-dashboard:latest
    links:
     - redis:redis
     - mongo:mongo
     - gateway:gateway
    ports:
     - "3001:3000"
    volumes:
     - ./tyk_analytics.conf:/opt/tyk-dashboard/tyk_analytics.conf
    networks:
     - compose2

I wonder who calls who at that point when I try to create a new API Key.

Failed to save new session object to Tyk: Could not create key for this API ID, API doesn't exist.

senj commented Feb 12, 2016

@josephearl any update on this?
I'm on 1.10 now and all the components are running, but I don't know what I should enter for

  • tyk_api_config => host. I tried it with my gateway alias, but if I try to create a key he can't find the value I enter there.
  • and in the API definition's target URLs at tyk dashboard.

I use the new -link feature so I can connect the components via alias (this works for redis_host) and put everything in my custom bridge-based network. E.g.:

  dashboard:
    image: tykio/tyk-dashboard:latest
    links:
     - redis:redis
     - mongo:mongo
     - gateway:gateway
    ports:
     - "3001:3000"
    volumes:
     - ./tyk_analytics.conf:/opt/tyk-dashboard/tyk_analytics.conf
    networks:
     - compose2

I wonder who calls who at that point when I try to create a new API Key.

Failed to save new session object to Tyk: Could not create key for this API ID, API doesn't exist.
@josephearl

This comment has been minimized.

Show comment
Hide comment
@josephearl

josephearl Mar 29, 2016

Contributor

@senj yes I submitted a PR to improve the quick start a few days ago https://github.com/lonelycode/tyk_quickstart/pull/3

Contributor

josephearl commented Mar 29, 2016

@senj yes I submitted a PR to improve the quick start a few days ago https://github.com/lonelycode/tyk_quickstart/pull/3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment