Controlling service exposure

45 views
Skip to first unread message

anthony kulis

unread,
Nov 23, 2016, 8:55:10 AM11/23/16
to fabric8
This is probably me learning still, but I have noticed that while fabric8 is deployed to google cloud that certain starter apps get exposed while others do not. This happens when using the canary release with a testing environment pipeline. So while trying to figure out what exactly is causing the exposure, I stumbled upon the tests in KubernetesIntegrationKT.java


public class KubernetesIntegrationKT {

    @ArquillianResource
    KubernetesClient client;

    @Test
    public void testAppProvisionsRunningPods() throws Exception {
        assertThat(client).deployments().pods().isPodReadyForPeriod();
    }
}

If this test is omitted, the app is not exposed. If it is available during the integration test, the app is exposed. I was under the assumption that exposure can be controlled via yml files such that in a service yml file, exposure can be turned off or on.

  1. metadata:

  2.   labels:

  3.     expose: true

While using the camel integration starter app, adding this svc.yml file, as well with configMap and deployment (found in the microservice starter), has no effect.

Can someone please give me some pointers as to what I am doing wrong (or right), and how I can control exposure?

Thanks


James Strachan

unread,
Nov 23, 2016, 9:23:21 AM11/23/16
to anthony kulis, fabric8
So some apps have services; some don't. A typical OOTB camel app doesn't have any services; however things like Spring MVC web apps or some REST examples do.

If you have a service, then using the "expose: true" label selector tells the exposecontroller to expose it publically (otherwise it is only exposed internally inside the kubernetes cluster).

as there are various ways to do this (Ingress on kubernetes, Router on OpenShift, Node ports or Load Balancer on public clouds like GKE).


Then separate to all this there are environments (Dev / Test / Staging / Production etc). 

Right now the Test environment the pipelines tend to reserve for running tests with Arquillian:

so if you don't have any system tests; the Test environment won't be used so nothing will run; nor will anything be exposed. If you're team doesn't do any system testing in Test you could just hide the Test environment (via the Environments tab you can create/edit/delete environments on a per team basis)


Hope that helps clear some things up. Really need a better overview/terminology docs!


 

Thanks


--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
James
-------
Red Hat

Twitter: @jstrachan
Email: james.s...@gmail.com
Blog: https://medium.com/@jstrachan/

open source microservices platform

anthony kulis

unread,
Nov 23, 2016, 9:48:53 AM11/23/16
to fabric8, anthon...@gmail.com

James, thanks for the quick reply, let me try to clarify a bit. I hope this helps you understand what I am missing. 

On Wednesday, November 23, 2016 at 8:23:21 AM UTC-6, James Strachan wrote:


On 23 November 2016 at 13:55, anthony kulis <anthon...@gmail.com> wrote:
This is probably me learning still, but I have noticed that while fabric8 is deployed to google cloud that certain starter apps get exposed while others do not. This happens when using the canary release with a testing environment pipeline. So while trying to figure out what exactly is causing the exposure, I stumbled upon the tests in KubernetesIntegrationKT.java


public class KubernetesIntegrationKT {

    @ArquillianResource
    KubernetesClient client;

    @Test
    public void testAppProvisionsRunningPods() throws Exception {
        assertThat(client).deployments().pods().isPodReadyForPeriod();
    }
}

If this test is omitted, the app is not exposed. If it is available during the integration test, the app is exposed. I was under the assumption that exposure can be controlled via yml files such that in a service yml file, exposure can be turned off or on.

  1. metadata:

  2.   labels:

  3.     expose: true

While using the camel integration starter app, adding this svc.yml file, as well with configMap and deployment (found in the microservice starter), has no effect.

Can someone please give me some pointers as to what I am doing wrong (or right), and how I can control exposure?


So some apps have services; some don't. A typical OOTB camel app doesn't have any services; however things like Spring MVC web apps or some REST examples do.

OOTB starter camel integration app gets deployed as service. Sorry if terminology is incorrect, I am only using the GUI as a reference point here. When deployed with a pipeline that has a testing environment, go into that environment, and go to services, the camel app is listed as such.  


If you have a service, then using the "expose: true" label selector tells the exposecontroller to expose it publically (otherwise it is only exposed internally inside the kubernetes cluster).

My confusion comes from the fact that if I set "expose: false" in the microservice starter at /src/main/fabric8/svc.yml and run the build again, it has no effect. The app remains exposed. This is where I get confused. Once the app rebuilds, it is still exposed. Are we to then manually use kubectl to then unexpose the service even if we update the config? Also that if we look at the camel starter app it has completely different configuration than the microservice app and does not have anything in the config that says "expose: true", or at least as obvious to this newb as found in the microservice. The only thing that is similar between the two that controls exposure is the KubernetesIntegrationKT test and this obviously seems awkward, and hence why I am asking what I should be looking at instead.


as there are various ways to do this (Ingress on kubernetes, Router on OpenShift, Node ports or Load Balancer on public clouds like GKE).


Then separate to all this there are environments (Dev / Test / Staging / Production etc). 

Right now the Test environment the pipelines tend to reserve for running tests with Arquillian:

so if you don't have any system tests; the Test environment won't be used so nothing will run; nor will anything be exposed. If you're team doesn't do any system testing in Test you could just hide the Test environment (via the Environments tab you can create/edit/delete environments on a per team basis)

I think I get that, my point was that this test was the only way I "could" control exposure, that the yml files found in /src/main/fabric8 had no effect. 
 

Hope that helps clear some things up. Really need a better overview/terminology docs!


 

Thanks


--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

James Strachan

unread,
Nov 23, 2016, 9:59:30 AM11/23/16
to anthony kulis, fabric8
On 23 November 2016 at 14:48, anthony kulis <anthon...@gmail.com> wrote:

James, thanks for the quick reply, let me try to clarify a bit. I hope this helps you understand what I am missing. 

On Wednesday, November 23, 2016 at 8:23:21 AM UTC-6, James Strachan wrote:


On 23 November 2016 at 13:55, anthony kulis <anthon...@gmail.com> wrote:
This is probably me learning still, but I have noticed that while fabric8 is deployed to google cloud that certain starter apps get exposed while others do not. This happens when using the canary release with a testing environment pipeline. So while trying to figure out what exactly is causing the exposure, I stumbled upon the tests in KubernetesIntegrationKT.java


public class KubernetesIntegrationKT {

    @ArquillianResource
    KubernetesClient client;

    @Test
    public void testAppProvisionsRunningPods() throws Exception {
        assertThat(client).deployments().pods().isPodReadyForPeriod();
    }
}

If this test is omitted, the app is not exposed. If it is available during the integration test, the app is exposed. I was under the assumption that exposure can be controlled via yml files such that in a service yml file, exposure can be turned off or on.

  1. metadata:

  2.   labels:

  3.     expose: true

While using the camel integration starter app, adding this svc.yml file, as well with configMap and deployment (found in the microservice starter), has no effect.

Can someone please give me some pointers as to what I am doing wrong (or right), and how I can control exposure?


So some apps have services; some don't. A typical OOTB camel app doesn't have any services; however things like Spring MVC web apps or some REST examples do.

OOTB starter camel integration app gets deployed as service.

the kubernetes term for an app is a "Deployment" which then creates one ore more Pods (using a ReplicaSet per version of the Deployment for rollouts (rolling upgrades).

I guess concentually this would be an integration service of sorts - but I ws using "service" to mean Kubernetes Service resource:

admittedly thats a bad term that kubernetes used - it really means a "one or more ports you can talk to in a group of pods"



Sorry if terminology is incorrect, I am only using the GUI as a reference point here. When deployed with a pipeline that has a testing environment, go into that environment, and go to services, the camel app is listed as such.  


If you have a service, then using the "expose: true" label selector tells the exposecontroller to expose it publically (otherwise it is only exposed internally inside the kubernetes cluster).

My confusion comes from the fact that if I set "expose: false" in the microservice starter at /src/main/fabric8/svc.yml and run the build again, it has no effect.

Once a service has been exposed; right now exposecontroller doesn't un-expose the service. I guess it could do though as it can check what it exposed and annotate/label it accordingly.
I've raised an issue for this:

 
The app remains exposed. This is where I get confused. Once the app rebuilds, it is still exposed. Are we to then manually use kubectl to then unexpose the service even if we update the config? Also that if we look at the camel starter app it has completely different configuration than the microservice app and does not have anything in the config that says "expose: true", or at least as obvious to this newb as found in the microservice.

This is because camel quickstarts don't usually listen on a port OOTB; so there's no kubernetes 'network service' to talk to. Rather camel talks to other things.


 
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

anthony kulis

unread,
Nov 23, 2016, 10:07:41 AM11/23/16
to fabric8, anthon...@gmail.com


On Wednesday, November 23, 2016 at 8:59:30 AM UTC-6, James Strachan wrote:


On 23 November 2016 at 14:48, anthony kulis <anthon...@gmail.com> wrote:

James, thanks for the quick reply, let me try to clarify a bit. I hope this helps you understand what I am missing. 

On Wednesday, November 23, 2016 at 8:23:21 AM UTC-6, James Strachan wrote:


On 23 November 2016 at 13:55, anthony kulis <anthon...@gmail.com> wrote:
This is probably me learning still, but I have noticed that while fabric8 is deployed to google cloud that certain starter apps get exposed while others do not. This happens when using the canary release with a testing environment pipeline. So while trying to figure out what exactly is causing the exposure, I stumbled upon the tests in KubernetesIntegrationKT.java


public class KubernetesIntegrationKT {

    @ArquillianResource
    KubernetesClient client;

    @Test
    public void testAppProvisionsRunningPods() throws Exception {
        assertThat(client).deployments().pods().isPodReadyForPeriod();
    }
}

If this test is omitted, the app is not exposed. If it is available during the integration test, the app is exposed. I was under the assumption that exposure can be controlled via yml files such that in a service yml file, exposure can be turned off or on.

  1. metadata:

  2.   labels:

  3.     expose: true

While using the camel integration starter app, adding this svc.yml file, as well with configMap and deployment (found in the microservice starter), has no effect.

Can someone please give me some pointers as to what I am doing wrong (or right), and how I can control exposure?


So some apps have services; some don't. A typical OOTB camel app doesn't have any services; however things like Spring MVC web apps or some REST examples do.

OOTB starter camel integration app gets deployed as service.

the kubernetes term for an app is a "Deployment" which then creates one ore more Pods (using a ReplicaSet per version of the Deployment for rollouts (rolling upgrades).

I guess concentually this would be an integration service of sorts - but I ws using "service" to mean Kubernetes Service resource:

admittedly thats a bad term that kubernetes used - it really means a "one or more ports you can talk to in a group of pods"

Thanks! Im learning this, so that will help! 

Sorry if terminology is incorrect, I am only using the GUI as a reference point here. When deployed with a pipeline that has a testing environment, go into that environment, and go to services, the camel app is listed as such.  


If you have a service, then using the "expose: true" label selector tells the exposecontroller to expose it publically (otherwise it is only exposed internally inside the kubernetes cluster).

My confusion comes from the fact that if I set "expose: false" in the microservice starter at /src/main/fabric8/svc.yml and run the build again, it has no effect.

Once a service has been exposed; right now exposecontroller doesn't un-expose the service. I guess it could do though as it can check what it exposed and annotate/label it accordingly.
I've raised an issue for this:

That would make sense. I think that is what I trying to get to understand. Knowing that will help me go forward. I was using the starters provided as a launching point to learn. 
Reply all
Reply to author
Forward
0 new messages