Thursday, October 5, 2017

Ingress Routing for ICP

I have spent time this week trying to play through a few more customer scenarios with IBM Cloud Private.  The issue under test this week was related to a set of services which all want to use the same port, but need to be mapped to either different URLs OR be mapped to different paths on the same URL.  We know Kubernetes is capable of this, but is there anything different in doing this with ICP, which already has some opinions about things like which ingress controller to use?

I started with the basics and deployed a simple, containerized application into my ICP environment.  This blog post outlines some of the basics for exposing an application which is running in ICP.  In particular, I used it to help with deploying a container and the basics of exposing an app.  (For a more complete experience, I also ran through this with a node.js app which my firm wrote, built it with Jenkins and placed the image into the ICP repo.  When deploying from the ICP Docker repo, you must specify the image with the repo address like this: mycluster.icp:8500/default/helloworld:latest where the values are - <internal_cluster_url>:8500/<namespace>/<image>:<tag>)

With an application deployed, and a couple of instances running, I set out to work through the ingress configuration to make the site available in a fan-out pattern to start with.  For this exercise, I was using the apache web server, so I called the app static.  The path on which the app was to be exposed was <proxy-address>/static/.

I created an Ingress by navigating to the Applications link in the menu, and selecting the settings icon on the right side of the screen corresponding to the application I deployed.

The form to configure the ingress looked like this:


I realized there was no easy way to define path based routing.  I attempted to add the path to the url, adjusted settings in numerous fields, until ultimately I concluded this cannot happen through the ICP form interface... NO PROBLEM!  I switched on JSON mode and we were off to the races.

I navigated to my ingress record, selected Edit, and clicked the toggle at the top to manipulate my entry.

{
  "kind": "Ingress",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "name": "default-static-demo",
    "namespace": "default",
    "selfLink": "/apis/extensions/v1beta1/namespaces/default/ingresses/default-static-demo",
    "uid": "ac450ec0-aa0d-11e7-9443-0800279d0b70",
    "resourceVersion": "359332",
    "generation": 4,
    "creationTimestamp": "2017-10-05T20:42:15Z",
    "annotations": {
      "ingress.kubernetes.io/rewrite-target": "/"
    }
  },
  "spec": {
    "rules": [
      {
        "http": {
          "paths": [
            {
              "path": "/static/",
              "backend": {
                "serviceName": "default-static-demo",
                "servicePort": 80
              }
            }
          ]
        }
      }
    ]
  }
}

By appending the necessary bits and clicking submit, ICP stored my new configuration, incremented my generation number, and triggered the steps to update the configuration of my cluster to serve up my application on <host>/static/.  The rewrite directive handled relative URL rewriting and everything.

Next steps for me will be to convert this into a yaml template so I can bundle this into my next helm chart!

To make the application work for a different host (static.<host>) for example, I was able to use the form method, and place the desired URL in the hostname filed as depicted above.


No comments:

Post a Comment

Nginx Ingress Controller on Bare Metal

After many hours of reading, trial-&-error, and general frustration… I have collected a few helpful bits WRT configuring the nginx ingr...